日本ソフトウェア科学会第 39 回大会 (2022 年度) 講演論文集

モバイルアプリの自動テストにおける強化学習の利用
村瀬 渓太

高田 眞吾

モバイルアプリの開発において, テストはコストが高い工程の一つであり, 自動化によるコスト削減は重要となる.
モバイルアプリの自動テストに用いられる手法の一つとして強化学習がある. 強化学習を用いてモバイルアプリをテストする手法はいくつか提案されているが, 先行研究では状態数が爆発する, 遷移に対する報酬が固定されている, 学習が収束しにくいといった課題が存在する. 本研究ではこれらの課題に対応することを目指し, UI 情報を用いた状態及び動的な報酬の定義を行い, 過去の状態遷移を用いて繰り返し学習を行うことを提案する.

においても, ランダムテストが用いられている. しか1 はじめにし, アクションの選択がランダムであるため, 探索の近年, スマートフォンの普及が進み, モバイルアプ効率面や安定性に問題がある. また, アプリ内で多くリは生活の一部となりつつある. アプリの開発においの操作が必要な状態へ到達ができないことも多い.てテストによる品質保証は重要とであるが, 自動化に探索効率の改善を図った手法として, モデルベース関してはまだ課題が多い. Android はスマートフォンの手法がある. モデルベースの手法では, コードの静の OS の中でも最もシェアが大きく, Android アプリ的解析などを用いてあらかじめ各状態において利用の自動テストに関する様々な手法が提案されている.

可能なアクションおよびアクションによってたどり

Android アプリの自動テストにおいては, Android の着ける状態を求め, 状態遷移図などの形式で表してお画面に対して, タッチやスワイプといったアクション

き, 効率の良いルートで探索を行うものである. しかを行っていく. アクションの結果として Android 画

し,Android アプリの正確な解析は難しく, 状態遷移面の状態が遷移していくが, この遷移によって様々な図を正しく構築できないことがしばしばある.

状態を訪れ, バグを探すことが基本となる.

ゲームの自動プレイなどにおいて有名な手法としAndroid アプリの自動テストの手法としてよく使わて強化学習が存在するが, 近年 Android の自動テストれるものとしてランダムテストがある. ランダムテスにおいていくつかの強化学習を利用した研究が行わ

トはタッチやスワイプなどのアクション及びアクショ

れている [5] [6] [7]. 強化学習では状態遷移に対して報ンの対象をランダムに選択するというものである. 広酬を与え, 得られる報酬が大きくなるように探索戦略

く普及している Monkey [4] という自動テストツールの学習を行う. 実際の状態遷移の結果に基づいて戦略を決めるため, モデルの正確性などに依存しないこと∗ This is an unrefereed paper.

Copyrights belong tothe Author(s).
Keita Murase, 慶 應 義 塾 大 学 理 工 学 研 究 科, Dept.
Graduate School of Science and Technology, Keio
University.
Shingo Takada, 慶 應 義 塾 大 学 理 工 学 研 究 科, Dept.
Graduate School of Science and Technology, Keio
University.

が利点となる. しかし, ゲームの自動プレイと違って目的が曖昧であったり, 時間経過によって変化するため, そのまま適用することは難しい.
本研究では, 強化学習の報酬を探索状況に応じて与えることで, テストの網羅率の向上を促す手法を提案する. また, このような報酬関数は時間経過によって変化するために, 学習結果が収束しにくいという問題用いた自動テストツールであり, GUI 構成要素を意が発生する. 本研究では今までの遷移履歴を保存し,味に応じてグループ分けし, どのグループの GUI 構直近の遷移を中心に学習を繰り返すことで収束に関成要素に対してアクションを行うかを決めている. 報する問題に対応することを提案する.

酬は遷移によって画面が切り替わった場合に大きい報酬を与えており, この報酬を用いて学習した場合, 画2 Q 学習について面に全く影響を与えない無意味な行動を回避しやす

強化学習は, 環境とエージェントが相互作用を行うくなるだろう. しかし, このような時間経過によってことで進行する. 基本的な流れは以下のようになる.

変化しない報酬を与えた場合, やがて学習が終了し,

1. エージェントがある戦略に基づき, 行動を行う.

Q 関数は一定値に収束した場合に各状態においてと

2. エージェントの行動に基づいて, 環境が現在のられる行動が一定になってしまう. この状態では同じ状態を変化させる.

3. 環境が行動の結果としてエージェントに対し,報酬を与える.

ような遷移を繰り返すため, 様々な遷移を行いたいというテストの目的と反する. ARES [6] も Qdroid のように画面の変化が生じた場合に大きい報酬を与え

