1

アプリケーションのコード カバレッジに取り組んでいます。さて、コード カバレッジは、作成するテストの種類と、コード カバレッジを実行する言語に関連するアクティビティであることがわかりました。

私の質問は: 一般的なコード カバレッジを行う方法はありますか? のように、たとえば 10% 以上のコードのコード カバレッジを取得するために (テスト対象のアプリケーションのより具体的なテストと共に) 実行できる一連の機能/テスト ケースを用意できますか?

もっと言えば、コード カバレッジ用のフレームワークを構築したい場合、一般的なフレームワークを作成するための最善の方法は何ですか? 一部の機能を自動化または一般化することは可能ですか?

4

2 に答える 2

1

いくつかの理由から、一般的なカバレッジ ツールが聖杯であるかどうかはわかりません。

  1. カバレッジは目標ではなく、手段です。これは、コードのどの部分がテストで完全にヒットしていないかを示します。テストがどれほど優れているかについては何も言いません。
  2. 生成されたテストは、コードのセマンティクスを推測できません。テストを生成するフレームワークは、コードの読み取りから意味を推測できますが、これは本質的に間違っている可能性があります。ユニットテストの全体的なポイントは、コードが実際に意図したとおりに動作するかどうかを確認することでもあるからです。
  3. 自動化されたフレームワークは人為的なカバレッジを生成するため、コードの一部が適切な単体テストでテストされているか、フレームワークによって表面的にテストされているかはわかりません。テストされていないコードがカバーされていないものとして表示されるようにしたいので、それを修正します。

あなたにできること (そして私は ;-) ) は、Java Bean をテストするための一般的なテストを作成することです。リフレクションにより、Java Bean の Sun 仕様に対して Java Bean をテストできます。equals と hashcode の両方が実装されている (またはどちらも実装されていない) ことを確認し、getter が実際に setter でプッシュした値を返すことを確認し、すべてのプロパティに getter と setter があるかどうかを確認します。

たとえば、「比較可能」を実装するものに対して同じ基本的なトリックを実行できます。

実行も維持も簡単で、きれいな豆を手に入れることができます。残りの単体テストに関しては、重要な部分を最初に徹底的にテストすることに集中するようにしています。

カバレッジは、誤った安心感を与える可能性があります。常識は自動化できません。

于 2008-12-08T22:23:23.753 に答える
0

これは通常、静的コード分析 (Coverity、Klockwork、またはそれらの無料の類似物) と、インストルメント化されたアプリケーション (プロファイラー + メモリ チェッカー) に対してテストを実行することによる動的分析を組み合わせることによって達成されます。残念ながら、これはテスト アルゴリズムを自動化するのが困難です。ほとんどのツールは、ドメインに応じてトラフィック/キー/シグナルを記録し、それらを再生できる一種の「レコーダー」です (セッション ID/ユーザー/などの変更/置換を最小限に抑えます)。

于 2008-12-08T21:41:19.157 に答える