1.3テストのパターンとアンチパターン
1.3.1テスト自動化
- パターン：テストユニット、コンポーネント、容量、機能、および展開を含めることにより、ソフトウェアの検証と検証を自動化します。
- アンチパターン：ユニット、コンポーネント、展開などの手動テスト
- 依存関係のないテストのユニット自動化。
- コンポーネント-他のコンポーネント、データベース、およびファイルシステムに依存するテストの自動化。
- 展開-テストを自動化して、展開と構成が成功したことを確認します。 これは「煙」テストと呼ばれることもあります。
- ユーザーの観点からソフトウェアの動作を検証するテストの機能自動化。
- キャパシティ-運用に近い条件で負荷とパフォーマンスをテストする自動化。
1.3.2テストデータの分離
- パターン：データベース依存のテスト（コンポーネントテストなど）にトランザクションを使用し、完了時にトランザクションをロールバックします。 効果的な動作テストのために、データの小さなサブセットを使用します。
- アンチパターン：実稼働データのコピーを使用して、コミットステージテストを行います。 共通データベースでテストを実行します。
1.3.3並列テスト
- パターン：並行して、ハードウェアインスタンスでいくつかのテストを実行し、費やす時間を削減します。
- アンチパターン：単一のマシンまたはインスタンスでテストを実行します。 並行して実行できない依存テストの実行。
1.3.4システムの安定性
- パターン：スタブを使用して外部システムをシミュレートし、展開の複雑さを軽減します。
- アンチパターン：コミットステージのビルドと展開のための相互依存システムの手動インストールと構成。
1.3.5有害と考えられるエンドツーエンドのテスト
継続的デリバリーは、市場投入までの時間を短縮することを目的とした全体的な原則と実践のセットです。 テストのおかげで、高速で信頼性の高いフィードバックに基づいています。 継続的デリバリでは、コード、構成、データ、またはインフラストラクチャを変更して、展開パイプラインで一連の自動化された探索的テストを実施し、運用の準備状況を評価する必要があります。 したがって、組織がより短い期限を達成したい場合、テストの実行時間は短く、テスト結果は明確でなければなりません。
たとえば、年末の支払いが後続の支払いサービスに送信される会社の支払いサービスを考えてみましょう。
Company Paymentサービスの動作は、以下のタイプの自動テストを実行することにより、アセンブリ時に確認できます。
- 単体テスト：個々のコードモジュールをチェックするときの目標と実装を比較します。
- 受け入れテスト：システムの機能部分をチェックするときの実装と要件の比較。
- エンドツーエンドのテスト：所有者なしの依存サービスを含むシステムの機能部分をチェックするときの実装と要件の比較。
単体テストと受け入れテストの目的と範囲は異なりますが、受け入れテストとエンドツーエンドテストの量は異なります。 受け入れテストには孤児に依存するサービスが含まれていないため、会社支払いのユーザーの旅行の受け入れテストでは、会社支払いの最新バージョンのコードと支払いスタブで構成されるテストシステムを使用します。
エンドツーエンドテストには所有者なしの依存サービスが含まれているため、企業ペイメントのユーザーのエンドツーエンド旅行テストでは、最新の会社ペイメントコードとペイメントの作業バージョンで構成されるテストシステムを使用します。
テスト戦略が継続的デリバリーと互換性がある場合、ユニットテスト、受け入れテスト、エンドツーエンドテストの適切な比率を設定する必要があります。これにより、情報の必要性と迅速で明確なフィードバックのバランスが取れます。 テストによって新しい情報がもたらされない場合、欠陥は見過ごされます。 ただし、テストに時間がかかりすぎると、配信が遅くなり、失われた収益が増加します。
2番目の部分の終わり。
確立された伝統によると、私たちはあなたのコメントを待っており、 オープンデーにあなたを招待します。 記事の3番目の部分は、 ここですでに利用可能です 。