ソフトウェアのテストプロセスは次のとおりです。
- テスト計画
- テスト設計
- テストの実行
- 単体テスト
- 統合テスト
- 確認テスト
- システムテスト
- 受け入れテスト
- 回帰試験
- アクティビティを確認する
テスト計画
テスト計画は、各テスト フェーズの目標と戦略を決定するためにテスト リーダーによって作成されます。このプロセスでは、テスト計画を出力し、完了するテスト アクティビティを明確にし、アクティビティを完了するために必要な時間とリソースの見積もりを行い、アクティビティの配置とリソースの割り当てを実行します。
テストベースは主にプロジェクト開発計画とテスト要件の分析結果に基づいて策定されます。
2: テスト設計
テスト計画に従ってテスト スキームを設計します。テスト設計プロセスの出力は、各テスト フェーズで使用されるテスト ケースであり、各テスト要件に設定されるテスト ケースを決定し、テスト ケースを実行するテスト プロセスを決定します。
ソフトウェアテスト計画、ソフトウェア要件、ソフトウェアアーキテクチャ設計、ソフトウェア詳細設計、その他の文書に従って、テストケースを次のように設計します。
- テスト要件ごとに、必要なテスト ケースを決定します。
- テスト ケースごとに、その入力と期待される結果を決定します。
- テスト環境の構成とテスト ケースに必要なドライバーを決定します。
- テストケースのドキュメントを書く
- テストケースのピアレビュー
3: テストの実行
図に示すように、テスト実行プロセスは、単体テスト、統合テスト、検証テスト、システム テスト、受け入れテストなどのテスト フェーズに分かれています。
4: 単体テスト
単体テストはソフトウェア開発プロセスにおける最も低いレベルのテスト活動であり、テストの目的はソフトウェア設計の最小単位です。単体テストはモジュールテストとも呼ばれます。
多くの人がユニットの概念をクラスの具体的な関数またはメソッドと誤解していますが、これは正確ではありません。最小単位として明確な機能定義、性能定義、インターフェース定義があり、他の単位と明確に区別できるものでなければなりません。メニュー、表示インターフェイス、または独立して実行できる特定の機能をユニットにすることができます。ある意味、ユニットの概念がコンポーネントに拡張されたものです。
単体テストの環境:
ソフトウェア全体では各モジュールが分離されていないため、各モジュールの単体テストを行う際には周囲のモジュールとの相互接続を
考慮する必要があります。
この接続をシミュレートするには、単体テスト中に
いくつかの補助テスト モジュールをセットアップする必要があります。これらの補助モジュールは 2 つのタイプに分類されます。
- ドライバモジュール（ドライバ）：被試験モジュールの上位モジュールをシミュレートするために使用され、被試験モジュールのメインプログラムに相当します。
- スタブ モジュール (stub): テスト対象モジュールの下位モジュールをシミュレートするために使用されます。テスト対象モジュールによって呼び出されるサブモジュールに相当します。
単体テストの実行方法
単体テストは次の 2 つの方法で実行できます。
単体テストの欠点:
- モジュールが相互に呼び出しを行うと、新たな問題が発生します。
- いくつかのサブ機能を組み合わせてもメイン機能を実現することはできません。
- エラーは許容できないレベルまで蓄積されます。
- グローバルデータ構造などのエラー
統合テスト
OKテスト
結合テストが完了すると、個別に開発されたモジュールが接続されて完全なプログラムが形成されます。その中で、モジュール間のインターフェースに存在するさまざまな問題が解消されました。そこで確認テストのフェーズに入った。
確認テストは、ソフトウェア製品をソフトウェア要件仕様に照らして評価し、要件仕様を満たしているかどうかを判断するプロセスです。最終的なソフトウェア製品が正しいかどうかが決まります。
テストの戦略を決定します。
- 要件ベースのテスト: ブラックボックス テスト戦略を使用すると、詳細な設計仕様やコードを知らなくてもユーザー要件がテストされます。要件ベースのテストでは、機能設計仕様に基づいてテスト ケースを設計します。
- 機能ベースのテスト: ブラックボックス戦略を採用し、機能設計仕様に従ってテスト ケースを設計し、等価クラス分割、境界値分析、故障推定などの方法を使用します。
- 内部ベースのテスト: ホワイトボックス テスト戦略のみを使用できますが、機能設計仕様を使用してテスト計画を作成できます。ホワイトボックス テストが採用されると、一連の手法を使用して、システムの内部部分が完全にテストされ、十分なロジック カバレッジが達成されることを確認できます。
システムテスト
システム テストは実際には、システム内の各コンポーネントの包括的な検査であり、私たちの日常のテスト実践に非常に近いものです。
システム テストの目的は、ソフトウェアの障害を見つけることではなく、システムのパフォーマンスを実証することです。
注意：系统开发人员和组织不能负责系统测试，系统测试最好由独立的测试机构完成。
受け入れテスト
受け入れテストは、最終製品とエンドユーザーの現在のニーズを比較するプロセスであり、ソフトウェア開発が完了し、ソフトウェア製品がユーザーに提供される前の最後の品質検査活動であり、開発されたソフトウェア製品が適切であるかどうかを答えます。期待される要件を満たしているか、ユーザーの受け入れなど。
受け入れテストでは、ソフトウェアの特定の側面の品質をチェックするだけでなく、包括的な品質検査を実施して、ソフトウェアが適格であるかどうかを判断します。したがって、受け入れテストは厳密に正式なテスト作業であり、開発環境ではなく実稼働環境で実行する必要があります。
回帰試験
回帰テストは、バグ修正の結果として新しいバグが導入されたかどうかを判断するプログラムのテストです。
回帰テストは新しいテスト活動ではなく、一部またはすべてのテスト ケースを再実行して、障害の修復によって新しい障害が発生するかどうかを確認するプロセスです。
アクティビティを確認する
検証活動は、要件検証、機能設計検証、詳細設計検証、コード検証など、テスト ライフ サイクルの各段階で行われます。各検証活動において、テストの目的はできるだけ多くの欠陥を見つけることであり、テスターはソフトウェアのレビューやウォークスルー作業に積極的に参加し、検証作業を実行する必要があります。
さあ、テスターの皆さん！計画を改善する必要がある場合は、実行してください。最初から様子見するよりも、途中で行動する方が良いでしょう。未来のあなたはきっと、頑張っている今のあなたに感謝してくれるはずです！
