ここでは、等価クラス、境界値テスト、ペアワイズ テストなどのよく知られ広く使用されているテスト設計手法については説明しません。その他のあまり一般的ではない手法について説明します。 に関する私の記事もお読みください。 組み合わせテスト設計手法の問題 デシジョンテーブルのテスト デシジョンテーブルは、要件を文書化し、アプリケーションの機能を説明するための優れたツールです。これらのテーブルは、アプリケーションのビジネス ロジックを説明するのに非常に便利であり、さらに、テスト ケースを作成するための強固な基盤としても機能します。テストされたアプリケーションに適切なドキュメントが不足している場合は、デシジョンテーブルを使用する十分な理由になります。要件をコンパクトでシンプルな形式で提示すると、テスト ケースの作成が非常に簡単になります。 アプローチ： デシジョン テーブルは、システム状態のエンティティ (プロパティ/条件) に基づいてアプリケーションのロジックを記述します。各デシジョンテーブルは、システムの 1 つの状態のみを記述する必要があります。 ルール1 ルール2 … ルールN エンティティ プロパティ 1 … 物件M 行動 アクション 1 … アクションP 1 から M までの Entity (Property) はシステムのさまざまなプロパティを表します。これらは、システムに入力できる入力データとしてテーブルに表示されます。 1 から P までのアクションは、エンティティの指定された組み合わせで発生する可能性のあるアクションです。エンティティのすべての入力データの組み合わせに応じて、アクションは必要な値をとります。各ルールは、特定のアクションの実行につながるすべてのプロパティに対する一意の入力データのセットを定義します。 デシジョンテーブルを作成した後、通常、不可能なシナリオの一部またはすべてを削除するなどしてテーブルを簡素化することができます。次に、テーブルをテスト ケースに変換できます。 状態遷移テスト 状態遷移テストは、デシジョンテーブルテストと同様、要件を文書化し、システムの構造と設計を説明するための貴重なツールです。特定のシステム状態を説明するデシジョンテーブルテストとは異なり、状態遷移テストはシステムのこれらの状態がどのように変化するかを説明します。ダイアグラムは、アプリケーションの動作中に発生するすべてのイベントと、アプリケーションがこれらのイベントにどのように応答するかを定義します。 アプローチ： この手法の視覚的表現には 2 つのタイプがあります。 状態遷移図 状態遷移テーブル 状態遷移図 例として、航空券の予約を考えてみましょう。これは大まかに次のように動作します。最初に、顧客は予約のための情報 (出発地、目的地、日付、出発時刻) を航空会社に提供します。航空会社の従業員は、顧客と航空券予約システムの間のインターフェイスとして機能し、顧客が提供した情報を使用して予約を作成します。その後、お客様の予約は「完了」状態となります。さらに、予約の作成後、システムはタイマーを開始します。タイマーが期限切れになり、予約したチケットの支払いが行われない場合、システムはそのチケットの予約をキャンセルします。 円は航空券予約システムの状態、つまり「Made」状態を表しています。矢印は「Made」状態への遷移を示します。矢印の下の説明 (「get_info」) はシステム外部から発生したイベントです。説明内の矢印の下 (「/」の後) のコマンドは、システムがイベントに応じて何らかのアクションを実行したことを示します (この場合はタイマーの開始)。黒丸は、図の開始点/入口点を示します。 タイマーが期限切れにならず、予約したチケットの支払いが完了している場合、システムは「支払い済み」状態になります。これは、「payMoney」というラベルの付いた矢印と、「Made」状態から「Paid」状態への遷移によって示されています。 (図では円で表されます) これは、1 つ以上のイベントを待機するシステムの状態です。この状態は、それまでに受信した入力データを記憶し、受信したイベントに対してシステムがどのように反応するかを示します。イベントはアクションをトリガーしたり、状態の変化を引き起こしたりすることがあります。 状態 : (図では矢印で表されます) これは、イベントによって発生する、ある状態から別の状態への遷移を表します。 遷移 : (矢印の上の四角形で表されます) イベントは、アプリケーションの状態を変更する原因となるものです。イベントは、アプリケーションのユーザー インターフェイスなどを通じて、アプリケーションの外部から送信されることがあります。同時に、アプリケーション自体がイベント (たとえば、「タイマーの期限切れ」などのイベント) を生成できます。イベントが発生すると、アプリケーションは同じ状態に留まったり、状態が変化したり、アクションを実行したりすることがあります。イベントにはパラメータを含めることができます。たとえば、「pay_money」イベントには、「Cash」、「Check」、「DebitCard」、「CreditCard」などのパラメータが含まれる場合があります。 イベント : (遷移の上のラベルの「/」の後に表示) これは、状態の変化によって開始されるアクションです。これは、「チケットの印刷」、「画面への表示」などのアクションです。通常、アクションは、システムの出力データとして機能する出力を作成します。アクションは遷移中に発生します。国家そのものが受動的である。 アクション : 図上では黒い点として示されています。 エントリ ポイントは、 図上では「ブルズアイ」シンボルとして示されています。 出口点は、 状態遷移テーブル 状態遷移テーブルは、現在の状態、イベント、アクション、次の状態の 4 つの列で構成されるテーブルです。 状態遷移テーブルの利点は、正しい状態遷移シナリオだけでなく、考えられるすべての状態遷移シナリオを定義していることです。したがって、状態遷移テーブルでは、未定義で文書化されていない状態遷移の組み合わせが見つかることがよくありますが、コードを記述する前に特定しておく方がよいでしょう。 状態遷移図は、テスト ケースの作成に簡単に使用できます。すべての遷移を少なくとも 1 回カバーする一連のテスト ケースを作成する必要があります。 状態遷移テーブルからテスト ケースを生成することも比較的簡単です。有効な組み合わせをすべて検討する必要があります (時間が許せば、またはリスクが禁止されない場合は、無効な組み合わせをすべて検討することも可能です)。 直交配列 値「1」と「2」の組み合わせは何通りありますか? {1,1}、{1,2}、{2,1}、および {2,2}。直交配列は、特別な特性を持つ 2 次元配列です。配列の任意の 2 つの列に、それらの列の値のすべての組み合わせが存在します。つまり、値が "1" または "2" のみである直交配列から任意の 2 つの列を取得すると、それらの列に対して次の行が見つかります - {1,1}、{1,2}、{ 2,1}、および {2,2}。 例として、それぞれがバイナリ (つまり、値「1」または「2」を取る) 3 つの入力パラメータを持つシステムを考えてみましょう。 行 変数1 変数2 変数3 1 1 1 1 2 2 1 1 3 1 2 1 4 1 1 2 5 2 2 1 6 1 2 2 7 2 1 2 8 2 2 2 直交配列は - L_4(2^3) として表されます。ここで、L_4 は直交配列に 4 つの行があることを示し、(2^3) は配列に 3 つの列があることを示し、値は「1」または「2」のいずれかになります。 」。 行 変数1 変数2 変数3 1 1 1 1 2 1 2 2 3 2 1 2 4 2 2 1 L_4、4 は行数です 2^3。2 は最大値 (== 2、3、…、N)、3 は列数です。 直交配列 - 次の特性を持つ 2 次元配列です。配列の任意の 2 つの列を選択すると、それらの列内の値のすべての組み合わせが見つかります。 直交配列の使用: 変数（入力データの数）を特定します。論理的に存在し得る値の組み合わせである入力データを選択する必要があります。 各変数が取り得る値の数を決定します。値の数が決定されるまでに、値の数 (境界値、等価クラスなど) を減らすために他のテスト設計手法がすでに適用されているはずです。 各変数の列が存在する直交配列を決定します (直交配列の列には変数と同じ数の値のオプションがあります)。 テスト タスクを直交配列に投影します。 テストケースを書きます。 AllPairs アルゴリズム AllPairs アルゴリズムの本質は、すべての変数の値のすべての組み合わせをテストする必要がないことです。代わりに、変数の各ペアの値のすべての組み合わせをテストすることに重点を置きます。 QA プロフェッショナルとして、これらのニュアンスを理解することが重要です。理論的な場合もありますが、組み合わせテスト設計手法の複雑さを理解することで、QA 専門家はアプリの複雑なビジネス ロジックを効果的にテストし、高品質のソフトウェアをユーザーに提供できるようになります。

This story contains new, firsthand information uncovered by the writer.

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Making security fun one episode at a time

組み合わせテスト設計手法の分析

長すぎる; 読むには

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

ラベル

Languages

この記事は...

組み合わせテスト設計手法の分析

長すぎる; 読むには

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

ラベル

Languages

この記事は...

関連ストーリー