質問
Visual Studio 2005プラグイン(cpptest_7.2.11.35_win32_vs2005_plugin.exe)としてUnitTestライセンス(Unit Testライセンスのみ)を使用してコンピューターC ++ Testのみをインストールしました。
次のようなサンプルがあります:
bool MyFunction(... parameters... )
{
bool bRet = true;
// do something
if( some_condition )
{
// do something
bRet = CallToAFunctionThatCanReturnBothTrueAndFalse....
}
else
{
bRet = false;
// do something
}
if(bRet == false)
{
// do something
}
return bRet;
}
カバレッジツールを実行した後の私の場合、次の結果が得られます(前述の機能と同様の機能に対して):
[LC=100 BC=100 PC=75 DC=100 SCC=100 MCDC=50 (%)]
PathCoverage(PC)の場合、100%のカバレッジが得られない理由は本当にわかりません。 また、C ++ Test Parasoftの経験がある人が、MCDCのカバレッジが低いことを説明してくれたら素晴らしいと思います。
カバレッジを増やすにはどうすればよいですか?この場合、私はアイデアを失っています。 ドキュメント(の一部)へのアクセスは歓迎です。
ありがとうございます
Iulian
解決
これは、さまざまなタイプのコードカバレッジに関する優れたリファレンスです。 http://www.bullseye。 com / coverage.html 。
MCDC :MCDCのカバレッジを改善するには、 some_condition
を確認する必要があります。複雑なブール式であると仮定すると、値の必要な組み合わせを行使しているかどうかを調べる必要があります。具体的には、各ブール部分式を真と偽で実行する必要があります。
パス:上記のリンクでパスカバレッジの欠点として言及されていることの1つは、多くのパスを使用できないことです。それはあなたの例の場合かもしれません。
他のヒント
使用している特定のツールを使用することはできませんが、パスカバレッジの一般的な考え方は、コードを通る可能な各パスを実行することです。
プログラムを介してフローチャートを描画し、if / break / continueごとに分岐する場合など、テストがプログラムを通過するパスを確認する必要があります。 100%を得るには(完全に必要というわけではなく、完全なテストを保証するものでもありません)、テストはコードのすべてのブランチに行き、すべての行を実行する必要があります。
役立つこと。
100%のカバレッジを得るには、少なくとも2つのテストケースが必要です。 some_conditionが真であるものとそうでないもの。その場合は、100%のカバレッジを取得する必要があります。
100%のカバレッジが完璧であるはずです。この場合、すべての組み合わせをテストできるように、3つのテストが必要になります。循環的な複雑さを調べて、それについて詳しく学んでください。
その関数には4つの仮想パスがあります。各if節はパスの数を2倍にします。各ifステートメントはブランチであり、2つの異なる方法を使用できます。したがって、ツールが" if"を検出すると、コードは" true"ブランチまたは" false"ブランチ。ただし、これは常に可能とは限りません。考慮:
bool x = true;
if (x) {
do_something();
}
" false" ifステートメントのブランチに到達できません。これは明らかな例ですが、複数のifステートメントを考慮すると、パスが可能かどうかを確認することがますます難しくなります。
コードには3つのパスしかありません。 " false"をとるパス最初のifステートメントで分岐し、" true" 2番目のブランチは到達不能です。
あなたのツールはそれを実現するほど賢くありません。
とはいえ、たとえツールが完全であっても、実際のアプリケーションでは100%のパスカバレッジを得ることはおそらくないでしょう。ただし、パスカバレッジが非常に低いことは、メソッドの循環的複雑度が高すぎることを示しています。
個人的に、すべての機能を開始するのは悪い形だと思います
bool retCode = true;
デフォルトで成功し、特定の条件下で失敗するという明示的な仮定をしている。
あなたの後に来るプログラマは、これと同じ仮定をしません。
早く失敗し、早く失敗します。
他の人が言ったように、失敗のケースをテストしたい場合、失敗したテストをコーディングする必要があります。