デシジョンテーブルは、テスト対象をフローチャートやビジネスルール(　)の形式で仕様化している場合に特に有効になる。

デシジョンテーブルは、(　)定義の技法でもあり、要件仕様がすでにこの形式で定義されている場合もある。テストアナリストは、テスト設計を開始する前に、デシジョンテーブルのレビューに参加し、デシジョンテーブルを分析すべきである。

デシジョンテーブル条件の組み合わせを考慮する際、特に要件が適切に(　)されていない場合、または存在しない場合には、相互作用するすべての条件を見つけることは困難となる。

デシジョンテーブルで考慮する条件を選択する際には、それらの条件の組み合わせの数が(　)可能であるように注意しなければならない。最悪の場合、ルールの数は指数関数的に増えていくこととなる。

デシジョンテーブルテストの一般的なカバレッジ基準は、デシジョンテーブルの各ルールを 1 つのテストケースでカバーすることである。カバレッジは、テストスイートでカバーされた(　)の数と、実行可能な(　)の総数の割合として測定する。

特に拡張指定デシジョンテーブルの場合には、(　)と(　)法は、デシジョンテーブル技法と組み合わせることができる。順序付けられた同値パーティションが条件にすべて含まれている場合、境界値はルールやテストケースの追加をもたらす追加項目として使用することができる。

デシジョンテーブルテストで見つかる典型的な欠陥としては、特定の条件の(　)に基づく論理的な処理が正しく行われず、想定外の結果となることが挙げられる。

デシジョンテーブルを作成していると、(　)書に欠陥が見つかることがある。

デシジョンテーブルテストにおいて、準備した条件のセットに含まれる 1 つ以上のルールに対する(　)結果が不明確であることは珍しくない。

デシジョンテーブルテストで見つかる最も一般的な欠陥は、(　)の欠落（ある状況下で実際に起こるべきことに関する情報がない）と矛盾である。

状態遷移テストは、テスト対象が有効な(　)を介して定義された状態に出入りできるかをテストするために使用する。

状態遷移テストは、有効な遷移と同様に、(　)な状態に入るのを試す、または(　)な遷移を実行することを試すために使用する。

状態遷移テストはイベントの発生により、テスト対象はある(　)から別の(　)に遷移したり、アクションを実行したりする。

状態遷移テストにおけるイベントは、選択したい(　)パスに影響を与える条件（ガード条件または遷移ガードとも呼ばれる）を考慮して特定することがある。例えば、ログインイベントの場合、有効なユーザー名およびパスワードの組み合わせを使用したものと、無効なパスワードを使用したものとは異なる遷移結果となる。

状態遷移テストのガード条件または遷移ガードは、(　)図または(　)表（状態間の潜在的な無効遷移を含む場合もある）で表す

状態遷移テストは、定義済みの状態を持ち、それらの状態間の遷移（例えば、画面の変更）を引き起こすイベントを持つ(　)のソフトウェアに適用できる。

状態遷移テストは、(　)のテストレベルで使用できる。組込みソフトウェア、Web ソフトウェア、および任意の種類のトランザクションソフトウェアが、この種類のテストの適切な適用対象である。信号機制御などの制御システムも同様である。

状態を決定することは、状態遷移図または状態遷移表を定義する作業の最も困難な部分である。テスト対象にユーザーインターフェースが含まれる場合、ユーザー向けに表示される様々な(　)を状態として表すことが多い。

状態遷移テストにおいて、組込みソフトウェアの場合、状態は(　)の状態に依存することがある。

状態そのものの他に、状態遷移テストの基本単位として、個々の遷移がある。単純に単一の遷移をすべてテストすれば、いくつかの状態遷移の欠陥を見つけることができるが、遷移の(　)をテストすることで、より多くの欠陥が見つかる可能性がある。

他の種類のテスト技法と同様に、カバレッジの度合いには階層がある。許容できる最小限のカバレッジは、すべての状態に滞在し、すべての遷移を少なくとも(　)は通過することである。

