エンティティ状態の要件
ほとんどの場合、エンティティの状態に関する明示的な要件はなく、テスターはそれらを自分で策定し、/ユーザーストーリーのユースケースから必要な情報を抽出する必要があります。 まだ要件がある場合は、次のようになります。
同様のチャートがある場合に最適です。 しかし、そうでなければ、それも大丈夫です。オブジェクトで可能な操作に関する利用可能な情報から独立して構築できます。
例：要件に応じた状態チャート
要件1 ：メールサーバーからメッセージを受信するとすぐに、未読としてマークされます。
要件2 ：ユーザーがメッセージをクリックしてコンテンツを開くと、メッセージは既読になります。
要件3 ：ユーザーは、以前に読んだメッセージを未読としてマークできます。
要件4 ：ユーザーはメッセージ（既読と未読の両方）を削除できますが、削除後にメッセージを返すことはできません。
これらの要件に従って、メッセージのこのような図を取得できます。
状態図に従ってテストを設計する方法
状態図の単純な肯定テストは、状態間の有効な遷移のチェックです。 矢印で示されたアクションを実行する機能。 ネガティブテスト-他のアクションを実行できないことを確認します。 したがって、必要な肯定的なテストの数-ダイアグラム内の矢印の数を計算するのは簡単です。 ネガティブテストの数も簡単に計算できます。
T-= N 2 -T + 、ここで、T-は否定的なテストの数、Nは状態の数、T +は肯定的なテストの数です。
上記の式は、状態図のマトリックス表現から簡単に取得できます。 この表現は次のように構成されます。
- 行列は正方形であり、行と列の数は図の状態の数に等しい。
- 行は発信矢印を示し、列は着信矢印を示します。
- 矢印が状態1を離れて状態2に入る場合、行1と列2の交点に+を入力します。
したがって、マトリックス内のプラスの数は陽性のテストに対応し、空のセル-陰性に対応します。 それらの数は上の式で計算されます。
状態をテストする際の最も難しいことは、テストの数を計算したり、何も忘れないことではなく（すべてのテストはマトリックスの助けを借りて簡単に考慮されます）、ネガティブテストに対応する実際のシナリオを設計することです。
このデータ表示により、特に時間メトリックが収集される場合、テストの評価が簡単になります。テストを記述する平均時間と完了する平均時間-各指標にN 2を掛けて追加するだけです。
例：メッセージ状態図のテスト
次の状態図のマトリックス表現を設計します。
したがって、このチャートには4つの単純な陽性検査と5つの陰性検査があります。
電子メールWebクライアントのネガティブテストを設計すると、次のようになります。
-未読-未読：
- 2つのブラウザタブでメッセージのリストを開きます。
- 読んだメッセージを見つけて、最初のタブで未読にします。
- 2番目のタブを更新せずに、手順2で選択した未読メッセージをマークします。
期待される結果：両方のタブのメッセージは未読としてマークされます。ステップ3ではエラーメッセージはありません。
-削除済み-削除済み：
- 2つのブラウザタブでメッセージのリストを開きます。
- 任意のメッセージを見つけて、最初のタブで削除します。
- 2番目のタブを更新せずに、手順2で選択したメッセージを削除します。
期待される結果：両方のタブのメッセージが削除され（メッセージリストから消えた）、ステップ3でエラーメッセージは発生しません。
このようなテストの設計は最も難しい部分です。上の表の空のセルのすべてがスクリプトを作成できるわけではない可能性があります（この例では可能です）。 ただし、これは、状態図のすべてのテストを考慮する最も簡単な方法です。
テストは明らかに2つの段階で構成されます。
- ポジティブテスト（既存の状態遷移）を正しく実行できることを確認します。
- 他の遷移がないことを確認してください（否定的なテスト）。
複雑な状態チャートのテスト
単純なポジティブテストは、上記のように、2つの状態間の1つの正しい遷移のチェックです。 したがって、ダイアグラムをテストでカバーするための最も単純な基準を定式化できます。状態間のすべての既存の遷移がテストされており、オブジェクトは各状態に少なくとも1回は存在しています。 ただし、複数の遷移で構成される、より複雑なシナリオテストを設計できます。 このようなテストは、さらに負荷テストに使用できます。 同様に、テストでのカバレッジのより強力な基準を設定できます。状態間、トリプル間などのすべての可能な遷移ペアがチェックされます。 （N-1まで。Nはオブジェクトの状態の数です）。 このようなコーティングは、Chow遷移コーティングまたはN-1遷移コーティングと呼ばれます。 したがって、最も弱いカバレッジは、遷移が0のカバレッジになります。
他の状態図アプリケーション
上記の状態図の適用は、完全に「古典的」ではありません。 「クラシック」フォームでは、状態図は、プログラムが可能な状態（たとえば、可能なすべての画面）とそれらの間の遷移（それぞれ、画面間を移動する方法）を表します。 ただし、このような図は包括的なテスト（カバレッジの定義による）には大きすぎる可能性があるため、複数の状態を1つに組み合わせて、必要に応じて詳細にできるより高いレベルのテストを設計することをお勧めします。
正式な仕様言語（VDM、Z、Bなど）のいずれかを使用して状態図を指定すると、テスト設計を自動化できます。 仕様の準備への正式なアプローチ、したがって、そのようなモデルに基づいたテスト（uniTESK）のための普遍的なソリューションがあります。 ただし、このようなツールを使用しなくても、状態図が大きすぎなければ、必要なテスト設計を手動で行うことができます。