受け入れテストとコードカバレッジ

Question

受け入れテストのカバレッジを測定する最良の方法は何ですか？

受け入れテストがどれだけカバーされているか、いつ十分であるかをどのように定義しますか？

Answer 1

受け入れテストをしているとき、私はむしろ 機能カバレッジ つまり、特定のアプリケーションの機能（またはユーザーストーリーまたはユースケース）がテストされています。そして、私にとって、各機能（またはユーザーストーリーまたはユースケース）について、すべてのシナリまたは可能なパスをテストする必要があります。言い換えれば、機能はテスト計画を書くための出発点である必要があり、目標はコードではなく機能をカバーすることです。これはわずかな違いですが、重要な違いです。コードカバレッジによる受け入れテストの測定は、開発者指向であり、機能カバレッジの測定はエンドユーザー指向です。

測定に関して、アジャイルの創設者の一人であるロンジェフリーズは、彼が本当に価値のある指標、RTF、または実行中のテスト機能と見なしているものの優れた要約を書きました。記事を表示できます ここ. 。以下の小さな部分を引用しているだけです。

プロジェクトのポイントは何ですか？

私はただ推測しているだけですが、ほとんどのソフトウェア開発プロジェクトのポイントは、機能するソフトウェアであり、投資1ドルあたり可能な機能を備えていると思います。私はその概念を実行してテストされた[機能]と呼び、実際にはある程度測定できます。

RTFの次の定義を想像してください。

1. 目的のソフトウェアは、目的のシステムを提供することの意味の一部である名前の機能（要件、ストーリー）に分類されます。
2. 指定された各機能について、1つ以上の自動化された受け入れテストがあり、それらが機能すると、問題の機能が実装されていることが示されます。
3. RTFメトリックは、プロジェクトのすべての瞬間に、すべての受け入れテストに合格している機能の数を示しています。

独立して定義されたテストを通じて、顧客定義の機能はいくつありますか？今、私は一緒に暮らすことができるメトリックがあります。

進捗を報告するために、私は特に累積フロー図が好きです。彼らは何かがうまくいかないときにはっきりと示しています、例えば（ここではバーンアップスタイル）：

_{（ソース： xprogramming.com)}

実生活の例については、 この郵便受け また これです （バーンダウンスタイルチャート）。