Parallels Cloud Server自動テスト

私が働いているParallels Inc.製品の1つがどのようにテストされているか、

-Parallels Cloud Server。 この製品は、 ParallelsがCloud ServerFastVPSの分類を 解除した記事:仮想化プラットフォームを変更し 、自分構築する方法:小規模ホスティング業者向けにAmazonスタイルのストレージを作成した方法に関する記事にすでに慣れている人もいると思います 。 そうでない場合は、上記の記事を読むことをお勧めします。



この製品のテストは多くの理由で興味深いものであり、その理由の1つは、製品が複雑でマルチコンポーネントであり、複数の独立したチームによって開発されていることです。



私があなたに興味を持ったなら、猫へようこそ。



Parallels Cloud Server自体ベアメタル製品です。つまり、ベアメタルにインストールされます。 統合コンポーネントを備えたRHELベースのLinuxディストリビューション(Cloud Linuxを使用)です:パッチを含むLinuxカーネル、 ハイパーバイザーParallels Cloud Storageコンポーネント、再設計されたAnacondaベースのインストーラー、 Parallels Virtual Automationコンテナーと仮想マシンを管理するための便利なWebベースのコントロールパネルCloud Serverを管理および監視するためのコンソールユーティリティ。 テストでは、これらの各コンポーネントを対象としています。



まえがき



現在、Parallels Cloud Serverの機能の98%が自動テストによってテストされています。 また、Parallels Server Bare Metal 4.0(PCS 6.0の前身)をテストするために180種類のテストを実行した場合、PCS 6.0にはすでに600のテストがありました。製品自体の詳細がテスト自体にマークを残したことをすぐに言わなければなりません:自動テストは物理テストのみで実行しますサーバーとテストは、テスト自体の複雑さ、構成の洗練度、および期間(テストは1時間から1週間続くことがあります)によって、Seleniumのサイトのテストと異なります。



テストの範囲を想像できるように、いくつかの数値を示します。PCS6.0 RTMでは、2.5か月で572テストを使用し、2959テストを開始しました。これは約294マシン日です。 そして、260のユニークなテストで最新のアップデートの1つをテストし、4800回のリリースを行いました。







しかし、常にそうではありませんでした。 より最近では、数年前に、それらを実行するための多くの自動テストとサーバーがありませんでした。 各マシンに手動で製品をインストールし、各自動テストを手動で起動し、バグトラッカーでバグを手動で作成しました。 しかし、時間の経過とともに、車の数は20から100に、テストの数は180から600に増加しました。これらは時々ではなく、ビルドごとに実行する必要があります。 そして、時間が経つにつれて、私たちはそのようなテストシステムに到達しました。



自己テストの一般的なスキーム







自動テストを実行するための基本的なインフラストラクチャは非常にシンプルで、いくつかのサービスで構成されています。





アセンブリ後の各ビルドは、テストのいくつかの段階を経ます。





ビルドシステムのスケジュールに従って、Parallels Cloud Serverビルドが収集され、ビルドサーバーにアセンブリの正常終了に関する通知が表示されます。 その後、BVT(基本検証テスト)が自動的に開始されます。 BVTは実際には2つの部分で構成されています:Parallels Cloud Server自体の検証テスト(これはコンテナーと仮想マシンの基本機能のテストです)およびParallels Cloud Storageのテスト(同じテストですが、Parallels Cloud Storageはローカルドライブではなくストレージです) 。 両方のテストが成功すると、BVTスケジューラーはビルドサーバーに通知を送信し、ビルドは有効としてマークされます。 その後、テストプランナーは他のすべてのスケジュールされたテストを開始します。 検証が成功しなかった場合、修正された問題を含む新しいビルドがアセンブルされるまで、テストはこれで終了します。



テストプランナーは、自動テストの重要なコンポーネントの1つです。 また、テストを実行するための一般的な継続的インテグレーションシステムの1つでうまくいくことがある場合(たとえば、Yandex はJenkinsを使用します )、テストを実行するために独自のロジックを使用する必要があるため、そのようなソリューションは私たちに適合しませんでした。



他のサービスから情報を受信するスケジューラは次のことができます。





次のアップデートまたはメジャーリリースをテストする前に、実行する必要のある一連のテストを作成します。 このような各テスト計画は、テストの構成(テストを実行するためのサーバー要件、テストパラメーターのセット)を簡単に説明するタイトルのセットで構成されています。







テスト計画の各タイトルには、いわゆる「ジョブ」があります-テストを実行するためのテスト環境とそのオプションの説明:実行に必要なサーバーの数、これらのサーバーの要件、テストを実行する場所(サーバー自体、コンテナまたは仮想マシン)など)。 ロボットは定期的にテスト計画を調べ、各タイトルを取得し、タイトルがテストまたは製品のバグによってブロックされていない場合、このタイトルを起動キューに配置しようとします:このタイトルのジョブの要件を満たすサーバーを見つけようとします。 必要なノードが見つかった場合、ロボットは、展開システムのこれらのノードにオペレーティングシステムと製品をインストールするアクティビティと、すべてのインストールの最後にテストを起動するアクティビティを作成します。







テストの実行中、テストに関係するノードはアクティビティでマークされ、他のテストには使用されません。







上記のスクリーンショットは、テストが5つのノードで実行され、テストがクライアント( pclin-c19 )から起動され、ノード自体ではなく、Parallels Cloud Serverが2つのノードにインストールされ、IPアドレスのプールが各ノード用に予約されていることを示していますコンテナおよび仮想マシンのIPアドレス。



テストが正常に完了すると、展開システムは結果をテストレポートシステムにエクスポートし、アクティビティは破棄され、サーバーは他のテストの実行に使用されます。



テストの開始時に問題が発生した場合、Jiraでバグが開始されます。 自動テストの各バグには、テストに参加している製品のバージョン、テスト結果へのリンク、テストの説明、テストのバックトレース、テストを再開する方法の説明、仮想マシンの問題、このタイトルの以前の結果へのリンクが含まれます(タイトルがまだ忘れられていません) ?)。 バグが見つかったマシンは、各バグに添付されています(スクリーンショットでは、これらはmccp46ts49 、およびsvvpamdです )。







開発者またはテスターは、発見された環境のバグをいつでも調査できます。 バグが些細なものであるか、調査ノードが不要な場合、ノードはバグから切り離されます(バグのフィールドを編集するだけです)。







ノードのテストプール全体で何が起こっているかをダイナミクスで確認するために、グラフがあります。







したがって、サーバーが何をしているかを常に把握しています。



上記で書いたように、テストを直接実行することに加えて、ロボットは製品のバグを自動的に検証できます。 どのように機能しますか? 製品への各コミットには、jirのチケットへのリンクが含まれています。 ビルドのビルドが成功すると、変更ログからクローズされたバグにビルド番号を追加するスクリプトが起動します。







テストを計画するとき、ロボットはこの情報を考慮に入れ、修正があるビルドでのみバグのあるテストを再開します。 再起動されたテストが成功した場合、ロボットはJiraのバグを自動的に検証し、ビルド番号とテストの成功へのリンクをコメントに追加します。



自動化は自動的に行われますが、人間が介入しなければ製品をテストすることは不可能です。 このような産業規模でのテスト実行の背後には、新しいテスト構成(「ジョブ」)の作成、各製品更新に必要なテストセットを使用したテスト計画の作成、サーバーサポート(壊れる場合があります。 SSD、USBバルクデバイスをエミュレートするデバイス)、テストプランナーへの新しい機能の追加など。



自動テストの何がおもしろいですか?



All Articles