2023/2/15 - 読み終える時間: 2 分

HCL RTist Announces Two New Releases

HCL RTist、2 つの新しいリリースを発表

2023年2月10日

著者: Mattias Mohlin / Senior Solutions Architect for HCLSoftware

HCL RTist 開発チームは、2つの新しいリリースを発表します。

• RTist 11.2 2023.04
• RTist 11.3 2023.04。

HCL RTist 11.3 は、Eclipse 2022.06 と Java 17 で動作し、現在、実稼働環境での使用を推奨しています。2022.06では、Eclipseのコアの改良に加え、CDT（C/C++ Development Tooling）とEGitの新バージョンが登場し、いくつかの重要な改良が加えられています。

CDTとEGitの改善点については、こちらのプレゼンテーションをご参照ください。What's Newプレゼンテーション

RTist特有の新機能として、Pure Virtual Operations with Bodies、Make Space Tool、Diagram Appearance Improvementが両リリースで利用可能です。各機能の詳細については、こちらをご覧ください。

ボディを使ったピュアバーチャルオペレーション

HCL RTist、2つの新リリースを発表

コードビューまたはコードエディタを使用して、純粋仮想操作の実装ボディを提供することが可能になり、モデルコンパイラによってC++に変換されます。このような実装は、再定義されたオペレーションから呼び出すことができるため、純粋な仮想オペレーションを実装すると便利な場合があります。

スペース作成ツール

ほとんどのダイアグラムで、パレットに新しい "Make Space "ツールが追加されました。このツールは、シンボルや線を図の特定のポイントから移動させ、コンテンツを追加するためのスペースを確保するために使用します。シンボルはクリックしたポイントから放射状に移動し、図に十分な空きスペースができるまでクリックし続けることができます。必要であれば、ダイアグラムのサイズを自動的に大きくして、コンテンツを配置することができます。

ダイアグラムの外観の改善

ステートマシン図において、継承された要素と再定義された要素の外観が改善されました。このような要素は、デフォルトで破線で描かれるようになりました。再定義された要素には、特別なスタイルの破線が使用され、継承された要素とより簡単に区別することができるようになりました。

継承された要素と再定義された要素の線の太さも以前より太くなりましたが、新しい環境設定「リアルタイム開発-ダイアグラム-状態図-継承された要素の外観-線幅」があり、以前の外観を好む場合は「小さい」に設定することが可能です。逆に、これらの要素をさらに強調したい場合は、環境設定を "大" に設定することができます。

RTistの新機能については、Sprint Demo YouTube Playlistにあるビデオをご覧ください。

2023/2/15 - 読み終える時間: ~1 分

API Testing Kubernetes: Transparent Remoting Using HCL OneTest の翻訳版です。

Kubernetes の API テスト - HCL OneTest を使ったトランスペアレント・リモーティング

2023年2月14日

著者: HCLSoftware - a division of HCL Technologies, fuels the Digital+ economy and fulfills clients transformative needs with AI and Automation, Data and Analytics, Digital Transformation, and Enterprise Security.

Kubernetes の API テスト - HCL OneTest を使ったトランスペアレントリモーティング 講演者: Chris Haggan, Head of Product – DevOps, HCL Software and Martin Lescuyer, HCL OneTest Product Manager

クラウドやコンテナ化された世界でのテストは、しばしば非常に困難です。テスターが直面しなければならないつらい作業の1つは、コンテナがデプロイされると、一部のAPIはアクセス可能なままかもしれませんが、他のAPI（内部のもの）にはもうアクセスできなくなることです。たとえAPIの一部がアクセス可能なままであっても、アプリケーションの外部から送信されたリクエストは、いくつかの管理レイヤーを通過しなければならない。テスターはこれらのレイヤーを取り除き、テストしたいサービスに直接リクエストを送りたいと思うかもしれない。

典型的なKubernetesアプリケーションは、通常、いくつかのコンテナと、それらのコンテナ内のサービスで構成されています。これらは通常、Egress/Ingressコントローラと多くのセキュリティレイヤーの背後に配置されているため、アプリケーションとのやり取りは、公開されているかどうかにかかわらず、アプリケーション全体のAPIに制限されます。HCL OneTest は、これらの制限に対するソリューションを提供します。HCL OneTest を使用した透過的リモーティングは、Kubernetes クラスター内の個々のサービスに、あたかもローカルであるかのように直接? Ingress コントローラーを経由するのではなく、テスターはコンテナ化されたサービスと直接対話することができるのです。

