[NCTSサミットレビュー] アリババの潘家騰：アリママのオフラインテストドメインのインテリジェント構築

2019年10月26日、Testinが主催する第2回NCTS中国クラウドテスト業界サミットが北京で開催されました。「AI+未来」をテーマにしたこのサミットには、国内外のテスト分野の著名な専門家や学者、大手企業の意思決定者、上級技術管理者、メディア関係者などが集まり、ハイエンドのクラウドテスト技術について議論し、テスト担当者が最先端の業界動向と最新の業界慣行を理解できるようにしました。

[[283750]]

会議では、アリババのテストと開発の専門家であるパン・ジアテン氏が「アリママのオフラインテスト領域のインテリジェント構築」について基調講演を行いました。 Pan Jiateng 氏は、ビジネスの現状と課題、インテリジェンス入力のロジック、オフラインテストのインテリジェンスを実現する方法など、Alimama のオフラインテストの実践を共有しました。

以下は潘家騰氏のスピーチの記録です。

みなさんおはようございます！ Testin 氏の仕事は非常に興味深く、本当に目を開かせてくれました。このように UI をテストすることができ、インテリジェントなアプリケーションによってテスト全体が簡素化されます。これまではテストを担当する学生が行っていましたが、今後はテストを担当しない学生だけでなく、開発、アルゴリズム、運用を担当する学生にも任せることができます。普通の人でもできますし、機械でもできます。問題はありません。

本日ご紹介するのは、Alimama のオフラインテストの実践、事業の現状と課題、インテリジェンス入力のロジック、オフラインテストのインテリジェンスです。インテリジェンスは非常に高度な技術ですが、オフライン テストはより現実的な仕事です。高度な技術と現実的な仕事をどのように組み合わせるかが、今回の私の講演の焦点です。

まず、Alimama がテスト中に遭遇した問題のいくつかを見てみましょう。オフライン機能テストの発展の歴史は、3 つの段階に分けられます。最初の段階は大航海時代で、自動化の度合いが低い手動テストが特徴でした。2 番目は産業革命で、自動化の度合いが非常に高くなりました。また、Alibaba の一部の内部プラットフォームなどの継続的統合ツールと組み合わせたテスト フレームワークもあり、これらが高度に自動化された方法を形成しました。しかし、テスト技術の敷居が非常に高いため、開発者が関与できず、作業のほとんどがテストによって行われています。アリババ社内では、多くのチームがまだ高度な自動化の時代にありますが、まだインテリジェンスの時代には入っていません。第3段階はインテリジェンスの時代であり、製品化、視覚化、部分的なインテリジェンスを特徴とし、効率が大幅に向上します。私たちは、開発者、アルゴリズム、または他の学生が参加できるように、しきい値を下げることで、テスト作業全体を簡素化するよう努めています。この段階では、主にテスト プラットフォームまたはテスト ミドル プラットフォームへの進化が中心となります。

これは、Alimama が直面している課題です。広告部門は非常に大きな領域であり、超大規模なオンライン システム、リンクのデータ化、非常に複雑でパーソナライズされたビジネス シナリオが含まれています。数千レベルのオンラインリリースを実施する場合、問題があればすぐにフィードバックを提供する必要があります。そうしないと、大きな損失が発生します。さらに、パフォーマンス要件が極めて厳しいため、テスターに​​とって大きな課題となります。先ほど述べたいくつかの複雑なシナリオでは、最初の課題はテストと開発の比率が非常に高いこと、2 番目は反復頻度がすでに毎日であること、3 番目はテスト シナリオが極めて複雑で、複雑さが指数関数的に増加していることです。私たちは、ボトルネックが QA に集中している、ナニー スタイルのテスト方法である Alimama 内の元のアプローチを見直しました。人数には限りがあり、プロジェクト数が増えると、どれだけ最適化してもボトルネックが発生し、インテリジェンスの時代に入ることを余儀なくされます。