状態遷移テストの100%の遷移カバレッジ（100%の 0 スイッチカバレッジとも呼ばれる）は、システム設計や状態遷移モデル（図や表）に欠陥がない限り、(　)の状態に滞在し、(　)の遷移を通過することを保証する。

状態遷移テストの状態と遷移の関係によっては、他の遷移を 1 回実行するために、ある遷移に対する(　)回の通過を必要とする場合もある。

用語「N スイッチカバレッジ」は、長さ(　)でカバーされたスイッチの数を意味し、その長さのスイッチの総数のパーセンテージで表す。

Nスイッチカバレッジのテストでは、100%の(　)スイッチカバレッジで見落としがちな故障の種類のいくつかを見つけ出すことができる。

「ラウンドトリップカバレッジ」は、遷移のシーケンスが(　)を形成するときに適用する

100%のラウンドトリップカバレッジを達成するには、任意の状態から同じ状態に戻るすべての(　)を、(　)が開始および終了するすべての状態に対してテストする。

より高い度合いのカバレッジを達成するには、上記のいずれのやり方だとしても、状態遷移表で識別されるすべての(　)な遷移を含めることとなる。

状態遷移テストのカバレッジ要件およびテストセットは、(　)な遷移を含んでいるかどうかを識別しなければならない。

特定のテスト対象の状態遷移図または状態遷移表は、望ましいカバレッジを達成するための(　)の設計を支援する。この情報は、特定の「N」値の N スイッチ遷移を示す表によって表すこともできる。

状態遷移テストでは、カバー対象のアイテム（遷移、状態、N スイッチなど）を(　)で識別できる場合もある。1 つの方法として、状態遷移図および状態遷移表を印刷し、必要なカバレッジが示されるまで、カバー対象のアイテムを筆記用具でマークする。

カバー対象のアイテム（遷移、状態、N スイッチなど）を手動で識別する手法は、状態遷移図および状態遷移表の複雑度の度合いが高まると、非常に時間のかかる作業となる。このため、状態遷移テストでは、(　)を使用すべきである。

状態遷移テストでは次の欠陥が検出できる 正しくないイベント(　)または値

状態遷移テストでは次の欠陥が検出できる 正しくないアクション(　)または値

状態遷移テストでは次の欠陥が検出できる 正しくない(　)状態

状態遷移テストでは次の欠陥が検出できる 特定の(　)状態に遷移できない

状態遷移テストでは次の欠陥が検出できる (　)状態に遷移できない

状態遷移テストでは次の欠陥が検出できる (　)な（不要な）状態

状態遷移テストでは次の欠陥が検出できる 特定の有効な(　)を正しく実行できない

状態遷移テストでは次の欠陥が検出できる (　)な遷移を実行できる

状態遷移テストでは次の欠陥が検出できる 間違った(　)条件

状態遷移モデルを作成するときに、仕様ドキュメントの欠陥を発見することがある。欠陥の最も一般的な種類は、(　)（つまり、特定の状況で実際に何が発生するかに関する情報が存在しない）および矛盾である。

クラシフィケーションツリーは、テスト対象に適用するために作成するデータ空間を(　)的に表すことができるので、特定のブラックボックステスト技法を支援する。

クラシフィケーションツリーで作成した作成するデータ空間は、クラシフィケーションとクラスにまとめることができる。 (　)： テスト対象のためのデータ空間内のパラメーターを表すもので、 入力パラメーター（さらに環境状態や事前条件を含むこともある）や出力パラメーターなどがある。 例えば、多くの異なる方法でアプリケーションを構成できる場合、 (　)には、クライアント、ブラウザー、言語、およびオペレーティングシステムを含むことがある。

