state transition testing technique
状態遷移テストとは何か、および状態遷移図の使用方法を学びます。
前回の記事では、「 原因と結果のグラフ のテストケース作成手法。今日は、次の動的テストケースの記述方法である状態遷移手法に移りましょう。
このドキュメントでは、このテストコンセプトを、全体としてFSMではないが、一部のコンポーネントが「ステートフル」であるという独自の機能と移行ルールを採用するために、より大きなアプリケーションに拡張する方法について説明します。これにより、多くの利点が得られます。
状態遷移テスト
状態遷移テストは ブラックボックステスト手法 、「有限状態機械」のテストに適用できます。
「有限状態機械（FSM）」は、入力または刺激に応じて、さまざまな離散状態（「準備完了」、「準備完了」、「開」、「閉」など）になるシステムです。
システムが最終的になる離散状態は、システムの遷移のルールに依存します。つまり、システムが同じ入力に対して以前の状態に応じて異なる出力を提供する場合、それは有限状態システムです。
さらに、すべてのトランザクションがシステムでテストされる場合、それは「0スイッチ」カバレッジと呼ばれます。テストが有効なトランザクションの2つのペアをカバーする場合、それは「1スイッチ」カバレッジなどです。
学習内容：
状態遷移テスト手法とは何ですか？
状態遷移手法は動的テスト手法であり、システムが有限数の状態に関して定義され、状態間の遷移がシステムのルールによって管理されている場合に使用されます。
つまり、この手法は、システムの機能が相互に変換される状態として表される場合に使用されます。変換は、ソフトウェアのルールによって決定されます。絵の表現は次のように表示できます。
だからここで私たちはエンティティが トランジション いくつかの理由で州1から州2へ 入力 状態、これは イベント 結果として アクション そして最後に 出力 。
例を挙げて説明するには：
あなたはATMに行き、$ 1000を引き出します。あなたはあなたの現金を手に入れます。今、あなたはバランスを失い、1000ドルを引き出すというまったく同じ要求をします。今回、ATMは残高不足のためあなたにお金を与えることを拒否します。だから、ここに 遷移 、原因となった 状態変化 以前の撤退です
状態遷移テストの定義
状態遷移とは何かを理解したので、状態遷移テストのより意味のある定義に到達できます。したがって、これは一種のブラックボックステストであり、テスターは、シーケンスで指定されたさまざまな入力条件に対してAUT（テスト対象アプリケーション）の動作を調べる必要があります。
システムの動作は、正と負の両方のテスト値について記録されます。
状態遷移テストをいつ使用するか？
状態遷移テストは、次の状況で使用できます。
リレーショナルデータベースと非リレーショナルデータベースの長所と短所
- テスト対象のアプリケーションが、さまざまな状態と遷移が含まれるリアルタイムシステムである場合。
- アプリケーションが過去のイベント/値/条件に依存している場合。
- イベントのシーケンスをテストする必要がある場合。
- 有限の入力値のセットに対してアプリケーションをテストする必要がある場合。
状態遷移テストを使用しないのはいつですか？
次の状況では、状態遷移テストに依存しないでください。
- 順次入力の組み合わせでテストが不要な場合。
- アプリケーションのさまざまな機能をテストする必要がある場合（探索的テストなど）。
ソフトウェアテストにおける状態遷移テストの例
実際のシナリオでは、テスターには通常、状態遷移図が与えられ、それを解釈する必要があります。
これらの図は、ビジネスアナリストまたは利害関係者によって提供され、テストケースを決定するためにこれらの図を使用します。
以下の状況を考えてみましょう。
ソフトウェア名 – Manage_display_changes
仕様– ソフトウェアは、入力要求に応答して、時間表示デバイスの表示モードを変更します。
表示モードは、次の4つの値のいずれかに設定できます。
- 時刻または日付の表示に対応する2つ。
- 時刻または日付を変更する場合の他の2つ。
さまざまな状態は次のとおりです。
- モード変更（CM）： これを有効にすると、表示モードが「表示時間（T）」と「表示日（D）」の間で移動します。
- リセット（R）： 表示モードがTまたはDに設定されている場合、「リセット」により、表示モードは「時間変更（AT）」または「日付変更（AD）」モードに設定されます。
- タイムセット（TS）： これを有効にすると、表示モードがATからTに戻ります。
- 日付セット（DS）： これをアクティブにすると、表示モードがADからDに戻ります。
状態遷移図
それでは、解釈に移りましょう。
ここに：
＃1）さまざまな状態は次のとおりです。
- 表示時間（S1）、
- 変更時間（S3）、
- 表示日（S2）、および
- 変更日（S4）。
＃2）さまざまな入力は次のとおりです。
- モード変更（CM）、
- リセット（R）、
- タイムセット（TS）、
- 日付セット（DS）。
＃3）さまざまな出力は次のとおりです。
- 時間の変更（AT）、
- 表示時間（T）、
- 表示日（D）、
- 日付の変更（AD）。
＃4）変更された状態は次のとおりです。
- 表示時間（S1）、
- 変更時間（S3）、
- 表示日（S2）と
- 変更日（S4）。
ステップ1： すべての開始状態を書き込みます。このために、一度に1つの状態を取り、そこからいくつの矢印が出ているかを確認します。
- 状態S1の場合、そこから2つの矢印が出ています。 1つの矢印は状態S3に移動し、別の矢印は状態S2に移動します。
- 状態S2の場合–2つの矢印があります。 1つは状態S1に行き、もう1つはS4に行きます
- 状態S3の場合– 1つの矢印のみが出て、状態S1に移動します
- 状態S4の場合– 1つの矢印のみが出て、状態S2に移動します
これをテーブルに置きましょう：
状態S1とS2については、2つの矢印が出ているので、2回記述しました。
ステップ2： 各状態について、最終的な遷移状態を書き留めます。
- 状態S1の場合–最終状態はS2とS3です
- 状態S2の場合–最終状態はS1とS4です
- 状態S3の場合–最終状態はS1です
- 状態S4の場合–最終状態はS2です
これを出力/結果状態としてテーブルに配置します。
ステップ3： 各開始状態とそれに対応する終了状態について、入力条件と出力条件を書き留めます
–状態S1が状態S2に移行する場合、入力は変更モード（CM）であり、出力は以下に示す表示日付（D）です。
同様に、すべての状態の入力条件とその出力を次のように書き留めます。
ステップ4：
c ++二重リンクリスト
次に、以下に示す各テストのテストケースIDを追加します。
それでは、正式なテストケースに変換しましょう。
このようにして、残りのすべてのテストケースを導き出すことができます。私は他を仮定します テストケースの属性 前提条件、重大度、優先度、環境、ビルドなどもテストケースに含まれています。
手順をもう一度要約します。
- 初期状態から出てくる線/矢印に基づいて、初期状態とその最終状態を特定します。
- 初期状態ごとに、入力条件と出力結果を確認します
- 各セットを個別のテストケースとしてマークします。
状態遷移手法のその他の例
これは、より大きなソフトウェアアプリケーションでの状態遷移テスト手法のもう1つの例です。
説明：
' ステートフル機能テスト」 アプローチは、有限状態マシン（FSM）の特性を使用して、アプリケーションの特定のパーツまたはコンポーネントをテストするために使用できます。
実装のステップ：
＃1） 「ステートフル機能テスト」を実装するための最初のステップは、FSMとして分類できるアプリケーションのさまざまなコンポーネント/パーツを特定することです。入力、状態、および出力は、これらのFSMごとに注意深く追跡されます。
＃二） 次のステップは、遷移ルール、入力、出力、および遷移状態に基づいて、これらのFSMのテストケースを開発することです。
＃3） 3番目のステップは、アプリケーションをエンドツーエンドで検証するために、これらのコンポーネントのテストを他のインターフェイスコンポーネントと統合することです。
これは、住宅の建築の承認、区画と住宅の登録、建築請負業者の選択などのさまざまなアプリケーションコンポーネントを使用して、住宅の建設を追跡する「住宅プロジェクト」という名前のアプリケーションの例によって説明できます。 、住宅ローンの承認など。
例えば、
「住宅プロジェクト」アプリケーションの1つのFSMコンポーネントである住宅ローンの承認をテストすることを検討します。
住宅ローン承認申請書（HLA）
HLAアプリケーションは、ローン申請を処理する独立したローン処理ユーザーによって実行されます。アプリケーションの処理におけるさまざまなステップの詳細を以下に示します。
1.1.1ステップ1：ドキュメントの収集
最初のステップは、以下の表に記載されているように、ローンを申請するための関連文書の収集です。これらは、アプリケーションを成功させるための「条件」です。申請者は必要な書類を集めて住宅ローンに申請します。
ローン処理ユーザーは、ドキュメントの受信を確認し、ローンアプリケーションの状態（つまり、HLAアプリケーションコンポーネントの状態）を「適用済み」状態に移行します。
表1：ドキュメントのリスト
1.1.2ステップ2：ローン評価
この段階で、貸し手はローン申請書を評価して、それが彼の信用要件を満たしているかどうかを判断します。この時点で、サポートドキュメントが検証されます。
表2：ドキュメントの重要度
評価に必要な文書、つまりこの段階で検証する必要のある「条件」が検証されます。各条件には重要度が付加されています（上の表では「Y」と記載されています）。必要なすべての重要な条件が満たされると、アプリケーションは「確認済み」状態に移行します。つまり、HLAアプリケーションコンポーネントは「確認済み」状態になります。
注意点：
＃1） この原則は、システムのテスト条件と「状態」定義に構造と客観性をもたらします 。
また、システムを検証するためのすべての「条件」が、システムがこの「確認済み」状態に到達するために重要であるとは限りません。上記の表では、アプリケーションが「確認済み」状態に到達するために、4つの条件が「重要ではない」とマークされています。
＃二） 各州に必要なルールのリスクまたは重要度に応じて、検証の数を最適に減らすことができます。これにより、テストの実行に必要な時間が大幅に短縮されると同時に、テストの品質が損なわれることはありません。
＃3） これは、個々のコンポーネントをテストするだけでなく、システムをエンドツーエンドでテストする場合にも役立ちます。
＃4） また、回帰テストスイートを作成するときに非常に便利です。
したがって、この段階では、0スイッチタイプのテストです。ただし、承認の後の段階では、その段階の1スイッチまたは2スイッチタイプの検証を行うことができます。
例えば、 「結婚証明書」はこの段階ではあまり関連性がないかもしれませんが、申請者がEMIを支払うリスクが考慮されている承認の後の段階で、結婚証明書が関連性を持つようになる可能性があります。つまり、配偶者も雇用されている場合です。 、それはリスクを減らし、採用されない場合、それはリスクを高めます。
＃5） 上記の原理は、その段階でのコンポーネントの要件に応じて、テスト条件を拡張するために使用できます。
1.1.3ステップ3：条件付き承認
アプリケーションの現在の状態は「確認済み」です。貸し手は、融資プロセスを進めるための「条件付き承認」を与えます。 HLAアプリケーションを「承認済み」状態に移行するには、さらに検証が必要です。
1.1.4ステップ4：承認
重要な検証はこの段階で行われます。
- 貸し手住宅ローン保険（LMI）による評価：これには、物件の真正性について2スイッチ以上の検証が含まれます。
- 貸し手は、「確認」段階で提供されなかった情報を要求する場合があります。
上記の条件が満たされると、アプリケーションは「承認済み」状態に移行します。承認プロセスの最終的な権限は、詳細を尋ねることによってローン申請者の信頼性をクロスチェックする場合もあれば、申請者の他の文書が決定的であるかどうかを尋ねない場合もあります。つまり、有効性を証明するには、メインアプリケーションのさまざまなコンポーネントからのより多くの入力が必要になります。 。
＃6） 言い換えると、アプリケーションの他のコンポーネントからコンポーネントへの入力条件に応じて、別の状態に移行するために、より多くの検証が必要になる（または削減される）場合があります。
次の図は、承認プロセスを示しています。
図1：ローン承認プロセス
リスクと課題
- 大規模なアプリケーションの場合、アプリケーションをさまざまな論理コンポーネントに分割してFSMおよび通常のコンポーネントとして分類できるようにするには、アプリケーションに関する深い知識が不可欠です。これには、SMEからのコストのかかる時間が必要になる場合があります。
- すべてのアプリケーションがこの種のFSM分類の実現可能性を備えているわけではありません。
- FSMコンポーネントはアプリケーション内の通常のコンポーネントと相互作用するため、さまざまなコンポーネントからFSMへの入力には、慎重な計画と実行が必要です。
状態遷移テストの利点
- この手法では、システムの動作を図式または表形式で表現することにより、テスターはアプリケーションの設計に精通し、テストを効果的かつ効率的にカバーおよび設計することが容易になります。
- システムの計画外または無効な状態も、この手法を使用してカバーされます。
- 状態遷移図を使用すると、すべての条件が満たされているかどうかを簡単に確認できます。
状態遷移テストのデメリット
- この手法は、非有限状態システムには使用できません。
- 大規模で複雑なシステムのすべての可能な状態を定義することは、非常に面倒な作業です。
結論
状態遷移テストは、有限状態システムに対してさまざまなシステム遷移をテストする必要がある場合に役立つアプローチです。
「ステートフル機能テスト」の概念を使用してアプリケーションをテストすると、複雑なアプリケーションをテストするための独自のテストアプローチがテスト組織に提供され、テストカバレッジを犠牲にすることなくテスト実行の生産性が向上します。
状態遷移テストは、複雑なアプリケーションをテストするための独自のテストアプローチであり、テストカバレッジを犠牲にすることなくテスト実行の生産性を向上させます。
この手法の制限は、テスト対象のシステムの状態が有限である場合を除いて、使用できないことです。