4. エージェントは報酬に基づいて, 戦略を改善する.ており, 加えてバグを発見した場合にも報酬を与えて強化学習のアルゴリズムには様々なものが存在するいる. しかし, Qdroid と同様に, 学習が収束した後にが, 本研究では Q 学習 [9] というアルゴリズムを用い最終的に高い報酬を得られる同じ遷移を繰り返してる. Q 学習は戦略を Q 関数という形で表し, Q 関数しまう可能性が高い.の学習を行うアルゴリズムである. Q 関数 Q(s, a) と一方, Q-testing [5] のように時間経過により変化

は, 状態 s における行動 a の価値であり, この値が正する報酬を導入している研究もある. Q-testing では

しいものとなれば, 状態ごとに Q 関数の大きい行動

Siamese Network により既に訪れた画面と類似してを選択することで得られる報酬を大きくすることがでいるかを判定し, 類似している画面を訪れていない場きる. 仮に状態 st において行動 at を行ったところ,合に高い報酬を与えている. しかし, 時間経過により状態 st+1 に遷移し, 報酬 rt が得られた場合, Q 学習報酬を変化させた場合, 学習が収束しにくいという問では Q(st , at ) の値は以下のように推測する. ここで題が発生する.

γ は割引率であり, 将来的に得られる報酬をどの程度考慮するかを表している.

Q(st , at ) = rt + γ max Q(st+1 , at+1 )学習率を α とすれば, Q 関数の値を以下のように4 提案手法
本研究では先行研究の問題点を踏まえ, 状態定義,報酬の与え方, 学習方法の 3 点を提案する.

学習できる.

Q(st , at ) = Q(st , at ) +α(rt + γ max Q(st+1 , at+1 ) − Q(st , at ))Ｑ関数を状態と行動のペアごとにテーブルに保存

4. 1 状態定義
状態定義は UIAutomator [8] というツールから得られる情報をもとに行う. 図 1 は Hot Death [3] としておき, 状態遷移の際にこの更新式に基づいて学習

いう UNO に似たカードゲームで遊ぶことができるを進めるのが Q 学習という手法である.

アプリの初期画面である. 実際にはもう少し多いが, 画面内に 5 個の UI があることがわかる. UIAu-3 先行研究と問題点

tomator によって, これらの UI の Resource ID や強化学習を用いて Android の自動テストを行った

クリック可能かなどといった情報を得ることができ先行研究はいくつかあるが, 状況によらず同じ遷移にる. Resource ID は UI 要素ごとに割り振られていは同じ報酬を与えるといったものが多い. Qdroid [7]る名前であり, 主に開発者によって決められる. 例は Deep Q-Network という強化学習アルゴリズムをえば, 図 1 に表示されている NEW GAME ボタンには, com.smorgasbork.hotdeath:idbtn new game とション at を行った回数であり, distance(st , s) は状態

いう Resource ID が割り振られている. 図 1 の画面で

st と状態 s のベクトルの L1 距離である. つまり, 過は 5 つのボタンに別々の Resource ID が割り振られ去に同じアクションを行っていた場合, その回数が多ているが, 実際には同じ Resource ID の UI 要素が画

く, アクションを行った状態と st が似ているほど, ペ面内に複数存在することもある. また, UIAutomator

ナルティは大きくなる.

によって各 UI 要素がクリック可能か, 長押し可能か,このペナルティを用いて, 状態 st におけるアクショ

スクロール可能かといった可能な操作に関する情報

ン at の報酬 r(s t , at ) を以下のように定義する.
Xhigh(penalty(st , at ) < P )r(st , at ) =Xlow
(penalty(st , at ) ≥ P )penalty(st ,at )も得ることができる. 本研究ではこれらを踏まえて,

Resource ID 及び可能な操作が等しいものをまとめて, それぞれの個数をベクトルの成分として状態定義を行っている. 例えば図 1 であれば, 最初の 5 つの成分に 5 つのボタンを割り当てたとすると, ベクトルは(1, 1, 1, 1, 1, 0) となる. 一方, 図 2 では新たに CONTINUE ボタンが追加されているため, 最後の成分がそれに対応するとすればベクトルは (1, 1, 1, 1, 1, 1) となる. 現在画面内にない UI 要素についても大きさ 0として成分に含まれるため, 例えば Hot Death では次元数は 100 程度必要となる. 各 UI 要素の座標も取得することができるが, これは連続値であるため, 状ペナルティが閾値 P 未満であれば大きい定数の報酬

