メインフレーム テスト – 完全なチュートリアル

メインフレームテストの概念を学ぶ前に、まずテストが実行されるプラットフォームについて見ていきましょう。

メインフレームとは何ですか?

メインフレームは、高性能かつ高速なコンピュータシステムです。高い可用性と強固なセキュリティが求められる大規模なコンピューティングに使用されます。主に金融、保険、小売などの分野で、膨大な量のデータが1日に何度も処理されるような重要な用途で利用されています。

メインフレームのテスト

メインフレームのテスト メインフレームテストとは、メインフレームシステム上で動作するソフトウェアアプリケーションおよびサービスをテストするプロセスです。メインフレームテストの目的は、検証および妥当性確認手法を用いてソフトウェアアプリケーションまたはサービスのパフォーマンス、信頼性、品質を保証し、展開準備が整っているかどうかを確認することです。

メインフレームのテストを行う際、テスターは主にCICS画面の操作方法を理解しておく必要があります。これらの画面は特定のアプリケーション向けにカスタマイズされています。COBOL、JCL、および類似の言語でコードに変更を加えた場合、テスターはマシン上のエミュレータの設定について心配する必要はありません。なぜなら、ある端末エミュレータで動作する変更は、他の端末エミュレータでも動作するからです。

• メインフレームアプリケーション（ジョブバッチとも呼ばれる）は、要件に基づいて作成されたテストケースに対してテストされます。
• メインフレーム テストは通常​​、入力ファイルに設定されたさまざまなデータの組み合わせを使用して、展開されたコードに対して実行されます。
• メインフレーム上で動作するアプリケーションは、端末エミュレータを介してアクセスできます。クライアントマシンにインストールする必要があるソフトウェアは、このエミュレータのみです。

プラットフォームの動作がウェブスタックとは異なるため、テスト設計を左右するメインフレームの特性を把握しておくことが重要です。そのため、メインフレームテストは他のテストと並んで位置づけられます。 ソフトウェアテストの種類 それらを交換するのではなく。

メインフレームの属性

1. 仮想ストレージ
   • これは、プロセッサが実際の実ストレージの量よりも大きな主ストレージをシミュレートできるようにする技術です。
   • メモリを効率的に使用して、さまざまなサイズのタスクを保存および実行する手法です。
   • 実ストレージの拡張としてディスク ストレージを使用します。
2. マルチプログラミング
   • コンピュータは複数のプログラムを同時に実行できる。しかし、いかなる時点においても、CPUを制御できるプログラムは1つだけである。
   • CPUを効率的に利用するために設けられた機能です。
3. バッチ処理
   • これは、あらゆるタスクをジョブと呼ばれる単位で実行する手法です。
   • ジョブにより、XNUMX つ以上のプログラムが連続して実行される場合があります。
   • ジョブ スケジューラは、ジョブを実行する順序を決定します。 平均スループットを最大化するために、ジョブは優先度とクラスに従ってスケジュールされます。
   • バッチ処理に必要な情報は、JCL（ジョブ制御言語）によって提供されます。JCLは、バッチジョブに必要なプログラム、データ、リソースなどを記述します。
4. 時間を共有する
   • タイムシェアリング システムでは、各ユーザーは端末デバイスを介してシステムにアクセスできます。ユーザーは、後で実行するようにスケジュールされたジョブを送信する代わりに、すぐに処理されるコマンドを入力します。
   • したがって、これは「対話型処理」と呼ばれます。 これにより、ユーザーはコンピュータと直接対話できるようになります。
   • タイムシェア処理は「フォアグラウンド処理」、バッチジョブ処理は「バックグラウンド処理」と呼ばれます。
5. スプール
   • SPOOLing は Simultaneous Peripheral の略です。 Operaオンラインのイベント。
   • スプール装置は、プログラムまたはアプリケーションの出力を保存するために使用されます。スプールされた出力は、必要に応じてプリンタなどの出力デバイスに送られます。
   • バッファリングの利点を活用して出力デバイスを効率的に使用する機能です。

メインフレームにおける手動テストの分類

これらの特性により、メインフレーム上での手動テスト作業は、明確に分離された2つの流れに分割された。

