AWS Mainframe Modernization アプリケーションテストの概念

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS アプリケーションテストでは、他のテストサービスまたはソフトウェアパッケージが使用する用語を少し異なる意味で使用します。以下のセクションでは、 AWS Mainframe Modernization アプリケーションテストがこの用語を使用する方法について説明します。

テストケース

テストケースは、テストワークフローにおいて最もアトミックなアクションの個別単位です。通常、テストケースはデータを変更する、独立したビジネスロジックの単位を表すために使用されます。比較はテストケースごとに行われます。テストケースはテストシナリオに追加されます。テストケースには、テストケースが変更するデータアーティファクト (データセット、データベース) に関するメタデータと、テストケースの実行時にトリガーされるビジネス機能 (バッチジョブ、3270 のインタラクティブダイアログなど) に関するメタデータが含まれています。例えば、データセットの名前やコードページなどです。

入力データ → テストケース → 出力データ

テストケースはオンラインタイプまたはバッチタイプのいずれかとなります。

テストスイート

テストスイートには、テストケースのコレクションがあり、順番に 1 つずつ実行されます。リプレイはテストスイートレベルで行われます。テストスイートがリプレイされると、テストスイートのすべてのテストケースがターゲットのテスト環境で実行されます。リファレンステストアーティファクトとリプレイテストアーティファクトを比較したときに違いがあれば、テストケースレベルで表示されます。

例えば、テストスイート A の場合:

テストケース 1、テストケース 2、テストケース 3 など。

テスト環境構成

テスト環境構成では、テスト実行を再現できるようにする必要がある CloudFormation でデータと設定パラメータ (またはリソース) の初期セットを設定できます。

アップロード

アップロードはテストスイートレベルで行われます。アップロード時には、比較対象となるソースメインフレームのアーティファクト、データセット、リレーショナルデータベース CDC ジャーナルを含む Amazon S3 ロケーションを指定する必要があります。これらはソースメインフレームからの参照データと見なされます。リプレイ中、生成されたリプレイデータはアップロードされた参照データと比較され、アプリケーションの同等性が確認されます。

リプレイ

リプレイはテストスイートレベルで行われます。リプレイ中、 AWS Mainframe Modernization アプリケーションテストは CloudFormation スクリプトを使用してターゲットテスト環境を作成し、アプリケーションを実行します。リプレイ時に変更されたデータセットとデータベースレコードがキャプチャされ、メインフレームからの参照データと比較されます。通常、メインフレームに 1 回アップロードし、機能同等性が得られるまで複数回リプレイします。

比較

リプレイが正常に終了すると、自動的に比較が行われます。比較の際には、アップロードフェーズでアップロードしてキャプチャした参照データが、リプレイフェーズで生成されたリプレイデータと比較されます。比較は、データセット、データベースレコード、オンライン画面の個別のテストケースレベルで個別に行われます。

データベースの比較

アプリケーションテストでは、ソースアプリケーションとターゲットアプリケーションの間でデータベースレコードの変更を比較する際に、状態と進行状況の照合機能が採用されます。状態と進行状況の照合では、プロセスの最後にテーブル行を比較するのとは異なり、INSERT、UPDATE、DELETE ステートメントを実行するごとに差異を比較します。状態と進行状況の照合は他の方法よりも効率がよく、変更されたデータのみを比較し、トランザクションフロー内の自己修正エラーを検出することで、迅速で正確な比較が可能になります。アプリケーションテストでは、CDC (変更データキャプチャ) テクノロジーを使用して、リレーショナルデータベースの個々の変更を検出し、ソースとターゲットの間で比較できます。

リレーショナルデータベースは、SQL INSERT、UPDATE、DELETE などの DML (データ修正言語) ステートメントを使用してテストされたアプリケーションコードによってソースとターゲットで変更が生成されますが、アプリケーションがストアドプロシージャを使用している場合や、データベーストリガーが一部のテーブルに設定されている場合、参照整合性を保証するために CASCADE DELETE が使用されて自動的に追加の削除がトリガーされる場合にも間接的に生成されます。

データセットの比較

アプリケーションテストは、ソース (記録) システムとターゲット (リプレイ) システムで生成された参照データセットとリプレイデータセットを自動的に比較します。

データセットを比較する方法:

リプレイが完了すると、アプリケーションテストは出力参照データセットとターゲットデータセットを自動的に比較して、レコードが同一か、同等か、異なるか、欠落しているかを示します。例えば、ワークロードの実行時と関連する (実行時 + 1 日、当月末など) 日付フィールドは、自動的に同等とみなされます。また、オプションで同等性ルールを定義して、同一ではないがビジネス上の意味が同じレコードに同等のフラグを付けられるようにすることもできます。

比較ステータス

アプリケーションテストでは、「IDENTICAL」、「EQUIVALENT」、「DIFFERENT」という比較ステータスを使用します。

