受け入れテストのカバレッジを測定するための最良の方法は何ですか？
受け入れテストがどの程度カバーし、いつ十分になるかをどのように定義しますか？
質問する
3426 次
1 に答える
12
受け入れテストを行うときは、機能範囲、つまり、特定のアプリケーションの機能 (またはユーザー ストーリーやユース ケース) がどれだけテストされているかを確認したいと思います。そして、私にとっては、各機能 (またはユーザー ストーリーまたはユース ケース) について、すべてのシナリオまたは可能なパスをテストする必要があります。言い換えれば、機能はテスト計画を書くための出発点であるべきであり、目標はコードではなく機能をカバーすることであるべきです。これはわずかな違いですが、重要なものです。コード カバレッジによる受け入れテストの測定は開発者向けであり、機能カバレッジの測定はエンド ユーザー向けです。
測定に関しては、アジャイルの創始者の 1 人である Ron Jeffries が、RTF または実行中のテスト済み機能について、彼が真に価値のある測定基準であると考える優れた要約を書きました。記事はこちらからご覧いただけます。以下、ごく一部を引用します。
プロジェクトのポイントは？
推測にすぎませんが、ほとんどのソフトウェア開発プロジェクトのポイントは、機能するソフトウェアであり、1 ドルの投資に対して可能な限り多くの機能を備えているソフトウェアだと思います。私はその概念を実行テスト済み [機能] と呼んでいますが、実際にはある程度測定することができます。
次の RTF の定義を想像してください。
- 目的のソフトウェアは、目的のシステムを提供することの意味の一部である名前付き機能 (要件、ストーリー) に分解されます。
- 名前付き機能ごとに、1 つ以上の自動化された受け入れテストがあり、それらが機能すると、問題の機能が実装されていることが示されます。
- RTF メトリクスは、プロジェクトのあらゆる瞬間に、すべての受け入れテストに合格した機能の数を示します。
独立して定義されたテストを通じて、機能していることがわかっている顧客定義の機能はいくつありますか? 今、私が一緒に暮らすことができる指標があります。
進捗状況を報告するには、累積フロー図が特に好きです。これらは、何かがうまくいかないときに明確に表示されます。たとえば (ここではバーンアップ スタイル):
(ソース: xprogramming.com )
于 2009-10-15T20:07:45.657 に答える