クラシフィケーションツリーで作成した作成するデータ空間は、クラシフィケーションとクラスにまとめることができる。 (　)： 各クラシフィケーションは、パラメーターの出現を表す任意の数のクラスとサブクラスを持つことができる。 各クラス、または同値パーティションは、クラシフィケーション内の特定の値となる。 前述の例では、言語クラシフィケーションは、英語、フランス語、およびスペイン語の同値パーティションを含むことがある。

テストアナリストは、適切だと思われる（　）をクラシフィケーションツリーに入力することができる。これには、例えばペアワイズ組み合わせ、3 ワイズ組み合わせ、およびシングルワイズが含まれる

テストアナリストはクラシフィケーションツリーを作成することで、関心のあるパラメーター(　)と同値パーティション(　)を識別できる。

クラシフィケーションツリー図をさらに分析することで、可能な(　)値を識別できる。そして、特に関心の対象となる、または無視可能となる入力の特定の組み合わせ（例えば、両立しないことによる）を識別できる。

作成したクラシフィケーションツリーは、同値分割法、境界値分析、または(　)テストに役立てることができる。

クラシフィケーションそして/またはクラスの量が(　)するにつれて、図が大きくなり、使用しづらくなる。

クラシフィケーションツリー技法では、完全なテストケースは作られず、テストデータの(　)のみが作られる。テストアナリストは、完全なテストケースを作成するために各テストの組み合わせの結果を提供しなければならない。

クラシフィケーション技法では例えば、最小のクラスカバレッジを達成するようにテストケースを設計する場合がある（つまり、クラシフィケーション内のすべての値を少なくとも(　)回以上テストする）。

クラシフィケーションツリーのカバレッジにおいて、テストアナリストは、ペアワイズの組み合わせをカバーするか、または 3 ワイズのような他の種類の(　)テストを使うことを決める場合もある。

検出できる欠陥の種類は、クラシフィケーションツリーが(　)する技法（つまり、同値分割法、境界値分析、またはペアワイズテスト）によって異なる。

ペアワイズテストは、可能な値を複数持つ複数の入力パラメーターを組み合わせてソフトウェアをテストしなければならず、組み合わせ数が、許容される時間内にテスト可能な数よりも(　)存在するときに使用する。

ペアワイズテストでは、組み合わせの技法を使用して、各パラメーター - 値ペアが他の各パラメーターのパラメーター - 値ペアそれぞれに対して 1 回はテストをする (つまり、任意の 2つの異なるパラメーターのパラメーター - 値ペアの「オールペア」をテストする)ことで、パラメーター - 値ペアの(　)の組み合わせをテストすることは避けている。

ペアワイズテストでは、テストアナリストが手動で表を作る方法を使用する場合、行をテスト(　)として表現し、各パラメーターに対して1 つの列となる。

ペアワイズテストで表を作る場合、テストアナリストは、すべての値のペアが表の中で識別できるように、表に(　)を入力する 。表の中で空欄になっている項目は、テスト アナリストが自身のドメイン知識を使って値を入力することができる。

テストアナリストがペアワイズテストの表を作成するにあたり、支援する(　)が多数利用可能である

ペアワイズテストの作成支援ツールは、入力として、パラメーターとその値のリストを必要とする。そして、各パラメーターの値の組み合わせの適切な(　)を生成する。このセットは、パラメーター - 値ペアのすべての組をカバーする

ペアワイズテスト作成ツールの出力は、テスト(　)の入力として使用できる。テストアナリストはツールによって生成された各組み合わせに対する期待結果を提供しなければならないことに注意する。

クラシフィケーションツリーはペアワイズテストと組み合わせて使用することが多い。クラシフィケーションツリーの設計は、ツールで支援されており、パラメーターとそれらの値の組み合わせを(　)化できる（ツールによってはペアワイズの拡張機能を提供しているものもある）。

クラシフィケーションツリーとペアワイズテストの組み合わせは、次の情報を識別するのに役立つ。 ・ペアワイズテスト技法で使用する(　)