解決策は、共同テスト モデルを作成し、従来のモデルに基づいて高速モデルを公開し、インテリジェントなアプローチを採用し、主に低リスクおよびアルゴリズム プロジェクトに焦点を当てたテスト プラットフォームを構築することです。高リスク プロジェクトは、引き続きテスターの責任となります。このプラットフォームにより、開発者やアルゴリズム開発者は、インテリジェント、視覚的、製品ベースの方法を通じて自動テストを実施できます。システムはエントリーとエグジットを判定し、システムが合格した場合はいつでもオンラインにすることができます。

オフライン テスト プラットフォームに関する私たちの考えとしては、いくつかの大きな要求があります。最初の大きな要求は、このプラットフォームがいつでもテスト可能であり、開発者がいつでもどこでも迅速にテストを実施できることです。これには、テストのアイデアをケースにすばやくマッピングし、システムがユースケースとテスト環境を効率的に管理して、究極の運用効率を実現できるように、非常に便利なケース記述が必要です。プラットフォーム全体には3つの方向性があります。1つ目はテストの極左シフト、2つ目はオフラインテストのインフラストラクチャになること、3つ目はR＆Dプロセスの再構築です。これらの指示に基づいて、テスト プラットフォーム全体で何を行うべきでしょうか? Markov は、私たちが構築したインテリジェントなオフライン テスト プラットフォームです。非常に強力なインフラストラクチャとして、この号では、インテリジェント回帰、ユース ケースのインテリジェントな推奨、データのインテリジェントな推奨、スモーキング回帰テクノロジ、ユース ケースの拡張、インテリジェントなトラブルシューティング クローズド ループなど、そのインテリジェントなテクノロジの一部を紹介します。Docker ベースの分散コンテナー管理、10,000 レベルのユース ケース管理システム、分散インテリジェント タスク スケジューリング システムなどの他のテクノロジについては、今回は説明しません。

インテリジェント テクノロジーは非常に重要ですが、それをテスト シナリオとどのように組み合わせるかがさらに重要です。機能テストの領域は、主に 3 つの部分に分かれています。最初の部分はケースの書き方、つまりユース ケースの生成です。2 番目はユース ケースの回帰、つまりケースを書いた後、すばやく反復することです。3 番目は、ケースが失敗したときにインテリジェントなトラブルシューティングを行う方法です。インテリジェンスの 3 つの側面すべてが反映されています。

まず、ユースケース ポートレートという概念を紹介します。テストにとって、堀と資産とは何でしょうか。それがユースケースです。私たちは Alibaba Mama の数万のユースケースを洗練、抽出、組み合わせ、最終的にユースケースごとに、ユースケース名、カバーされているコードドメイン、ビジネス特性、ユースケース障害の帰属、類似ユースケースセット (つまり、他のユースケースがどの程度類似し関連しているか)、および派生した異常ユースケースセット、操作の安定性など、独自のポートレートを形成しました。ユースケースの全体像に基づいて、ユースケースの全体像を把握することができ、ユーザーがユースケースを完全に理解できるようになります。同様に、ユースケースポートレートもインテリジェンスを実現するための重要な基盤となります。

インテリジェントなユースケース推奨の目標はシンプルです。従来の標準化されたユースケースの記述を、究極のエクスペリエンスを提供するケース記述方法にアップグレードすることです。以前は、テスト名から書き始めて、次に依存するテスト データ、送信要求と期待値の順に書き込むのが最も簡単でした。または、ユースケース ライブラリ内のユースケース データをコピーします。したがって、従来の方法は、手動で記述するか、古いユースケースをコピーすることです。 Markov のインテリジェントなユースケース推奨方法では、ユーザーがどのようなユースケースが必要かを自由に記述したり、設計ドキュメントを直接コピーしたりできるスマート ボックスを提供します。Markov プラットフォームは、入力した説明をビジネス機能に 1 つずつ抽出できます。同様に、ユースケース ライブラリ全体に何千ものユースケース ライブラリがある場合、各ユースケースは機能プールを形成するようにトレーニングされます。この時点で自然言語処理が利用でき、最終的にはビジネス機能が提案されます。ナイーブ ベイズ アルゴリズムを使用すると、類似度が上位 N の関連ユース ケースのリストを取得し、最終的に選択を決定して、数千のユース ケースの中から最も類似したユース ケースをすばやく取得できます。これにより、検索プロセスが節約され、ユースケースの作成プロセスも容易になります。右の図はユースケースの展開を示しています。正常なユースケースを書いた後、異常なユースケースを書く必要があります。最も基本的なプロセスは、パラメータを調整し、最大値、境界値、異常値、文字化けしたコードなどに変更することです。ユースケースライブラリ全体で、N ワイズ特徴モデルと多因子モデルをトレーニングしました。たとえば、特徴が 1、2、3、4 の場合、これらのデータのタイプを取得し、タイプに基づいて外れ値を取得できます。ライブラリ全体の機能をトレーニングし、すべての外れ値と境界値を組み合わせると、インテリジェントな推奨を通じて見つけたユースケースを簡単に組み合わせて変更できるようになります。特定の機能を拡張したい場合は、システムから拡張された組み合わせ値を推奨し、最終的なクロス積を通じて異常なユースケースセットを組み合わせることができ、最終的にはユーザーが選択して選別します。この組み合わせにより、多数のユースケースが生成され、複数のユースケースの生成が迅速に完了します。

