2016-05-06 10 views
3

通常のブランチカバレッジでは、単純なif文をカバーするために2つのユニットテストが必要です。しかし、if (A && B)のような束縛条件がある場合、制御フローグラフの観点からは、短絡が使用されている場合は追加の分岐があります。これは、3を与える循環的複雑度カウントと一致している(各論理演算子は、短絡の場合に決定ノードが作成されるので、1だけ複雑性を増加させるという規則を適用する)。しかし、私が知る限り、コードアナライザはそれらの分岐を考慮しません。 表現の部分的な評価から副作用が発生しないようにするためには、とにかくそれらをカバーする価値がありますか?短絡によるコードの分岐をコードカバレッジに考慮する必要がありますか?

答えて

3

これは、自然にコードを分析する目的によって異なります。

FAAは、短絡したオペレータのすべてのオペランド(Cのものを含む)を一般に推奨します(たとえば、DOT/FAA/AR-06/54「ソフトウェア検証ツール評価スタディ」、最終報告書、2007年6月、セクション4.2.5)三項演算子、ブール演算子)は、あなたのように決定として解釈されます。より高い設計保証レベル(特に壊滅的かつ危険な)については、関連する基準(DO178、DO254など)で満たされるべき目的は、より高いDALでの独立性を高めることで、すべての可能な決定をカバーする必要がある。

したがって、アプリケーションがより高いDALを必要とすると仮定すると、答えは通常yesになります。代わりに、分析やテストの目的を達成するためにそのようなカバレッジが必要でないという主張を支持するための特定の議論を構築し、評論家にその議論を受け入れるように説得することもできます。このような議論は、短絡のあらゆるインスタンスに対して構築する必要があるかもしれない。あなたはさまざまな方法でこれについて議論することができます

1

が、ことを私のために、実際:

if (a && b) { X=... } 

は、(多くの場合のように定義)とまったく同じです:

if (a) 
{ if (b) { X=... } 
} 

はのカバレッジへのあなたの答えを意味し、 & &演算子は、等価な定義の答えと同じでなければなりません。同様に||オペレーター。

+0

あなたが言うことは本当ですが、付随する 'else'があれば等価性についての推論はより複雑になります – Peter

+0

それでもなお正確な等価性があり、簡単な定義が明確なサブケース。 –

関連する問題