メインフレーム 手動テスト 次の 2 つのタイプに分類できます。

1. バッチジョブのテスト —

• テストプロセスには、現在のリリースで実装された機能に関するバッチジョブの実行が含まれます。
• テスト結果trac出力ファイルとデータベースからのデータは検証され、記録されます。

2. オンラインテスト —

• オンラインテストとは、CICSの画面をテストすることを指し、ウェブページのテストに似ています。
• 既存の画面の機能が変更されたり、新しい画面が追加されたりする可能性があります。
• さまざまなアプリケーションに問い合わせ画面や更新画面が存在します。 これらの画面の機能は、オンライン テストの一環としてチェックする必要があります。

メインフレームのテスト方法

1. ビジネスチームは、リリースサイクルにおいて特定のアイテムやプロセスがどのように変更されるかを決定する要件定義書を作成します。
2. テストチームと開発チームは要件定義書を受け取ります。そして、変更によって影響を受けるプロセスの数を特定します。通常、リリースにおいては、カスタマイズされた要件によって直接影響を受けるアプリケーションは全体の20～25%程度です。残りの75～80%のリリース作業は、周辺アプリケーションやプロセスのテストなど、標準機能のテストに費やされます。
3. したがって、メインフレーム アプリケーションは XNUMX つの部分でテストする必要があります。
   • テスト要件 — 要件定義書に記載されている機能または変更点について、アプリケーションのテストを実施する。
   • 統合のテスト ― 影響を受けるアプリケーションとデータの送受信を行うプロセス全体、または他のアプリケーションをテストする。 回帰テスト このテスト活動の主な焦点は次のとおりです。

メインフレーム自動テストツール

以下はメインフレームで使用できるツールのリストです。 自動化テスト.

• REXX — z/OSに付属するスクリプト言語で、繰り返し実行されるジョブの投入や出力チェックに広く使用されている。
• Excel マクロと組み合わせて使用​​し、テストデータと出力ファイルの作成、比較、およびレポート作成に使用します。
• OpenText UFT 1 — 業界で今も使われているツールの現在の名称 QTP またはQuickTest Professional。これは3270種類の端末画面を自動化します。
• ガラサ — オープンソース、 Open Mainframe Projectのディープインテグレーションテストフレームワーク これは、CI/CDパイプラインから3270台の画面、JCLバッチジョブ、およびDb2を駆動します。
• ベンダー提供のz/OSテストスイート - IBM ZおよびBMC AMI DevX Total Test用のテストアクセラレータは、COBOL単体テストと仮想化テスト環境に対応しています。

どのツールを選んだとしても、それは維持管理された環境下でのみ効果を発揮する。 テスト自動化フレームワーク バラバラの脚本の山ではなく。

メインフレーム テストの方法論

例として、XYZ保険会社に会員登録モジュールがあるとします。このモジュールは、会員登録画面とオフライン登録の両方からデータを取得します。前述のとおり、メインフレームのテストには、オンラインテストとバッチテストの2つのアプローチがあります。

• オンラインテストは会員登録画面で行われます。ウェブページと同様に、データベースは画面を通して入力されたデータに基づいて検証されます。
• オフライン登録は、紙での登録またはサードパーティの Web サイトでの登録のいずれかです。オフライン データ (バッチとも呼ばれます) は、バッチ ジョブを通じて会社のデータベースに入力されます。入力フラット ファイルは、規定のデータ フォーマットに従って準備され、一連のバッチ ジョブに渡されます。したがって、メインフレーム アプリケーションのテストには、次のアプローチを使用できます。
  • 一連のバッチジョブの最初のジョブは、入力されたデータの検証を行います。例えば、特殊文字や、数値のみのフィールドにアルファベットが混入していないかなどを確認します。
  • 2つ目のジョブは、業務条件に基づいてデータの一貫性を検証します。例えば、子供の登録情報に扶養家族データが含まれていたり、登録プランでサービス提供対象外の郵便番号が含まれていたりしてはなりません。
  • 3つ目のジョブは、データベースに入力できる形式にデータを変更します。例えば、プラン名を削除し（データベースにはプランIDと保険プラン名のみが保存されます）、入力日を追加するなどといった変更を行います。
  • XNUMX 番目のジョブは、データをデータベースにロードします。