HCL Software Head of Product- DevOps の Chris Haggan と HCL OneTest Product Manager の Martin Lescuyer が、HCL OneTest を使った Transparent Remoting の仕組み、実際の使用感、そしてなぜそれがユーザーにとってそれほど重要なのかを、最新の TestGuild 自動化ポッドキャストに出演していますので聞いてください。

CTA: https://testguild.com/podcast/automation/a435-chris/

2023/2/8 - 読み終える時間: 2 分

A New Release: RTist 11.2 2022.48 の翻訳版です。

新しいリリース: HCL RTist 11.2 2022.48

2023年1月27日

著者: Mattias Mohlin / Senior Solutions Architect for HCLSoftware

HCL RTist 開発チームは、2つの新しいリリースを確定しました。

• RTist 11.2 2022.48
• RTist 11.3 2022.48です。これは、RTist 11.3 for Eclipse 2022.06 with Java 17の実験的なリリース

これらのリリースの新機能のいくつかを見てみましょう。

改良された継承の再整理

Inheritance Rearrangement ダイアログが大幅に改善され、継承の再配置によって影響を受ける参照のリストを表示することができるようになりました。各参照の処理方法を選択でき、ダイアグラム・エディター、プロジェクト・エクスプローラー、プロパティ・ビューで参照する要素を表示するように移動することが可能です。

継承の再配置ダイアログは、リファクタリング後、サブカプセル内の少なくとも1つの参照が現在のターゲット要素にバインドできない場合にのみ表示されます。すべてのターゲット要素にアクセスできる場合（新しいスーパーカプセルはすでに古いスーパーカプセルを継承しているため）、ダイアログは表示されず、継承の再配置は簡単に実行できるようになります。これは、既存の継承階層にカプセルを追加または削除する一般的なシナリオを最小限の労力で実行できるようにするための重要な改善点です。

再起動時にモデリング・エディタを自動復元する機能

新しい環境設定 Modeling - Automatically restore modeling editors on startup は、Eclipse の再起動後に以前に開いていたモデリング・エディターを自動的にリストアするように設定できます。これは、Eclipse に組み込まれたエディタのリストアの拡張であり、モデリング・エディタはワークベンチ・エディタ・エリア で通常の Eclipse エディタの後に配置されます。

MinGw 12.2

MinGw 12.2 コンパイラーは RTist で直接使用できるようになりました。このコンパイラー用のターゲット構成が提供され、以前の MinGw 8.1 用の構成を置き換えます。このコンパイラのためのプリビルドライブラリ（TargetRTS、Connexis、LibTCPServer）も利用可能です。

この作業の一環として、Connexisにおける64ビットアプリケーションのサポートも改善されました。

コンポジットステートナビゲーションの改善

継承された複合状態に移動すると、継承されたステートマシンを開くか、状態を再定義してローカルのステートマシン図を作成するかを尋ねるプロンプトが表示されます。この選択は記憶されるため、何度もプロンプトが表示されることはありません。対応する環境設定は、RealTime Development - Diagrams - State Chart - When going inside inherited composite state（リアルタイム開発 - ダイアグラム - ステート・チャート - 継承された複合状態の内部に入るとき）です。

新機能の詳細については、Sprint Demo YouTube Playlist にあるビデオをご覧ください。

2023/1/11 - 読み終える時間: 12 分

Docker Container with VersionVault Dynamic View Client Access の翻訳版です。

Docker コンテナによる VersionVault Dynamic View クライアントアクセス

はじめに

本ブログでは、HCL VersionVaultとDockerをインストールしたDockerホストに、Docker Container with Dynamic View Client Accessを提供する設定方法について説明します。これまで開発者は、1台のマシンで異なるバージョンのソフトウェアに対応する環境を構成するのは面倒な作業でした。しかし現在では、アプリのバージョンごとに「Dockerコンテナ」と呼ばれる隔離された環境を作成し、各コンテナは、開発者マシン上で同時に実行されるOSや他のコンテナの構成に影響を与えない個別の環境設定を保持することができます。このような柔軟な環境をユーザーに提供するため、HCL VersionVaultはDockerに対応するよう強化されました。

