[NCTS サミットレビュー] Li Yuanchun: 自動テストにおける強化学習の応用

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

[[283751]]

会議では、北京大学コンピュータサイエンス学部の博士である李元春氏が「自動テストにおける強化学習の応用」について基調講演を行いました。 Li Yuanchun氏は、GUIテストに関連する研究を紹介し、「強化学習をGUIテストに適用する際の難しさは、主に状態の表現と報酬関数の設計、つまりインタラクティブインターフェースに画像やテキストなどのマルチモーダル機能を効果的にエンコードする方法と、テスト目標をテスト入力に対する報酬に変換する方法にあります」と指摘しました。

以下は李元春氏の演説の記録である。

こんにちは、同僚の皆さん！ GUI テストに関連する私の仕事をここで共有できることを光栄に思います。私の名前は Li Yuanchun です。私の研究分野は、モバイル アプリケーションのプライバシーとセキュリティです。プライバシーとセキュリティ関連の分析を行う際、静的分析または動的分析手法を使用することが多いです。動的分析では、アプリケーションが十分なコードをカバーし、プライバシーとセキュリティに敏感な動作を十分にトリガーできるようにアプリケーションを動的にテストする方法が、プライバシーとセキュリティの分析結果の整合性を直接決定します。そこで、GUI テストの研究方向に触れ、いくつかの小さな探索作業を行いました。本日、皆さんにお伝えしたいのは、技術的な実装についてです。

まず、GUI テストの背景を紹介します。ソフトウェアのグラフィカル インターフェースに基づいて、インタラクティブなアクション シーケンスをテスト ケースとして生成します。主なアプリケーション シナリオは 2 つあります。1 つは GUI トラバーサル テスト、つまりソフトウェアの機能を完全に探索する方法です。2 つ目は機能テストで、アプリケーションのログイン機能をテストするなどです。生成されるテスト ケースは、アカウント名を入力し、パスワードを入力し、クリックしてログインするといったものになります。

これら 2 つのシナリオに基づいて、それぞれディープラーニングと強化学習の手法の使用を検討しました。

1 つ目は、ディープラーニングに基づく GUI トラバーサル テストです。自動 GUI トラバーサル テストには、主に 2 つの戦略があります。1 つはランダム戦略です。たとえば、Android の公式ツール Monkey はランダム戦略です。アプリケーションをテストする場合、これらのツールは、アプリケーションの特定の GUI とコードを理解できず、コードの内容とはまったく関係のないテスト ケースを生成するサルのようなものです。 2 つ目はモデルベースの戦略で、コードに対して静的または動的分析を実行し、モデルを構築し、このモデルを使用して入力をガイドします。例えば、右の図は学術論文から引用したツールの一部です。コードの実行パスを分析し、シンボリック実行を使用してパス到着法を解決することで、よりターゲットを絞ったテストケースを生成できます。これらの方法の共通点は、テストの容易さとテストの効率の間でトレードオフを行うことです。たとえば、Monkey は使いやすさのために効率を犠牲にし、あらゆるアプリケーションを迅速にテストできますが、欠点も特に顕著です。ランダム テスト ケースは説明、拡張、再現が困難です。モデルベースの戦略では、コードを分析してユースケースを生成します。主な欠点は、コードを分析する必要があることです。現在、多くのアプリケーションのコードは非常に複雑で、多くの言語が混在し、さまざまな高級言語の機能が使用されているため、静的分析が非常に困難になっています。また、ブラックボックステストでは、ソースコードが入手できなかったり、コードが暗号化されていたりするため、モデルベースの静的解析手法を使用することは困難です。現在主流となっているのは、両者のバランスを取るアプローチです。テストケースもモデルに基づいて生成されますが、このモデルはコードを分析してモデル化するものではなく、アプリケーション実行時のインターフェース変換関係をモデル化します。これは、後でテストケースを生成するときに無効な入力を回避するためのメモリ機能としてのみ機能します。