• このプロセスにおけるバッチジョブのテストは、2つのフェーズで行われます。
  • 各ジョブは個別に検証され、
  • 各ジョブ間の連携は、最初のジョブに入力フラットファイルを提供し、データベースを検証することによって検証されます。（念のため、中間結果も検証する必要があります。）

メインフレームのテストには、以下の方法が用いられます。

ステップ1）シェイクダウン／スモークテスト

この段階での主な焦点は、デプロイされたコードが適切なテスト環境にあるかどうかを検証することです。また、コードに重大な問題がないことも確認します。これはメインフレームの同等のものです。 スモークテスト 他のプラットフォームでは利用できません。

ステップ2） システムテスト

以下は、システム テストの一環として実行されるテストの種類です。

1. バッチテスト このテストは、出力ファイルに対するテスト結果と、テスト対象のバッチジョブによって行われたデータ変更を検証し、記録することによって実施されます。
2. オンラインテスト このテストは、メインフレームアプリケーションのフロントエンドで行われます。ここでは、保険プラン、プランの利息、その他類似の値など、入力フィールドが正しく処理されるかどうかがテストされます。
3. オンラインバッチ統合テスト このテストは、バッチ処理とオンラインアプリケーションの両方を備えたシステムで実施されます。オンライン画面とバッチジョブ間のデータフローと相互作用が検証されます。

   （この種のテストの例として、金利の引き上げなど、プランの詳細を更新する場合を考えてみましょう。金利の変更は更新画面で行われ、影響を受ける口座の残高詳細は夜間バッチジョブによってのみ変更されます。この場合のテストは、プランの詳細画面と、すべての口座を更新するためのバッチジョブの実行を検証することによって行われます。）

4. データベースのテスト メインフレームアプリケーションからのデータが格納されているデータベース（IMS、IDMS、Db2、VSAM/ISAM、シーケンシャルデータセット、GDG）のレイアウトとデータストレージが検証されます。

ステップ3）システム 統合テスト

このテストの主な目的は、テスト対象のシステムと対話するシステムの機能を検証することです。

これらのシステムは要件によって直接影響を受けることはありません。しかし、テスト対象システムのデータを使用します。 インタフェース また、システム間でやり取りされるさまざまな種類のメッセージ（ジョブ成功、ジョブ失敗、データベース更新など）と、それに応じて各システムが実行するアクションについても説明します。

この段階で行われるテストの種類は次のとおりです。

1. バッチテスト
2. オンラインテスト
3. オンライン - バッチ統合テスト

ステップ4）回帰テスト

回帰テストは、あらゆる種類のテストプロジェクトにおいて共通のフェーズです。メインフレームにおけるこのテストは、テスト対象システムと直接やり取りしない（または要件の範囲外である）バッチジョブやオンライン画面が、現在のプロジェクトリリースによって影響を受けないことを保証します。

効果的な回帰テストを行うには、テストケースの複雑さに基づいて特定のテストケースセットを絞り込み、回帰ベッド（テストケースリポジトリ）を作成する必要があります。このセットは、新しい機能がリリースに展開されるたびに更新する必要があります。回帰ベッドが大きすぎて完全に実行できない場合は、 リスクベースのテスト どのジョブと画面を最初に再実行するかを決定するために使用されます。

ステップ5） 性能試験

このテストは、フロントエンドのデータ入力やオンラインデータベースの更新など、負荷の高い領域のボトルネックを特定し、アプリケーションのスケーラビリティを予測するために行われます。長時間実行されるバッチウィンドウは通常、 ストレステスト ピーク時の取引量に対して。

ステップ6） セキュリティテスト

このテストは、アプリケーションがセキュリティ対策攻撃に対抗するためにどの程度適切に設計および開発されているかを評価するために行われます。

システムに対しては、メインフレームのセキュリティとネットワークのセキュリティという2つの側面からセキュリティテストを実施する必要がある。

テストする必要のある機能は以下のとおりです。

