単体テストのコード カバレッジの最小パーセンテージを、おそらくリポジトリにコミットするための要件としても義務付けるとしたら、それは何になりますか?
どのようにして答えにたどり着いたのか説明してください (もしあなたが数字を選ぶだけなら、私はすべて自分でできたはずです ;)
257132 次
30 に答える
1536
Alberto Savoia によるこの散文は、その質問に正確に答えています (非常に面白い方法で!)。
http://www.artima.com/forums/flat.jsp?forum=106&thread=204677
テストカバレッジに関するTestivus
ある朝早く、プログラマーが偉大なマスターに尋ねました：
「ユニットテストを書く準備ができました。どのコード カバレッジを目指すべきですか?」</p>
大師はこう答えました。
「カバレッジについて心配する必要はありません。良いテストを書いてください。」</p>
プログラマーは微笑み、頭を下げ、立ち去りました。
...
その日の後半、別のプログラマーが同じ質問をしました。
偉大なマスターは沸騰したお湯の鍋を指して言った：
「その鍋には何粒の米を入れるべきですか?」</p>
困惑した様子のプログラマーは、次のように答えました。
「どうすればあなたに話せますか？それは、何人の人に食べさせる必要があるか、どれだけお腹がすいているか、他にどんな食べ物を提供しているか、どれだけの米を用意しているかなどによって異なります。」</p>
「そのとおりです」と偉大なマスターは言いました。
2 番目のプログラマーは微笑み、お辞儀をして立ち去りました。
...
その日の終わりに、3 人目のプログラマーが来て、コード カバレッジについて同じ質問をしました。
「80パーセント以上！」マスターは厳しい声で答え、拳をテーブルに叩きつけた。
3 人目のプログラマーは微笑み、頭を下げ、立ち去りました。
...
この最後の返事の後、若い見習いが偉大なマスターに近づきました：
「偉大なマスター、今日、あなたがコード カバレッジに関する同じ質問に 3 つの異なる回答をしているのを耳にしました。なぜ？」</p>
偉大なマスターは椅子から立ち上がった：
「私と一緒に新鮮なお茶を飲みに来て、それについて話しましょう。」</p>
彼らがカップを熱い緑茶で満たした後、偉大なマスターは答え始めました：
「最初のプログラマーは新人で、テストを始めたばかりです。現在、彼には多くのコードがあり、テストはありません。彼にはまだ長い道のりがあります。この時点でコード カバレッジに焦点を当てることは気のめいるようで、まったく役に立たないでしょう。彼は、いくつかのテストを書いて実行することに慣れたほうがよいでしょう。彼は後でカバレッジについて心配することができます。」</p>
一方、2 番目のプログラマーは、プログラミングとテストの両方でかなりの経験があります。私が鍋に何粒の米を入れるべきかを彼女に尋ねて答えたとき、必要なテストの量は多くの要因に依存することを彼女が理解するのを助けました.彼女は私よりもそれらの要因をよく知っています. . 単一の単純な答えはありません。彼女は真実を処理し、それを処理するのに十分スマートです。」</p>
「なるほど」と若い見習いは言いました。「しかし、単純な答えが 1 つもないのなら、なぜ 3 番目のプログラマーに『80% 以下』と答えたのですか?」</p>
偉大なマスターは非常に激しく大声で笑ったので、彼の腹は、彼が緑茶以上のものを飲んだ証拠であり、上下に揺れました.
「3 番目のプログラマーは、単純な答えがなくても、単純な答えだけを求めています…そしてとにかくそれに従わないのです。」</p>
若い見習いと白髪交じりの偉大な師匠は、瞑想的な沈黙の中でお茶を飲み終えました。
于 2008-09-18T04:30:10.230 に答える
93
コードカバレッジは、（すべての機能を100％テストするのではなく）100％のカバレッジが目標である場合、誤解を招く指標です。
- すべての行を1回押すと、100％を取得できます。ただし、それらの行がヒットする特定のシーケンス（論理パス）のテストを見逃す可能性があります。
- 100％を取得することはできませんでしたが、80％/freqで使用されるすべてのコードパスをテストしました。'throw ExceptionTypeX'または同様の防御的なプログラミングガードをすべてテストするテストを行うことは、'必要な'ではなく'必要な'です。
したがって、自分自身または開発者が徹底して、コードのすべてのパスをカバーすることを信頼してください。実用的であり、魔法の100％のカバレッジを追いかけないでください。コードをTDDする場合、ボーナスとして90％以上のカバレッジを取得する必要があります。コードカバレッジを使用して、見逃したコードのチャンクを強調表示します（ただし、TDDを使用している場合は発生しないはずです。コードはテストに合格するためだけに記述しているためです。パートナーのテストなしでは、コードは存在できません。）
于 2008-09-18T04:33:58.613 に答える
72
Jon Limjap は良い点を指摘しています。すべてのプロジェクトの標準として意味のある単一の数値はありません。そのような標準を必要としないプロジェクトがあります。私の意見では、受け入れられた答えが不十分なのは、特定のプロジェクトに対してその決定を行う方法を説明することです。
私はそうすることに挑戦します。私はテスト エンジニアリングの専門家ではありません。より多くの情報に基づいた回答をお待ちしております。
コード カバレッジ要件をいつ設定するか
まず、そもそもなぜそのような基準を課したいのですか？一般に、プロセスに経験的な信頼を導入したい場合。「経験的信頼」とはどういう意味ですか? さて、本当のゴールの正しさ。ほとんどのソフトウェアでは、すべての入力についてこれを知ることはおそらくできないため、コードは十分にテストされていると言うことで解決します。これはより認識しやすいものですが、依然として主観的な基準です。これを満たしているかどうかについては、常に議論の余地があります。これらの議論は有用であり、行われるべきですが、不確実性も露呈しています。
コード カバレッジは客観的な測定値です。カバレッジ レポートを確認すると、標準が満たされているかどうかが有用であるかどうかについてあいまいさはありません。それは正しさを証明しますか？まったくそうではありませんが、コードがどれだけ十分にテストされているかに明確な関係があります。これは、コードの正確性に対する信頼を高めるための最善の方法です. コード カバレッジは、私たちが気にかけている計り知れない品質の測定可能な近似値です。
経験的基準を持つことで価値が高まる特定のケース:
- ステークホルダーを満足させる。多くのプロジェクトでは、ソフトウェアの品質に関心を持ち、ソフトウェアの日常的な開発に関与していない可能性のあるさまざまな関係者 (マネージャー、テクニカル リーダーなど) がいます。彼らは完全に信頼するか、継続的な綿密な監視によって検証する必要があります (そうするための技術的な理解さえあると仮定します)。
- チームの行動を正常化する。利害関係者はさておき、複数の人がコードとテストを書いているチームで作業している場合、「十分にテストされた」と見なされるものにはあいまいさの余地があります。どのレベルのテストが適切かについて、同僚全員が同じ考えを持っていますか? おそらくそうではありません。これをどのように調和させますか？全員が同意できる指標を見つけて、妥当な概算値として受け入れます。これは、たとえば、リードがジュニア開発者を直接監督できない可能性がある大規模なチームで特に (ただし排他的ではありません) 役立ちます。信頼のネットワークも重要ですが、客観的な測定がなければ、全員が誠意を持って行動していても、グループの行動に一貫性がなくなりがちです。
- 自分を正直に保つために。あなたがプロジェクトの唯一の開発者であり、唯一の利害関係者である場合でも、ソフトウェアに対して特定の資質を念頭に置いている場合があります。ソフトウェアがどれだけよくテストされているか (手間がかかる) について継続的に主観的な評価を行う代わりに、コード カバレッジを合理的な概算として使用し、機械にそれを測定させることができます。
どの指標を使用するか
コード カバレッジは単一の指標ではありません。カバレッジを測定する方法はいくつかあります。どちらに基準を設定するかは、その基準を使用して何を満たすかによって異なります。
基準を設定するためにそれらを使用する場合の例として、2 つの一般的なメトリックを使用します。
- ステートメント カバレッジ: テスト中に実行されたステートメントの割合は? コードの物理的な範囲を把握するのに役立ちます: 自分が書いたコードのうち、実際にテストしたのはどれくらいか?
- この種のカバレッジは、正当性の主張を弱めますが、達成するのも簡単です。コード カバレッジを使用して物事が確実にテストされるようにする (それ以上のテスト品質の指標としてではなく) 場合は、おそらくステートメント カバレッジで十分です。
- 分岐範囲: 分岐ロジック (例: an
if) がある場合、両方の分岐が評価されているか? これにより、コードの論理範囲をよりよく理解できます。つまり、コードがたどる可能性のあるパスのうちいくつをテストしたか?- この種のカバレッジは、プログラムが一連の包括的な入力に対してテストされたことを示すより優れた指標です。コード カバレッジを、正確さを保証するための経験に基づく最良の近似値として使用している場合は、ブランチ カバレッジなどに基づいて基準を設定する必要があります。
他にも多くのメトリックがあります (行カバレッジはステートメント カバレッジに似ていますが、複数行のステートメントに対して異なる数値結果を生成します。たとえば、条件付きカバレッジとパス カバレッジは分岐カバレッジに似ていますが、可能な順列のより詳細なビューを反映しています。プログラムの実行に遭遇する可能性があります)。
必要な割合
最後に、元の質問に戻ります。コード カバレッジ基準を設定する場合、その数値はいくつにすべきですか?
この時点で、そもそも概算について話していることが明らかであることを願っています。そのため、選択した数値は本質的に概算になります。
選択できるいくつかの数字:
- 100%。すべてがテストされていることを確認したいので、これを選択するかもしれません。これはテストの品質についての洞察を与えるものではありませんが、何らかの品質のテストがすべてのステートメント (またはブランチなど) に影響を与えたことを示しています。繰り返しになりますが、これは信頼度に戻ります。 、コードの一部のサブセットがテストされていない
ことがわかっています。
- これはばかげていると主張する人もいるかもしれません。コードの本当に重要な部分だけをテストするべきです。また、コードの本当に重要な部分だけを維持する必要があると私は主張します。テストされていないコードも削除することで、コード カバレッジを改善できます。
- 99% (または 95%、90% 後半のその他の数値)。100% に近い信頼度を伝えたい場合に適していますが、時折発生するテストが難しいコーナーについて心配しないように、ある程度のマージンを残しておきます。コード。
- 80%。この番号が使用されているのを数回見たことがありますが、その由来は完全にはわかりません。これは、80-20 ルールの奇妙な流用かもしれないと思います。一般に、ここでの目的は、ほとんどのコードがテスト済みであることを示すことです。(はい、51% は「最も」にもなりますが、80% は、ほとんどの人が最も意味することをより反映しています。)価値の低いテストに無駄な労力を費やしたくありません) が、何らかの標準を整備したいという優先順位は十分にあります。
私は実際に 80% 未満の数値を見たことがなく、それらを設定するケースを想像するのに苦労しています。これらの基準の役割は、正確さに対する信頼を高めることであり、80% 未満の数値は特に信頼を高めるものではありません。(はい、これは主観的なものですが、基準を設定するときに一度主観的な選択を行い、その後は客観的な測定値を使用するという考え方です。)
その他の注意事項
上記は、正確さが目標であることを前提としています。コード カバレッジは単なる情報です。それは他の目標に関連しているかもしれません。たとえば、保守性が気になる場合は、おそらく疎結合が気になるでしょう。これは、テスト容易性によって実証でき、コード カバレッジによって (特定の方法で) 測定できます。したがって、コード カバレッジ標準は、「保守性」の品質を概算するための経験的根拠も提供します。
于 2016-01-09T20:44:34.047 に答える
67
コードカバレッジは素晴らしいですが、機能カバレッジはさらに優れています。私は自分が書いたすべての行をカバーすることを信じていません。しかし、私は、提供したいすべての機能の100％テストカバレッジを作成することを信じています（私が自分で持ってきた、会議中に議論されなかった非常にクールな機能についても）。
テストでカバーされていないコードがあるかどうかは気にしませんが、コードをリファクタリングして別の動作をするかどうかは気にします。したがって、100％の機能カバレッジが私の唯一の目標です。
于 2009-04-27T22:56:46.047 に答える
31
私のお気に入りのコード カバレッジは 100% で、アスタリスクが付いています。アスタリスクが付いているのは、特定の行を「カウントしない」行としてマークできるツールを使用することを好むためです。「カウント」する行を 100% カバーしたら、完了です。
基礎となるプロセスは次のとおりです。
- 考えられるすべての機能とエッジ ケースを実行するためのテストを作成します (通常はドキュメントから作業します)。
- コード カバレッジ ツールを実行する
- カバーされていない行またはパス、および重要ではない、または到達できないと思われる行またはパスを調べます (防御的なプログラミングのため)。カウントしないとマークします。
- 不足している行をカバーする新しいテストを作成し、それらのエッジ ケースが言及されていない場合はドキュメントを改善します。
このようにして、将来、私と共同研究者が新しいコードを追加したり、テストを変更したりした場合、何か重要なことを見逃していないかどうかを示す明確な線があります。カバレッジは 100% を下回りました。ただし、さまざまなテストの優先順位に対処する柔軟性も提供します。
于 2014-10-07T15:58:24.520 に答える
21
共有したいテストカバレッジに関する別の逸話があります。
Twitterで、700の単体テストで、コードカバレッジが20％しかないという巨大なプロジェクトがあります。
スコット・ハンゼルマンは知恵の言葉で答えました：
正しい20％ですか？ユーザーが最もヒットしたコードを表すのは20％ですか？さらに50のテストを追加し、2％しか追加しない場合があります。
繰り返しになりますが、コードカバレッジ回答に関する私の証言に戻ります。鍋にどれくらいのご飯を入れればいいですか？場合によります。
于 2008-09-18T04:42:07.503 に答える
9
多くの店はテストを評価しないので、もしあなたがゼロより上なら、少なくともいくらか価値を評価している。
.Net の世界では、人々はしばしば 80% を合理的なものとして引用します。しかし、彼らはこれをソリューションレベルで言っています。私はプロジェクト レベルで測定することを好みます。Selenium などまたは手動テストがある場合、UI プロジェクトでは 30% で十分かもしれません。完全に必要でない場合は、ルール層。したがって、全体的なカバー率は 60% かもしれませんが、重要なビジネス ロジックはそれよりもはるかに高い可能性があります。
これも聞いたことがあります。100% を目指すと、80% に到達します。しかし、80% を目指すと 40% に到達します。
結論: 80:20 ルールを適用し、アプリのバグ数を参考にしてください。
于 2016-07-29T23:50:06.217 に答える
8
よく設計されたシステムで、最初から単体テストによって開発が進められている場合、85% という数字はかなり低いと言えます。テスト可能なように設計された小さなクラスは、それ以上にカバーするのは難しくありません。
この質問は、次のように簡単に却下できます。
- カバーされた行はテストされたロジックと同じではなく、パーセンテージを読みすぎないようにしてください。
確かにそうですが、コード カバレッジに関して重要な点がいくつかあります。私の経験では、このメトリックは、正しく使用すると実際に非常に役立ちます。そうは言っても、私はすべてのシステムを見たわけではなく、実際の価値を追加するコード カバレッジ分析を確認するのが難しいシステムがたくさんあると確信しています。コードは非常に異なって見える可能性があり、利用可能なテスト フレームワークの範囲は異なる可能性があります。
また、私の推論は主に非常に短いテスト フィードバック ループに関するものです。私が開発している製品の場合、最短のフィードバック ループは非常に柔軟で、クラス テストからプロセス間シグナリングまですべてをカバーします。成果物サブプロダクトのテストには通常 5 分かかります。このような短いフィードバック ループの場合、テスト結果 (特にここで見ているコード カバレッジ メトリック) を使用して、リポジトリ内のコミットを拒否または受け入れることができます。
コード カバレッジ メトリクスを使用する場合、満たさなければならない一定の (任意の) パーセンテージだけを持つべきではありません。私の意見では、これを行っても、コード カバレッジ分析の真の利点は得られません。代わりに、次のメトリックを定義します。
- ロー ウォーター マーク (LWM)、これまでにテスト対象のシステムで見られたカバーされていない回線の最小数
- ハイ ウォーター マーク (HWM)、テスト中のシステムでこれまでに見られた最高のコード カバレッジ パーセンテージ
LWM を上回らず、HWM を下回らない場合にのみ、新しいコードを追加できます。つまり、コード カバレッジの減少は許されず、新しいコードをカバーする必要があります。私がどのようにすべきか、すべきではないか注意してください (以下で説明します)。
しかし、これは、もう使用しない古い十分にテストされたゴミを一掃することが不可能になることを意味しませんか? はい、それが、これらのことについて実用的にならなければならない理由です。ルールを破らなければならない状況もありますが、通常の日常的な統合では、これらの指標が非常に役立つことが私の経験からわかります。それらは、次の 2 つの含意を与えます。
テスト可能なコードが促進されます。新しいコードを追加するときは、テスト ケースですべてのコードをカバーする必要があるため、コードをテスト可能にするために本当に努力する必要があります。通常、テスト可能なコードは良いことです。
レガシ コードのテスト カバレッジは時間の経過とともに増加しています。新しいコードを追加し、テスト ケースでカバーできない場合、LWM ルールを回避する代わりに、一部のレガシー コードをカバーしようとすることができます。この場合によっては必要となる不正行為は、少なくとも、レガシー コードの対象範囲が時間の経過とともに増加するという肯定的な副作用をもたらし、これらの規則の一見厳密な適用を実際には非常に実用的なものにします。
繰り返しになりますが、フィードバック ループが長すぎる場合、統合プロセスでこのような設定を行うことはまったく現実的ではありません。
また、コード カバレッジ メトリックの一般的な利点を 2 つ挙げたいと思います。
コード カバレッジ分析は、動的コード分析の一部です (静的コード分析、つまり Lint とは対照的です)。動的コード分析中に (purify ファミリーhttp://www-03.ibm.com/software/products/en/rational-purify-familyなどのツールによって) 発見された問題は、初期化されていないメモリー読み取り (UMR) などです。メモリ リークなど。これらの問題は、実行されたテスト ケースでコードがカバーされている場合にのみ発見できます。テスト ケースでカバーするのが最も難しいコードは、通常、システムの異常なケースですが、システムを適切に失敗させたい (つまり、クラッシュではなくエラー トレースを行う) 場合は、異常なケースをカバーするためにいくらかの努力を払うことをお勧めします。動的コード分析でも。少し運が悪いと、UMR はセグメンテーション違反またはそれ以上の事態につながる可能性があります。
人々は、新しいコードを 100% 維持することに誇りを持ち、他の実装の問題と同様の情熱を持ってテストの問題について議論します。この関数をよりテストしやすい方法で記述するにはどうすればよいでしょうか? この異常なケースをどのようにカバーしようとしますか?
そして、完全を期すために、否定的です。
- 多くの開発者が関与する大規模なプロジェクトでは、全員がテストの天才であるとは限りません。この質問に対する他の多くの回答で述べられているように、一部の人々は、コードがテストされていることの証明としてコード カバレッジ メトリックを使用する傾向があり、これは真実とはかけ離れています。これは、適切に使用すればいくつかのメリットをもたらす 1 つの指標ですが、誤って使用すると、実際には悪いテストにつながる可能性があります。上記の非常に価値のある副作用は別として、カバーされた行は、テスト中のシステムが入力データのためにその行に到達でき、ハングまたはクラッシュすることなく実行できることを示しているだけです。
于 2014-07-25T07:45:32.947 に答える
7
これが完璧な世界だったら、コードの 100% が単体テストでカバーされるでしょう。ただし、これは完璧な世界ではないため、時間の問題です。結果として、特定のパーセンテージに集中するのではなく、重要な領域に集中することをお勧めします。コードが適切に作成されている場合 (または少なくともその適切な複製である場合)、API が他のコードに公開される重要なポイントがいくつかあるはずです。
これらの API に集中してテストしてください。API が 1) 十分に文書化されていること、および 2) その文書に一致するテスト ケースが記述されていることを確認してください。期待される結果がドキュメントと一致しない場合は、コード、ドキュメント、またはテスト ケースのいずれかにバグがあります。これらはすべて吟味するのに適しています。
幸運を！
于 2008-09-18T04:30:24.723 に答える
6
コード カバレッジは単なる別の指標です。それ自体、非常に誤解を招く可能性があります ( www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overratedを参照)。したがって、目標は 100% のコード カバレッジを達成することではなく、アプリケーションに関連するすべてのシナリオを確実にテストすることです。
于 2014-09-25T19:00:45.700 に答える
4
コードの単体テストが十分ではなく、次に何をテストすればよいかわからない場合は、カバレッジを使用して次に何をテストするかを決定します。
単体テストのカバレッジを増やすと、この単体テストに価値があることがわかります。
これは、カバーされていないコード、50% がカバーされている、または 97% がカバーされているコードに当てはまります。
于 2010-05-19T15:34:10.290 に答える
4
85% は、チェックイン基準の出発点として適しています。
テスト対象のサブシステム/コンポーネントの重要性に応じて、出荷基準にさまざまな高いバーを選択したと思います。
于 2008-09-18T04:27:43.700 に答える
4
私は cobertura を使用していますが、割合に関係なく、cobertura-check タスクの値を最新の状態に保つことをお勧めします。少なくとも、totallinerate と totalbranchrate を現在のカバレッジのすぐ下まで上げ続けますが、決してこれらの値を下げないようにしてください。Ant のビルド失敗プロパティもこのタスクに関連付けます。カバレッジ不足のためにビルドが失敗した場合、誰かがコードを追加したことは知っていますが、それをテストしていません。例：
<cobertura-check linerate="0"
branchrate="0"
totallinerate="70"
totalbranchrate="90"
failureproperty="build.failed" />
于 2009-04-27T23:29:07.670 に答える
4
私は、自動化された受け入れテスト、場合によっては他の統合テスト、および単体テストを組み合わせて使用する BDD を行うことを好みます。私にとっての問題は、自動化されたテスト スイート全体の対象範囲をどの程度にするかということです。
それはさておき、答えは方法論、言語、テストおよびカバレッジ ツールによって異なります。Ruby または Python で TDD を実行する場合、100% のカバレッジを維持することは難しくありません。90 パーセントのカバレッジよりも 100% のカバレッジを管理する方がはるかに簡単です。つまり、カバレッジ ギャップが表示されたら埋める方がはるかに簡単です (また、TDD を適切に実行している場合、カバレッジ ギャップはまれであり、通常は時間を費やす価値があります)。カバーされていないコードの一定のバックグラウンドによる回帰。
答えは、プロジェクトの歴史によっても異なります。最初からそのように管理されたプロジェクトで上記が実用的であることがわかっただけです。私は大規模なレガシー プロジェクトのカバレッジを大幅に改善してきましたが、それには価値がありました。早く。
于 2016-05-12T14:05:47.710 に答える
3
ユニットテストをかなりの時間行っているのであれば、95％以上に近づかない理由はわかりません。ただし、テストを初めて行う場合でも、少なくとも80％で作業してきました。
この数には、プロジェクトで記述されたコード（フレームワーク、プラグインなどを除く）のみを含める必要があり、外部コードの呼び出しで記述されたコードで完全に構成される特定のクラスを除外することもできます。この種の呼び出しは、モック/スタブする必要があります。
于 2008-09-18T04:35:32.480 に答える
3
この難問に対する私の答えは、テストできるコードの行カバレッジを 100% にし、テストできないコードの行カバレッジを 0% にすることです。
Python での私の現在のプラクティスは、.py モジュールを app1/ と app2/ の 2 つのフォルダーに分割することです。単体テストを実行するときに、これら 2 つのフォルダーのカバレッジを計算し、app1 のカバレッジが 100% であることを視覚的に確認します (いつかこれを自動化する必要があります)。 app2 のカバレッジは 0% です。
これらの数値が標準と異なる場合は、コードの設計を調査して変更し、カバレッジが標準に準拠するようにします。
これは、ライブラリ コードの 100% の行カバレッジを達成することをお勧めできることを意味します。
また、app2/ をときどき見直して、そこにあるコードをテストできるかどうかを確認し、可能であれば app1/ に移動します。
プロジェクトの規模によってカバー率が大きく変わる可能性があるため、総カバー率についてはあまり心配していませんが、一般的には 70% から 90% を超えています。
Python を使用すると、カバレッジを測定しながらアプリを自動的に実行できるスモーク テストを考案でき、スモーク テストと単体テストの数値を組み合わせたときに 100% の集計が得られることを願っています。
于 2008-09-19T10:11:17.123 に答える
3
コード カバレッジは優れていますが、そこから得られるメリットが、それを達成するためのコストや労力を上回る場合に限られます。
しばらくの間、80% の標準に取り組んできましたが、これを放棄し、代わりにテストに集中することを決定しました。複雑なビジネスロジックなどを中心に、
この決定は、コード カバレッジの追跡と既存の単体テストの維持に費やす時間が増加したために行われました。コード カバレッジから得られる利益が、それを達成するために投入しなければならなかった労力よりも少ないと見なされるようになったと感じました。
于 2008-09-19T15:23:34.010 に答える
3
一般的に言えば、私が読んだいくつかのエンジニアリング エクセレンスのベスト プラクティスの論文から、単体テストで新しいコードの 80% が最高のリターンを生み出すポイントです。その CC% を超えると、努力の量に対して欠陥の量が少なくなります。これは、多くの大企業で使用されているベスト プラクティスです。
残念ながら、これらの結果のほとんどは企業内部のものであるため、参照できる公開文献はありません。
于 2008-09-18T04:53:45.477 に答える
2
Crap4jをチェックしてください。これは、ストレートコードカバレッジよりも少し洗練されたアプローチです。コードカバレッジ測定と複雑さの測定を組み合わせて、現在テストされていない複雑なコードを示します。
于 2008-09-18T20:00:52.160 に答える
2
短い答え: 60-80%
長い回答: プロジェクトの性質に完全に依存すると思います。私は通常、すべての実用的な部分を単体テストすることからプロジェクトを開始します。プロジェクトの最初の「リリース」までに、実行しているプログラミングのタイプに基づいて、かなり良い基本パーセンテージが得られるはずです。その時点で、最小限のコード カバレッジの「適用」を開始できます。
于 2008-09-18T04:31:14.673 に答える
2
私の意見では、答えは「どれだけ時間があるかによる」です。100%達成を目指しますが、時間内に達成できなくても大騒ぎしません。
単体テストを書くときは、本番コードを開発するときとは別の帽子をかぶっています。テストされたコードが何を行うと主張しているのか、それを壊す可能性のある状況は何かについて考えます。
私は通常、次の基準または規則に従います。
単体テストは、コードの予想される動作に関するドキュメントの形式である必要があります。特定の入力が与えられたときに期待される出力と、クライアントがキャッチしたい可能性のあるスローされる可能性のある例外 (コードのユーザーが知っておくべきことは何ですか?)
単体テストは、私がまだ考えていなかった可能性のある条件を発見するのに役立つはずです。(コードを安定して堅牢にする方法は?)
これら 2 つのルールで 100% のカバレッジが得られない場合は、それで問題ありません。しかし、時間ができたら、カバーされていないブロックと行を分析し、単体テストのないテスト ケースがまだあるかどうか、または不要なコードを削除するためにコードをリファクタリングする必要があるかどうかを判断します。
于 2011-08-14T15:13:36.033 に答える
2
カバレッジを別の観点から見る: 明確な制御フローを備えた適切に作成されたコードは、最もカバーしやすく、読みやすく、通常はバグが最も少ないコードです。明確さと網羅性を念頭に置いてコードを記述し、コードと並行して単体テストを記述することで、最高の結果が得られます。
于 2009-01-31T11:16:42.447 に答える
1
正しいコードカバレッジの最良の症状は、単体テストで修正するのに役立つ具体的な問題の量が、作成した単体テストコードのサイズに合理的に対応していることだと思います。
于 2008-09-18T04:34:09.237 に答える
1
最も重要なことは、時間の経過に伴うカバレッジの傾向を知り、傾向の変化の理由を理解することだと思います. トレンドの変化を良いと考えるか悪いと考えるかは、理由の分析次第です。
于 2009-04-27T22:49:59.823 に答える
1
それはあなたのアプリケーションに大きく依存します。たとえば、一部のアプリケーションはほとんどが単体テストできない GUI コードで構成されています。
于 2008-09-18T04:29:23.163 に答える
1
そんなB/Wルールはあり得ないと思います。
コードは、重要な詳細に特に注意してレビューする必要があります。
ただし、テストされていない場合は、バグがあります。
于 2008-09-18T04:30:42.117 に答える
1
コードの重要度にもよりますが、75% から 85% の範囲が目安です。配送コードは、社内ユーティリティなどよりも徹底的にテストする必要があります。
于 2008-09-18T04:31:39.133 に答える
1
これは、アプリケーション開発ライフサイクルのどの段階にいるかによって異なります。
開発にしばらく携わっていて、すでに多くのコードが実装されていて、コード カバレッジについて考える必要があることに気付いたばかりの場合は、現在のカバレッジを確認し (存在する場合)、そのベースラインを使用してスプリントごとにマイルストーンを設定する (またはスプリント期間の平均上昇)。これは、エンド ユーザーに価値を提供し続けながら、コードの負債を負うことを意味します (少なくとも私の経験では、テストを増やしても、エンド ユーザーは少しも気にしません。新しい機能が表示されない場合は、カバレッジ)。
ドメインによっては、95% を狙うのも無理はありませんが、平均して 85% から 90% のケースを見ていると言わざるを得ません。
于 2008-09-18T04:33:11.423 に答える
0
Testivusの投稿から、答えのコンテキストは2番目のプログラマーでなければならないと思います。
実用的な観点からこれを言ったとしても、私たちは努力するためのパラメータ/目標が必要です。
これは、アーキテクチャ、機能（ユーザーストーリー）を備えたコードを分析することでアジャイルプロセスで「テスト」できると思います。そして、いくつかを考え出します。テレコム分野での私の経験に基づくと、60％がチェックするのに良い値だと思います。
于 2013-03-13T17:28:57.363 に答える
0
数日前までは 80% 以上を目標にしていましたが、多くの生成されたコードを使用した後、%age は気にせず、レビュアーに必要なカバレッジについて電話をかけてもらいました。
于 2008-09-18T04:32:14.297 に答える