Xhigh を与えており, 閾値以上であれば小さい報酬をペナルティに応じてさらに下げた報酬を与えている.
閾値に応じて分けているのは, テストにおいて大きい意味を持つ初回の遷移を重視するためである. 上記の報酬定義では探索の状況に応じて報酬が変化していくため, 同じ状態でも状況に応じた行動を選択することができる.
図 1 において, HELP ボタンを選択する場合のペナルティを考える. 図 1 の状態との距離は当然 0 であるた態数の爆発を防ぐために省いている.

め, 過去に図 1 において HELP ボタンを 3 回選択していた場合, ペナルティには 31 加算される. 図 2 の状態との距離は distance((1, 1, 1, 1, 1, 0), (1, 1, 1, 1, 1, 1)) =1 であるため, 過去に図 2 において HELP ボタンを3 回選択していた場合, ペナルティは 32 となる. 二つの画面で HELP ボタンを 3 回ずつ選択していた場合,ペナルティは 4.5 となり, これを閾値 P 以上とすればlow
報酬は X4.5となる.

4. 3 学習方法
図1

画面 1

図2

画面 2

Q 関数については各行を状態, 各列を行動とした表形式で保持する. 各セルの値は行に対応する状態で列に対応する行動を行った場合の行動価値である. 新た

4. 2 報酬の与え方
ここでは画面内の各 UI 要素を操作することをそれぞれ 1 つのアクションとしている. まず, 状態 st においてアクション at を行う際のペナルティpenalty(st , at )を以下のように定義する.
∑count(s,at )penalty(st , at ) = s distance(st ,s)+1
ここで count(s, at ) は過去に状態 s においてアクな状態を訪れた際は新たな行を追加, 報酬を前述の定義に基づいて初期化しておく.
状態遷移のたびに Q 学習の更新式に基づいて学習するだけでは Q 関数が収束しにくいため, 定期的に以下の流れで繰り返し学習を行う.

1. 今までの遷移履歴について, 報酬を再計算する.
2. 直近 N 個の遷移を新しい順に取り出し, Q 関数を更新することを繰り返す.

3. 今までの遷移をランダムに取り出し, Q 関数を更新することを繰り返す.

• Menu ボタン• Back ボタン• ランダムな位置のクリック可能なボタン

まず, 今までの遷移はその遷移が起きた時に比べて報Menu ボタンや Back ボタンに関しては操作可能な状

酬が変わっている可能性が高いため, 再計算を行う.

況であっても画面内に存在しないアプリもあるため,

次に, まだあまり反映されていないだろう最近の遷移

仮想的な UI 要素として追加することで扱えるようにを用いて, 繰り返し学習を行う. 遷移を新しいものかしている. ランダムな位置へのボタン追加に関しては,ら取り出すことで, 辿ってきたルートに直近の結果をUIAutomator に認識されない UI 要素の影響を軽減効率よく伝搬させることを図っている. 最後に, 今まするために追加している.

での遷移すべての中からランダムに選択して学習を繰り返すことで, 全体の Q 関数を正しい値に近づけ

5. 2 Agentることを目指している.

Agent は Interactor から受け取った UI 情報をもとに, 操作する UI 要素を以下のような流れで決めて5 実装いる.

提案手法をツールとして実装した. アーキテクチャを図 3 に示す.

1. 操作前の状態, 前回の操作, 受け取った状態の組み合わせを遷移の履歴として保存する.

2. 新たな状態に訪れた場合, Q 関数のテーブルを拡張する.

3. 遷移履歴に基づき, Q 関数のテーブルの値を更新する.

4. 現在の状態において, Q 関数の値が高い行動を選択する. 低確率でランダムな行動を選択する.

5. 選択した行動を Interactor に伝達する.
図3

アーキテクチャ

6 評価
6. 1 評価方法
5. 1 Interactor

初期評価として, 本研究の実装にも利用しており,Interactor は Qdroid を ベ ー ス に 実 装 し て お り,強化学習を利用した自動テストツールの一つである

UIAutomator を利用し Android との相互作用を行Qdroid との比較を行った. AndroTest [1] というフう. UIAutomator は Android 画面の UI 要素の取得

レームワークを用いて, 仮想マシン上でアプリを実行および, UI 要素への操作を行うことができるフレー