同等性ルール

同等の結果と見なすことができる、見せかけの差異を識別するための一連のルール。オフラインの機能同等性テスト (OFET) では、ソースシステムとターゲットシステムの間で結果の一部に違いが生じることは避けられません。例えば、更新タイムスタンプは設計によって異なります。同等性ルールは、これらの違いを調整し、比較時に誤検出が発生しないようにする方法を明確にします。例えば、特定のデータ列の日付がランタイム + 2 日である場合、同等性ルールはそれを記述し、参照アップロードの同じ列と厳密に一致する値ではなく、ターゲットシステムでのランタイムに 2 日を足した時間を受け入れます。

最終状態のデータセットの比較

作成または変更されたデータセットの最終状態。初期状態からデータセットに加えられたすべての変更または更新を含みます。データセットの場合、アプリケーションテストはテストケース実行の最後にそれらのデータセットのレコードを調べ、結果を比較します。

状態と進行状況のデータベース比較

データベースレコードに加えられた変更を、個々の一連の DML (削除、更新、挿入) ステートメントとして比較します。アプリケーションテストでは、ソースデータベースからターゲットデータベースへの個々の変更 (テーブルの行の挿入、更新、削除) を比較し、個々の変更の違いを見極めます。例えば、個々の INSERT ステートメントを使用して、ソースデータベースとターゲットデータベースの値が異なる行をテーブルに挿入できます。

機能同等性 (FE)

2 つのシステムは、入力データが同じ場合、観測可能なすべての操作で同じ結果が得られる場合、機能的に同等であるとみなされます。例えば、同じ入力データから (画面、データセットの変更、データベースの変更を通じて) 同一の出力データが生成される場合、2 つのアプリケーションは機能的に同等であるとみなされます。

3270 のオンライン画面比較

ターゲットシステムが の AWS Blu Age ランタイムで実行されている場合のメインフレーム 3270 画面の出力とモダナイズされたアプリケーションウェブ画面の出力を比較します AWS クラウド。また、ターゲットシステムが の Rocket Software (旧 Micro Focus) ランタイムで実行されている場合、メインフレーム 3270 画面の出力とリホストされたアプリケーションの 3270 画面の出力を比較します AWS クラウド。

リプレイデータ

リプレイデータは、ターゲットテスト環境でテストスイートをリプレイして生成したデータを記述するために使用されます。例えば、 AWS Mainframe Modernization サービスアプリケーションでテストスイートが実行されている場合、リプレイデータが生成されます。その後、リプレイデータはソースからキャプチャされた参照データと比較されます。ターゲット環境でワークロードをリプレイするたびに、新世代のリプレイデータが生成されます。

参照データ

参照データは、ソースメインフレームでキャプチャされたデータを記述するために使用されます。リプレイ (ターゲット) で生成されたデータが比較される参照元です。多くの場合、参照データを作成するメインフレームのレコードごとに、リプレイが複数回行われます。これは、通常、ユーザーがメインフレームでアプリケーションの正しい状態をキャプチャし、モダナイズされたターゲットアプリケーションでテストケースをリプレイして同等性を検証するためです。バグが見つかった場合は、修正され、テストケースが再びリプレイされます。多くの場合、リプレイ、バグの修正、発生を検証するためのリプレイを複数サイクル繰り返します。これは、テストの「1 回キャプチャ、複数回リプレイ」パラダイムと呼ばれます。

アップロード、リプレイ、比較

アプリケーションテストは次の 3 つのステップで行われます。

差異

データを比較することで、参照データセットとリプレイデータセットの間に差異が検出されたことを示します。例えば、オンラインの 3270 画面のフィールドで、ソースメインフレームとのモダナイズされたターゲットアプリケーションとの間で、ビジネスロジックの観点から見て異なる値が表示される場合、そのフィールドには差異があるとみなされます。もう 1 つの例として、ソースアプリケーションとターゲットアプリケーションでデータセットのアップロードが同一ではない場合があります。

同等性

同等レコードとは、参照データセットとリプレイデータセットでは差異があるが、ビジネスロジックの観点からすると異なるものとして扱うべきではないレコードのことです。例えば、データセットが作成されたときのタイムスタンプ (ワークロード実行時間) を含むレコードなどです。カスタマイズ可能な同等性ルールを使用すると、参照データとリプレイデータの値が異なっていても、このような誤検出の差異を同等として扱うようにアプリケーションテストに指示できます。

ソースアプリケーション

比較対象となるソースメインフレームアプリケーション。

ターゲットアプリケーション

テストを実施する新規または変更後のアプリケーション。ソースアプリケーションとターゲットアプリケーション間の機能同等性を達成するために、ソースアプリケーションと比較されます。ターゲットアプリケーションは通常、 AWS クラウドで実行されています。