1. VersionVaultとDockerコンテナの統合のための前提条件

Linuxホスト上に以下の4つがインストールされ、稼働していることが必要です。

• HCL VersionVault バージョン2.0.1以降
• Docker
• NFSサービス
• Automounter サービス
• LinuxホストへのDockerとVersionVaultのインストール

2.1. VersionVaultのインストール

• MVFSとMVFSデバイスを共有するために、Dockerホストは最低限VersionVault 2.0.1をインストールし、VersionVaultダイナミックビュークライアントとして動作するように設定する必要があります。
• コマンドラインユーザーのソフトウェア開発ワークステーションに必要な最小数のVersionVaultコンポーネントをインストールするため、Dockerホストでは、VersionVault最小開発者用インストールのみが必要です。
• Dockerコンテナに含まれ、共有が必要な主なコンポーネントは、MVFSとview/VOBサーバーです。
• HCL VV 2.0.1をDockerホストにインストールするには、IBM Installation Manager 1.8.6、1.9.1およびその将来の修正パックを使用する必要があります。

• VV 2.0.1インストール後の "cleartool-version "コマンドのスクリーンショットを以下に掲載します。

2.2. Dockerのインストール

• VersionVault 2.0.1がインストールされたLinuxホストには、最新バージョンのDockerをインストールすることができます。以下は、Docker Engineのインストール概要のリンクで、異なるLinuxプラットフォームでのインストール手順を共有しています。

https://docs.docker.com/engine/install/

1. DockerホストへのNFSサーバとLinux Automounterのインストール

• VersionVaultは、NFSとLinuxオートカウンターを使用して、ビューやVOBストレージにアクセスします。Dockerホストシステムは、NFSとLinuxオートカウンター用に設定されている必要があります。

3.1. NFSサーバーのインストール

• このブログ記事では、RedHat OSを使用しています。以下に示すコマンドは、使用する特定のLinuxディストリビューションによって異なります。

ステップ 1：サーバーの更新とホスト名の設定

サーバーには、再起動後も有効な固定IPアドレスと固定ホスト名が必要です。

ステップ 2：NFSサーバーのインストール。

次に、LinuxホストへのNFSサーバ・パッケージのインストールです。

インストール後、nfs-serverサービスを開始し、有効にします。

ステータスが "running" と表示されるはずです。

2. Linuxオートカウンターのインストール

ステップ 1：Linuxホストにautofsをインストールします。

• AutoFSパッケージをインストールする場合、インストールプロセスでは以下のことが行われます。
• /etcディレクトリに auto.master、auto.net、auto.misc などの複数の設定ファイルを作成します。
• systemd に AutoFS サービスを作成 (Create) します。
• 「nsswitch.conf」ファイルに automount エントリを追加し、files ソースにリンクします。

ステップ 2: インストール直後、systemctl status コマンドで AutoFS サービスが起動していることを確認します。

ステップ 3: スタートアップ時に実行されるように、AutoFSサービスを有効にすることもできます。

3. Docker Host での VOB、View 作成について

• Dockerコンテナ内で使用するVOB/Viewを作成する場合、オプションを指定する必要があります。-ホスト、-hpath、-gpath を指定します。hpathとgpathは、いずれもVOB/Viewの格納ディレクトリのグローバルパス名を指定します。

例えば、ホスト名がtest_hostであるマシンにVOB/Viewを常駐させたいとします。DockerホストとVOB/Viewサーバーのホストであるtest_hostは、automounterを使用しています。

コンテナ内で使用するVOB/ViewをDockerホスト上に作成する場合は、以下のようにします。

cleartool mkview -tag testview -host dockhost -hpath /net/ dockhost /viewstg/testview.vws -gpath /net/dockhost/user/viewstg/testview.vws /net/dockhost /user/viewstg/testview.vwsを実行します。

cleartool mkvob -tag /vob/testvob -host dockhost -hpath /net/dockhost/vobstg/testvob.vbs - gpath /net/dockhost/user/vobstg/testvob.vbs /net/dockhost/user/vobstg/testvob.vbsを実行します。