以下はデータインテリジェント推奨です。ケースレベルの推奨に基づいて、より正確にテストデータを推奨できるため、ケースの書き込み率がさらに向上します。インテリジェントな推奨はユースケースを素早く見つける方法を提供しますが、ユースケースを見つけた後でも、それを変更して記述する必要があります。データ インテリジェントな推奨はこれを実現します。テストデータを作成する際、ユースケースを変更するという本来の方法に基づいて、特定のテストデータが見つからない場合は、他のケースでテストデータを見つけて、それをコピーして変更することがあります。 Markov プラットフォームでは、テスト データを書き込むときにそれを選択すると、システムが最も適切なテスト データを推奨します。推奨方法は 3 つあります。1 つ目はテンプレート推奨で、ユーザーがカスタマイズできるデータ ソース テンプレートを推奨する方法です。 2 番目は最長一致方式です。テスト データを推奨するだけです。この方法は非常に簡単です。最長のテスト データには最も完全な情報が含まれており、最も必要になる可能性が高いと想定しています。 3 つ目は、以前のユースケースの類似性に基づいた類似ユースケース距離の推奨です。このユースケースが現在編集中のユースケースと非常に類似している場合、そこで使用されるデータは必要なデータである可能性が高くなります。この作業を行うと、テスト データの変更が非常に簡単になります。

3 つ目は、インテリジェントな煙の逆流技術です。この技術は非常に興味深いもので、私たちが取り組んでいるものでもあります。別の方法でユースケースを生み出すことを期待しています。この方法は、本番トラフィックスモークに基づいてテストを実施し、それをユースケースのインテリジェント推奨テクノロジーと組み合わせて、オフラインのユースケースにすばやく戻ることで、オンラインとオフラインのクローズドループを開くというものです。これはどういう意味ですか？従来のテスト方法では、ユースケースを見つけて、それを変更し、テストします。このスモークデバッグは、Alibaba Mama の内部アルゴリズムの同僚のデバッグ方法を参考にした別の方法です。彼らはオンラインで喫煙し、オンライン データと独自のデータおよび本番トラフィックを使用して監視し、問題がなければ作業は完了です。私たちは、オンラインで作業しているときに、オンライン プロセスをワンクリックで再生し、オフライン ケースに変換できるソリューションを提供できるのではないかと考えていました。この方法では、オンライン デバッグが完了すると、オフライン ライブラリにケースが自動的に作成されます。これはどのように達成されるのでしょうか?これは比較的完全なインフラストラクチャに依存しています。Alimama は、環境インフラストラクチャなど、内部的に非常に優れたインフラストラクチャを備えています。本番環境と一貫性のある環境を、クリック 1 回ですばやく取得できます。これが環境のクローン作成です。この環境を取得した後、データ ファクトリーから提供されるトラフィックに基づいてアルゴリズムを変換し、簡単なオンライン スモーキングを実行できます。その後、オフライン トラフィック用のワンクリック変換モードを提供します。ここで 2 つの問題が発生します。オンラインとオフラインの間には常にギャップがあり、データが異なる必要があります。作業はいくつか完了しました。最初のタスクは、比較的単純なモジュールのスモーキング プロセス中に、ログ レベルからアプリケーション全体が依存するテスト データを取得することです。入力データが取得できたので、それをオフラインに戻すことができます。また、実際の出力も取得できたので、オフライン トラフィックをギャップなしで変換できます。しかし、この方法は非常に侵襲的であり、ポイントを追跡するために開発コード全体が開発に依存する必要があることに気付きましたか。そこで私たちは、推奨される技術である喫煙入力要求という別のアプローチを採用しました。入力要求機能や出力期待機能の一部を抽出し、ユースケース ライブラリのユースケース機能に基づいて可能なユースケースを推奨します。推奨後、ユースケースは修正され、システムが自動的に修正作業を行います。その後、修正されたユースケースに基づいてユースケースを記述できます。

