マイクロサービスアーキテクチャのテスト自動化の中核

こんにちは、Habr！ 私の名前はDmitry Khimionです。Avitoの品質保証部長です。 今日は、マイクロサービスアーキテクチャの操作の一環としてのテスト自動化についてお話します。 品質管理を促進するために開発を提供できるものは何ですか？ カットの下で読んでください。

参加する代わりに

「実装は、送信動作では保守的で、受信動作ではリベラルでなければなりません。」

ジョナサンブルースポステル、コンピューター科学者

マイクロサービスアーキテクチャとは何ですか？

私の話を完了するために、基本から始めましょう。 簡素化するために、 マイクロサービスアーキテクチャはアプリケーションサーバーを編成する方法です。 彼はどのように働いていますか？ 基本的に、これは単にDevOpsなどのプラクティスの出現に対するサービス指向アーキテクチャの答えです。 SOAがサービスのサイズとサービスが行うべきことを規制していない場合、マイクロサービスアーキテクチャ内には投機的な制限があります。 マイクロサービスは、管理し、一部のデータを外部サービスに提供する1つの小さな機能を実現するエンティティです。



マイクロサービスは500行のコードであるという情報を提供する場合があります。 しかし、それは必要ではありません。 ポイントは、これらのサービスは非常に小さく、多くのプロジェクトで機能するモノリシックバックエンドと同じビジネスプロセスを形成するということです。 機能的に-同じこと、違い-組織構造。



ここで何が問題になりますか？ サービスは急速に多くなり、その接続性は増加しています。 これによりテストが複雑になります。1つのマイクロサービスの変更をチェックするには、可変マイクロサービスが相互作用する多くのサービスからかなり厚いインフラストラクチャ層を作成する必要があります。 プロジェクトの開発のある時点で、関係と依存関係の数が大幅に増加し、迅速かつ個別のテストを実行することが難しくなります。 私たちはよりゆっくりと働き始めています。 開発は減速しています。 これらおよびその他の問題は、テスト自動化を使用して解決できます。

マイクロサービスへの移行

最初に、モノリスからマイクロサービスアーキテクチャへの移行を検討します。 モノリスの場合、このシステムの部品を交換するために、個別に展開することはできません。 バックエンドを再構築して完全に更新する必要があります。 これは常に合理的で便利なわけではありません。 マイクロサービスアーキテクチャに切り替えるとどうなりますか？ バックエンドを取得し、それをコンポーネントコンポーネントに分割し、機能別に分割します。 それらの間の相互作用を判断し、同じフロントエンドと同じデータベースを持つ新しいシステムを取得します。 マイクロサービスは相互に作用し、同じビジネスプロセスを提供します。 ユーザーとシステムのテストについては、すべてが以前のままであり、内部組織が変更されました。







それは何を与えますか？ 一部の機能を実装するマイクロサービスXに変更を加え、すぐにロールアウトして機能させることができます。 それはすべて非常にいいですね。 しかし、いつものように、微妙な違いがあります。マイクロサービスが相互にどのように相互作用するかを確認する必要があります。

マイクロサービスアーキテクチャ契約

マイクロサービス間の相互作用は、契約を通じて実装されます。 これはサービス指向アーキテクチャにとって何を意味しますか？ 契約は、外部ユーザーが相互にやり取りするためにサービス開発者が作成する特定の契約です。 サービスの開発者自身が、「X」を要求できると判断し、「Y」を提供します。 このサービスでは、リンゴ、トマト、プルトニウムを外部ユーザーに提供したり、子供服やテレビを販売したりすることができます。機能に明確に焦点を当てているとは宣言されていません。 内部コンテンツは常識のレベルでのみ規制されています。 それに応じて、このサービスは外部ユーザーに対して、受信するものとアクセス方法を指示します。



このタスクの複雑さを増すと、数十のサービス（10-20-50）ではなく、数百（200、400 ... 2000）になり、従来の「古典的な」契約は機能的な意味で機能しなくなります。 そして、マイクロサービスアーキテクチャの契約を近代化する必要が生じます。 開発者用のテンプレートが開発され、テンプレートとマイクロサービスの「エンドユーザー」が交換されます。このアプローチは、消費者主導の連絡先と呼ばれます。 現在、リクエストは外部ユーザーによって行われます。 これは、この種の会話として想像できます。

ユーザー1：「リンゴを提供していると聞きました。 小さくて緑色のものが必要です。」

ユーザー2：「そして、私は巨大な赤いリンゴが必要です。」

ユーザーN：「そして、3トンのリンゴを持ってくる必要があります。」

したがって、ユーザーは契約を作成し、要件を設定し、それらを実装するプロバイダーに送信することがわかります。 プラスとは何ですか？ 各サービスにはかなり限られた数の消費者しかいないため、特定のケースで提供する「リンゴ」や、これらの「果物」に加えて他に必要なものを推測するよりも、それぞれから3つの仕様を取得して実装する方がはるかに簡単です。