1. Integrity
2. 機密性
3. Authorization
4. 認証
5. 利用状況

バッチテストの手順

1. QAチームが承認済みのパッケージ（パッケージには、手順書、JCL、制御カード、モジュール、その他類似の項目が含まれる）を受け取った後、テスターは必要に応じて内容をプレビューし、PDSに取り込む必要があります。
2. 本番環境用JCLまたは開発用JCLをQA用JCL（別名JOB SETUP）に変換します。
3. 本番環境用ファイルをコピーし、テスト用ファイルを準備してください。
4. 各機能ごとにジョブシーケンスが定義されます（メインフレームテストの方法論のセクションにある例で説明されているとおり）。ジョブは、テストデータファイルとともにSUBコマンドを使用して投入する必要があります。
5. データの欠落やエラーの原因を特定するために、中間ファイルを確認してください。
6. テスト結果を検証するために、最終出力ファイル、データベース、およびスプールを確認してください。
7. ジョブが失敗した場合、スプールにジョブ失敗の理由が存在します。 エラーに対処し、ジョブを再送信します。

テストレポート - A 欠陥 実際の結果が期待される結果と異なる場合は、その旨をログに記録する必要があります。

オンラインテストの手順

1. オンライン画面を選択します テスト環境.
2. 各フィールドをテストして、許容可能なデータかどうかを確認します。
3. テストする テストシナリオ 画面上。
4. オンライン画面からデータベースのデータ更新を確認します。

テストレポート 実際の結果が期待される結果と異なる場合は、欠陥として記録する必要があります。

オンラインバッチ統合テストの手順

1. テスト環境でジョブを実行し、オンライン画面上のデータを検証してください。
2. オンライン画面上のデータを更新し、更新されたデータでバッチジョブが正しく実行されるかどうかを検証してください。

メインフレームのテストで使用されるコマンド

これらの手順は端末から実行されるため、少数のコマンドを覚えるだけでテスターの1日の作業のほとんどをカバーできます。

1. SUBMIT — バックグラウンドジョブを提出してください。
2. CANCEL ― バックグラウンド処理の依頼をキャンセルする。
3. 割り当てる — データセットを割り当てます。
4. COPY データセットをコピーします。
5. RENAME データセットの名前を変更します。
6. DELETE データセットを削除します。
7. ジョブスキャン — JCLを実行せずに、プログラム、ライブラリ、ファイル、その他のリソースとJCLをバインドします。

必要に応じて使用されるコマンドは他にもたくさんありますが、それほど頻繁ではありません。

メインフレームのテストを開始するための前提条件

メインフレームのテストに必要な基本情報は以下のとおりです。

• アプリケーションにログインするためのログインIDとパスワード。
• ISPFコマンドに関する基本的な知識。
• ファイル名、ファイル修飾子、およびファイルの種類。

メインフレームのテストを開始する前に、以下の点を確認する必要があります。

1. Job
   • 実行前にジョブスキャン（コマンド：JOBSCAN）を実行してエラーがないか確認してください。
   • CLASSパラメータにはテストクラスを指定する必要があります。
   • MSGCLASSパラメーターを使用して、ジョブの出力をスプールまたはJHSに、あるいは必要に応じて出力先として指定します。
   • ジョブ内のメールをスプールまたはテスト用メールアドレスに転送します。
   • 初期テストのためにFTP関連の手順をコメントアウトし、ジョブをテストサーバーに指定してください。
   • ジョブで IMR (インシデント管理記録) が生成された場合は、ジョブまたはパラメータ カードに「テスト目的」というコメントを追加してください。
   • ジョブ内のすべての実稼働ライブラリを変更し、テスト ライブラリを指すようにする必要があります。
   • 仕事は放置すべきではありません。
   • エラーが発生した場合にジョブが無限ループに陥るのを防ぐため、TIMEパラメータに指定した時間を追加する必要があります。
   • スプールを含むジョブの出力を保存します。 スプールは XDC を使用して保存できます。
