CI / CDパターンとアンチパターン。 パート3

こんにちは。 本日、記事「CI / CDパターンとアンチパターン」の第3部の翻訳を共有したいと思います。その前の部分は、 こことここで読むことができます 。 この一連の出版物は、コース「DevOps Practices and Tools」の新しいストリームの立ち上げに専念していることを思い出してください。このセットは今後数日で終了します。



1.3.5.1エンドツーエンドテストの欠点



「このシステムと通信することの利点は、非決定論を根絶する必要性に隠れています」とマーティン・ファウラー。



エンドツーエンドテストは、アセンブリ中に多数の自動化されたエンドツーエンドおよび手動のリグレッションテストが、少数の自動化された単体テストおよび受け入れテストとともに使用されるプラクティスです。 エンドツーエンドテストのテストの比率は、 アイスクリームホーンとして視覚化できます。







エンドツーエンドテストは、エンドツーエンドテストの主観的な利点のために魅力的であることがよくあります。

1. エンドツーエンドのテストは、テスト対象システムを最大化します。これは、高度なテストカバレッジを意味します。
2. エンドツーエンドテストでは、システム自体をテストクライアントとして使用します。これは、テストインフラストラクチャの低コストを意味します。

上記を考えると、多くの組織がエンドツーエンドのテストを導入している理由を理解できます。 Don Reinertsenが述べたように、「 この低コストと高信頼性の組み合わせにより、このようなシステムテストの費用対効果の錯覚が生まれます 。」 ただし、エンドツーエンドのクロステストの価値命題は、両方のステートメントが間違っているため、完全に間違っています。

1. システム全体のテストにはコンポーネントのチェックが含まれるという考えは、 分解エラーです。 要件への準拠の検証は、目標への準拠の検証とは異なります。 これは、エンドツーエンドテストがコードパス間の相互作用をチェックすることを意味しますが、これらのパス自体の動作はチェックしません。
2. システム全体をテストすることは、そのコンポーネントをテストするよりも安くなるという考えは、 安い投資の誤りです 。 テスト実行時間と非決定性は、SUTボリュームに正比例します。 これは、エンドツーエンドのテストが遅く、非決定性になりやすいことを意味します。

以前、Martin Fowlerは「 非決定論的テストは自動回帰セットの価値を完全に破壊する可能性がある」と警告し、Stephen CoveyのControl、Influence、Concern Cyclesは、非決定論の検索と解決を複雑にするパススルーテストファクターの数を強調しています。 同じCompany R Us組織内の異なるチームがCompany Accounts and Productsサービスを所有している場合、Company Accountsチームはエンドツーエンドテストでサービスを制御しますが、これは支払いサービスにのみ影響します。



エンドツーエンドテストの改善に必要な時間は、SUTの変更の場所によって異なります。 企業アカウントチームは、この変更を短時間で分析して実装する必要があります。 ただし、ペイメントサービスに変更を加えるのに必要な時間は、企業アカウントチームがペイメントサービスチームに業務を開始するよう説得するのに必要な時間より短くすることはできません。



別のケースでは、別のPayments R Us組織がペイメントサービスを所有していた場合、それは単なるサードパーティサービスであり、企業アカウントチームにとっては問題ではありません。

この場合、企業アカウントチームはPayments R Usの組織に影響を与えないため、Paymentsサービスの変更にはさらに時間がかかります。 さらに、Paymentsサービスは予期せず更新される可能性があります。これにより、企業アカウントのエンドツーエンドテストの非決定性が高まり、テスト実行の予測可能な結果を​​確立できなくなります。



エンドツーエンドテストへの依存は、資金不足の長期化の症状であることが多く、これによりシステムが脆弱になり、変更できなくなり、配信時間が長くなり、 平均復旧時間ではなく平均 MTBFに最適化されます。 このようなシステムでは、外部要因による変化のためにユーザーエクスペリエンスと運用パフォーマンスを正確に予測することは不可能であり、障害のコストではなく障害の可能性に注目すると、 Black Swansとして知られる非常にありそうではないが非常に高価なイベント、たとえばKnights Capitalが440ドルを失います45分で100万。 そのため、Paymentsデータセンターで壊滅的な障害が発生した場合、企業アカウントサービスで行われたすべての顧客支払いは実行されません。



その場で支払いサービスにアクセスできないと、企業アカウントの顧客への支払いがブロックされ、サービスの回復が遅いため、不満のある顧客は他の会社に振り向けられます。 一部の支払いが失われ、それが公に知られるようになると、これは顧客の信頼を大きく失うことになります。