このアプローチでは、品質保証部門として、マイクロサービスを迅速に展開するプロセスを遅らせないように、テストの分野で価値ある答えを提供する必要があります。

CDCテストの述語（消費者主導の契約）

何がなければCDCテストの原則に取り組み始められないでしょうか？ 最初のもの。 契約に基づいて作業するプロセスが開発で守られていないことがわかった場合、支援することはできません。 2つ目はより技術的なものです：コミット後システム（必要に応じてPR後）フックであり、コントラクトを使用して開発者間のこの通信フローを処理し、テストシステムに更新、削除、および新しいものの出現について通知します。 したがって、対応するタスクはJiraで開始されるため、オートマトンはこれらすべてを「ダイジェスト」する時間ができます。 この基本プロセスには、追加のチェック、プロセスローションを追加できますが、マイクロサービス間の相互作用のコントラクトを変更する制御がなければ、生きることは困難です。 何らかの方法でこれらの2つのポイントを完了したら、実装を続行できます。

CDC自動化の実装

テスト自動化システムは、PACTフレームワークなどのソリューションに基づいています。 それらについて何を知る必要がありますか？ これはAPIとのプロトコル相互作用です。HTTPを介したJSONです。複雑なことはありません。 これらのソリューションはマイクロサービスと相互作用し、組織の分離とテストのための追加機能を提供します。 他に何を言いますか？ 私はこれが7つのプログラミング言語（Java、Javascript、Ruby、Python、Go、.NET、Swift）でどのように実装されているかを見ました。 しかし、もしあなたがこのリストに載っていなくても心配しないでください。ベースライブラリを使って自分の自転車を作ったり、すでに実装されているものに似たものを書いたりできます。



ほぼ100％の場合、他に何が待っていますか？ 1つ目は、外部サービスを隠すことです。 問題は、外部サービスの動作の関連性を維持すること、およびすべてのスタブでこれを維持することが難しいことです。 この問題を解決するには？ それはあなた次第です。 多くの場合、これにより多くのリソースを割り当てるか、テストの範囲を制限する必要があります。 2番目：サンプルデータベース。 システム内でのテストに必要なすべてのデータが含まれるように、戦闘データベースを軽量な形にカットする必要があります。 その後、関連する明確な結果が得られます。







さらに進みます。 このプロジェクトで私がすぐにやりたいことは、有益なロギングです。 代表的なテスト結果は常に必要です。 簡単な真実：結果を読み取って理解できない場合、誰も結果を見ることができません。 私は、PACTフレームワークの基本的なロギングが非常に不十分に実装されていると言わなければなりません。



私はそれを別のモジュールに入れ、それを包み、そこに必要なものをねじ込むことを好みます。 まず、エラーの発生源に応じてエラーを分離します。 さらに、たとえば、Allureなどのソリューション（テスト結果の分析を簡素化するYandexのソリューション）など、実装できるすべてのもの。 何でもできますが、有益なログの必要性を考慮する必要があります。



次の、おそらく「船長」の瞬間は、構成リーダーです。 しかし、マイクロサービスアーキテクチャのテストの一環として、これは少し注意が必要です。 Config Readerには、2つのソースがあります。 1つ目はPACTファイルで、2つ目はStateです。







.pactファイルとは何ですか？ これは何らかの暗号化されたバイナリではなく、特定の構造を持つ通常のJSONファイルです。 消費者、プロバイダー（つまり、この契約のフレームワーク内で誰とどのような役割でやり取りするか）を区別します。 次に、相互作用について説明します（これは開発者によって行われます）。私は消費者であり、このサービス（プロバイダー）に「小さな青リンゴ」を提供してほしいです。 私はそのような応答コード、ステータス、ヘッダー、ボディなどを待っています。 説明フィールドがあります-これは単なる説明であり、契約で議論された内容、その意味を開発者に思い出させる機会です。



そして、最も興味深いのは州プロバイダーです。 これは何ですか 実際、これは、特定のテストの繰り返し、特定の要求のために、テストされたマイクロサービスがアクセスするときに留まるべき状態です。 状態は、SQLクエリ（またはサービスを特定の状態にするためのその他のメカニズム）と、サンプルデータベース内のデータの作成の両方を記述することができます。 状態は、サービスを適切な状態にするあらゆる種類のエンティティを含むことができる複雑なモジュールです。



スイートランナーがここに表示されることに注意することが重要です（下の図を参照）。 これは、開発者/テスターに​​とって便利な形式でテストを実行および構成する責任を負うエンティティです。 書かれていないかもしれませんが、プロジェクトで一度に実行する必要があるテストを予測するのは難しいので、この点を指摘します。 その結果、マイクロサービスアーキテクチャのテスト自動化のコアが得られます。