VOB/View が Docker ホストまたは Docker コンテナ上に存在する場合に必要です。

Dockerコンテナでは、コンテナの設定次第でストレージもホスト名も一時的なものになるため、Dockerコンテナの外部のVOB/Viewを使用することをお勧めします。

1. サンプルのDockerコンテナ

動的なビュークライアントアクセスが可能なDockerコンテナ

• この方法では、コンテナ内にビューを作成し、VOBにアクセスして新しいファイル/ディレクトリの要素を作成したり、既存のファイル/ディレクトリの要素を変更したりすることができます。
• Docker build ディレクトリは、Dockerfile, config_ssh.sh, config_dir, docker_compose.yml から構成されています。
• Linuxのベースイメージは、Dockerホスト上で動作するVersionVaultのリリースでサポートされている必要があり、initプロセスもサポートされている必要があります。RedHatとSUSEの両社は、それぞれのレジストリでベースイメージを提供しています。
• Linuxベース・イメージには、VersionVaultを実行するために必要なすべてのパッケージが含まれていない場合があります。ユーザーは、これらのパッケージをインストールするためにコンテナを更新する必要があります。Technote 535653、887639、718343 を参照してください。
• Dynamic View Client Access 搭載コンテナに関連するDocker buildディレクトリとサンプルDockerfile、docker_compose.yml、config_ssh.sh、config_dirの詳細については、以下のリンク先を参照してください。ウィンドウ右上のResourcesドロップダウンで、"HCL VersionVault and Docker Containers"という記事へのリンクを探します。

https://www.hcltechsw.com/versionvault

2. 最終的な統合の実行

• Dockerfile と docker_compose.yml ファイルが必要な設定内容で作成されたら、Docker build ディレクトリに移動して、以下のコマンドを実行してコンテナを構築・実行する必要があります。引数"-d "は、コンテナをデタッチャブルモードで実行するために使用されます。

• 上記のコマンドは、サービス用のコンテナのビルド、（再）作成、起動、アタッチメントを行うものです。実行中のコンテナを確認するには、以下のコマンドを実行する。

• コンテナにsshでアクセスするためには、コンテナのIPアドレスを見つける必要があります。これを実現するために、以下のコマンドを実行する必要があります。

コマンドの出力の最後に、IPアドレスが表示されます。以下は、参考のためのサンプルスニペットです。

• コンテナのIPアドレスが見つかったら、Dockerホストの/etc/hostsファイルにコンテナのIPとホストネームを入力します。同様に、Dockerfileで提供された入力に従って、コンテナ作成時に作成したアカウントを使用してコンテナにsshした後、コンテナの/etc/hostsファイルにDockerホストのIPアドレスとホスト名の詳細情報を追加してください。

• このブログ記事では、コンテナ作成時に「root」アカウントを作成するようにDockerfileをカスタマイズしているため、コンテナのログインにも同じアカウントを使用します。また、Dockerfileを修正して、そのアカウントがClearCaseコマンドの実行、ビューの作成、VOBへのアクセスを確実に行えるようにすれば、必要に応じてVOBオーナーや通常のVersionVaultユーザーを作成することができます。

• VOBオーナーアカウントは、Dockerホストに存在するようなコンテナ内に作成されるため、ログイン後に切り替えることができます。VersionVaultのVOBオーナーアカウントを特定する理由は、VOBやVOBオブジェクトをrootアカウントやVersionVault管理者グループに所有させることは、権限の問題に直面することになるため、良い習慣とは言えないからです。

• コンテナ内で "cleartool "コマンドを実行できるようになりました。

DockerホストがVersionVaultのバイナリをボリュームとしてコンテナと共有しているからこそ、「cleartool」コマンドの実行が可能なのです。

• Dockerコンテナから、DockerホストにホストされているVOBを一覧表示し、説明することができます。

• DockerホストでホストされているVOBにアクセスするために、コンテナ内にビューを作成する。

• VOBにアクセスするために、ビューをコンテナ内に作成した後、ビューに設定します。

• チェックアウトを行い、"mkelem "を実行してVOBの下に新しいファイルエレメントを追加しました。最後にcatコマンドを実行し、test.txtファイルの中身を確認。

