提示された経験は、大多数の企業やスタートアップにとって有用であると確信しています。 まず、 テストクラウドを自分で作成できます 。 これは、予算が限られている場合に重要です。 次に、テストクラウドを最も初期の形式で2〜3台のサーバーに展開できます。 第三に、テストクラウドの作成に関連するすべての問題は、テストプロセスを自動化することで得られる以上のものです。 これは、定期的に更新プログラムをリリースし、プロジェクトコードが非常に膨大な場合に特に重要です。
前文では、すべてがそうです。 私は猫の下で好奇心を誘います。
なぜクラウドが必要なのですか？
Parallels Plesk Panelのコストは、世界中でホスティングに使用されるすべてのサーバーの約50％です。 これらは数百万のハードウェアとVPSであり、その上で何億ものクライアントサイトが回転します。 ソフトウェアのバグの価格は莫大で、些細なことはありません。 この点で、スプラッシュはQAエンジニアにとって非常に複雑な製品です。 60個の構成で、1日あたり約2000個のp0およびp1回帰自動テストを実行する必要があります（そのうち約700個のテストがユーザーインターフェイス専用です）。 24時間で、120,000を超える自動テストが開始されます。 さらに、少なくとも週に1回は作業を完了します。数十の構成でサポートされる7つの「スプラッシュ」バージョンからのアップグレード/バックアップ/復元/移行をチェックするテストが必ず開始されます。 月に一度、QAエンジニアはパフォーマンス、密度、負荷のテストを実施します。 さて、リリースの前夜はとても暑いです。 次に、上記のすべての操作に、多数の製品との統合を検証する必要性が追加されます。
明らかに、すべてを手作業で行い、環境を準備し、製品をインストールし、フレームワークとテストをアップロードし、別のサーバーで実行し、ログと結果を収集して分析することさえ難しくありません。原則として不可能です。 そのため、これらのタスクをクラウドにフィードすることにしました。
それは何でしょうか？
Pleska QAチームの「ウィッシュリスト」（および実際にサービスプロバイダー向けのその他の製品が多数作成されているNovosibirsk Parallels開発センター）は2008年に作成され、4つの簡潔なポイントでレイアウトされました。
- 信頼性と耐障害性。 さらなる実践が示しているように、QAのクラウドの稼働時間は、パブリッククラウドサービスの稼働時間とほぼ同じ重要な基準であることが判明しました。
- 高性能。 ここでの基準は、必要な時間内に全量のテストを実行できるかどうか、仮想マシンの作成速度（読み取り、VPS）です。
- スケーラビリティ。 タスクの複雑さに基づいて、適切な量のリソースをいつでも割り当てる機能。 たとえば、単純な問題を解決するには、1台のマシンを選択して1時間で結果を取得し、複雑な問題を解決するには20台の車を選択して1時間で結果を取得します。 さらに、拡張性。 新しい完全に構成されたサーバーは、1時間以内に準備が整います。
- 変化する要件のサポート。 変化する要件（変化する仮想化の種類、プロジェクト間のタスクに優先順位を付ける機能など）にクラウドを迅速に適応させる能力。
1年後、基本的なタスク（マシンの展開、自動テストの実行）を実行できる「クラウド」の準備が整いました。 2-3人がその作成に取り組みました。 いくつかのすぐに使える製品を除き、ほとんどすべてのクラウドソフトウェアはプロプライエタリです。 これらは、Munin（リソースの可用性を監視する）とNagios（リソースの使用を監視する）です。 しかし、TestLink（テストケースの口頭での説明の保存、テストケースの手動および自動実行の結果の形成）は、真剣に削られなければなりませんでした。 コアおよびレポートシステムが変更されました。 たとえば、後者は、レポートの生成を2桁加速することで提供されました。5分でしたが、5秒になりました。
有能な読者は、なぜAmazonクラウドを使用せず、目標と目的のためにAmazonクラウドのインスタンスをリベットしなかったのかを尋ねます。 私は論文に答えます：
- ハードウェアの不足はありません。 それは長年にわたって蓄積され、それを完全にロードすることは論理的でした。
- 外部クラウドは現在でも要件に完全には適合していませんが、その中には多くの特定の構成と仮想化の種類があります。
- 高価な 紙幣に関するタスクを実行する際に消費されるリソースの毎日の量は、単に天文学的なものになります。
真実の瞬間：クラウドはテスターの生活をどのように変えましたか？
クラウドが出現する前に、ペンを使用していくつかの構成を展開し、そこに新鮮な製品ビルドを注ぎ、インストールし、自動テストを注ぎ、それらを起動し、落ちないように定期的に制御し、すべてのマシンからパフォーマンス結果を収集し、分析しました。 それは長く、困難で、非常に非効率的でした。
どう？ クラウドはQAチームを日常業務から救いました。 テスターは「小さな管理者」ではなくなり、サーバー、OS、製品ビルド、およびテスト計画を個別に展開することはなくなりました。 現在、ロボットはこれに従事しており、GUIまたはAPIインターフェースを介して命令することができます。
これは次のようなものです。
製品とバージョン（1）、テスト計画の名前（2）、ビルド（3）、構成のリスト（4）を選択し、「実行」ボタン（5）を押すと起動します。 数十、数百のマシンを展開し、それらに製品をインストールし、自動テストを起動するのは、数回のクリックで行われます。
[タスク]タブでは、タスクマネージャーを使用して定期的な自動テスト用のタスクを追加できます。これにより、クラウドの負荷を考慮してタスクを追加できます。
[一括実行]タブでは、テスト計画のグループを実行できます。 数回クリックするだけで、50万回の自動テストを実行できます。 あなた自身の偉大さを楽しむことができます。
テストクラウドの内部
この独創的な動画は、クラウドの動作を示し、そのアーキテクチャのアイデアを示しています。
連続積分スキームの例を使用して、歯車が内部でどのように回転するかを見てみましょう。
- プロセス起動の開始者は開発者です。 彼らは別の機能を積み重ねた後、バージョン管理システムにコミットします。
- その後、ソースビルドからビルドプロセスが開始されます。
- 構成のいずれかのビルドが組み立てられるとすぐに、ビルド検証テスト（BVT）を実行するための要求がテストエグゼキューターにすぐに送信されます-ビルド検証テスト（BVT）-製品の基本的な機能をチェックし、ブロッキングの問題がないことを確認する10-20の自動テストを含むテスト計画
- テストエグゼキューターは、適切な環境を作成するためにリクエストを展開サーバーに送信します。
- 展開サーバーは、OSダンプストレージで事前に準備されたオペレーティングシステムイメージを選択します...
- ...そして、特定のルールに従ってロードバランサーによって選択された最適なサーバーまたはサーバーのグループに展開します（それらの一部については後で検討します）。 その後、組み立てられたビルドが作成されたすべての車にインストールされます。
- 展開サーバーが必要なすべての環境を準備するとすぐに、制御はテストエグゼキューターに戻り、準備されたマシンでBVTテスト計画を実行し、それらに自動テストを配布します。
- 自動テストの性質に応じて、外部サービスを備えたサーバー（Selenium、外部メール、データベースなど）を使用できます。
- テスト計画がエラーで実行された場合、失敗したコミットを行った開発者は、すべてが失われ、迅速かつ迅速に修復する必要があるという通知を受け取ります。 テスト計画がエラーなしで実行された場合、収集されたビルドは特別な製品ビルドストレージサーバーに転送され、そこから手動およびフルスケールの自動テストでビルドを利用できます。
図には、言及していないノードがいくつかあります。 クラウド内には、テストフレームワークと自動テストを保存するテストストレージと、TestLinkが配置されているテスト仕様システムがあります。 外部には、クラウドを操作するためのインターフェイスを提供するツール管理サーバー（上記のテスト計画起動フォームなど）と、クラウドの監視、クラウド内の問題の迅速な検出、クラウド内のボトルネックの検出などを可能にするインフラストラクチャ監視サーバーがあります。 d。
もちろん、この形の雲はすぐには現れませんでした。 それは、その効果的な使用に関する目的と私たちのアイデアに従って進化しました（そして、変化し続けています）。
ライフハックと改善
テストクラウドの最も重要なライフハックの1つは、レポートシステムです。 従来のTestLinkに対する利点は、その可視性です。 TestLinkは、テストがエラーなしで合格した場合にのみ有効です。 そうでなければ、TestLinkはほとんど役に立ちません。 以下のスクリーンショットをご覧ください。
製品の80のクラッシュは80のバグですか？ テストで80の問題がありますか？ これは、80個のテストをクラッシュさせる製品のバグですか？ 製品はどのような状態ですか？ 正確に壊れたのは何ですか？ ログはどこで見ることができますか？ 多くの質問といくつかの答え。
現在、結果はLogTrackerシステム（社内開発）に報告されています。
画面には、特定のビルドでのテスト計画の1つの実行結果に関する情報を含むこのシステムのページの1つが表示されます。
各構成の統計、成功したテストと失敗した自動テストの数、および既知のエラーの数が左上の部分に明確に表示されます。 設定をクリックすると、各自動テストに関する情報、さまざまな詳細レベルのログ、スクリーンショット、バグ追跡システムの既知のバグへのバインドなどを取得できます。
右上に、さまざまな構成のドロップ数でソートされた自動テストのリストが表示されます。 これにより、リソースが限られている状況で、エンジニアは「正しい」問題（製品のバグまたは製品の変更に起因する古い自動テストの問題）に集中できます。
左下には、既知のエラー、クラッシュの数、バグ追跡システムのエンティティバインディングに関する情報が表示されます（これには、製品のバグとテストのバグが含まれます）。
右下には、このテスト計画とビルドの一般的な統計が表示されます。これには、不明なエラーや「検疫」によって修復されたエラーに関する情報が含まれます。 「検疫」とは、完全に新しい環境でのフォールドテストの自動再起動を指します。 これにより、ネットワークの不安定性や高負荷下で動作するセレンサーバーの問題に起因する自動テストの「誤った」低下をふるいにかけることができます。
注： QAエンジニアが使用するデータの配列全体が自動的に収集および生成されます 。
おわりに
結論が出れば、祝福できます。 QAでクラウドを使用するトピックに本当に興味があり、少なくとも2つまたは3つのサーバー上で独自のテストクラウドを構築することをお勧めします。 これを初めて行う人への私の推奨事項は次のとおりです。
- クラウド要件を明確に明確にします。 クラウドが解決するのに役立つタスク、パフォーマンスと安定性の基準を満たす必要があるなどを理解します。
- パフォーマンスと安定性の要件に基づいて、必要なリソースを決定します。どのようなハードウェアとネットワークデバイスが必要か、どのソフトウェア、仮想化ツール、必要な人的リソースか
- サーバー間の負荷分散システムを開発し、適切なサーバーの選択が行われる基準を決定します。 率直に言って、読者に出版物の大きさを完全におびえさせないように、私は意識的にロードバランサーの章をポストに含めませんでした。 バランサーについて読むのが面白い場合は、コメントを書いて、別の投稿をします
- クラウド監視システムを作成して、クラウド内の問題とボトルネックをすばやく見つけます
- クラウド管理システムを作成します（最初は単にAPIである可能性がありますが、クラウドをより速く使用でき、技術的な知識が少なくて済むGUIが必要です）
- TestLinkで行ったように、テスト管理システムを選択し、必要に応じて変更します。
- テストフレームワークを決定します。 彼の選択は、主に製品のベースとなるテクノロジーと、それが書かれているプログラミング言語に依存します。
これらすべてのアクションの後、パーソナルクラウドがどの方向に発展するかが明確になります。