ISTQBはこれらを区別しませんが(「ブランチ/決定カバレッジ」と表示されます)、一部のソースはそれが異なると述べています。 2つの質問があります。重要なのは違いについてです。そしてもう1つ-この概念全体は単体テストに属しますか?またはホワイトボックステスト?ありがとう
ISTQBから:
分岐カバレッジは、決定カバレッジと密接に関連しており、100%カバレッジでは、まったく同じ結果が得られます。決定カバレッジは、条件付きブランチのカバレッジを測定します。ブランチカバレッジは、条件付きブランチと無条件ブランチの両方のカバレッジを測定します。シラバスは分岐のソースであるため、決定カバレッジを使用します。一部のカバレッジ測定ツールは、実際に意思決定カバレッジを意味する場合、ブランチカバレッジについて話す場合があります。 (c)ISTQBファンデーションブック。
分岐はオプションの実行パスですが、決定は条件の組み合わせ(つまり、ブール式)の結果です。
したがって、分岐せずに決定することができます。例えば:
int fun(int a, int b){
return (a > 5) && (b < 15);
}
上記の関数では、「(a> 5)」が条件、「(b <15)」が条件です。 「(a> 5)&&(b <15)」は決定です。そして枝はありません。
したがって、この例では、判定カバレッジは2つのテストのみで到達し、分岐カバレッジソースコードは1つのテストで100%に到達します。
アセンブリレベルでの分岐カバレッジには同じ2つのテストが必要ですが、次のような関数を作成すると、質問が難しくなります。
int fun(int a, int b){
return (a > 5) & (b < 15);
}
ブール演算(算術演算で計算)がまだあり、アセンブリには分岐がありません。
NDCのMCDC測定に関するハンドブックでは、この種の違いを明らかにしています。 http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20040086014_2004090420.pdf
ここに一言で言えば問題があります:
if ((test1() || test2()) {
invoke_some_latent_bug_only_if_test1_is_false;
}
else {
do_something_benign;
}
次の2つのテストケースがあるとします。
test1()
はtrue
と評価され、test1()
とtest2()
はどちらもfalse
と評価されます。これらの2つのテストケースはすべてのステートメントの実行につながるため、一部のコードカバレッジツールは100%のカバレッジをもたらします。問題は、すべてのパスがテストされていないことです。このコードには3つのテストケースが必要です。1つはtest1()
がfalse
に評価され、test2()
はtrue
に評価される場合です。
この架空の例では、3番目の重要なテストケースによって、潜在的なバグが明らかになります。その3番目のケースを提供せずに、ステートメントの実行のみに基づいたカバレッジツールを使用すると、テストが完了したという誤った感覚が生じます。
プログラムを、開始ノードが1つ以上の終了ノードに向かう大きな有向グラフと考える場合。プログラムの各ステートメントはグラフ上のノードであり、分岐または決定はノード間のエッジです。
完全なステートメントカバレッジとは、グラフ内のすべてのノードに少なくとも1回アクセスしたときであり、完全な分岐/決定カバレッジとは、グラフ内のすべてのEdgeを少なくとも1回トラバースしたときです(これらは同じものだと思います)。
開始ノードからすべての終了ノードまですべてのパスをトラバースする場合、これらのいずれも必ずしもフルパスカバレッジと同じではありません。
他の用語と同様に、誰もが同じ用語でまったく同じことを意味するという保証はありません。ウィキペディアはブランチカバレッジを意味するようです 変更された決定カバレッジ しかし、 たくさんその他ソース があります、それらは同じであると言います。より信頼できると言えるのは、ステートメントカバレッジはブランチカバレッジと同じではなく、どちらもパスカバレッジと同じではないということです。
これらの用語を使用する必要がある場合は、使用する前に、あなたが何を意味するかを定義するのが最善の策です。
ポイント2の場合、カバレッジメトリックは任意の形式のテストで使用できます。単体テストおよび自動化されたシステム/統合テストで使用することは確かにかなり一般的です。