あなたが知っているように、「銀河へのヒッチハイクのガイド」という本、人生、宇宙、そして42のすべての主要な質問への答えから。製品の品質を判断するのに十分なテストですか？」
IT分野とテストでの作業中、テスターが実際にコードカバレッジを使用しているチームやプロジェクトはほとんど見られませんでした。 私の意見では、これは次の2つのことに関連しています。
1.すべての要件の最初にテストするという事実。
2.誰もがコーティングのカウント方法と使用方法を理解しているわけではありません。
興味のある方のために、これらの2つの点について意見を述べます。
要件とコード
テスターは要件をテストします。 それらが正式に存在していなくても、システムがどのように振る舞うべきかという考えがあります。 これは、長期的にはこれだけが重要です。
しかし 。
明確で完全な完全な要件はなく、それぞれを確認したため、システムは正常に機能し、バグはないと言うことができます。
例1
アプリケーションは、データベース（別のサーバーにある）にデータを保存しようとしています。 操作の実行が不可能な場合（たとえば、データベースへのアクセスがない場合）、特定のタイムアウトが期限切れになる前にこれを試行し、クライアントにエラーを与える必要があるなど、これを行う方法の説明があります。
操作を実行できないことはどういう意味ですか？
テスターが、操作中にデータベースへの接続が失われたスクリプトをチェックするとします。 すべてうまくいきますが、バグがないということですか？
上記のアプリケーションでは、対応するクラスのコードカバレッジを調べました。開発者がコード内の約5つの例外的な状況の処理を提供していることがわかりました。
これは、少なくとも次の場合を意味していました。
1.データベースサーバーへの接続を確立できません。
2.データベースサーバーへの接続が確立され、クエリの実行によりOracleエラーが発生しました。
3.データベースサーバーへの接続が確立され、リクエストの実行が開始され、ハングしました-バグがありました。 アプリケーションは約5分間応答を待った後、実行がログに飛んで、このデータを書き込もうとしませんでした。
他のカップルは、さまざまな理由で注目に値しませんでした。
要件の例では、最初のケースも正式にチェックされましたが、コードカバレッジを分析した後にバグが見つかりました。 この例は、コードカバレッジの利点ではなく、チーム内でやり取りすることの利点（前もって実装の詳細を確認したり、レビューのためにケースを提供したりできる）であると主張することができます。コードのカバーされていないブロックは、しばしば特定のことに注意を引きます。
例2
私がテストした別のシステムでは、データの一貫性が失われた場合、アプリケーションは適切な実行をスローし、監視に通知を送信し、人々が来て保存するのを待ちます。 テストでは、このような状況のさまざまなケースがカバーされ、すべてが正常に処理されました。
コードを見て、目的の部分はよく覆われていましたが、別のクラスでは、コードのコーティングされていない領域があり、同じイベントが一貫性の喪失について急いでいました。 どのような条件下で-それは知られていない、なぜなら 開発者はすぐにそれを切り落としました。 彼は古いプロジェクトからスキップされたことが判明しましたが、誰もそれを覚えていませんでした。 どこで撃つことができるかは不明ですが、コード分析がなければ見つかりませんでした。
したがって、テスターに要件をテストさせてください。ただし、コードを調べた場合、要件に記述されていないものをキャッチでき、テスト設計のcな方法も常に見つかるとは限りません。
カバレッジ=80。そして品質は？
数量は品質を意味するものではありません。 コードカバレッジの評価は、製品の品質に直接関連するのではなく、間接的に関連しています。
ある報告会で、私はコードカバレッジが回線で82％、用語で51％に増加したと述べました。その後、経営者から次の質問がありました。 論理的な質問、本当に：それがどれだけ良いものになるのか？
一部の開発者はコードをカバーし、100％を達成しています。 100％テスターを達成することは無意味です。ある時点から、統合テストでこのコードに物理的に影響を与えられないという事実に遭遇するでしょう。
たとえば、開発者はメソッドの入力パラメーターのnullをチェックすることをお勧めしますが、実際に動作しているシステムではそのようなケースは存在しない場合があります（そのため、そのための条件を含めて50％）。 これは正常です。実際にこの状況を処理する最初のチェックの前にのみ、外部からnullを渡すことができます。
「これは正常です」という質問に答えます。カバーされていないコードの定性的評価は 、私の理解では、コードカバレッジの適切な使用につながります。 どれだけではなく、あなたが覆われていないことを見ることが重要です。 JavaコードとメソッドtoString（）、equals（）、または例外付きの分岐であり、それらを完全に再現するのが難しい場合は、まあ、実際のビジネスロジックの80％がカバーされるようにします。 多くのツールは、余分なコードをカウントせずにフィルタリングできます。
ホワイトスポットにまだ疑問がある場合は、統合テストとユニットの合計カバレッジを計算することができます。おそらく、開発者は、統合テストではアクセスが困難な多くのことを考慮しました。
ただし、1つの「しかし」があります。 コードカバレッジが低い場合はどうなりますか？ 20％、30％？ どこかで私がおもしろい事実を読んだのですが、カバレッジが50％以下（回線と条件による）は、アプリケーションの結果がテストなしの場合と同じになるテストカバレッジのレベルを意味します。 つまり バグがあるかもしれません、バグがないかもしれません、あなたがそれをテストしなかったかもしれない同じ成功で。 もう1つの説明は、デッドコードが大量にあることです。
そして、自動テストはありません
しかし、それらは必要ありません。 反対のことを確信していても、一部の開発者は、カバレッジが単体テストだけでなく考慮されることを認識していません。 実行時にカバレッジを記述するツールがあります。
ポイントは何ですか？
素晴らしいテストリーダーである私の友人は、「テストケースがすべてではなく、自動化がまだ始まったばかりのとき、コードカバレッジの評価にリソースを費やすのは理にかなっていますか？」という質問をしました。そして他の存在の弱さ、テスター・ドリーマーの飛行の余地はありません。
コードカバレッジを検討する場合は、リソースをどこで使用する必要があるかを正確に分析します。
- アプリケーションに適したツールを選択する
- ビルドのインストルメンテーション（コードカバレッジツールチップの構成とコード評価のための「不要」のフィルタリングを含む）
- テスト実行後のカバレッジレポート
- カバレッジ分析
ポイント1と2は開発者に与えることができ、それらの多くはよく知られており、よく知られており、よく知られたツールに出会い、さらに、独自のビルドをビルドできます。 レポートは通常、コマンドラインで1つのコマンドによって実行されるか、CIを使用している場合は自動的に実行されます（ジェンキンスは私のためにこれを行いました。
最も高価なのは4番目のポイントです。 ここでの主な難点は、適切な評価のために、コードを読むか、開発者の隣に座って、この作品の意味と再現方法を説明できるようにする必要があることです。 これには、テストエンジニアからの一定の資格と1人または2人の労働時間が必要です。
価値があるかどうかは、チームとそのリーダーが決定します。 要件の形式化が不十分なプロジェクト、またはテスターにとって不可解な方法でバグが発生するプロジェクトでは、おそらくこれは少なくとも掘る方向を理解するのに役立ちます。
別のカテゴリは、非常に高いレベルのブラックボックステストを伴うプロジェクトです。 これは主に、独自の法則に従って動作するロジックの束を含むUIまたは外部APIシステムを介したテストです。 外部からは触ったり制御したりできません。つまり、正常にテストすることはできません。 このようなプロジェクトのカバレッジを分析すると、モジュール式、コンポーネント単位、スタブテストなど、より低いテストレベルに移行する必要性が生じます。
累積されたコードカバレッジは数字でうまくいきます。グラフでは、新しいコードが注がれた瞬間を確認でき、テストはまだ到着していません。 カバレッジレベルが高い場合は、低下し始めましたが、前のレベルには達しませんでした。テストなどに達していない要件の良いホワイトスポットがあるかもしれません。
おそらくこれが今日私が言いたかったことのすべてです。
最後に、制限と範囲外
- 多くの技術的な詳細を説明することなく、この問題へのアプローチを一般的な用語で説明しようとしました。 80％の「カバレッジ」と言えば、特定の一般的な、または平均的なカバレッジについて話しているのです。特定のメトリクス（回線、条件などのカバレッジ）を参照していません。 特定のメトリックの選択は、別の興味深い質問です。
- 私の経験は主にJavaコードとそのためのツールに関連しており、他のテクノロジーとこの脈絡で働いていませんでした、C ++用のツールがあることは知っていますが、今のところそれらを試すことができませんでした。
- カバレッジの深刻な分析は、安定したビルドと安定したテストで実行する必要があります。そうしないと、テストの欠落、重大なバグ、または実際に見逃したものの欠落の原因を特定することが困難になります。