この文では、ソフトウェア テストにおける複数の欠陥の仮定と境界値分析の適用について説明しています。
多重欠陥の仮定とは、複数の変数が同時に特定の値を取る場合、欠陥またはエラーが発生する可能性があるという事実を指します。ソフトウェア システムでは、さまざまな変数 (入力パラメーター、構成オプションなど) 間の相互作用により、エラーや異常な動作が発生する可能性があります。したがって、これらの潜在的な問題を特定して検証するには、複数の変数が同時に特定の値を取る状況に注意を払う必要があります。
境界値分析は、変数の境界ケースと極値を特定し、これらの値をテスト ケースとして使用することを目的としたテスト手法です。通常、境界値分析のユースケースは複数の欠陥を想定して設計されています。具体的には、境界値分析では、複数の変数が同時に境界値を取る状況に焦点を当て、対応するテストケースを生成します。
この文で言及されている「各変数のデカルト積」は、境界値分析の一般的な方法を指します。デカルト積とは、可能なすべての組み合わせを生成するための複数のセット内の要素の組み合わせを指します。境界値分析では、各変数の境界ケースと極値を組み合わせて、特定の境界値を同時に取る複数の変数をカバーするテスト ケースを生成します。
複数の欠陥仮定と境界値分析を適用することで、テスターはソフトウェア システムに存在する可能性のある潜在的な問題をより完全に調査できます。境界値分析のテストケースでは、複数の変数が同時に境界値をとる状況をカバーし、その状況でのシステムの動作と処理能力を検証できます。
要約すると、この文は、ソフトウェアテストでは、複数の欠陥の想定に基づいて、通常、境界値分析により、欠陥を引き起こす可能性のある状況をカバーするために同時に境界値を取る複数の変数を含むテストケースを生成することを意味します。
ここで設定する直積とは、x、y、zなどを境界値として設定し、それらを組み合わせるという意味です。
有効な同値クラスと非 put の同値クラス
有効な同値クラスは
プログラムの仕様上意味があり、妥当な入力データの集合
無効
な同値クラスは
プログラムの仕様上意味がない、または不合理な入力データ
の集合
デシジョン テーブルとデシジョン ツリーは、ソフトウェア テストおよびルール エンジンで意思決定ロジックを表現するためによく使用される 2 つのツールであり、これらの間にはいくつかの類似点がありますが、いくつかの相違点もあります。
デシジョン テーブルは、テーブルの形式で意思決定を表現する方法であり、さまざまな条件下で意思決定が必要なアクションや結果を記述するために使用されます。通常、条件列とアクション列で構成されます。「条件」列には、意思決定ロジック内のさまざまな条件またはイベントがリストされ、「アクション」列には、条件に基づいた対応するアクションまたは結果がリストされます。デシジョン テーブルでは、最終的な意思決定結果を決定するために、論理演算子 (AND、OR など) を使用して条件間の関係を表します。
デシジョンテーブルはツリー構造の意思決定表現方法であり、意思決定ロジックをブランチとノードの形式で表現します。デシジョン ツリーでは、各ノードは条件またはイベントを表し、各ブランチは考えられる結果または決定における次のステップを表します。与えられた入力条件に従って、ルート ノードから開始して、条件の値に従って、対応する分岐を段階的に下りてリーフ ノードに到達し、最終的に最終的な判定結果を取得します。
デシジョン テーブルとデシジョン テーブルの関係は、デシジョン ロジックを表現し、与えられた条件に従って対応する決定を行うために使用できるということです。これらはすべて、テスターやルール エンジンが意思決定ロジックを設計および検証するのに役立つツールです。
具体的には、デシジョン テーブルは一般に、条件とアクションの関係が複雑な複雑なデシジョン ロジックに適しています。デシジョン テーブルの利点は、考えられるすべての条件の組み合わせを明確にリストし、テーブルに決定結果を視覚的に表示できることです。デシジョンテーブルは、テストケースの設計とルールエンジンのルール記述に適しています。
デシジョン テーブルは、デシジョン ロジックが比較的単純で分岐が少ない状況に適しています。デシジョンテーブルの利点は、意思決定ロジックをツリー構造で表示できるため、理解しやすく視覚化が容易であることです。デシジョン テーブルは、ルール エンジンの実行とデシジョン ツリーの構築に適しています。
つまり、デシジョンテーブルとデシジョンテーブルは一般的に使用される意思決定表現方法であり、与えられた条件に従って意思決定を行うことができ、適用可能なシナリオと利点が異なります。どの方法を使用するかの選択は、決定ロジックの複雑さとテスト/ルール エンジンのニーズによって異なります。
第四章
第五章
第11章
FP（ファンクションポイント）とは、ソフトウェアテストにおいて、ソフトウェアの開発工数やファンクションポイント数を評価するためのソフトウェアの規模を計測するための計測単位です。FP は、ソフトウェア、入出力、ユーザー インターフェイスの機能要件に従って計算できます。
指定された文では、「すべての関数ポイントにはテスト ケースが必要です。平均 > 4/FP」は、関数ポイント (FP) ごとに、その関数ポイントをカバーするために少なくとも 4 つ以上のテスト ケースを記述する必要があることを意味します。これは、テスト ケース カバレッジを測定するための要件です。
テスト ケース カバレッジとは、ソフトウェアの機能要件と特性がテスト ケースの実行によってどの程度カバーされるかを指します。ソフトウェアの各機能ポイントを効果的にテストするには、少なくとも一定数のテスト ケースを作成する必要があります。この場合、関数ポイントごとに平均して少なくとも 4 つのテスト ケースが必要です。
複数のテスト ケースを作成することで、関数ポイントを徹底的にテストできます。さまざまなテスト ケースでさまざまなシナリオ、入力の組み合わせ、予想される結果をカバーし、潜在的なバグ、エッジ ケース、異常を発見できます。
平均値は、ソフトウェア プロジェクト全体の範囲内で、各ファンクション ポイントのテスト ケースの平均数が 4 より大きくなければならないことを意味することに注意してください。テスト ケースの正確な数は、プロジェクトの規模、複雑さ、テスト戦略によって異なる場合があります。
つまり、この文は、ソフトウェア テストにおいて、高いテスト カバレッジ率を達成するには、各ファンクション ポイント (FP) に対して、そのファンクション ポイントをカバーするために少なくとも 4 つのテスト ケースを作成する必要があることを意味します。
第13章
