開発した製品の統合をテストするグループとして、品質管理と開発者への迅速なフィードバックを確保しながら、新しい製品の導入速度を落とさないよう義務付けられています。 各開発チームは、製品の品質を担当します。 私たちのタスクは、エンドツーエンドの機能とグループの調整に重点を置いて、さまざまな技術グループとスムーズに連携することです。 私たちは、200人を超える開発者がいる組織の統合テストの専門家の小さなグループです。
必要に応じて新しい開発を迅速に導入し、必要な品質を確保することで、チームにとって興味深いタスクが作成されます。 この記事では、次の3つのタスクを検討します。
1.上位のインプレッションのテストと監視（影響度の高いタイトル= HIT =ヒット）
2. A / Bテスト
3.グローバルな発売
評価の高いインプレッションのテストと監視
テレビシリーズオレンジ-ヒットオブザシーズンなど、多くの高評価番組が定期的にNetflixに掲載されています。 これらのショーの形式とサイズは大きく異なります。 いくつかはシリーズで、いくつかは別々の絵です。 子供にのみ焦点を当てています。 シーズンのすべてのエピソードを一度に撮影するものもあれば、毎週いくつかのエピソードをリリースするものもあります。 これらのショーの一部は、テストの各要素が参加者と異なる相互作用を持つ複雑なA / Bテストで実行されます。
これらのショーはメンバーに非常に人気があるため、徹底的にテストする必要があります。 テストは開始の数週間前に開始され、開始まで増加し続けます。 発売後、これらの印象をすべての国の異なるハードウェアプラットフォームで追跡します。
テスト戦略はそのフェーズに依存します。 さまざまな段階で、さまざまなプロモーション戦略が実行され、テスト/自動化タスクが非常に難しくなります。 基本的に、2つのフェーズを区別できます。
1.ショーの開始前。 起動前に、すべてが起動日に完全に実行されるように、表示メタデータが必要な場所にあることを確認する必要があります。 多くのグループ（チーム）がヒットの立ち上げに関与しているため、すべての内部（サーバー）システムとユーザーインターフェイスのクライアント部分とのドッキングが完全に行われることを確認する必要があります。 プロモーションは、スポットライト（Netflixのメインページの上部にある掲示板に似た大きなウィンドウ）、ティーザー、トレーラーを通じて行われます。 ただし、Netflixのすべてのレベルにパーソナライズが存在するため、ディスプレイのタイプが参加者のプロファイルと一致することを確認するために、複雑なテストスイートを作成する必要があります。 システムは絶えず変化しているため、自動化は困難になります。 このフェーズの主なテストは手動です。
2.ショーの開始後。 私たちの仕事は打ち上げ日に終わりません。 実行中のインプレッションを常に監視する必要があります。これにより、参加者との相互作用が弱まることはありません。 ショーはNetflixの拡張ディレクトリの一部となり、これ自体が問題を引き起こします。 ショーが一貫して視聴者を見つけ続けるかどうか、データがそのままかどうかを確認するテストを作成する必要があります（たとえば、一部のチェックではエピソードの合計数が起動後に変更されていないかどうかを確認し、別のチェックは検索結果が引き続きショーを返すかどうかを制御します）適切な検索文字列に）。 しかし、ライセンスされたコンテンツに加えて、今年だけ600時間のオリジナルのNetflixプログラミングがオンラインで行われるため、ここでの手動テストに頼ることはできません。 また、番組の実行中には、この番組とプロモーションロジックのデータは変更されないため、一般的な前提があります。たとえば、テレビのリリースではエピソードの数が0より大きい場合、番組は検索可能です（映画のように、およびTVリリース用）など。 これにより、各ショーに関連する特定の操作が引き続き正常に機能するかどうかを自動的に監視できます。
ヒットのテストは困難で時間制限があります。 しかし、ショーの立ち上げへの参加、ショーに関連するすべての機能、サーバーロジックが起動中に正しく機能することを追跡することは、刺激的な体験を提供します。 有名人の映画やクールなNetflixプロモーションを見るのもいい追加です。 :)
A / Bテスト
多くのA / Bテストを実施しています 。 各時点で、多くのA / Bテストはさまざまなレベルの複雑さで機能します。
これまで、A / Bテストのテストの大部分は自動テストと手動テストの組み合わせでした。自動化は個々のコンポーネントに使用され（ホワイトボックステスト）、エンドツーエンドテスト（ブラックボックステスト）はほとんどが手動でした。 A / Bテストの量が著しく増加したとき、必要なすべてのエンドツーエンドテストを手動で実行することは不可能であることが判明し、自動化を強化し始めました。
A / Bテストのエンドツーエンド自動化の導入に関する主な問題の1つは、自動的に処理する必要のある膨大な数のコンポーネントでした。 私たちのアプローチは、テスト自動化を提供製品として検討し、再利用可能なパーツで構成される最小機能（最小実行可能製品= MVP）の製品の提供に焦点を当てることでした。 MVPの要件は、さまざまなマイクロサービスのRESTエンドポイントからのデータの正確性をチェックすることにより、参加者との基本的な相互作用の確認を提供することでした。 これにより、最初から最適なソリューションを見つけるのではなく、ソリューションに繰り返し移行する機会が与えられました。
私たちにとって重要な出発点は、自動化されたテストのためにモジュールの再利用と再割り当ての可能性を提供する共通ライブラリの作成でした。 たとえば、参加者の「マイリスト」を変更するA / Bテストがありました。それを自動化するときに、参加者の「マイリスト」に表示を追加するか、このリストから表示を削除するスクリプトを書きました。 これらのスクリプトは、マイリストを扱う将来のA / Bテストで再利用できるようにパラメーター化されています。 このアプローチにより、再利用可能なビルディングブロックの数が増えたため、A / Bテストをより迅速に自動化できました。 既存のオートメーションを最大限に活用することにより、効率が向上しました。 たとえば、独自のユーザーインターフェイス自動化プログラムを作成する代わりに、 Netflix Test Studioを使用して、さまざまなデバイスのユーザーインターフェイスアクションを必要とするテストスクリプトを切り替えることができました。
自動化を実装するための言語/プラットフォームを選択するとき、製品開発チームに迅速なフィードバックを提供する必要性から進みました。 これには、テスト複合体の非常に高速な作業が必要でした-文字通り数秒で実行できます。 また、実装と配布のためにテストを可能な限り簡単にすることを目指しました。 これら2つの要件を念頭に置いて、最初の選択肢であるJavaを放棄しました。 テストは、相互接続された多くのjarファイルの使用に依存し、JARファイル形式の異なるバージョンの変更の影響を受ける依存関係管理、バージョン管理に対処する必要があります。 これにより、テストの期間が大幅に長くなります。
自動化を導入して、RESTエンドポイントを介してマイクロサービスにアクセスできるようにすることで、jarファイルの使用を構成し、ビジネスロジックを記述しないようにしました。 自動化の実装と配布を容易にするために、コマンドラインから実行できるパラメーター化されたシェルとpythonスクリプトの組み合わせを使用することにしました。 テストスクリプトの実行を制御するための別のシェルスクリプトであると想定されていました。その間に、再利用可能なユーティリティとして機能する他のシェルスクリプトとpythonスクリプトを呼び出す必要があります。
このアプローチには、いくつかの肯定的な側面があります。
1.テストの期間（インストールと切断の時間を含む）を4〜90秒取得できました。 ランタイムの中央値は40秒です。 Javaオートメーションを使用する場合、ランタイムの中央値は5〜6分と推定されます。
2.継続的な統合が簡素化されました。 必要なのはJenkins Jobシステムのみで、これはリポジトリからダウンロードされ、必要なスクリプトを実行し、結果をログに記録しました。 レコードのJenkinsの組み込みコンソール分析は、統計を取得するのに十分な合否テストであることが判明しました。
3.簡単なスタート。 サードパーティのスペシャリストがテストスイートを起動するには、gitリポジトリとターミナルへのアクセスのみが必要です。
グローバル打ち上げ
2015年の最大のプロジェクトの1つは、130か国でNetflixをスムーズに同時起動できるように、十分な統合テストを実施することでした。 実際、少なくとも、国と言語の組み合わせごとに全体的なパフォーマンスのテストスイートを自動化する必要がありました。 これにより、自動化製品の機能が著しく複雑になりました。
テストは非常に高速に実行されたため、最初に、国と言語の組み合わせごとにテストプログラムをループで実行するだけで十分であると判断しました。 その結果、約15秒かかったテストが1時間以上動作し始めました。 この問題に対するより受け入れられるアプローチを見つける必要がありました。 これに加えて、各テストプロトコルは約250倍になり、障害分析がより困難になりました。 これらの問題に対処するために、2つのことを行いました。
1. Jenkins Matrixプラグインを使用してテストを並列化したため、各国のテストが並行して実行されるようになりました。 また、テストが異論のある状況または無限のサイクルに陥ったときに他のタスクがキューに入らないように、異なる実行者を使用するようにJenkinsスレーブを構成する必要がありました。 自動化にはシェルスクリプトの実行に関連するコストしかなく、バイナリファイルをプリロードする必要がないため、これは私たちにとっては実現可能です。
2.ここまでに作成された各テストをリファクタリングしたくはありませんでした。また、各テストをそれぞれの国/言語の組み合わせで動作させたくありませんでした。 その結果、「オンデマンド」モデルを使用することにしました。このモデルでは、以前と同様に自動化されたテストを作成し続け、グローバルな準備に追加するために、アドインが追加されます。 このアドインには、テストケース識別子と国/言語の組み合わせがパラメーターとして含まれている必要があり、次に示すように、これらのパラメーターを使用してテストケースを実行する必要があります。
現在、自動化されたテストはグローバルに機能し、以下を含むすべての優先度の高い統合テストスイートを閉じています。 そのようなショーが利用可能なすべての地域でヒット監視。
今後の課題
新しいものを導入するペースはNetflixで遅くなりません-それは成長しているだけです。 したがって、当社の自動化製品は進化し続けています。 ロードマップ上のプロジェクトの一部を以下に示します。
1. ワークフローベースのテスト。 Netflixサービスファンネルを通るデータフローをシミュレートするためのワークフローまたは一連のステップとしてテストスイートを含める必要があります。 これの動機は、テストが失敗したステップを簡単に特定することにより、テストの失敗を分析するコストを削減することです。
2. アラートを埋め込みます。 Netflixにはいくつかの警告システムがあります。 ただし、特定の警告を含めることは、対応するテストコンプレックスの実装とは無関係な場合があります。 これは、テストが100％機能しない可能性のあるサービスに依存しており、一般的に誤動作している可能性があり、当社に適用できない結果をもたらすためです。 これらの警告を分析し、実行するテストを決定できるシステムを作成する必要があります。
3. 混乱の説明。 現在のテストでは、Netflixが100％機能することを前提としていますが、これは常に発生するとは限りません。 信頼性の専門家チームは、システムの完全な整合性をテストするために、 障害テストを常に実行しています。 現在、低下した環境でのテスト自動化の結果は、90％を超える障害率を示しています。 劣化した環境で作業する場合に一貫した結果を確保するには、テストの自動化を改善する必要があります。