次に、インテリジェントな回帰テクノロジがあります。ユースケースの動的オーケストレーション アルゴリズムを開発し、回帰効率を 2 ～ 10 倍向上させ、ユースケースの数に応じて回帰時間が直線的に増加する曲線を打ち破りました。回帰テストはユースケースライブラリ内のユースケースをバッチで実行するものですが、非常にシンプルであるにもかかわらず、R&D の効率を妨げる重要なリンクとなっています。従来のモードでは、さまざまな理由により、ケースバイケースでしか実行できず、依存データが再開され、データの競合が発生します。 Markov プラットフォームは、ユースケース オーケストレーション プロセス全体で最も効率的なオーケストレーションを実現し、回帰効率全体を飛躍的に向上させ、最終的に成長曲線を打破することを目指しています。ユースケースが数十ある場合は 1 回後退しても問題ありませんが、ユースケースが数百または数千ある場合はどうすればよいでしょうか?学生によっては、正確なテストを実施し、コードに影響を与えないユースケースのみを実行する場合があります。別の方法としては、複数の環境を並行して実行することです。これは実際には、リソースが常に限られているため、時間と引き換えにリソースを犠牲にする方法です。マルコフ氏は、アルゴリズムをプログラミングすることで、成長曲線を打破できると期待している。単一環境の回帰でこの曲線を破れば、複数の環境で回帰を実行するのがはるかに簡単になります。複数の環境とは、複数の環境を並行して実行することを指します。従来の方法は非常に単純です。ユースケースの総数は、環境の数に均等に分割されます。マルコフ法は、ユースケース時間が回帰に与える影響を蓄積し、ユースケースを逆に動的に割り当てることができる方法を使用します。グローバル最適値は、回帰分散を推定することによって達成されます。各環境のユースケース時間は、可能な限り均一になります。これは、回帰が完了したかどうかの評価が、最後の環境の完了に基づいているためです。回帰プロセスは、時間が均一で、各回帰の時間が似ているときに開始されます。これがグローバル最適値を達成する方法です。

最初に行うことは、回帰アルゴリズム全体の問題を解決することであり、次に行うことは、環境の問題を解決することです。動的オーケストレーション アルゴリズムを見てみましょう。アルゴリズムの核心はテスト データにあります。一度に大量のデータを準備すると、プロセス全体が非常に高速になり、多くの時間を節約できます。ユースケースにデータ依存関係がない場合、それらはすべて並行して実行できます。右のグラフは、データの冗長性率を表す曲線です。ユースケースの数が増えると、実行時間が非指数関数的に増加することがわかります。冗長性がゼロの場合、つまり冗長性がない極端なケースでは、ユースケースごとにデータを1回準備する必要があり、データの準備に多くの時間がかかります。ここで使用するアプローチは、最大の公開データセットに基づいてバイナリユースケースツリーを再帰的に作成することです。ツリーを構築した後、2 番目のステップはテストデータを集約することです。階層的クラスタリングアプローチを使用してさまざまなテキストデータを集約し、データの準備時間を短縮します。 3 番目のステップは、深さ優先アプローチに基づいて高速実行ツリーを構築し、実行プロセス全体が効率的な並列シリアル方式になるようにすることです。

これは私たちの研究室からのデータです。私たちは全体のプロセスを 4 つの段階に分けました。1 番目はデータ準備段階、2 番目は階層化データ準備段階、3 番目は高速実行段階、4 番目は失敗再試行段階です。ここには 600 を超えるデータがあり、冗長性は 500 に達しています。データが準備されており、すばやく実行できるため、ブラックタイムを節約できます。実験室でのデータ準備段階の効率は 500% 以上向上しました。並列化により、時間が約 50% 節約されます。

