「期待値」の「適切に」などの漠然とした言葉は嫌いです。「適切に」は、テストの「有毒な言葉」の一例にすぎません。排除しないと、この「アプローチ」が広まり、テスト全体が事実上無効になる可能性があります。人間のテスターにとっては「十分」かもしれませんが、そのような「テストケース」は、最初の探索的な「スモークテスト」の試みでのみ受け入れられます。
再現性があり、体系的で自動化できるものが何であれ、すべてのテストケースは具体的でなければなりません。（「すべき」だけでなく、「だろう」の柔らかさを許容できると仮定するのではなく、現在形の 「しなければならない」またはさらに厳密な「ある」を確認/拒否の主張として使用します。）そしてこのルール自動化に関しては絶対的です。
テスターが作成したのは、実際のテストケースではなく、むしろ「テストエリア」、「シナリオテンプレート」でした。考えられるテスト結果が非常に多く生成される可能性があるためです。非常に具体的な実際の「テストケース」でした。テストケースを自動化することは可能です。マシンに委任して、必要な頻度で自動的に評価することができます。（継続的インテグレーションサーバーからの自動レポートのボーナス付き）
しかし、「空のテストシナリオテンプレート」？これにもいくつかの価値があります。これは「シナリオテンプレート」であり、データで埋められるように準備された空のスケルトンです。したがって、これらの状況に「DDT」：「データ駆動型テスト」という名前を付けるのが大好きです。
10個の入力の検証、相互検証、および送信ボタンを使用して、テストするWebフォームを想像してみてください。すべての入力に対して10個のテストケースが存在する可能性があります。
- 空;
- 文字を使用しますが、とにかく短すぎます。
- サーバーには長すぎますが、フォーム内でコピー＆ペーストおよびさらなる編集が許可されています。
- 無効な文字で..。
私がお勧めするアプローチは、一連の合格データを準備することです。データを（DBから、またはランダムに）生成する場合でも、予測できるものはすべて、テストに合格する「ハッピーシナリオ」です。データをデータテンプレートとして脇に置き、それを使用してフォームを初期化し、入力してから、いくつかの単一の値をブレーキダウンします。「失敗する」テストケースを作成します。つまり、1つの入力ごとに10回、10個の入力ごとに10回（クロスルールが試行される前でも100個のテストケース）...そして、サーバーによるフォームの拒否が100回行われた後、入力します。フォームを歪ませることなく、データを渡すことでフォームを渡すことができるため、フォームを最終的に受け入れることができます。（承認された送信はserver-appでステータスを変更するため、同じapp-stateで101のケースすべてをテストするには、最後の1つとして実行する必要があります）
この方法でテストを行うには、次の2つが必要です。
- 空のシナリオテンプレート、
- および100行のデータのテーブル：
- 10列の入力データ：1つの値のみが操作され、テーブルを行ごとに渡す（つまり、グレイコードについて聞いたことがありますか？）
- 継承履歴を行記述に保持する可能性があります。ここで、fromは行が派生し、どのように、どの操作値を介して行われます。
- また、11番目の列である「期待される結果」の列に入力されています。テストカバレッジ追跡の要件への参照として、期待されるステータス、期待されるエラー/検証メッセージを合格/不合格にします。（つまり、FitNesseを見たことがありますか？）
- また、テストが実行されたときに実際に検出された結果の列も、単一行のテストケースの履歴を追跡するために使用されます。（したがって、CIサーバーはすでに述べました）
一方の「空のシナリオスケルトン」ともう一方の「テストを実行するためのデータテーブル」を組み合わせるには、確かに何らかのメカニズムが必要です。そして、データをインポートする必要があります。したがって、理論的にはインポートすることもできるExcelで行を準備できますが、より簡単な生活のために、CSV、プロパティ、XML、または機械と人間が読み取れる形式のテキスト形式のいずれかをお勧めします。