クラシフィケーションツリーとペアワイズテストの組み合わせは、次の情報を識別するのに役立つ。 関心のある特定の(　)（頻繁に使用する組み合わせ、欠陥の共通の発生源など）

クラシフィケーションツリーとペアワイズテストの組み合わせは、次の情報を識別するのに役立つ。 (　)しない特定の組み合わせ。これは、組み合わされた因子が相互に影響しないことを想定していない。 影響を与える可能性が十分にあり、許容できる範囲で相互に影響するべきである。

クラシフィケーションツリーとペアワイズテストの組み合わせは、次の情報を識別するのに役立つ。 変数間の(　)的関係。例えば、「変数 x が 1 の場合、変数 y が 2 になることはない」。 これらの関係を表すクラシフィケーションツリーを、「フィーチャーモデル」と呼ぶ。

パラメーター値に関してあまりに多くの組み合わせを持つことの問題は、テスト時に少なくとも 2 つの異なる局面で現れる。例えば複数の入力欄のある画面のように、一部のテストアイテムには、とり得る値が複数存在するパラメーターが複数存在する。この場合、パラメーター値の組み合わせがテストケースの入力データとなる。さらに、システムによっては、いくつかの次元で設定可能なものがあり、その結果、構成空間が大きくなる可能性がある。いずれの状況でも、ペアワイズテストにより、扱いやすくて(　)可能な組み合わせのサブセットを識別することができる。

値の数が非常に多いパラメーターでは、まず、同値分割法や他の抽出の仕組みを各パラメーターに適用して、各パラメーターの値の数を減らしてからペアワイズテストを適用して、結果として得られる組み合わせのセットを(　)ことができる。パラメーターとその値をクラシフィケーションツリーに取り込むことがこの活動を支援する。

ペアワイズテスト技法は通常、(　)統合テスト、(　)テストおよび(　)統合テストのテストレベルで適用する。

これらの技法の主な制限は、少数のテストの結果がすべてのテストの結果を(　)し、それらのテストが期待される使用方法を表すと仮定することである。

ペアワイズテストは、テストを論理的に削減するということが理解されづらいため、技術を知らない(　)への説明が難しい。そのような説明は、経験に基づく研究の結果に言及することによってバランスをとる必要がある。　

医療機器の領域の研究では、故障の 66%は単一の変数によって引き起こされており、97%は 1 つの変数または(　)つの変数の相互作用のいずれかによって引き起こされていることが示されている。3 以上の変数による相互作用が存在する場合、ペアワイズテストでシステム故障を検知できないことがあるというリスクが残る。

ペアワイズテストのパラメーターとそれぞれの値を識別するのが困難な場合がある。このため、このタスクは、可能であれば(　)ツリーの支援を受けて実施するべきである。

ペアワイズテストであるレベルのカバレッジを満たす最小の組み合わせのセットを見つけることは、手作業では困難である。可能な限り小さい組み合わせのセットを見つけるために、(　)を使用することができる。

ペアワイズテスト支援(　)の中には、最終的な組み合わせの選択をする際に、いくつかの組み合わせを強制的に含めたり、除外したりする機能をサポートしているものがある。テストアナリストは、この機能を使用することにより、ドメイン知識またはプロダクトの使用情報に基づいて、因子を重要として扱うかどうかを選択できる。

ペアワイズカバレッジ 100%とするためには、任意の 2 つのパラメーターについて、各値のすべてのペアを(　)つ以上の組み合わせに含める必要がある。

ペアワイズテスト技法で見つかる最も一般的な欠陥のタイプは、2 つのパラメーターの値の(　)に関連する欠陥である。

ユースケーステストは、ユースケースで具体的にした、コンポーネントまたはシステムの意図される(　)方をエミュレートするトランザクションベースおよびシナリオベースのテストを可能にする。

ユースケーステストは何らかのゴールを達成するために、アクターと、コンポーネントまたはシステムとの間の(　)作用の観点でユースケースを定義する。