今、最も重要なことは実装です。 開発者への記述された契約の存在に関する要件をこのスキームに提供する必要があります。 私たちは何を得ますか？







各サービスについての情報があります。それが提供するものと、「近隣」から要求するものについてです。 したがって、テスト自動化システムの助けを借りて、PACTファイルの助けを借りて、統合される外部サービスに関係なく、マイクロサービスを隔離して、テストを確実に隔離します。 そして、moki、スタブ、サンプリングされたデータベースを通じて状態を提供するか、何らかの形でサービスを直接変更します。 それぞれ、独立したテストを受けます。 出来上がり：モノリスからマイクロサービスアーキテクチャへの移行中にテスト自動化をどうするかという質問に対する答えがあります。

実装する際に考慮すべきことは何ですか？

実装中に考慮すべきことは何ですか？ 1つ目は、マイクロサービスのビルド/デプロイプロセスでのコンテナー化と仮想化の使用です。 また、テスト自動化システムも同様にコンテナにねじ込まれています。 マイクロサービスとテスト自動化システムの相互作用をどのように確保するかはそれほど重要ではありません。より便利で実行できます。



2つ目は、契約要件ファイルの更新です。 プロバイダーに対する消費者の要件が山積みになり始め、開発者は今すぐに必要なことだけをしているという問題があります。 ここでは、開発者向けのテスト管理または製品管理のレベルでタスクを設定する必要があります。たとえば、成長しないように週に1時間、この「テール」を操作します。 もちろん、これらのテストは迅速で、数秒かかる場合があります。 しかし、それらの数が数千単位で測定される場合、これはテストの実現を複雑にします。 また、コミットフックシステムを通じて情報を受け取り、不要な自動テストを削除します。 要するに、CDCはいわばドキュメント主導の開発です。



第三に、この作業に導入される状態とデータスイートを更新するプロセスを導入する必要があります。 データスイートとは何ですか？ 開発プロセスの開発者は、いくつかの基本的な相互作用シナリオを作成します。 例：「そのような要求とそのような答えが必要です。」 そして、他のすべてについて-どのフレームワークに存在すべきか、どのパラメータ値が可能か、そしてどれが-いいえ、彼らは忘れます。 これを確認する必要があります。 そして、ここで、本番環境でのマイクロサービスアーキテクチャのフォールトトレランスを保証するために、データ駆動型のテストアプローチを設定器に実装し、ポジティブ、ボーダーライン、ネガティブテストを実行する必要があります。 これがないと、動作する可能性が低く、右/左へのステップが発生し、相互作用エラーが発生します。



したがって、新しい協定ファイルが表示されると、フックを介してタスクを取得し、新しい/変更されたインタラクションをインタラクションの多数のデータセットで満たします。これは、実行される一連のテスト全体に相当します。 相互作用を手動で入力および編集することができ、それらをパラメーター化してテストを実行するジェネレーターを作成できます。



状態については、Webテストの自動化を行う場合、これらは前提条件、setUps、FixTureです。 マイクロサービスには問題があります-既成のメカニズムはありません。このモジュールのPACTファイル内の州の名前の変更をどのように一致させるかを考慮する必要があります。 最も単純なメカニズムは、テスト自動化の言語を話すエイリアス、基本的にはKDT（キーワード駆動テスト）を使用することです。 より美しくエレガントなソリューションについて話す準備はできていません。まだ思いつきません。

まとめ

1. コミット後のフック、監視の自動化、外観と変更、サービス間の契約の削除については、すべて自動化する必要があり、システムの一部です。 これは、リポジトリレベルにあるカーネルの一部だと思います。
   
   
   
   
2. 開発者向けのCDCパターンが必要です。 これが基盤であり、それなしでは機能しません。
   
   
   
   
3. システムに欠陥が現れる傾向が減少していることがわかります。 実際、すべての部品は絶縁試験で覆われています。 欠陥を迅速に特定し、それらを迅速に修正し、高いテスト範囲を確保します。 システムテストのレベルで欠陥が発生した場合、それらはフロントエンドまたは一部の外部サービスに関連している可能性が最も高くなります。
   
   
   
   
4. 変更を手動でテストすることから逃れる機会があります。 キーポイント：高速かつ分離されたテスト。 そうすれば、問題や欠陥をうまく特定できるという事実から利益を得ることができます。

PS

読むのではなく、動画を見る場合は、この情報をレポート形式で入手できます 。 また、8月下旬に、Avitoはテストプロフェッショナル向けのテーマラリーを開催します。 一般的な自動化システムの開発のベクトルについて説明し、適用されたツールの適用と、テストインフラストラクチャの変更に対するそれらの影響について説明します。 興味がある場合は、 FBページで更新情報を確認するか、コメントを記入してください。イベントの詳細がいつ発表されるかお知らせください。