• コンテナ内に作成したファイル「test.txt」は、Dockerホストからアクセスすることができます。

サンプルビルドの実行

※本節では、サンプルビルドを実行します。

• このセクションでは、コンテナ内でビルドを実行する方法について説明します。
• コンテナにsshで入り、VOBのオーナーアカウントに切り替えて、コンテナ内に作成したビューにセットし、VOBにcdします。

• VOBの下にhelloworldディレクトリが作成され、その下に簡単なC言語プログラムが配置されているのがわかります。

• 次に、ビルドユーティリティ "clearmake "を実行して、単純なCコードをコンパイルし、helloworldプログラムを実行して出力を見ます。

• clearmakeの完了後、上記のスクリーンショットから、helloworldの実行ファイルが作成され、 実行可能な状態にあることが分かります。

• この例では、コンテナ内でのシンプルなclearmakeのビルドを確認しましたが、同様の方法で、Dockerコンテナ内で実行可能な他のカスタマイズされたビルドを設定することが可能です。このように、異なるビルド環境のために複数の物理ビルドマシンを構成する代わりに、異なるコンテナ内で実行するようにビルド環境を構成することができるので、コストと時間を節約することができます。

• VersionVaultは、コンテナ内にインストールすることができます。コンテナではMVFSファイルシステムのインストールと起動を行わないため、インストールはサーバーインストールである必要があります（最小または完全な開発者用インストールではありません）。

2023/1/10 - 読み終える時間: ~1 分

2022 Value Stream Management Trends: A Recap の翻訳版です。

2022年バリューストリームマネジメントの動向。振り返り

2023年1月4日

著者: Ryley Robinson / Project Marketing Manager for Accelerate, Launch, VersionVault, and Compass

2022年秋、世界中のさまざまな職種、業種、場所で働く1万人以上のプロフェッショナルを対象に調査を実施しました。

本レポートで集計・分析した調査結果からは、2022年のVSM（顧客要求から納品までのビジネス価値の流れを増大させる）の状況を読み取ることができます。回答者からは、企業が現在直面している課題や、価値に関する組織や責任の分担方法について多くの知見が得られました。また、その回答から、企業が今後どのような方向に進んでいこうとしているのかについても明らかになりました。

その結果、バリューストリームマネジメントは現在あまり活用されていませんが、将来的には誰もが望む手法になることがわかりました。現在のトレンドを理解することは、コスト削減、リスク低減、組織内の価値の発見、そしてデジタル変革の時代において企業を最前線に立たせるための包括的な戦略を策定する上で重要な鍵となります。

バリューストリームマッピングは、フローチャートを使って製品やサービスの提供を分析し、次に改善するものです。バリューストリームマッピングは、製品やサービスがどのように消費者に届けられるかを説明する一連の連続したステップである「バリューストリーム」の概念に基づいています。

ソフトウェア開発のライフサイクルは短縮され、DevOpsのような方法論によってソフトウェアの継続的なデリバリーが可能になります。エンドツーエンドのバリューストリームは、バリューストリームマネジメントによって表示・最適化され、ビジネスの意思決定と成果を向上させます。ビジネスとITデリバリープロセスは、価値、無駄、摩擦をVSMに取り入れることで改善されます。

その目的は、価値の高い変化の組織への提供を加速させることです。バリューストリームマネジメントは、業務の現状を把握するだけでなく、業務の理想的な状態を可視化し、誰もが目指すべき具体的な目標を与えることができます。

2022年バリューストリームマネジメント動向レポートには、組織内の価値を求めている方、組織内の価値提供を加速させたい方、バリューストリームマネジメントへの理解を深めたい方など、多くの素晴らしい洞察や興味深い統計が掲載されています。

VSMトレンドレポートのダウンロードはこちら

HCL Accelerateによるバリュー・ストリーム・マネジメントの詳細については、当社のインタラクティブ・デモをお試しください。

2023/1/10 - 読み終える時間: ~1 分

Why You Need to Procure the Right VSM Partner の翻訳版です。

適切な VSM パートナーを調達する必要がある理由

2023年1月4日

著者: Ryley Robinson / Project Marketing Manager for Accelerate, Launch, VersionVault, and Compass