ユースケーステストの(　)としては、ユーザー、外部ハードウェア、またはその他のコンポーネントやシステムを挙げることができる。

ユースケーステストは、通常、(　)テストレベルおよび(　)テストレベルで適用する。

ユースケーステストはコンポーネントまたはシステムの振る舞いがユースケースで指定されている場合には、(　)テストにも使用することがある。

ユースケースはシステムの実際の使い方を表すので、(　)テストのベースとなることが多くある。

ユースケースが示すシナリオを仮想ユーザーに割り当てることで、システムに現実的な(　)をかけることがある（負荷および性能要件がユースケース内、またはユースケースのために仕様化されている場合）。

有効なユースケースは、(　)的なユーザートランザクションを反映する必要がある。

ユースケースの仕様は、システム(　)の形式の 1 つとなる。

ユーザーが達成する必要のある要件は、ユーザーまたはユーザーの代表者から入手し、対応するユースケースを設計する前に組織的な要件と照らし合わせて(　)する必要がある。

ユースケースが実際のユーザーか組織の要件を反映していない場合、またはユーザータスクの完了を支援ではなく妨害をする場合、ユースケースの価値は(　)する。

ユースケースのカバレッジを十分なものにするには、例外、代替、およびエラー処理に関する振る舞いを正確に(　)することが重要となる。

ユースケースは、ガイドラインとしてとらえるべきであるが、要件のセット全体を明確に定義するものではない可能性があるため、テストすべき内容を(　)に定義するものとはならない。

テストの精度を高め、ユースケース自体を検証するためには、ユースケースの記述からフローチャートそして/またはデシジョンテーブルなど他の(　)を作成することも有益なことがある。これによって、他の形式の仕様と同じように、ユースケース仕様に論理的な不正が存在する場合、それらが明らかになる可能性がある。

ユースケースの受け入れ可能な最小カバレッジレベルは、基本的な振る舞い用の 1 つのテストケースと、代替および(　)処理の振る舞いのそれぞれをカバーするのに十分な追加テストケースを用意することである。

ユースケースのカバレッジにおいて、最小テストスイートが必要な場合、複数の代替の振る舞いが相互に互換性があればそれらを(　)つのテストケースに組み込むことができる。

ユースケーステストにおいて診断能力を高める必要がある場合（例えば、欠陥を特定しやすくするため）、代替の振る舞いごとに(　)つのテストケースを追加で設計することがある。ただし、入れ子になる代替の振る舞いでは、いくつかを単一のテストケースに融合する必要がでてくる（例えば、「リトライ」をする例外の振る舞い内での「終了」と「非終了」の代替の振る舞いなど）。

ユースケーステストで検出できる欠陥には、(　)済みの振る舞いの誤った処理、(　)の振る舞い欠落、提示された条件の(　)処理、十分に実装されていない、または不適切な(　)メッセージがある。

テストケースを作成するために技法を組み合わせることがある。テストアナリストは、適用する特定の技法を選択する際に、その技法の適用可能性、制限や困難さ、カバレッジや検出すべき欠陥の観点からのテストの(　)といったことを考慮すべきである。

ある状況下では、単一の「最善」の技法は存在しないかもしれない。技法を正しく適用するための十分な時間とスキルがあると仮定すれば、技法を(　)ることで、最も完全なカバレッジが得られる。

経験ベースのテストは、欠陥検出を向上させるために、テスト担当者のスキルと直感、およびテスト対象に類似のアプリケーションや技術での(　)を活用する。

経験ベースのテスト技法の範囲は、テスト担当者が実行する活動を事前に計画していない「(　)テスト」から、テストチャーターを使う事前に計画したテストセッション、さらにはスクリプト化されたテストセッションにまで及ぶ。

経験ベースのテストには、次の長所がある。 システムに関する(　)が不足する場合に、構造化されたアプローチに対する優れた代替となることができる。