連続したアプローチを使用する場合、最初に頭に浮かぶのは、安定した環境との比較です。 しかし、標準として、非常に限られた範囲の製品に適しています。これは、安定したテスト環境のデータが分岐することが多いためです。 多くの場合、安定した環境との比較が失敗することを確認して、研究者はバックツーバックテストの使用を拒否します。 このアプローチを実装するいくつかの標準的な方法について猫の下で読んでください。Yandexサービスに使用し、安定した環境を使用するときに発生する多くの問題を解決します。 また、発見した利点と欠点についても説明します。
たとえば、フロントエンドとバックエンドに分割できるWebサービスを考えます。 そのページは、バックエンドから受信したデータに基づいて形成されます。 したがって、フロントエンドの2つの独立したバージョンに同じデータが届く場合、それらはすでに比較可能な同じページを形成する必要があります。 これは2つの方法で行いました。
- フロントエンドの両方のバージョンを同じバックエンドに設定します。
- 彼らは必要なバックエンド応答をフロントエンドに直接渡しました。
これらの各方法をより詳細に検討してください。
共有バックエンド
サービスの説明
このメソッドを使用して、Yandex.Marketアフィリエイトインターフェイス（ ドキュメント ）をテストしました。これは、YandexパートナーがYandex.Marketでの商品の配置を管理し、店舗のステータスを監視し、統計を表示できるWebサービスです。 実際、サービスのすべての機能は、大量のさまざまなデータの表示です。 一部のデータは機密情報であり、ほとんどのページは認証プロセスの背後に隠されています。 同じページが異なるタイプのユーザーとストアで異なるように見える場合があるため、完全なテストを行うには、すべてのケースをカバーする多数のテストデータをサポートする必要があります。
テスト環境と安定した環境を比較するという事実に基づいて、このサービスはスクリーンショットによるチェックには絶対に適していません。 テストおよび安定した環境で大量の同一データを維持するのは非常に高価であり、一部のストアデータは機密であり、テスト環境で繰り返すことができないため、一部のページでは単に不可能です。
実装
手動チェック中、テスト環境は必要なすべてのケースを再生するためのデータをサポートします。 したがって、安定したパッケージを配置するサービスに追加の環境を展開し、テストベースに向けることで、データの不一致を取り除き、スクリーンショットを比較してテストできる2つのサービスインスタンスを取得します。
テストを開始するには、サービスを展開する物理マシンまたは仮想マシンが必要です。 テストが実行されている間、それらは短時間で必要になるため、サービスのインスタンスを絶えず発生させ続けるのではなく、クラウドから仮想マシンを受け取り、必要なパッケージをインストールすることにしました。 これを行うために、OpenStackを介して必要な仮想マシンを受け取るjenkinsのプラグインを使用しました。 そして、一連のスクリプトを使用して、必要なすべてのパッケージをそれらにインストールし、サービスを開始します。 安定したパッケージをテスト環境に展開するため、既存のテスト環境構成ファイルはそれらに適しています。 プロセス全体には約10分かかります。
テスト自体は、ユーザー（この場合は手動テスター）がテストするページのセットに加えて、承認データ、ロールなどのパラメーターを設定する方法で作成されました。テストは入力条件を読み取り、アクションのセットを実行します。次に、ページまたはその一部のスクリーンショットを比較します。 レポートを比較して作成するには、この投稿と同じツールを使用します。 スクリーンショットの違いを人間にとって便利な形式で表示するため、多数のテストの起動結果を簡単に分析できます。
使用する
このアプローチによるフロントエンドチェックの安定性は、バックエンドの作業に依存します。 これは問題を引き起こす可能性があります。なぜなら、テスト環境のバックエンドは、たとえばビルドの失敗や環境の問題などにより、時々壊れるからです。 フロントエンド自体が動作している場合でも、このような場合のテストは失敗します。 しかし同時に、ページは現在のバックエンドの回答に基づいて形成されるため、統合がチェックされます。 対話の形式は異なる場合があります。 たとえば、ページの新しい部分を構築するために必要な応答にデータブロックを持つバックエンドが表示される場合、フロントエンドの古いバージョンはこのデータを処理できなくなり、一部のテストが中断します。 ただし、バックエンド全体だけでなくデータウェアハウスのみを共通部分として選択すると、この場合、互換性のあるバージョンを持つフロントエンドとバックエンドの2つのバンドルがチェックされるため、問題は解決されます。
テスト自体はページ上でほとんどアクションを生成しません。 多くの場合、どのケースをチェックするかは、テスト環境のデータによって決まります。 したがって、それらは安定している必要があり、何かが変更された場合、自動テストのユーザーは常にこれに注意する必要があります。 たとえば、安定した環境からデータを定期的にコピーできます。 テスターは実際のユーザーと同じコンテキストにいますが、すべてのケースが「戦闘」データで再現されるわけではないため、これは便利です。 機能の一部はテスト環境にのみ存在する場合があり、それをテストするには追加データが必要になりますが、安定した環境ではまだ利用できません。 コピー中に消去された場合、新しい機能のテストは必要なケースのチェックを中断または停止する可能性があります。
テストで新しいページのチェックを開始するには、リストに追加してパラメータを設定するだけで十分です。したがって、新しいケースをカバーしたり、データをサポートしたりするには、自動テストの開発者の参加は必要ありません。 テスト開発は、ページとの対話のより複雑なシナリオ（値の入力、ポップアップのアクティブ化、プロンプトなど）にのみ必要です。
検証に必要なすべてのデータは既にテスト環境にあります。 テスト結果を手動で再現するために、追加のツールは必要ありません。 要素が欠落している場合、またはその位置に違反している場合は、テストフロントエンドでチェック中のページを開いてください。
この方法の長所と短所
利点：
- 低い実装コスト。
- 低サポートコスト。
短所：
- テストの実行時間は、テスト対象のサービスだけに依存しません。
- 安定性はバックエンドに依存します。
- いくつかのケースをプレイするのは難しいかもしれません。
バックエンド応答のエミュレーション
サービスの説明
このアプローチを使用して、パートナーが広告キャンペーンを管理できるYandex.Directインターフェイスをテストしました 。 前のケースと同様に、ページの機能の主な部分は、バックエンドから受信した大量のデータの表示です。 表示は、広告キャンペーンのタイプ、ユーザーなど、多くの要因に依存します。これらの要因は制御が困難です。 たとえば、ユーザー情報は他のサービスからYandex.Directに送られます。変更するには、ユーザーに連絡する必要があります。 広告キャンペーンのタイプなどのパラメーターは、通常、1日に限られた回数だけ変更できます。 これはすべて、テストを非常に困難にします。 テストをより安定させるために、バックエンドへの依存、したがってデータへの依存、および他のYandexサービスとの統合を削除することにしました。
実装
テスト環境のフロントエンドでは、ページの読み込み時にバックエンドの応答を設定する機能が追加されました。つまり、テストで指定された任意のデータを使用してページを構築します。 安定したパッケージを配置する環境がすでにあるため、新しいパッケージを展開する必要はありません。 ただし、スクリーンショットの比較を完全に使用するには、ページに送信されるデータを管理するテスト用の追加モジュールを作成する必要がありました。 使用されたバックエンド応答を保存するために、 Elliptics分散ファイルシステムを使用することにしました。 その中のデータは、ケースおよびテストタイプごとにグループ化されます。 管理を容易にするために、自動テストのユーザーが簡単に何をどのようにチェックし、必要に応じて何かを変更できるように、内部wikiにデータに関する一般情報を保存することにしました。 サービス開発者が見つけたバグを簡単に再現して修復できるように、手動でテストを繰り返す機能を実現する必要がありました。
使用する
このアプローチにより、テストはバックエンドから完全に独立し、テストが高速化され、より安定します。 特定の状況を再現するには、事前に保存したり、テンプレートに従って作成したりできる希望の回答をフロントエンドに送信するだけで十分です。 ただし、この場合、バックエンドの現在のバージョンとの統合はチェックされません。たとえば、上記のアプローチを使用して、個別にテストする必要があります。
テストの前に多くの準備手順を実行する必要はありません。 ケースをチェックするために、新しいキャンペーンを作成したり、一連のチェックを行ったり、プラスのバランスを提供したりする必要はありません。適切なバックエンドレスポンスを作成するだけで十分です。 時間に依存する動作など、単に再現できないケースをチェックする機会があります。
バックエンドの応答形式は変更される可能性があり、これによりテストが潜在的に脆弱になります。 この問題を解決するために、実際のバックエンドレスポンスを取得してテストデータストレージに記録する機会を提供しました。その後、後続のテスト実行で使用されます。 ただし、場合によっては、この方法は機能しません。 困難なケースを再現するためにバックエンドの回答を編集した場合、実際のバックエンドの回答を取得することはできません。 応答形式を変更すると、そのようなケースのデータを更新する必要があり、これには時間がかかります。 バックエンドのテストの回答を修正するには、サービス実装の機能を理解し、特定の技術スキルを持っている必要があります。これにより、データサポートがより高価になります。
この方法の長所と短所
利点：
- 速度：テストはバックエンドの応答を待たないため、より速く動作します。
- 安定性：テストはフロントエンドのパフォーマンスのみに依存します。
- 柔軟性：複雑なケースを簡単にプレイできるようになります。
短所：
- 高い実装コスト：サービスコードを変更するか、バックエンドをエミュレートし、データを管理してエラーを再現するためのツールを作成する必要があります。
おわりに
簡単にわかります。あるアプローチの欠点が別のアプローチの利点になるので、これらのアプローチを組み合わせるのは合理的です。 最初の方法は簡単で、最初から行うことができます。追加の開発とサポートは必要ありません。 ただし、2番目の方法はより柔軟性があり、複雑な状況を再現することができます。 1つのバックエンドで2つのバージョンを上げると、複雑なケースの数、テストの実行時間、安定性を推定する機会が得られます。 これは、より高度なアプローチを実装する必要があるかどうかを理解するのに役立ちます。
どちらの場合も、バックエンドのアプローチを使用してフロントエンドをテストしました。 しかし、自分自身をフロントエンドに制限することはまったく必要ありません。 バックツーバックテストの主な問題は、パッケージの異なるバージョン間でデータが一致することを確認することです。 ほとんどの製品では、データは何らかのストレージにあります。 ストレージのみを共通部分として分離すると、追加のテストを作成せずにバックエンドロジックをテストできます。 まったく同じ方法で、フロントエンドを含まないさまざまなAPIまたはその他のサービスをテストできます。
セルフテストがまだないか、少なすぎる場合、製品開発の最初にアプローチを適用すると非常に便利です。 結果の計算と表示のロジックをすばやくカバーすることで、この方法では検証できないより複雑な機能（データの保存や変更など）に集中できます。 製品が活発に変化しているという事実のために、異なるバージョンの結果はしばしば一致せず、これは連続したテストの誤ったクラッシュにつながる可能性があります。 したがって、そもそも、結果の分析を容易にする優れたレポートを提供する必要があります。 この問題は、多くの新しい機能が絶えず出現し、サービスの外観が大きく変化するため、製品開発の最初の段階で特に関連しています。
スクリーンショットのテストに関する問題は、テストを複雑にするのではなく、環境を改善することで簡単に解決できるため、テストを開発する前に、環境を改善する利点を分析することは合理的であり、そうすれば複雑なテストをまったく作成する必要がなくなる場合があります。