2. File
   • 必要なサイズのテストファイルのみを作成してください。同じ名前の連続したファイルにデータを保存する必要がある場合は、GDG（Generation Data Groups、MYLIB.LIB.TEST.G0001V00 と MYLIB.LIB.TEST.G0002V00 のように、同じ名前でバージョン番号が連番になっているファイル）を使用してください。
   • ファイルに対する DISP (Disposition — ステップまたはジョブの正常終了または異常終了後にデータセットを保持するか削除するかをシステムに指示する) パラメータは正しくコーディングする必要があります。
   • ジョブの実行に使用されるすべてのファイルが適切に保存および閉じられていることを確認し、ジョブが保留状態にならないようにしてください。
   • GDGsを使用してテストを行う際は、正しいバージョンが指定されていることを確認してください。
3. データベース
   • ジョブまたはオンラインプログラムを実行する際は、意図しないデータが挿入、更新、または削除されないようにしてください。
   • また、テストには正しいDb2リージョンが使用されていることを確認してください。
4. テストケース
   • 空のファイル、最初のレコードの処理、最後のレコードの処理といった境界条件については、必ずテストを行ってください。
   • 必ず、肯定的なテスト条件と否定的なテスト条件の両方を含めてください。
   • プログラムでチェックポイント再起動、異常終了モジュール、制御ファイルなどの標準手順が使用される場合は、以下を含める テストケースモジュールが正しく使用されているかどうかを検証します。
5. テストデータ
   • テストデータのセットアップは、テストを開始する前に行う必要があります。
   • テスト領域のデータを、他の担当者に通知せずに変更することは絶対にしないでください。同じデータを使用している他のチームが存在する可能性があり、変更すると彼らのテストが失敗する恐れがあります。
   • 実行中に実稼働ファイルが必要な場合は、それらをコピーまたは使用する前に適切な許可を取得する必要があります。

ベストプラクティス

1. バッチジョブの実行において、MAX CC 0 はジョブが正常に実行されたことを示す指標です。これは、機能が正常に動作していることを意味するものではありません。出力が空であったり、期待どおりでなかったりする場合でも、ジョブは正常に実行されます。したがって、ジョブの成功を宣言する前に、すべての出力を確認することが常に推奨されます。
2. テスト対象ジョブのドライラン（空実行）を行うことは、常に良い習慣です。ドライランは、入力ファイルが空の状態で実行されます。この手順は、テストサイクルで行われた変更の影響を受けるジョブに対して実施する必要があります。
3. テストサイクルを開始する前に、テストジョブの設定を事前に済ませておく必要があります。これにより、JCLエラーを事前に発見でき、実行時の時間を節約できます。
4. SPUFI（エミュレーター上のDb2テーブルへのアクセスオプション）を介してDb2テーブルにアクセスする場合は、意図しない更新を避けるため、必ず自動コミットを「いいえ」に設定してください。
5. バッチテストにおける最大の課題は、テストデータの入手可能性です。必要なデータはテストサイクル開始前に十分に準備し、完全性を確認する必要があります。 Tracking 共有された準備 テスト管理 リポジトリは、回帰分析環境とデータ設定を整合させておく。
6. オンライントランザクションやバッチジョブの中には、MQ（メッセージキュー）にデータを書き込むものがあります。 transmit他のアプリケーションにデータを送信する際、データが正しくない場合、MQが無効化または停止する可能性があり、テストプロセス全体に影響を及ぼします。テスト後にMQが正常に動作していることを確認することをお勧めします。

メインフレームのテストにおける課題とトラブルシューティング

こうした対策を講じても、ほぼすべてのメインフレームのリリースでいくつかの問題が再発します。以下の表は、それぞれの問題とその解決策をまとめたものです。

チャレンジ	アプローチ
不完全/不明確な要件	ユーザーマニュアルやトレーニングガイドにアクセスできる場合もあるが、それらは文書化された要件とは異なる。テスターは、 ソフトウェアテストのライフサイクル 要件定義段階以降、このプロセスは要件がテスト可能かどうかを確認するのに役立ちます。
データ設定／識別	要件に応じて既存データを再利用する必要がある場合もあります。既存データから必要なデータを特定するのは時に困難です。データ設定には、必要に応じて自社開発ツールを使用できます。既存データを取得するには、事前にクエリを作成する必要があります。何らかの問題が発生した場合は、データ管理チームに依頼して必要なデータの作成または複製を依頼できます。
	ジョブがPDSに取り込まれたら、ジョブが本番環境の修飾子やパスの詳細情報とともに送信されないように、QA領域でジョブを設定する必要があります。設定中に発生する人的ミスを回避するために、ジョブ設定ツールを使用する必要があります。