エンドツーエンドのテストは、費用がかかり制限的な戦略です。 パススルーテストは動作を確認せず、実行に時間がかかり、定期的に失敗するため、主にパススルーで構成されるテストスイートはカバレッジが悪く、実行時間が遅くなり、結果が不確定になります。 欠点は気付かれず、フィードバックは遅く信頼性が低くなり、サービスコストが増加し、その結果、テスターは独自の手動のエンドツーエンドの回帰テストに頼らざるを得なくなります。 エンドツーエンドのテストでは、リードタイムを短くすることはできず、継続的デリバリーとは完全に互換性がありません。



1.3.5.2継続的テストの利点



「大量管理への依存症を終わらせる 最初に製品の一部を高品質にすることで、大量検証の必要性を排除します。 W.エドワーズデミング 。



継続的デリバリーには継続的テストが必要です。これは、多数の自動化された単体テストと受け入れテストを、少数の自動化されたエンドツーエンドの集中的な研究テストで補完する戦略です。 連続テストでのテストの比率は、 ピラミッドの形で視覚化できます。これは、アイスクリームホーンの一種のアンチテーゼです。



継続的テストは、テストによる開発および受け入れテストによる開発と連携しています。 品質に対する全体的な取り組みの一環として機能横断的なテストを行うことで、継続的デリバリの原則、つまりプロセスに統合された品質を体現しています。 ただし、ユニットと受け入れテストの欠陥が疑われるため、継続テストは複雑に見えるかもしれません。

1. 単体テストまたは受け入れテストは、SUTを最小化します。これは、テスト範囲が低いことを意味します。
2. ユニットまたは受け入れテストでは、独自のテストクライアントを使用します。これは、テストインフラストラクチャのコストが高いことを意味します。

多くの人々は、高いテストカバレッジと低いサポートコストという誤った仮定からエンドツーエンドテストを使用していますが、それでも連続テストではテストカバレッジが低く、サポートに費用がかかると考えています。

1. 単体テストは目標の実装の適合性を検証し、受け入れテストは実装が要件を満たしていることを検証します。 そのため、すべての実行方法と相互の相互作用を確認できます。
2. 単体テストはSUTを単一の実行パスに制限し、受け入れテストは単一のサービスに制限されます。 そのため、どちらも最短のリードタイムと確定的な結果を得ることができます。

非決定的受け入れテストは、SUTの唯一の所有者のおかげで、エンドツーエンドテストよりもはるかに高速に修正できます。 会社R Usが会社アカウントサービスを所有し、支払いR Usが支払いサービスを所有している場合、会社アカウント受入テストではチームが管理するサービスのみを使用します。



企業アカウントチームが受け入れテストで非決定性を特定して解決しようとする場合、必要な変更を短時間で実装できます。 また、最新の企業アカウントコードの受け入れテストを妨げる可能性のある、ペイメントサービスの予期しない変更を恐れる必要はありません。 これにより、予測可能なレベルのテストが作成されます。



エンドツーエンドのテストは継続的なテストの一部です。特に、「システムの個々の部分をテストすることはシステム全体をテストする」という考えは誤りであるためです。 少数の自動化されたエンドツーエンドテストを使用して主要なユーザーシナリオを検証する必要がありますが、ビルド中、所有者のない依存サービスが信頼できず代表的でない場合は検証しないでください。 エンドツーエンドテストは、リリース中の煙テストおよび操作中のモニタリングに使用して、人工的なトランザクションでユーザーアクティビティをシミュレートする必要があります。 このアプローチは、バトルのリリースに対する信頼性を高めるため、フィードバックサイクルを高速化し、ユーザーの行動の理解を向上させるために、ビジネスおよび運用メトリックのリアルタイムモニタリングと組み合わせる必要があります。



継続的デリバリでは、平均故障時間の最適化は平均故障間隔の最適化よりも重要であると認識されています。これにより、組織は製造欠陥の影響を最小限に抑え、達成しやすくなります。 Little Lawでは、短いリリースでトラブルシューティング期間が短縮されるため、欠陥のコストを制御できます。ContinuousTestingは、頻繁なリリースのフィードバックサイクルを減らすために必要なインフラストラクチャを提供します。 Blue Green ReleasesやCanary Releasesなどの継続的なテストと継続的な配信方法の組み合わせにより、組織は不測の事態を中和できる信頼性の高いシステムを作成できます。また、Dark LaunchingやChaos Engineeringなどの高度なプラクティスにより、Black Swansの恩恵を受ける脆弱なシステムを構築できます。 たとえば、Chaos Engineeringがペイメントサービスの問題を検出した場合、企業アカウントチームは、ペイメントスタブのダークローンチを実稼働に移行し、ペイメントデータセンターの障害の予期しないケースで使用できます。



