0

私はこれらの違いを研究していますが、違いを理解できません。私には同じように思えます。それらは同じではありませんか？リスクは短絡から来ていますよね？

ステートメント カバレッジでは、論理演算子のテストは必要ありません。C++ および C では、これらの演算子は &&、||、および ?: です。ステートメント カバレッジは、論理演算子で区切られたコードをステートメントの残りの部分から区別できません。ステートメント内のコードの任意の部分を実行すると、ステートメント カバレッジによって、ステートメント全体が完全にカバーされていると宣言されます。論理演算子が不必要な評価を (短絡によって) 回避する場合、ステートメント カバレッジは膨張したカバレッジ測定値を示します。

void function(const char* string1, const char* string2 = NULL);
...
void function(const char* string1, const char* string2)
{
    if (condition || strcmp(string1, string2) == 0) // Oops, possible null pointer passed to strcmp
    ...
}

決定範囲 - 短所は、このメトリックが、短絡演算子が原因で発生するブール式内の分岐を無視することです。たとえば、次の C/C++/Java コード フラグメントについて考えてみます。

if (condition1 && (condition2 || function1()))
    statement1;
else
    statement2;
4

2 に答える 2

1

それらはわずかに異なりますが、正しく推測したように、問題を実証するにはどちらも短絡操作が必要です。

ステートメント カバレッジの問題

if (complex-condition-evaluation-with-short-circuits) 
  doAction();

ステートメント カバレッジは、上記の両方の行にアクセスしたことを記録する場合がありますが、複雑な条件の一部のみが評価されたシナリオを実行したかどうかはわかりません。

つまり、あなたの例ではstrcmp(...)実行されたことがありますか?

ブランチ カバレッジに関する問題

if (complex-condition-evaluation-with-short-circuits) 
  doAction(); 
else
  doOtherAction();

分岐カバレッジは、(ソース) コード内のすべてのパスを通過したことを記録する場合がありますが、(前述のように) 複雑な条件評価の一部である分岐は無視します。

つまり、あなたの例では、ブランチ カバレッジは||代替ブランチとは見なさず、実際には 4 つあるのに、コードを通る 2 つのパスのみと見なします。

path1 (calls doAction) => condition1 == true, condition2 == true, function1() == ?
path2 (calls doAction) => condition1 == true, condition2 == false, function1() == true
path3 (calls doOtherAction) => condition1 == true, condition2 == false, function1() == false
path4 (calls doOtherAction) => condition1 == false, condition2 == ?, function1() == ?

これが役立つことを願っています

于 2013-02-21T09:16:07.317 に答える
1

私が見る限り、これらの例のリスクは短絡に起因しており、実際には同等のものです。他の場合には、違いがあるかもしれません。たとえば、次のケースを考えてみましょう。

if (a>5)
    b = 6
if (a<20)
    c = 4 + b

ステートメント カバレッジの場合は、a=10(すべての行が実行される) でテストするだけで十分であり、テストはパスします。

デシジョン カバレッジでは、すべての if ステートメントを true と false の両方に評価する必要があります。100% の判定カバレッジは、たとえば と の 2 つのテストで達成できa=30ますa=0。その場合、変数が設定されていないため、後者は失敗しますb。

したがって、意思決定カバレッジはより強力です。実際には、100% の意思決定カバレッジは 100% のステートメント カバレッジを保証しますが、その逆はありません。ただし、言語にショートサーキットがあるかどうかに関係なく、決定カバレッジがバグを明らかにするのに十分でない例を構築することは依然として可能です。

短絡しない状況を考えてみましょう

if (a>0 || b>0)
    c = 5 / b

これを入力データ a=0; でテストしてみましょう。b=1; a=0、b=0。最初のものは、ステートメント カバレッジを提供するのに十分です。両方を組み合わせることで、意思決定カバレッジが提供されます。しかし、どちらもif内のゼロ除算を公開していません。

于 2013-02-21T09:17:42.373 に答える