アドホックリクエスト	次のような状況があるかもしれません エンドツーエンドテスト 上流または下流のアプリケーションに問題が発生した場合、サポートが必要になります。このようなリクエストは、実行サイクルにおける時間と労力を増加させます。自動化スクリプト、回帰テストスクリプト、スケルトンスクリプトを使用することで、時間と労力のオーバーヘッドを削減できます。
スコープ変更のためのオンタイムリリース	コードの変更によってシステムの外観や操作感が完全に変わってしまう状況が発生する可能性があります。その場合、テストケース、スクリプト、データの変更が必要になるかもしれません。そのため、スコープ変更管理プロセスと影響分析を実施しておく必要があります。

よく遭遇する不測の事態

ジョブが失敗すると、スプールは異常終了コードを報告します。以下のリストは、メインフレームテスターが最も頻繁に遭遇するコードと、その一般的な原因をまとめたものです。

1. S001 入出力エラーが発生しました。

   理由 — ファイルの末尾を読み取ろうとした、ファイル長エラー、または読み取り専用ファイルへの書き込みを試みた。

2. S002 — 無効な入出力レコード。

   理由 — レコード長を超える長さのレコードを書き込もうとした。

3. S004 — OPEN中にエラーが発生しました。

   理由 — 無効なDCB。

4. S013 — データセットを開く際にエラーが発生しました。

   理由：PDSメンバーが存在しないか、プログラム内のレコード長が実際のレコード長と一致しません。

5. S0C1 - Opera例外処理。

   理由：ファイルを開けない、またはDDカードが見つかりません。

6. S0C4 — 保護例外／ストレージ違反。

   理由 — プログラムが利用できないストレージにアクセスしようとしています。

7. S0C7 — プログラムチェック例外、データ。

   理由：レコードレイアウトまたはファイルレイアウトの変更。

8. Sx22 — 仕事はキャンセルされました。

   理由 — 作業が完了する前に終了しました。真ん中の数字は、誰がまたは何がキャンセルしたかを示します。

9. S222 — ユーザーによってジョブがダンプなしでキャンセルされました。
10. S322 ジョブまたはステップの実行時間が指定された制限を超えたか、プログラムがループ状態にあるか、またはTIMEパラメータが不足しています。
11. S522 — TSOセッションがタイムアウトしました。
12. S806 リンクまたは読み込みに失敗しました。

    理由 — 指定されたロードモジュールが見つかりません。

13. S80A GETMAINまたはFREEMAINリクエストを満たすのに十分な仮想ストレージがありません。
14. S913 — ユーザーが使用権限を持たないデータセットにアクセスしようとしています。
15. Sx37 データセットに十分なストレージを割り当てることができませんでした。

エラーアシスト — さまざまな種類の異常終了に関する詳細情報を取得するための非常に人気のあるツールです。

メインフレームのテスト中によく発生する問題

• ジョブが異常終了する ジョブを正常に完了するには、データ、入力ファイル、および指定された場所にモジュールが存在するかどうかを確認する必要があります。異常終了は複数の原因で発生する可能性がありますが、最も一般的な原因は、無効なデータ、入力フィールドの誤り、日付の不一致、または環境の問題です。
• 出力ファイルが空です ジョブが正常に実行されたとしても（MaxCC 0）、出力が期待どおりにならない場合があります。そのため、テストケースを通過する前に、テスターは出力が相互検証されていることを確認する必要があります。検証が完了してから初めて、テストを続行すべきです。
• 入力ファイルが空です — アプリケーションによっては、上流プロセスからファイルを受信する場合があります。受信したファイルを現在のアプリケーションのテストに使用する前に、再実行や再作業を避けるために、データの相互検証を行う必要があります。

よくあるご質問