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