ソフトウェア開発業界においてバリューストリームマネジメント（VSM）の認知度が高まる中、多くの企業が依然として価値の実現に苦戦しています。新しいテクノロジーの時代には、最新のDevOpsプラクティスやツールを使用して、プロジェクトを戦略的目標に整合させることがより重要です。

DevOpsやDevSecOpsといった分野には多くの注目が集まっていますが、これらはいずれも顧客に価値を生み出すものです。しかし、ほとんどの組織は、自社の技術を普遍的な方法で見るのではなく、特定の分野の改善に焦点を合わせているため、期待される効果を得ることができません。優れたVSMパートナーは、組織が顧客価値の提供に焦点を当て、価値最適化の旅において開発およびデリバリーリソースを最適化することを支援します。

価値は顧客の認識から生まれるので、ユーザーが製品やサービスから期待される利益を得て初めて価値が生まれます。バリューストリームは、変更が要求されたときから、変更が展開され、価値が創造されるまでの連鎖反応である。

ここからバリューストリームマネジメントが始まるのです。

eGuide: バリューストリームマネジメントパートナーの調達は、組織における価値の提供を加速させ、バリューストリームマネジメントへの理解を深めるための素晴らしい洞察を提供します。

今すぐダウンロード

2023/1/6 - 読み終える時間: ~1 分

Why You Need Continuous Testing and How to Go About Choosing the Right Partner の翻訳版です。

継続的なテストが必要な理由と適切なパートナーの選び方

組織は、従来のウォーターフォールモデルによるソフトウェア提供から、現在ではDevSecOpsのプラクティスを採用するまでに進化しています。このシフトの理由は？企業は、より速く革新し、より速く製品を市場に提供する必要があります。リリースサイクルを短縮し、より効率的にする必要があります。同時に、品質とセキュリティは妥協することができません。もし妥協してしまったら、最終顧客だけでなく、組織にとっても負担が大きすぎるからです。

このシナリオを乗り切るための重要な方法は、継続的なソフトウェア開発とデリバリー、そして自動化を採用することです。自動化は、継続的な開発とデリバリーに関連し、効率性と敏捷性を達成するために必要です。バリューストリームマネジメントは、顧客の要求から顧客への納品までのビジネス価値の流れを高めることに焦点を当てた実践であり、組織が採用し始めているもう一つの注目すべき哲学である。

継続的テストとは、開発の最終段階だけでなく、ソフトウェア開発ライフサイクル（SDLC）全体を通じてアプリケーションを継続的にテストすることを指します。 自動化されたテストは、SDLCを通じて可能な限り多くのリスクを軽減するために、チームが即座に洞察を得られるようにするために行われます。このタイムリーなフィードバックは、テストのスピードとカバレッジを向上させ、手作業を減らすのに役立ち、企業にとってコスト削減だけでなく、市場投入までの時間を短縮することにつながります。

継続的テスト戦略を成功させるために考慮すべき重要な要因は何ですか？真のパートナーとなり、目標達成を支援する適切な継続的テストベンダーを選ぶには、どうすればよいでしょうか？

この e-Guide を読んで、組織の成功のための継続的テストに関するより多くの情報を入手してください。

2022/12/24 - 読み終える時間: 5 分

Transparent Remoting and Other Cool Features with HCL OneTest 10.5.1 の翻訳版です。

HCL OneTest 10.5.1 によるトランスペアレントリモーティングとその他のクールな機能

2022年12月21日

著者: Ragasudha Mardhaniyogan / Product Marketing Manager, OneTest

HCLSoftwareは、HCL OneTest 10.5.1のリリースを発表します。この新しいリリースは、あなたのOneTestテスト体験を向上させるエキサイティングな機能を提供します。

OneTestのエンタープライズエコシステムサポートを強化する戦略の一環として、ユーザーのために透過型リモーティング機能を提供します。

透過的リモーティングとは何か

トランスペアレントリモーティングは、開発者やテスターが、ゲートウェイや複雑な出入口ルールを介さずに、Kubernetes上でホストされている特定のマイクロサービスと直接対話することを可能にします。Pod xでこのマイクロサービスをテストするには？ OneTest API内でKubernetesクラスタへのポインタを作成し、そこでホストされているサービスにゲートウェイを介さずにアクセスすることが可能になりました。これにより、サービスの内部および/または外部APIを、あたかもローカルであるかのようにテストできます。

