9

ほとんどの確立された言語には、信頼できるテスト カバレッジ ツールが用意されていますが、機能の深さは言語ごとに大きく異なります。

また、さまざまな VM とコンパイラはすべて異質な構造を持っているため、コード カバレッジ ツールを作成する作業は、C では Lisp とは大きく異なります。

  • Python はsys.settrace、実行中の行を直接通知する必要があります
  • Clover（Java用）は独自のコンパイラを使用し、デバッグメタデータを追加します（最後に使用したときはとにかく）
  • Emma (Java 用) には、バイトコードをオンザフライで書き換える ClassLoader があります。
  • COVER (Lisp 用) には、コードを計測するための注釈パスがあります。

さまざまな言語のコード カバレッジの実装に興味があります。

  1. どのコード行が実行されたかを追跡できるC0カバレッジに到達するための主なアプローチは何ですか? 上記のネイティブ VM イントロスペクションと静的および動的コード インストルメンテーションについて言及しましたが、他の方法はありますか?

  2. C1 や C2などのより適切なカバレッジ データを取得することは、C0 と比較して言語にとらわれない作業のように思えます。私には大規模なカルノー マップ操作のピシャリです。実際にそれを行う方法に関するベストプラクティスはありますか? ファジネスのような最新の論理手法は役割を果たしますか?

  3. テスト カバレッジで見過ごされがちな側面は、結果をプログラマーに表示することです。これは、C1 および C2 データではますます難しくなります。率直に言って、彼らは C0 の仕事を成し遂げていますが、私はほとんどのテスト カバレッジ インターフェイスに圧倒されています。カバレッジ データ用にどの斬新で直感的なインターフェイスを見たことがありますか?

4

3 に答える 3

5

基本的にすべてのコード カバレッジ ツールは、コードのどの部分が実行されたかをチェックするためにコードを計測します。

あなたが提供したリンクで定義されているように、 C0 と C1 は、インストルメンテーションを書いている人の観点からはかなり似ています。唯一の違いは、コードを配置する場所です。さらに進んで、C1 は C0 よりもさらに簡単であると推測します。これは、インストルメンテーションが、たとえば、行末があまり重要でない抽象的な構文レベルで行われるためです。

私が C1 の方が簡単だと言っているもう 1 つの理由は、C1 が字句エンティティではなく構文エンティティを扱うためです。

if
c > 1 && c
< 10
then
blabla
end

まあ、ただの考えです。

C2 に関しては、実際に行われているのを見たことがありません。その理由は、指数関数的な爆発を得ることができるからです:

if c1 then * else * end
if c2 then * else * end
...
if cn then * else * end

n 行のコードの場合、2^n 個のテストが必要になります。また、ループはどうしますか？通常、それらは単純な if ステートメントとして抽象化します (つまり、ループごとに、その本体が 1 つのテストで 0 回実行され、別のテストで少なくとも 1 回実行されたことをテストします)。

PC のサンプリングは、コード カバレッジを行うには特にひどい方法だと思います。なぜなら、ステートメントの実行が速すぎていくつかのステートメントを見逃す可能性があるからです。通常、コード カバレッジを決定論的にする必要があります。

Karnaugh マップはブール関数を最小化するために使用されますが、コード カバレッジ ツールとの有用なリンクは見当たりません。

また、あなたの質問は時々あまり明確ではありません: より良いコード カバレッジを達成するためのテクニックが必要ですか、それとも単にコード カバレッジ ツールの実装に興味があるだけですか?

于 2009-01-21T10:47:20.623 に答える
-2

.NET では、 .NET プロファイリング APIを使用することをお勧めします。これは基本的に、CLR 自体に一連のジョイント ポイントを提供します。

于 2009-01-18T13:00:52.827 に答える