これは先ほど述べた 3 番目の方法で、よく使われるインターフェース遷移図モデルです。たとえば、このモデルでは、各ノードはインターフェースの状態であり、各エッジは状態間の遷移関係です。このようなモデルを構築した後、アプリケーションをテストできます。右の写真は私が以前作成したツール、DroidBot です。これは、ブラック ボックス状況で任意のアプリケーションのインターフェイス遷移グラフを構築できます。インターフェース遷移グラフに基づいて、深さ優先、幅優先、ランダムプローブ、ヒューリスティックルールなどのトラバーサルテスト戦略を誰でも記述できます。

ただし、これらの単純なルールを使用してアプリケーション機能を探索することは非効率的であることが多く、アルゴリズムではアプリケーション内の重要なインターフェースや機能にすぐに到達できないことがよくあります。非常に興味深い点を思いつきました。手動テストを実施する場合、実際のテスターであれユーザーであれ、コードを理解していなくても、アプリケーション インターフェイスを非常に効率的に探索できる場合が多いのです。その理由について考えてみると、主に 2 つの理由が見つかりました。まず、さまざまなアプリケーションの GUI インタラクション モードが類似していることです。たとえば、どのアプリケーションであっても、何らかの検索機能があります。多くのアプリケーションは、下向きのウォーターフォール スタイルの情報フロー構造を持っています。機能が類似していなくても、インタラクション モードは類似しています。 2 つ目の理由は、多くの人がこれまでテストの経験がないにもかかわらず、多くのアプリケーションを使用しており、無意識のうちにさまざまなインタラクション モードを学習していることです。そこで、機械学習を使用して、アプリケーションを使用する人々のインタラクション パターンを学習し、これらのインタラクション パターンを使用して機械学習モデルを形成し、このモデルを使用して自動テスト データの生成をガイドできるのではないかと考えました。もちろん、ソフトウェア GUI の状態とアクションを機械的に表現する方法や、GUI のこれらのインタラクション モードを効率的にキャプチャするモデルを設計する方法など、ここでは多くの課題があります。

このアイデアに基づいて、私たちは Humanoid という作品を作りました。主なアーキテクチャは次のとおりです。まず、オフライン学習段階では、実際のユーザーインタラクションデータが大量に収集されることが想定されます。これらのインタラクションデータは、テスト対象のアプリケーションからではなく、任意のアプリケーションから取得できます。オフラインのユーザー インタラクション レコード データから学習し、学習した内容をインタラクション モデルにキャプチャし、このモデルを使用してテスト UI インタラクション データの生成を継続的にガイドします。

これが、ヒューマノイドがインタラクティブ インターフェースの状態とアクションを表現する問題を解決する方法です。各 UI 状態を UI 構造図として表現します。UI 内の画像とテキスト情報は無視し、各 UI 上のテキストと画像領域のみを確認します。これを行う目的は、限られたデータからより多くの、よりシンプルな UI 機能を収集し、機械学習中に一般化しやすくすることです。インタラクティブなアクションを表現する場合、2 つの部分で構成されます。1 つ目は、クリック、スライド、入力などのインタラクティブなアクションの種類です。 2つ目の要素は、インタラクティブアクションの場所です。インターフェイス上でインタラクティブアクションが発生する場所も、X座標とY座標で直接表現されます。ただし、孤立したユーザーがクリックするポイントを、この点を核とした分布図に変換する必要がある場合がよくあります。学習時に、各データポイントは孤立しているのではなく、分散しているため、学習が容易になります。

上記の 2 つの表現により、モデルの入力と出力のマッピング関係が明確になります。現在のインターフェース コンテキストには、現在のインターフェース S と最新のインタラクションが含まれます。出力は、相互作用位置確率分布と相互作用アクションタイプ確率分布の 2 つの確率分布です。これら 2 つの確率分布に基づいて、各相互作用アクションの確率を計算できます。

