現在、シラバスでISTQB「テクニカルテストアナリスト」の認定を確認しています。このシラバス(以降、「TTAシラバス」と呼ばれます)には、"条件テスト"専用の章が含まれています(これは"条件カバレッジ"または"条件とも呼ばれます。カバレッジテスト "。)
条件テスト TTAシラバスで定義されているように、ソフトウェアテストよりも おばあちゃんのハムストーリー に関連する非常に奇妙で時代錯誤的なものとして私を襲います。説明させてください...
TTAシラバスによる「条件テスト」とは何ですか?
ISTQBの「Advanced Level Syllabus-Technical Test Analyst、Version 2012」を参照してください here 、「条件テスト」は12ページで次のように定義されています。
決定(分岐)テストは、決定全体を全体として考慮し、個別のテストケースでTRUEとFALSEの結果を評価します。条件テストは、決定の方法を考慮します。各決定述語は、1つ以上の単純な「アトミック」条件で構成され、それぞれの条件は個別のブール値に評価されます。これらを論理的に組み合わせて、決定の最終結果を決定します。 このレベルのカバレッジを実現するには、テストケースによって各アトミック条件を双方向で評価する必要があります。
適用性
条件テストは、以下に述べる困難のため、おそらく要約でのみ興味深いでしょう。しかし、それを理解することは、その上に構築されるより高いレベルのカバレッジを達成するために必要です。
それでは言葉を明確にしましょう
実行したいテスト対象のソフトウェアがあるとしますホワイトボックステスト(つまり、ソースコードがあります)。コードには自然にそれらの多くが含まれています決定述語誰もが知っており、大好きで、if
、while
、until
などの文字列の後に表示されます。
決定述語の例は次のとおりです。
((x>y+z) AND (y<-3)) OR ((z²+x²<4) AND (z≤y))
この決定述語は、整数値(たとえば)のトリプル(x、y、z)を受け入れ、ブール値b_outを出力します。
(x、y、z)を{TRUE、FALSE}にマッピングする第1レベルの関数は条件(--原子条件)で呼び出されますTTAのシラバス。
条件テストの適用範囲
"条件テストカバレッジ"すべての条件decisionが少なくとも1回見つかるまでテストケースを実行することで達成trueおよび少なくとも1回false。
したがって、次の5つのテストケース(たとえば)を実行することで、条件テストカバレッジを達成できます。
b、b1、b2、bのそれぞれは、少なくとも一度はtrueで表示されますおよびfalseで少なくとも1回。一部のテストケースでは、出力を適切にしたい条件に影響を与えないため、特定の値を気にしません。
補遺:決定カバレッジ
ちなみに、真理値表は"決定カバレッジ"b_outが少なくとも1回trueおよびfalseを指定して少なくとも1回、コードの両方のブランチをカバーします。
そして今問題
上記で定義されている「条件テスト」は実際には何に適していますか?
それはあなたが決定述語の正確さを確かめるのを全く助けません。
Thatはコードインスペクションによって最適に実行されます。2番目のチームに同じ式を記述させ、出力を比較するか、「境界値」でテストケースを実行します(ここでは、y = -4、-3、-など)。 2)。
個々の条件を確認すると、CPUのALUのテスト、またはコンパイラの出力のテストについて詳しくなります。手動で作成されたアセンブラコードをチェックしたり、手動でアセンブルされたロジックを検証したりするのに適しています。
そして、これにより、「条件テスト」は実際に条件がパネルに配線された日からの残り物である可能性があると思います(たとえば ENIAC内 )。したがって、配線のバグの影響を受ける可能性があります。最近では、条件は高レベルのコードで記述されており、概念的に必要なexactlyです。レビューは役立つかもしれませんが、状態のテストは時間の無駄です。
それとも何か不足していますか?
補遺:文献検索
「条件テスト」で IEEE Xploreライブラリ を検索すると、ソフトウェアに関連する2つの論文のみが出力されます(他のすべてはハードウェアのみに関連するようです)。ノースカロライナ州立大学コンピュータサイエンス学部のタイ。
それらのうちの1つをチェックすると、 条件ベースのソフトウェアテスト戦略 は、作成者が条件という用語を上記の決定の意味で使用していることを明らかにします。紙の「状態テスト」は実際には「決定テスト」です。 TTAシラバスで使用される条件は簡単な条件と呼ばれます。 TTAのシラバスの定義は広く使用されていないようです。
要約から:
コンピュータープログラムは、ブール式と関係式の組み合わせである条件を含むIFステートメントやWHILEステートメントなどのステートメントで構成されます。 条件テストと呼ばれるテスト方法は、このプログラムの条件のテストに焦点を当ててプログラムをテストすることです。多数の条件テスト戦略が開発されていますが、複雑な条件でのエラーの検出には効果的ではありません。このホワイトペーパーでは、ブール式と関係式の検出に基づいて、2つの条件テスト戦略を定義します。 E1 op E2という形式の式。E1とE2は算術式であり、opは6つの可能な関係演算子の1つです。<<=、=、!=、>、 > =]条件のエラー。これらの2つの条件テスト戦略について、いくつかの理論的特性を示し、複雑な条件を含むプログラムのテストにそれらが実用的で効果的である理由を説明します。
条件テストは、ソフトウェアの各if
が「分岐」(本質的にはコードを2つの別個のコードビットに分割する)を作成するという事実の直接の結果であり、それによってコードの全体的な循環的複雑度が増加します。
ホワイトボックステストシナリオで完全なコードカバレッジを取得するには、if
条件についてある程度の知識が必要です。これにより、テスト中に各コードブランチが確実に実行されるようにすることができます。
コードの「正しさ」については、意味のある単体テストを書くことで確認できます。つまり、コード内の特定のパスを実行する各入力に対して、いくつかの出力を期待できます。その結果は、あなたが求めている正確さが達成されたことを示しています。
「意味がある」とは、つまり、通常、ユニットテストでは、一部の契約または要件が満たされていることを示すことになります。ただし、すべてのコードパスを実行して、後で不愉快な驚きが発生しないようにします。