このリリースの一部として、すべてのOneTest製品に機能強化が施されています。このリリースの一部である他の機能の詳細については、読み進めてください。

HCL OneTest Server (OTS)

• XRay プロジェクトへのテスト結果エクスポートのサポート

  変更管理ソリューションとして既にJiraを使用しており、テスト管理にXRayを使用しているお客様向けに、OneTest ServerからXRayプロジェクトにテスト実行結果をエクスポートすることが可能になりました。

• Team Space ランディングページの Surface ユーザーとユーザーロールデータ

  チームスペースのランディングページがプロジェクト情報の中継のために見直されました。接続されているユーザーが、リストされたプロジェクトやチームスペースに対してどのような役割を持っているかを確認することができるようになりました。

  例えば、チームスペースの場合

プロジェクトタイルには、現在のユーザーが持っている役割も表示されます。

HCL OneTest サーバーの詳細については、[リリース情報](https://help.hcltechsw.com/onetest/hclonetestserver/10.5.1/docs/topics/rn_server.html)を参照してください。

HCL OneTest UI

• すべてのテスト ステップのグローバル遅延を定義する機能

  各ステップごとに実行するのではなく、各テストステップの前に実行される遅延をグローバルに定義できるようになり ました。デフォルトでは、環境設定で定義されていますが、ユーザーが実行時に定義値を変更することも可能です。

• テストレポートへのログメッセージのロギング

  ユーザーは、テスト スクリプトでコメントのような新しいステートメントを使用できますが、機能テスト レポートにログ記録されるため、レポートの読みやすさが格段に向上しました。 テスト ウェブ UI

• 機能テストレポートの機能強化

  画像検証ポイントの実績/期待値の表示方法が改善され、読みやすくなりました。また、以下の画像のように、評点に基づく検証ポイントのフィルタリングを行い、数値を表示することができるようになりました。

• 矢印キーの拡張サポート

  再生エンジンが、環境設定とは関係なく、矢印キーをサポートするようになりました。

  機能テスト自動化の新機能の詳細については、リリース情報を参照してください。

HCL OneTest パフォーマンス

• デフォルトの HTTP パフォーマンスレポートに、いくつかのページ要素統計が追加されました

  デフォルトの HTTP パフォーマンスレポートに、すべてのページ要素統計のテーブルが含まれるようになりました。この表は、ページ要素の必須応答時間、パーセンタイル応答時間、エラー、およびスループットの詳細を提供します。この新しいテーブルは、実行中のリクエスト統計の優れた統合ビューを提供します。

• 失敗したページの可視性を向上

  各ページにレスポンスコード検証ポイントをデフォルトで追加することで、失敗したページがより見やすくなりました。テスト生成の動作は、ユーザー設定によって条件付けされます。

• 失敗したページのレスポンスタイムを報告するかどうかの制御

  失敗したトランザクションと失敗したページのどちらについて、実行が応答時間を報告するかをユーザーが制御できるようになりました。

  パフォーマンス テストに関する新機能の詳細については、リリース情報を参照してください。

HCL OneTest API と HCL OneTest 仮想化

• Kubernetesクラスタ内のサービスへの透過的なアクセス

  ブログでも紹介しましたが、OneTest API内部でKubernetesクラスタへのポインタを作成し、そこでホストされているサービスにゲートウェイを通さずにアクセスすることが可能になりました。ユーザーはKubernetesクラスタを物理リソースとして定義できます。

例えばOpenAPI 3.0定義と同期することで、公開されているかどうかに関わらず、あたかもローカルであるかのように、サービスのすべてのAPIにアクセスできるようになります。

• 実行中の仮想サービスの状態への容易なアクセス

  ユーザーはスクリプトを使用して、HCL Quality Serverにパブリッシュされているスタブの状態を見ることができるようになりました。

• IBM WebSphereR MQ トランスポートの接続回復力が強化されました

  MQ トランスポートの一部の障害の処理方法が強化されました。

  インテグレーション?テストとサービス仮想化の新機能の詳細については、リリース情報を参照してください。

ご不明な点がございましたら、メールにてお知らせください。ご興味のあるテーマについてはリモート会議でのご相談も承っております。