し, メソッド網羅率を計測した. 対象とするアプリはムワークである. Interactor は UIAutomator から受AndroTest 内で提供されており, Qdroid の評価に用け取った XML 形式の画面データを UI 要素の配列へいられた 12 個を対象とした. 各アプリについて, それと分離し, Agent へ UI 情報を伝達する. また, Agentぞれのツールで 2 時間の実行を 3 回ずつ行い, メソッから選択する UI 要素を受け取り, 該当する UI 要素ド網羅率の平均値を算出している. 網羅率は Emmaに対して UIAutomator を通してクリックなどの操作[2] というフレームワークを用いて取得している.

を行う.
また, UIAutomator から得られた元の Android 画
面の UI 情報に対して追加で以下の UI 要素を加えている.

6. 2 結果と考察
結果は表 1 に示す. 提案手法は Qdroid に比べて高いメソッド網羅率を達成している. まず, MunchLife,

WeightChart, Multi SMS Sender, Anymemo は網羅率が改善されているが, これは仮想的な UI 要素の追7 まとめと今後の課題加により, アクションの選択肢を増やした影響が大き

現状の強化学習の課題を解決するために, 状態数がいと考えられる. 例えば MunchLife は Menu ボタン

爆発しない状態定義, 状況に応じて変化する報酬及びによる画面遷移が可能な状況でも Menu ボタンが画面

それらを十分に生かすための学習方法を提案した. 結

上に UI として現れないため, UIAutomator で認識果として, 実装のベースとした Qdroid に比べて網羅することができない. 本研究の実装では Menu ボタン率の改善を行うことができた. 今後の課題としては,を仮想的な UI として追加しているため, Menu ボタパフォーマンスの向上のために各種パラメータや状ンからのみたどり着ける状態にたどり着くことができ態, 報酬の調整, アクションの選択肢の拡張などを考た. Tippy Tipper, Mileage, Hot Death などは強化えている. また, さらなる評価として, Qdroid 以外と学習がうまく動作したと考えている. 例えば, Tippyの最新のツールとの比較や, 網羅率だけではなくバグTipper では, 最終的に行き着く画面から抜ける方法が検知の観点で性能を評価することを予定している.

Back ボタンと再起動であり, Back ボタンをうまく利用しないと効率が落ちてしまうと考えられる. Dalvik

参 考 文 献Explorer や Who has my stuﬀs, Mini Note Viewer,[1] Choudhary, S. R., Gorla, A., and Orso, A.: Automated Test Input Generation for Android: Are
We There Yet?, 2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2015, pp. 429–440.
[2] EMMA: a free Java code coverage tool: http://emma.sourceforge.net/.
[3] Hot Death: https://github.com/jpriebe/hotdeath.
[4] Monkey: https://developer.android.com/studio/
test/monkey.
[5] Pan, M., Huang, A., Wang, G., Zhang, T., and Li,X.: Reinforcement Learning Based Curiosity-Driven
Testing of Android Applications, Proceedings of the29th ACM SIGSOFT International Symposium on
Software Testing and Analysis, ISSTA 2020, 2020,pp. 153–164.
[6] Romdhana, A., Merlo, A., Ceccato, M., andTonella, P.: Deep Reinforcement Learning forBlack-Box Testing of Android Apps, ACM Transactions on Software Engineering and Methodology,
Vol. 31, No. 4(2022).
[7] Tuyet Vuong, Shingo Takada: Semantic analysis
for deep Q-network in android GUI testing, 31stInternational Conference on Software Engineeringand Knowledge Engineering, 2019, pp. 123–128.
[8] UI Automator for Python: https://github.com/xiaocong/uiautomator.
[9] Watkins, C. J. and Dayan, P.: Q-learning, Machine Learning, 1992, pp. 279–292.

My Expenses では網羅率が落ちていた. これらは例
えば Menu ボタンが必要ないなど, UI 要素の追加により増えた選択肢が余計なものであったために, 効率が落ちたと考えられる. 強化学習により意味のない選択肢を選択する頻度はある程度抑えることができたと考えている. Random Music Player に関しては現在のアクションの選択肢において探索できる部分はほぼ尽くされており, 網羅率の向上には適切な URL の自動入力などが必要になると考えられる.
表1

網羅率の比較

アプリ名Qdroid の網羅率 (%)

提案手法の網羅率 (%)

Any Memo

31.3

39.2

Dalvik Explorer79.8

78.2

Hot Death

63.5

78.3

Mileage

36.5

44.3

Mini Note Viewer

59.1

49.4

Multi SMS Sender

38.3

59.5

Munch Life

47.9

68.8

My Expenses

63.5

62.1

Random Music Player

54.1

54.1

Tippy Tipper

74.3

83.1

Weight Chart

35.3

65.6

Who has my stuﬀs

81.0

78.1

平均53.563.4