ペイメントデータセンターがオフラインの間は、ペイメントサービスが動作を開始するまで、企業アカウントサービスはペイメントスタブでの顧客の支払いの収集にエレガントに移行します。 このインシデントは顧客に影響を与えません。競合他社が同じサードパーティペイメントサービスに依存している場合、これは市場での戦略的優位性になる可能性があります。 過剰な運用能力は不要に思えるかもしれませんが、継続的テストは運用の卓越性を促進します。NassimNicholas Talebが述べたように、「異常なことは通常何でも起こる」



連続テストは、包括的で安価なテスト戦略になります。 Dave FarleyとJez Humbleによると、「品質の埋め込みとは、複数レベルでの自動化されたテストの記述」であり、ユニットテストと受け入れテストで主に構成されるテストスイートには、高度なテストカバレッジで慎重にテストされたシナリオが含まれ、短いリードタイムと予測可能なテスト結果。 そのため、エンドツーエンドのテストは煙のテストと生産の監視に任せることができ、手動の回帰テストの代わりにテスターは、たとえば研究テストなど、より価値のあることを行うことができます。 これにより、製造上の欠陥の数、迅速で信頼性の高いフィードバック、市場参入の準備時間の短縮、収益成長の新たな機会がもたらされます。



1.3.5.3エンドツーエンドのテストから継続的なテストまで



「最大限の投資収益率と最速のフィードバックを得るために、可能な限り深くテストしてください」 ジャネット・グレゴリーとリサ・クリスピン 。



エンドツーエンドテストから継続的テストへの移行は、責任範囲が次のように定義されている場合、エンドツーエンドテストがテストピラミッドの下部にあるという考えに基づいた長期投資です。

• 通信-サービスが相互に接続できるかどうか。
• ダイアログ-サービスが互いに通信できるかどうか。
• 動作-サービスが相互に反応できるかどうか。

Company AccountsサービスがPaymentsサービスのPaypointエンドポイントに依存しており、Paypointエンドポイントが会社IDと支払いサイズを受け入れ、確認コードと支払いが行われるまでの日数を発行するとします。 サービス会社のアカウントはリクエストフィールドのIDと支払いサイズを送信し、レスポンスフィールドに依存します。



サービス間の接続は、テストダブルを使用してモジュール式でテストできます。これにより、企業アカウントサービスは、支払いサービスのさまざまな動作に対する反応をテストできます。 企業アカウントの単体テストでは、コネクタをモックまたはスタブコネクタに置き換えて、予期しない支払いタイムアウトなどのスクリプトを正しく処理します。



サービス間の対話は、コンシューマードリブン契約の助けを借りてモジュール式で確認できます。これにより、企業アカウントサービスは、支払いサービスとの相互作用を継続的に確認できます。 ペイメントサービスは、ビルド時にPay APIを説明するプロバイダーコントラクトを発行し、企業アカウントサービスは、使用状況を説明するコンシューマコントラクトを返します。 支払いサービスは、各ビルド中にチェックされる消費者主導の契約を作成します。



Company Accountsサービスは何日もフィールドを使用しないため、Consumer ContractおよびConsumer Driven Contractから除外されます。 したがって、日数の削除または応答コメント用の新しいフィールドの追加を含む、ペイメントサービスのアセンブリは成功します。 応答コードフィールドが削除されると、消費者主導の契約は失敗し、支払いチームは別のアプローチで企業アカウントチームに同意する必要があります。



サービスの動作は、APIサンプルを使用してモジュール式でテストできます。これにより、企業アカウントサービスは、Paymentsサービスの新しいリリースでの動作の変更を確認できます。 各リリースには、PayエンドポイントのリクエストおよびレスポンスAPIの例を含むアーティファクトが付属します。これは、代表的なテストデータとして企業アカウントの単体テストに接続され、動作の変更を警告します。



ペイメントサービスの新しいバージョンが応答コードフィールドの形式を英数字から数字に変更すると、アセンブリ中に企業アカウントサービスがクラッシュし、ペイメントサービス内の動作の変更と、両方のチームでこの問題を議論する必要があることを示します。



1.3.5.4結論



「システムテストはすべてのバグを検出するだけでなく、効果的な受け入れテストをスキップすることで節約できる以上の時間と費用も必要になります」 -Jerry Weinberg 。



エンドツーエンドのテストは、高いテストカバレッジと低いサポートコストの約束で組織を引き付けます。 ただし、自動化されたエンドツーエンドおよび手動の回帰テストを継続的に使用すると、配信時間が長くなり、継続配信と互換性のない、信頼性の低い低速の脆弱なシステムになります。 継続的なテストには、テスト自動化への予備的および継続的な投資が必要ですが、自動化されたユニットと受け入れテストの包括的なセットは、製造欠陥と納期を削減し、信頼性が高く脆弱なシステムの継続的デリバリーを促進する、迅速で確定的なフィードバックを提供します。