これは、インターフェースのコンテキストとインターフェースのインタラクションアクションの関係を捉えるために使用するディープラーニングモデルです。インターフェース上の画像情報を捉えるために多くの CNN が使用されていることがわかります。 4 つのインタラクション シーケンスを使用しました。インタラクティブ インターフェースの現在の状態に加えて、以前の 3 つのインタラクション履歴も使用しました。これらの 4 つのインタラクション アクションを LSTM に入力し、インターフェース インタラクション機能を抽出し、この機能を元のインタラクション入力に再マッピングして、インタラクション アクション位置の確率分布を生成しました。

これは、モデルのトレーニング後に実際に使用する疑似コードです。テスト時には、探索するかモデルを使用するかをランダムに選択します。探索する場合は、モデルを使用してインタラクティブなアクションを生成し、インタラクティブなアクションを実行します。使用されている場合は、インターフェース遷移図に従って前のインターフェースに戻ります。

ヒューマノイド実験の評価には、アプリケーションを使用するユーザーの多くのインタラクション記録を含む Rico データセットを使用します。このデータを使用して、UI 遷移モデルをトレーニングします。 Monkey、PUMAなど代表的な6つのツールと比較しました。

インタラクション パターンを学習する効果は、このモデルが実際のユーザーのインタラクション アクションをより高い確率で予測できることです。このモデルは、実際のユーザーが使用するインタラクション アクションを最上位にランク付けできるため、モデルがインタラクション情報を効果的に学習したことがわかります。このモデルを実際のテストに適用すると、これらのテスト ツール間のカバレッジの差はそれほど大きくありませんが、Humanoid は市場で人気のあるアプリケーションに対して最高のコード行カバレッジと比較的高いインターフェース カバレッジを達成できます。これはHumanoidと他のツールのカバレッジ向上速度の評価結果です。赤い線がHumanoidの結果であり、比較的早く高いカバレッジ率を達成できており、この曲線は上昇傾向にあることがわかります。

2 番目の部分は、強化学習に基づく UI 機能テストです。まず、UI 機能テストの背景を紹介します。私たちの目標は、一連の UI インタラクティブ アクションを生成し、ソフトウェアの特定の機能を検証することです。たとえば、先ほど説明したログインの例では、テスト ケースの最初の行はアプリを開くこと、2 行目は電子メール アドレスを入力すること、次のコードはパスワード ボックスにパスワードを入力して、最後にログイン ボタンをクリックすることです。手動で作成されたテストケースは時間がかかり、労力もかかるため、テストの修復も手動で行う必要があり、効率性に大きな問題が生じます。右側は、Sikuli ツールなどの主流のツールを使用した手動テストのサンプルを示しています。これにより、テスト ケースの作成が非常に簡単になりました。ただし、テストの経験がない人にとっては、このようなコードの作成は依然として比較的複雑です。私たちの目標は、テスト ケースのテキスト記述に基づいてテスト スクリプトを自動的に生成することです。たとえば、Lyft/Uber の Web サイトの場合、テスト ケースの説明は「ある場所から別の場所までのタクシー料金を見積もる」などです。自然言語とソフトウェアのインタラクティブ インターフェイスを理解することで、右下隅のテスト スクリプトを生成したいと考えています。強化学習の問題には、Web ブラウザーと報酬モデルを含むテスト実行環境と、テスト実行環境に配信されて最終的なテスト スクリプトを取得する強化学習エージェントがあります。

