ソフトウェアテストの手順は、一般に開発段階に応じて単体テスト、結合テスト、確認テスト、システムテスト、受け入れテストの5つに分かれますが、各段階で必要となる作業の一部を以下にまとめます。みんなを助けて。
1. 単体テストの内容：（主にホワイトボックス、ブラックボックスで補足）
単体テスト (モジュール テストとも呼ばれる) は、ソフトウェア設計の最小単位のプログラム モジュールの正しさをチェックするテスト作業です。単体テストでは、プログラムの内部構造に基づいてテスト ケースを設計する必要があります。複数のモジュールを独立して単体テストできます。並行して。
1. モジュールインターフェーステスト
テスト対象のモジュールを通過するデータ フローをテストする必要があります。
テスト対象モジュールを呼び出す際の入力パラメータがモジュールの仮パラメータの数、属性、順序と一致するかどうか
テストされたモジュールがサブモジュールを呼び出すとき、入力サブモジュールのパラメータが、数、属性、および順序に関してサブモジュールの仮パラメータと一致するかどうかを確認します。
標準関数に出力されるパラメータの数、属性、順序は正しいか。
グローバル変数の定義が各モジュールで一貫しているかどうか。
モジュールが外部デバイスを介して入出力操作を行う場合、ファイルの属性が正しいか、open 文と close 文が正しいか、指定された I/O 形式の記述が I/O 文と一致しているか、バッファ容量が一致しているかを確認します。レコード長、バッファ容量がレコード長と一致するかどうか、以前にファイルが開かれたかどうか、読み取りと書き込み後にファイルが閉じられたかどうか、および I/O エラーが処理されたかどうか。
2. ローカルデータ構造のテスト
ローカル データ構造は最も一般的なエラーの原因です
一貫性のないデータ型
不正確または一貫性のないデータの説明
まだ値が割り当てられていない、またはまだ初期化されていない変数を使用する
初期値が間違っている、またはデフォルト値が間違っている
3. パステスト
操作の優先順位付け、一般的な比較、制御フロー
4. エラー処理テスト
エラー条件が発生し、適切なエラー処理を設定する
5. 境界テスト
例えば、ループ回数、最大値または最小値
2. 単体テストの手順:
設計ドキュメントを使用してテスト ケースを設計します。
テスト対象モジュールのスタブ モジュールまたはドライバー モジュールを作成します。
テスト対象モジュール、ドライバーモジュール、スタブモジュールを使用してテスト環境を構築し、テストを実施します。
ドライバモジュール：被試験モジュールのメインプログラムに相当し、試験データを受け取り、そのデータを被試験モジュールに送信し、最終的に実際の結果を出力します。
スタブ モジュール: テストされるモジュールの代わりに呼び出されるサブモジュール。
3. 結合テスト（ホワイトボックスとブラックボックスの組み合わせ）
結合テストは組立テストや結合テストとも呼ばれ、単体テストをベースに、概要設計仕様書や詳細設計仕様書の要求事項に従って、すべてのモジュールを組み立てる必要があります。
さまざまなモジュールを接続すると、各モジュールのインターフェイスを通過するデータが失われます。
あるモジュールの機能が別のモジュールの機能に悪影響を与えるかどうか
各サブ関数がアセンブルされた後、期待される親関数を達成できますか?
グローバルデータ構造に問題があるのでしょうか？
単一モジュールによって生成されるエラーは累積的に増幅されますか?
統合テストレベル: サブシステム内の統合テスト、サブシステム間の統合テスト、モジュール間の統合テスト。
モジュールがシステムに組み立てられる方法: 1 回限りの組み立てと増殖的な組み立て
1.ワンタイムアセンブリ法（非増殖統合）
まずモジュールを個別にテストし、次にテスト用にすべてのモジュールを組み立てます。
短所: 間違いを見つけたときに、それを見つけるのは簡単ではありません。
2. 増殖アセンブリテスト: トップダウン、ボトムアップ、階層的統合、サンドイッチ統合、草の根統合、高周波統合。
最初にモジュールごとにモジュールテストを実行し、それらのモジュールを徐々にシステムに組み立てます。これには、トップダウン方式とボトムアップ方式の 2 つの方式があります。
(1) トップダウン増殖方式（ドライバモジュール不要）
モジュール式アンモニウム システム プログラム構造は、厳格な制御レベルで上から下まで組み立てられています。
まず、メインモジュールを被テストモジュールおよび駆動モジュールとして使用し、メインモジュール直下のすべての従属モジュールをスタブモジュールに置き換えてメインモジュールをテストします。次に、深さ優先または幅優先の戦略を採用し、スタブ モジュールを実際のモジュールで置き換えてから、その直下にあるモジュールをスタブ モジュールで置き換えて、テストされたモジュールで新しいサブシステムを形成します。次に、回帰テストを実行します。
(2) ボトムアップ増殖方式（ドライバモジュール不要）
ドライバー モジュールは、最下位モジュールの並列テストを制御します。
(3) 混合増殖型
トップダウン増殖法:
利点: 重大な制御問題を早期に検出できる
欠点: スタブ モジュールを確立する必要があり、いくつかの追加テストが追加されます。アルゴリズムや入出力に関係するモジュールは通常、最下位にあります。これらの最下位モジュールは、アセンブリとテストの後の段階まで発見できません。問題が発見されると、回帰テストが多すぎます。
ボトムアップ増殖法:
利点: スタブ モジュールを作成する必要がありません。スタブ モジュールよりもドライバー モジュールを作成する方がはるかに簡単です。同時に、アルゴリズムの入出力に関係するモジュールを最初にテストする必要があり、最も重要な部分はテストする必要があります。起こりやすい問題を早期に解決できます。
短所: 最後のモジュールが追加されてエンティティが形成され、最終的に制御面にアクセスできるようになるまで、プログラムはエンティティとして存在しません。
3. 統合テストの完了の兆候:
1) テスト計画で指定されたすべての統合テストが正常に実行されました。
2) 見つかったエラーを修正しました
3) テスト結果は専門グループの審査を通過します。
4) 統合テストのために提出する必要があるテストレポート:
5) 結合テスト計画書、結合テスト仕様書、結合テスト分析報告書
4. 確認テスト（ブラックボックス）
検証テストの目的は、ソフトウェアの機能、パフォーマンス、およびその他の特性がユーザーの要件と一致していることを検証することです。検証テストには通常、妥当性テストとソフトウェア構成のレビューが含まれます。通常、この検査は第三者の検査機関によって実施されます。
1. 妥当性テストの実施
現在のソフトウェア検証は、一連のブラック ボックス テストに合格する必要があります。確認テストでは、テスト計画とプロセスの開発も必要です。テスト計画では、テストの種類とテストの進行状況を指定する必要があります。テスト プロセスでは、ソフトウェアが要件と一致しているかどうかを示すために、いくつかの特別なテスト ケースを定義します。
計画であってもプロセスであっても、ソフトウェアが契約で指定されたすべての機能とパフォーマンスを満たしているかどうか、文書が完全かつ正確であるかどうか、マンマシンインターフェイスやその他の側面（移植性、互換性、エラー回復、メンテナンス性など）ユーザーが満足できるかどうか。
確認テストの結果には 2 つの可能性があり、1 つは機能および性能指標がソフトウェア要件記述の要件を満たしており、ユーザーが許容できるかどうかです。
もう 1 つは、ソフトウェアがソフトウェア要件記述の要件を満たしておらず、ユーザーが受け入れられない場合です。プロジェクトの現段階で発見された重大な誤りや逸脱は、通常、予定工期内に修正することが困難であるため、ユーザーと交渉して問題を適切に解決する必要があります。
2. ソフトウェア構成のレビュー
ソフトウェア構成のすべてのコンポーネントが完了し、品質が要件を満たしていることを確認します。ユーザーマニュアルおよび操作マニュアルに指定されている手順に従ってください。
5. システムテスト 通常の意味でのシステムテストには、ストレステスト（強度テストとも呼ばれます）、容量テスト、負荷テスト、パフォーマンステスト、セキュリティテスト、フォールトトレランステストなどが含まれます。
コンピュータ システムの一部として、ソフトウェアはハードウェア、ネットワーク、周辺機器、サポート ソフトウェア、データ、および人員と統合され、実際の環境またはシミュレートされた環境でコンピュータ システムをテストします。
目的は、システム要件と比較し、問題点を見つけることです。
プログラムのユーザー ドキュメントまたは文書を利用します。ターゲットドキュメントとユーザードキュメントを分析してテストケースを解明することにより、システムテストを設計します。
唯一の方法がないため、システム テストには多くの創造性が必要です。実際、優れたシステム テスト ケースを設計するには、システムやプログラムを設計するよりも多くの創造性、知恵、経験が必要です。
何も欠落しないようにするには、テスト ケースを設計するときに 15 種類すべてを考慮する必要があります。
能力テスト、容量テスト、強度テスト、ユーザビリティテスト、セキュリティテスト、
パフォーマンステスト、ストレージテスト、構成テスト、互換性/構成/変換テスト、インストールテスト、
信頼性テスト、回復性テスト、適合性テスト、文書化テスト、およびプロセステスト。
6. 受け入れテストには、正式な受け入れ、アルファ テスト、ベータ テストが含まれます。
ユーザー指向のテストにはソフトウェア開発者と品質保証担当者が関与し、ユーザーはテスト ケースを設計します。
システム全体をテストするのではなく、中核となるビジネス プロセスがテストされます。
契約、要件仕様書、または受け入れテスト計画に従って製品の受け入れテストを実施します。
受入テストに合格したソフトウェア製品は、「構成管理仕様書」に定められた識別方法を参照してテストステータスを変更するとともに、プロジェクト管理者の責任で「受入報告書」を作成してください。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。
書類の入手方法：
この文書は、[ソフトウェア テスト] に参加したい友人にとって、最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、私が最も困難な旅を乗り越えるのにも同行してくれました。また、あなたのお役に立てれば幸いです。
上記はすべて共有可能で、vx 公式アカウント「Programmer Hugo」を検索するだけで無料で入手できます。