継続的インテグレーションパイプラインで信頼できる十分な自動テストはいつ行われますか？
テストとの継続的な統合は、常に「出荷可能」コードがチェックインされていることを確認するのに役立ちます。
ただし、包括的なテストスイートを維持することは非常に難しく、多くの場合、ビルドにバグがあるように感じます。
CIパイプラインテストに自信を持たせるには、どのくらいのテストが必要ですか。十分なテストがあるかどうかを判断するために、ある種のメトリックを使用していますか？
一般に
継続的インテグレーションパイプラインで信頼できる十分な自動テストはいつ行われますか？
自信を持ってやりたいことを考えれば、答えは明らかになるでしょう。最終的には、1-1にマッピングされます。すべてのテストで、テストする1つのことに自信が持てます。
- ユニットテストでは、クラス（またはモジュール）がテスト対象の機能を実行していることを確認できます。
- 統合テストでは、いくつかのユニットがテストされた方法で連携して動作することを確信できます。
- エンドツーエンドのテストでは、アプリケーション全体がテストで記述されている方法で特定のことを実行することを確信できます。
あなたが質問を作成した方法から、あなたはおそらく現在、例えばビジネスの全体像を考えているでしょう：
私のアプリがXを実行できることを確信したいと思います。
したがって、Xを実行しようとするエンドツーエンドのテストを作成し、それが正しく実行されるかどうかを確認します。
より具体的
それはすべて非常に自己参照的ですが、それはそれが重要なことだからです。単にでないだけです。
たとえば、料理のレシピを作成するアプリを作成するとします。特徴の1つは、さまざまな種類のチーズをさまざまな量で追加すると、すべてが溶けるように正しい温度と時間が得られることです。
そのため、CheeseMeltCalculatorのユニットテストを記述できます。このテストでは、ゴーダ100gとエメンタールチーズ200gを与え、温度と時間が正しくなることを確認します。つまり、CheeseMeltCalculatorが100グラムのゴーダと200グラムのチーズで機能することを確信できます。 200gではなく300g Goudaでこのテストを繰り返すと、さまざまな値で正しく機能することをかなり確信できます。 Goudaの0、-1、int.MaxValue gのテストを追加して、奇妙な入力に対してコードが作動しない（または意図したとおりに作動しない）ことを確認できます。
統合テストを作成して、CheeseMeltCalculatorが食品全体の温度と時間の計算プロセスに正しく組み込まれていることを確認できます。これがうまくいかなくても、上記のCheeseMeltCalculatorテストで問題がなければ、バグが他の計算機にあるか、別の計算機のデータが結合される方法にあると確信できます。
そして最後に、レシピ全体を作成するためのエンドツーエンドのテストを作成できます。確認することの1つは、結果の温度と時間です。前の2つのレベルのテストで問題はないが、これがうまくいかない場合は、これらの部分が正しいことと、温度計算がアプリケーションにどのように統合されているかについて間違いがあることを再度確信できます。たとえば、ユーザー入力が正しく転送されない可能性があります。
そして、最終的に、これらすべてのテストが問題なければ、「異なる量のいくつかの異なる種類のチーズを追加すると、それはすべてが溶けるように正しい温度と時間を提供します "
ロングストーリーショート
要点は、「正しく機能する」テストを実行できないことです。 「Xを実行すると、Yが発生する」だけをテストできます。
しかし、これはまさにプロジェクトの技術仕様にあるべきものです。 「いくつかの異なる種類のチーズを異なる量で追加すると、正しい温度と時間が得られ、すべてが溶ける」のようなステートメントは、クライアントに明確な期待を与えるだけでなく完成した製品の動作だけでなく、自動テストに変えることもできます。
追加情報
ユーザーRichardが編集にこの情報を追加しました：
Martin Fowlerが彼のウェブサイトで最も一般的な戦略についての非常に素晴らしい要約を持っています： https://martinfowler.com/articles/microservice-testing/
私はこれを削除したくありませんが、私はこれを言いたいです：この回答と比較して、それは「要約」ではなく、ニースのグラフィックスとすべてを備えた、より詳細な説明です。
私のアドバイスは次のとおりです。私の答えを読んだ後、すべてが理にかなっている場合は、完了です。それでも不明点がある場合は、少し時間を置いて、リンクされた記事を読んでください。
求める信頼度を計算できるメトリックはありません。自信は、何かをしてから成功するか、失敗してそこから何かを学ぶことによって構築されます。
テストカバレッジに自信を与える唯一の「メトリック」は、次のとおりです。
- 生産で見つかった欠陥の数
- コードベースをリファクタリングし、テストカバレッジに依存して回帰の欠陥をキャッチできますか？
自動テストは特効薬ではありません。各リリースサイクル中に検出された製品の欠陥の数を追跡する必要があります。この数値が下がると、より優れたソフトウェアが提供されます。自動テストと継続的インテグレーションは単なるtoolsより良いソフトウェアを提供するために使用します。
実際に測定できる唯一の測定基準は、「より優れたソフトウェアを提供していますか」です。
そしてそれでも、それは主観的です。
継続的インテグレーションパイプラインで信頼できる十分な自動テストがあるのはいつですか？
ほとんどの経済環境では、十分な信頼性（> 99％）を実装するための予算はありませんが、限られた予算を管理する必要があります。それはすべて費用対効果の比率に関するものです。
- 自動化されたテストの中には、実装するのに安価なものもあれば、非常に高額なものもあります。
- 実際の risk-management に応じて、一部のリスクはテストでカバーする必要がありますが、他のリスクはカバーできません。
したがって、実際には、簡単/安価/危険なテストは実装されますが、高価な/可能性の低いテストは実装されません。
ソフトウェア開発のサブゴールの1つは、テストが容易/安価なアーキテクチャ（ Test-driven_development を適用してテスト容易性を設計する）を作成して、自動テストを手頃な価格で維持することです。
Pareto_principle は、ここでも保守可能/テスト可能なソフトウェアに適用できると思います。20％の追加の投資で、80％の追加の利益が得られるということです。残りの20％の利益を増やすには、追加の80％のお金を使う必要があります。
コードカバレッジ や ミューテーションカバレッジ のようなテスト指標を適用して、テストされていない可能性のあるソースコードを表示できます。
ただし、カバレッジが100％であっても、コードにバグがないことを確信することはできません。
管理はコードメトリックスが好きです。開発者が自動テストをサポートしていないなど、「コードカバレッジ> = 80％」が管理者によって強制されている場合、誤ったセキュリティ感を与えないことを証明しない高いカバレッジでテストコードを書く方法があります。
ここでの秘訣は、完全なカバレッジについて心配することではなく、変更のリスクを管理することです。
パイプラインを使用して、すでに本番環境にあるのとまったく同じバージョンをデプロイしているとしましょう-回帰エラーのリスクは何ですか？ゼロ（変更がないため）。
ここで、画面の1つのテキストを変更したいとします。テキストが正しく表示されることを確認するためのテストを追加しました（議論のために、それが本当に重要なテキストであると仮定しましょう）。回帰エラーがないことを確認するには、他にどのようなテストが必要ですか？現実的にはなし...
したがって、各リリースを有効にするために必要な自動テストの数は、アプリケーションのサイズではなく、変更のサイズの関数です。小さな低リスクの変更を行う場合は、リスクを軽減するために必要なテストがはるかに少なくなります。
しかし、ちょっと待ってください...これはCIとCDのポイントとうまく一致していませんか？
うん！すべての変更とデルタを非常に小さく保つことで、テストではなくプロセスを通じて多くの回帰リスクを軽減します。さらに、質問は実際には自動化の1つにはなりません（これは、使用するツールにすぎません）。テストとリスク選好の問題にすぎません。自動化を完全に忘れて、変更が問題を引き起こしていないことを確認するために、変更に対してどのテストを実行しますか？その質問への答えは、手動テストプロセスからCIシステムに変わりません。唯一の利点は、これらの回帰テストの多くが以前の機能で以前に開発された可能性があり、CIはより小さく、より安全な変更を行うことをお勧めします。
[〜＃〜] tldr [〜＃〜]
テストは、変更のリスクを軽減するためのものです。デルタがゼロの展開にはリスクがないため、リスクはありません。変更を小さく保つことで、それらを検証するために必要なテストを特定することがはるかに容易になります-自動化の再利用性はおまけです。
これは、製品を手動でテストする場合と同じ指標です。
実際には、これらの信頼度の低いゾーンを特定するのは簡単です。製品を出荷していると仮定すると、出荷可能であるという自信を高めるパイプライン後の手動ステップがあると思います。これらは、自動プロセス自体の信頼性を向上させるために自動化する必要がある領域です。
自動化は継続的な取り組みです。製品が向上するにつれて、成長し、向上します。欠陥は、CIを再考するとともに、コードを再考する理由です。そして、ここでの明るい面は、製品自体への信頼が得られるため、自動化への信頼も得られるということです。