テスト ケース設計の最も基本的な要件は、テスト対象の機能をカバーすることです。これは最も基本的な要件ですが、単純な文として見ないでください。包括的なカバレッジを達成するには、テスト対象製品の機能を包括的に理解し、明確なテスト範囲を設定する必要があります (特に、テストする必要のないものを明確にする)テスト対象）、基本的なテスト技術（等価クラス分割など）を習得している。では、上記の要件を満たすように設計されたテスト ケースは良いテスト ケースでしょうか?
回答: 理論的にはそうですが、実際のエンジニアリングではそうではありません。理論と現実にこれほどの違いがあるのは、理論上は考慮しなくてもよいものでも、実際のエンジニアリングではコストというものを考慮しなければならないからです。ここでのコストには、テスト計画コスト、テスト実行コスト、自動テスト ケース、テスト自動化コスト、テスト分析コスト、テスト実装の技術的制限、テスト環境のバグ、人的要因、予測不可能なランダム要因などによって発生する追加コストが含まれます。 . .
コスト要因の介入により、プロジェクトにおける適切に設計されたテストケースの原則は、「住宅でテストする機能をカバーする」ことに限定されないことがわかりました。私の職歴に基づいて、レンガを作って私を修正してください。これらの原則は、特に自動化して頻繁に実行する必要があるテスト ケースに当てはまります。
1. 単一のユースケースの範囲を最小限に抑える原則
この原則は、これら 4 つの原則すべての中で「ボス」であり、エンジニアリングにおいて最も忘れられやすく無視されやすいものでもあり、多かれ少なかれ他のいくつかの原則に影響を与えます。ここで紹介する例は、関数 A をテストする場合、それには 3 つのサブ関数ポイント A1、A2、および A3 があります。テスト ケースを設計するには 2 つの方法があります。
方法 1: 1 つのテスト ケースで 3 つのサブ関数をカバーする - Test_A1_A2_A3、
方法 2: 3 つの個別のユース ケースを使用して 3 つのサブ関数 - Test_A1、Test_A2、Test_A3 をカバーします。
方法 1 は小規模プロジェクトに適していますが、次の利点があるため、規模と品質の要件が小規模なプロジェクトには方法 2 の方が適しています。
テストケースの適用範囲の境界がより明確に定義される
テスト結果は製品の問題をより明確に示します
テスト ケース間の結合が最小になると、相互の干渉が少なくなります。
これらの利点の直接的な利点は、テスト ケースのデバッグ、分析、メンテナンスのコストが最小限で済むことです。
各テスト ケースはできる限りシンプルで、検証したいことだけを検証する必要があり、すべてを持ち込んで「草を捕まえてウサギを倒す」ようなことは、テスト実行フェーズの負担とリスクを増大させるだけです。
David Astels は、著書『テスト駆動開発: 実践ガイド』の中で、テスト ケースに対して Assert ステートメントを 1 つだけ使用するのが最善であると説明しています。さらに、機能的なポイントをカバーするシンプルで明確なテスト ケースは、新しいテストを生成するために組み合わせるのにも便利です。順序付きテストの概念は Visual Studio で導入されました。
2. 製品ドキュメント機能を置き換えるテスト ケースの原則
通常、開発の初期段階 (各スクラム スプリントの最初の 2 日間) では、Word ドキュメントまたは OneNote を使用して、製品要件、機能の説明、および現時点で決定できる詳細を記録し、機能の外観の概要を説明します。チーム内でコミュニケーションを図り、製品の機能を改良し、合意に達するのに便利です。この時点で合意に達した後、説明されている機能が A であるとします。製品開発が深まるにつれて、チームは製品の機能についての最新の理解を持ち、製品の機能がより具体的かつ洗練されていきます。イテレーションまたはスプリント その時点で、最終的に実現される機能は A+ になる可能性があります。このようにして、常にユーザーのフィードバックに耳を傾けて吸収し、製品の機能を修正し、何度も繰り返した結果、当初 A として説明されていた機能が最終的に Z になる可能性があります。
ここで、以前の Word 文書と OneNote ページを確認しますが、A はまだ記録されています。その理由は、製品機能の現在の正確な状態を正確に反映するためにこれらのドキュメントを更新し続けようとしている (そして更新できる) 人がほとんどいないためです。やりたくないわけではありませんが、本当に難しいです! ここで注意してください: 初期の Word または OneNote ドキュメントが依然として必要であり、これにより、少なくともチームが実装される機能について一貫性のある正確な理解を確保できます。初期の反復。
製品の機能を一貫して正確に説明するものはありませんか?
回答: もちろん、それは製品コードとテスト ケースです。製品コードは製品機能を実現するものであり、製品の現在の機能を正確に記述する必要がありますが、オブジェクト指向、抽象化、デザインパターン、リソースファイルなどのさまざまなプログラミング手法により、製品コードを表現することは困難です。読みやすい 機能を理解するためにコードを見るのではなく、製品の機能を知ることを前提としてコードを読むことがよくあります。
優れたコードには詳細なコメントが付いていますが、ここでのコメントは実装コードの説明とメモであり、製品の機能の説明ではありません。
その場合、テスト ケースのみが存在し、テストは製品の機能を忠実に反映する必要があります。そうでない場合、テスト ケースは実行に失敗します。これまではテストケースを単なるテストケースとして捉えていましたが、テストケースの理解はさらにレベルアップし、製品説明文書としての機能も果たせるようになるべきです。
そのためには、作成するテスト ケースが十分に詳細であり、テスト ケースの構成を調整して優先順位を付ける必要があり、Word、Excel、OneNote などの汎用ツールでは到底完成できません。 Visual Studio 2010 への Microsoft Test Manager の導入など、テスト ケース管理ツールが必要です。
さらに、自動化されたテスト ケースの場合 (API レベルか UI レベルかに関係なく)、コードは製品コードとは異なるスタイルで記述する必要があり、読みやすさと説明しやすさが重要な考慮事項となります。もちろん、テストコードにはオブジェクト指向やデザインパターンなどの優れた設計思想を導入することもできますが、それらの導入はほどほどにし、プロセス指向のコーディング手法の方が整理しやすく、読みやすく、記述しやすい場合が多いです。
3. 単一入力コストと複数入力コストの原則
これはテストケースを判断するための原則というよりも、問題を考えるための思考の角度および原則と言ったほうがよいでしょう。プロジェクトの意思決定において常に考慮すべき要素はコストであり、プロジェクト内のテストも同様であり、コストの考慮はテストの設計、実行、保守の全段階において客観的かつ包括的に反映される必要があります。テスト中にジレンマに遭遇し、意思決定が必要になった場合は、コストの観点から分析してみると、意思決定に役立つ可能性があります。
テストのコストは、期間に応じて単一入力コストと複数入力コストに分類できます。
例: テスト ケースの作成は、一般にテストの計画段階 (スクラムの各スプリントの開始段階) で実行されるため、テスト ケースの作成は 1 つの入力コストとみなすことができます。ただし、後で小さな変更は発生しますが、ほとんどの場合、基本的には初期設計段階で形成されます。自動テスト ケースにも同様のことが当てはまり、これも 1 回限りの投資です。テスト ケース (手動テスト ケースと自動テスト ケースを含む) の実行には複数の入力コストがかかります。新しいバージョンが構築されると、すべてのテスト ケースを実行する必要があり (BVT テストの場合は優先度の高いテスト ケースのみが実行されます)、テスト結果が分析され、テスト ケースの失敗がデバッグされ、テスト ケースの失敗の原因が特定されるためです。 (製品の欠陥、テスト ケースの欠陥、テスト ケースのフレームワークの欠陥、またはテスト ケースの失敗につながるランダムな問題)、バージョンの全体的な品質が指定された基準を満たしていることを検証します。
単一コストと複数コストを導入する理由は、テストのテスト コストに対するさまざまなアクティビティの影響を区別し、さまざまな段階で投資を合理的に配置し、正しい決定を下せるようにするためです。限られたテスト費用を負担できることを前提として、最大限効率的にテスト作業を行うことができます。たとえば、テスト ケースの設計と自動化は 1 回限りの投資であるのに対し、テスト ケースの実行は繰り返しの投資であることがわかれば、繰り返しの投資が必要なテスト実行の効率を向上させる方法を積極的に考える必要があります。 1 回限りの投資と複数の活動のバランスをとる必要がある場合、複数の投入活動の効率を優先する必要があります。実際、ここで実行できる作業はたくさんあります。
例: 最初の原則 (単一のユース ケースの範囲を最小限に抑える原則) は良い例です。A 関数の 3 つの関数ポイント A1、A2、A3 を表面上でテストし、設計時にユース ケース Test_A1_A2_A3 を使用します。最も単純ですが、繰り返しの実行フェーズで多くの問題が発生します。
まず第一に、このようなユースケースの障害分析は比較的複雑であり、どの機能ポイントがテスト障害の原因となったかを確認する必要があります。
次に、自動化ユースケースのデバッグはより複雑で、A3 関数ポイントに問題がある場合は、A3 に到達する前に A1 と A2 を継続的に通過する必要があり、デバッグ時間と複雑さが増加します。
第三に、多くのステップを含む手動テスト ケースは手動実行の不確実性を高め、多くのステップを含む自動テスト ケースは自動実行の失敗の可能性を高めます。特に UI 自動化テクノロジに基づくユース ケースです。
第 4 に、(最後に重要なことですが) 無関係な機能ポイントを結合すると、製品回帰欠陥の早期検出の可能性が減ります。これはテスト作業ではタブーです。例: Test_A1_A2_A3 が自動テスト ケースで、A1->A2->A3 の順序で実行される場合、A1 にバグがあるとテスト ケース全体が失敗し、A2 と A3 はテストによって実行されません。現時点で何らかの理由で A1 のバグの修正に時間がかかる場合、Test_A1_A2_A3 は常に A1 のバグが原因で失敗したとみなされますが、A2 と A3 は常にカバーされておらず、ここには潜在的な危険と抜け穴が存在します。 。
製品がリリースされる前に最終的に A1 のバグを修正し、Test_A1_A2_A3 が合格するのが当然だと考えると、この時点で A2 と A3 の問題が発生し、A2 の問題を修正するために残業を続けなければなりません。そしてA3。心配するわけではありませんが、A2/A3 のコードが A1 のバグ修正に関連している場合、このように設計されたテスト ケースが多数ある場合、問題はさらに悪化する可能性があります...、本当に! :(
要約すると、Test_A1_A2_A3 の設計は、1 回限りの設計と自動化の投資を削減するだけで、複数の投資を必要とするテスト実行の負担とリスクを増加させます。特にテスト ケースを設計する場合) Test_A1_A2_A3 または Test_A1、Test_A2、および Test_A3 を選択します。投資コストを必ず考慮してください。
4. テスト結果の分析とデバッグを簡素化する原理
この原則は、実際には、自動テスト ケースに対する前の原則 (単一入力コストと複数入力コストの原則) の拡張および継続です。自動テスト コードを作成する場合は、ユース ケース ログ、デバッグ補助情報の出力など、テスト結果の分析とテストのデバッグを容易にする方法を考慮することが重要です。
テスト ケースの実行は複数の投資に属するため、テスターはテスト結果を分析し、テスト ケースを頻繁にデバッグする必要があり、この部分の活動への投資は多額になります。場合によっては、テスト フレームワークによって提供されるいくつかの補助 API が、この原則を適切に実現するのに役立ちます。例: コード化された UI テストは、同様の API を提供します。「VS 2010 テスト関数の学習 (18)」を参照してください。 - コード化された UI テストは、コード化された UI フレームワークのエクスペリエンスに基づいた自動テスト ケースのデバッグを改善するために知っておくべき 3 つの関数です。
テスト理論はテスト作業の一般的な方向性を示しますが、実際のエンジニアリングでは、理論と実践をよりよく適合させるために、これらの理論を常に「有効化」する必要があります。私の考えでは、ソフトウェア エンジニアリング プロジェクトは、成功しても失敗しても、良くても悪くても、関係する私たち一人ひとりにとって非常に貴重なものです。思いやりのある私たちは、本には書かれていない多くのことを経験しており、観察し、経験し、まとめ続けることで、自分自身の知識、理解、発見が増えます。コードとテストの美しさを称賛する本を書く人はたくさんいますが、もっと客観的に見ることができるかどうかを考えてみましょう。実際、エンジニアリング プロジェクトも美しいのです。
最後に: 以下はサポート学習教材です。[ソフトウェア テスト] を行う友人にとって、これは最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を私に同行させてくれました。あなたにも役立つことを願っています。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクには、何百万人もの人が参加しました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