強化学習の非常に重要な部分は、強化学習環境です。強化学習環境は、タスクの初期状態を与え、現在の状態でどのアクションを実行できるかをモデルエージェントに伝えます。エージェントが現在の状態でアクションを実行すると、アクションに対する報酬と新しい状態が返されます。強化学習を GUI テストに適用する際の難しさは、主に状態の表現と報酬関数の設計、つまり、インタラクティブ インターフェイスで画像やテキストなどのマルチモーダル機能を効果的にエンコードする方法と、テスト目標をテスト入力に対する報酬に変換する方法にあります。テストでは、エージェントが観察する状態は現在の UI 構造であり、実行可能なアクションは現在のインターフェースで実行可能なすべてのインタラクティブ入力のセットです。テスト環境では、エージェントがアクションを実行し、そのアクションに対する報酬を返すことを許可する必要があります。強化学習環境の報酬関数を設計する場合、設計目標は、強化学習が正しいテストケースを見つけられるように、正しいアクションシーケンスに高い報酬を与えることです。ここでの私たちの観察は、対話型アクション シーケンスが正しいテスト ケースである場合、通常、次の 3 つの指標を満たしているということです。まず、アクションはタスク パラメーターと一致する必要があります。たとえば、先ほど言ったように、A から B まで、2 つのポイント間のタクシー料金 AB がこのタスクのパラメータです。この 2 つのパラメータに一致する 2 つのアクションが必要です。 2つ目は、UIのテキストと説明文が重複してしまうことです。 3 つ目は、アクション シーケンスが実際のユーザーのインタラクション習慣に準拠する必要があることです。たとえば、テスト ケースを生成するときに、ページの下部をクリックしたり、中央をクリックしたり、ジャンプしたりすることはできません。これは間違っている可能性があります。テスト中にエージェントが UI と正しく対話できるように、いくつかの制約を追加する必要があります。

現在主流の強化学習アルゴリズムの 1 つに、ディープ ニューラル ネットワークを使用して Q 関数を推定する Q ネットワークがあります。Q 関数は、現在の状態 s と選択されたアクション a をパラメーターとして受け取り、現在の状態 s でアクション a を実行した場合の値を返します。私たちのモデルでは、状態 s とインタラクションアクション a を使用してそれぞれ画像情報とテキスト情報を抽出し、Q ネットワークの入力として相互に融合して最終的に Q 値を推定します。

これは、強化学習アルゴリズムによって生成された最後の例です。A から B までのタクシー料金のテスト ケースでは、それぞれ最終的な報酬スコアを持つ 3 つのスクリプトを生成できます。

強化学習に基づくテスト入力生成方法を評価し、10 のカテゴリの Web サイト、合計 73 の Web サイトを選択しました。これらの Web サイトで 41 のテスト記述を定義しました。たとえば、「ボストンで午後 8 時に 4 人分のテーブルを予約する」はテスト ケース記述です。これらをテスト ケースとして使用し、テスト ケース記述と Web サイトの組み合わせを 172 個取得しました。目標は、各組み合わせに対してテスト スクリプトを生成することです。最後に、評価の際には、各テスト ケースの説明と Web サイトで強化学習アルゴリズムを 1 時間実行して、最高のインタラクティブ トレーニングを取得し、その後手動で評価を行いました。

これが最終評価の結果です。トップ1の精度は65.7%、トップ5の精度は76.6%でした。一般的な検索アルゴリズムと比較したところ、強化学習は比較的高い優位性を達成できることがわかりました。

まとめると、テストにおけるディープラーニングと強化学習の応用には幅広い展望があるものの、大規模に利用できるようになるまでにはまだまだ長い道のりがあります。困難さには次のようなものがあります。まず、この問題のテストは本質的に非常に複雑です。現在のディープラーニングは主に画像やテキストを入力として受け取りますが、UI は視覚情報とテキスト情報の両方を含む、より複雑なタイプの情報です。現在、UI の特徴を捉えるための特に優れたモデルや方法は存在しません。 2 つ目の問題は、強化学習アルゴリズムが成功する分野はゲームであることが多いことです。たとえば、強化学習は囲碁を非常にうまく解くことができます。重要な理由の 1 つは、ゲームの分野では報酬が比較的明確であるのに対し、テストではテストケースの良し悪しを評価する正確な指標がないことです。結局、評価後、正しいか間違っているかに関係なく、すべてのテストケースは非常に似たような報酬を得るため、強化学習モデルが正しいか間違っているかを区別することが難しくなります。これらの問題を解決するには、一方では研究上の課題があり、他方では解決すべき多くの工学上の問題があり、学界と産業界の共同の取り組みが必要です。

今日はこれで終わりです。みなさんありがとうございました！