これはトラブルシューティングの領域です。ユースケースが失敗した後、どのようにトラブルシューティングしますか?このトラブルシューティングは非常に興味深いものです。私たちは、ユースケース ポートレートに基づいたメモリを備えたトラブルシューティング システムを開発しました。これには 2 つの目標があります。1 つ目は、障害のトラブルシューティングの効率を数分から数秒に向上させること、2 つ目はトラブルシューティングの経験を次のトラブルシューティングのために蓄積できるようにすることです。従来のトラブルシューティング システムは、左半分のリングを実装します。つまり、失敗したトラフィックを再生し、その後、実行プロセス中にシステム全体がリンク データを収集します。たとえば、実行プロセス中にログを収集し、トランクの状況はどうなっているか、テスト環境が正常に起動されているか、基本的な構成チェックなどを行います。このようにして、最終的にシステムが失敗の理由を示します。これは、非常に一般的なトラブルシューティングの考え方、つまりシステムの自己検査です。これに加えて、右半分のリンクという別のリンクを実装し、ユーザー フィードバック システムを追加しました。これは何を意味するのでしょうか?ループの左半分は、非常に基本的なセルフチェック方法です。複雑なシナリオをトラブルシューティングすることはできません。トラブルシューティング方法全体は、ユーザーによる手動トラブルシューティングになります。トラブルシューティングの障害情報はシステムに入力され、システムはそれを記録します。最後に、トラブルシューティングの障害全体の特徴が抽出され、過去の障害原因と比較されます。トラブルシューティングが実行されるたびに、システムセルフチェックの理由と、過去に手動トラブルシューティングの理由として考えられる理由が紹介されます。

インテリジェントなトラブルシューティング フィードバック全体とインテリジェントな回帰全体をリンクして、回帰フィードバックのクローズド ループを形成します。簡単に言えば、システムが自動的に自動調査を開始し、原因に関するフィードバックをユーザーに提供することで、回帰を迅速に実行できます。ユーザーは一度実行するだけで原因がわかるため、最も効率的なフィードバック速度が実現します。

テストを左にシフトすることについて話しましょう。インテリジェントなシナリオは効率性の問題を解決したり、開発者が最小限の方法でテストを実施できるようにしたりしますが、効率性の向上は依然としてリンクの 1 つです。 R&Dプロセス全体の効率を向上させるには、R&D効率の問題を線形的にも表面的にも解決するためにシフトレフトを行う必要があります。1つ目は、プログラム可能なパイプライン技術です。このプロセスはもともと5日かかっていました。当社は、機能テスト、機能AB、パフォーマンスABを含むUT自動化ワンストップサービスを提供しています。テストコードを提出する際に、ワンクリックで全プロセスを提出できるインフラを構築し、全プロセスを 4 時間以内に短縮しました。変更が古い機能に影響を与えない場合、テストが 4 つの段階に合格する限り、カバレッジ率は 100% に近づくことができると考えています。

機能的な A/B テストでは、オンライン環境と比較して、プロセス全体に強力なインフラストラクチャが必要です。必要なコア機能には、環境のクローン作成、データ ファクトリーに基づく正確なトラフィックの抽出と変換、高トラフィック実行の比較などがあります。同様に、パフォーマンス A/B テストも同じ考え方で、パフォーマンスを追求します。たとえば、このバージョンがオンラインになった後の安定性はどのようなものか、CPU の状態はどのようなものか、メモリの状態はどのようなものか、そして、最短のフィードバック時間を追求できることで、このバージョンのパフォーマンスとテスト レポートを決定できます。これらはすべて、強力なインフラストラクチャに大きく依存します。 3 つ目は CLI トリガー操作で、git の動作方法に基づいています。コマンドライン方式を使用してコードを変更します。Markov git 方式を使用して、R&D モードにシームレスに組み込むことができます。上記の機能が組み合わさって、Alimama の極端な左シフト プロセスが形成されます。

皆様ありがとうございました！