⽬次
n はじめに⾃⼰紹介
n 課題
マルチプラットホームへの対応、イベントトリガーの検出、⼈間のエミュレート
n デバイス⽐較
エミュレータとスマホ実機、ビデオキャプチャー機器とWebカメラ
n 画像解析
⼊⼒画像の加⼯、領域の分割、矩形の検出、オブジェクトの検出
n テンプレートマッチング
第1世代、第2世代、第3世代
n ⽇本語OCR
クローラーの開発、⽂字認識⽤の教師データ、⽂章解析⽤の教師データn 性能改善
処理速度の向上、聴覚のサポート
n まとめ
1

⾃⼰紹介

折⽥ 武⼰ <takemi.orita@levtech.jp>
フリーランスのエンジニアとして、様々な開発プロジェクトに携わってきた。また、エンジニア向け技術研修の講師として、後進の指導に当たることも多い。
どこの開発現場でも直⾯する喫緊の課題であるテストの⾃動化については、ライフワークのひとつとして⻑年に渡り取り組んできた。
本⽇の講演内容も、これまでの開発経験から得られた知⾒をベースにしているが、独⾃の視点からアイデアを練り直し、⽇々カイゼンを施している。
2

課題

Webアプリとスマホアプリでは設計思想が根本的に異なる。
Webアプリ

スマホアプリ

実⾏環境

WebブラウザーOS（Android/iOS）

通信プロトコルHTTP/HTTPS

（任意）

通信データ

テキスト*1

バイナリ、テキスト

プログラミング⾔語

HTML/CSS/JavaScript

（任意）

データ構造

DOM

（任意）

⾃動テストツール

Selenium

AppiumWebアプリに⽐べて、スマホアプリのUIテストが技術的に困難な理由を次の視点から考えてみる。
Ø マルチプラットホームへの対応
Ø イベントトリガーの検出Ø ⼈間のエミュレート*1 画像データや⾳声データなど、⼀部にバイナリを利⽤することもある。

3

【課題】マルチプラットホームへの対応

⽇本国内でのAndroidとiOSのシェアは拮抗しており、どちらか⼀⽅だけに特化するのは避けたい。次のような要求を満たすため、既存のツールキットを採⽤することになる。
• 提供するアプリのUX/UIを統⼀したい• コードベースを共有したい
Android/iOSに両対応したツールキットの多くは、OS固有のウィジェットを使わず、等価な挙動のコンポーネントを⾃前で描画している。その結果、テキストやボタンなどの汎⽤的なコンポーネントでさえ、その背後にあるデータ構造は失われ、画⾯上のピクセルに⾊の濃淡として塗り潰される。
スマホアプリのUIテストの技術的な障壁は、すべてそれに起因する。ラスタライズされた画像データの中から、ボタンやリンクなどのイベントトリガーを探し出すことを求められる。
4

【課題】イベントトリガーの検出

ラスタライズされた画像データの中から、イベントトリガーを検出するために画像解析技術を応⽤することになる。しかし、それだけは不⼗分なことも多い。
普段は何気なく操作している、次のようなウィジェットを画⾯上のピクセルに格納されたRGBデータから拾い出し、適切な座標でイベントを発⾏する必要がある。
• テキスト⼊⼒フィールド• チェックボックス• ラジオボタン• ドロップダウンリスト

Webアプリなら簡単に実現できることが、なぜこんなにも難しいのか？
あまりの不条理さに、この最初のステップで脱落してしまうことが多い。

• リンク
• ボタン
5

【課題】⼈間のエミュレート

UIテストを⾃動化するためには、ラスタライズされた画像データから意味を読み取り、適切なアクションを起こす仕掛
け・・・つまり⼈間のような器官が必要不可⽋である。
⼈間をエミュレートするためのソフトウェア構成は次のようになる。

脳• Python視覚• OpenCV

触覚• Appium

聴覚• BlueZ
6

デバイス⽐較

スマホアプリのUIテストを⾃動化するのに利⽤可能なデバイスをリストアップすると下記のようになる。
• エミュレータ• スマホ実機• ビデオキャプチャー機器• Webカメラ
次のような観点からデバイスの⽐較検討を⾏う。
Ø エミュレータとスマホ実機
Ø ビデオキャプチャー機器とWebカメラ

7

【⽐較】エミュレータとスマホ実機

エミュレータと実機の⽐較結果は次の通り。
エミュレータ

スマホ実機

利便性

○

×

導⼊コスト

○

×

管理コスト

○

×

デバイスの互換性

×*1○

バイナリの互換性

×*2

○

実⾏速度

△*3

○

エミュレータはあくまでも擬似環境に過ぎないので、UIテス
トは（可能な限り）スマホ実機で⾏うべきである。
*1 スマホ実機を完璧にエミュレートしているわけではないので、画⾯の解像度以外のパラメータはあまり当てにならない。
*2 AndroidエミュレータはARMプロセッサ⽤の命令コードをそのまま使っているが、iOSシミュレータはx86プロセッサ⽤の命令コードに変換している。
*3 Androidエミュレータは遅くて使い物にならないが、iOSシミュレータは実⽤的な速度で動作する。
8

【⽐較】ビデオキャプチャー機器とWEBカメラ

ビデオキャプチャー機器とWebカメラの⽐較結果は次の通り。
ビデオキャプ
チャー機器

Webカメラ

利便性

○

○

汎⽤性

△

○*1

画像品質

○

△*2

⾳声品質

○

△*3

導⼊コスト

×*4

○

管理コスト

×*5

○

実⾏速度

○

○

*1 AndroidでもiOSでも、まったく同じ機器構成のまま扱うことができる。
*2 Webカメラのレンズで映像データを取り込むので周囲の環境に⼤きく影響される。
*3 Webカメラのマイクで⾳声データを取り込むので周囲の環境に⼤きく影響される。
*4 MHL（HDMI）の信号は著作権保護されており、PCに直接取り込むことはできない
ため、パススルー可能なスプリッターを経由する必要がある。
*5 たくさんのケーブルを接続するため、配線の取り回しに苦労する。
また、プロダクトの将来的な供給体制にも不安が残る。
9

画像解析

実機とWebカメラを使ったUIテストの実施にあたり、下記の⽬標を掲げる。
• （デバッグ⽤ではなく）リリース⽤のバイナリを使う• （スマホだけではなく）タブレットにも対応する• （座標を決め打ちせず）オブジェクトを動的に検出する
この⽬標を実現するためには、レンダリングされた画像データを解析し、画⾯に表⽰されているオブジェクトを⾃動判別する必要がある。そこで次のようなアプローチを採⽤する。
Ø ⼊⼒画像の加⼯Ø 領域の分割Ø 矩形の検出Ø オブジェクトの検出10

【画像解析】⼊⼒画像の加⼯Webカメラからの⼊⼒画像は（ビデオキャプチャー機器のそれと⽐べて）理想的とは⾔い難い。そのため、次のような前処理を⾏う。
1. ノイズ除去

2. ⾊調補正

3. 射影変換

4. サイズ変換

5.⾊分解

1. ノイズ除去・・・照明の映り込みなどを除去
2. ⾊調補正・・・明度や彩度の調整3. 射影変換・・・画⾯をトリミングし、台形から矩形に変換
4. サイズ変換・・・VGAまたはXGAにサイズを縮⼩5. ⾊分解・・・フルカラー、グレースケール変換、2値変換
11【画像解析】領域の分割

特定のシンボルを検出し、現在表⽰されている画⾯を特定するところから画像解析作業はスタートする。その上で、画⾯を任意の領域に分割し、それぞれにドリルダウンする。
• ステータス領域
スコアやアイテム、パンくずリストなどを表⽰する。
• メイン領域
アプリのコンテンツを表⽰する。
• サブ領域
画⾯遷移のトリガーやティッカーなどパネルを表⽰する。
• ポップアップ領域
ダイアログボックスなどをオーバーレイ表⽰する。
※⾯遷移することによって、画⾯のレイアウト⾃体も⼤きく変化することが多い。
12

【画像解析】矩形の検出

分割された領域をさらにドリルダウンする際、OpenCVの矩形検出機能が⼤いに役⽴つ*1 。
ユーザーに情報を表⽰するためのパネルは、⼊れ⼦状態になった矩形*2に内包されているのが⼀般的*3だからである。
15,300※絶対座標や相対座標を使って、オブジェクトを検出するのは（⾃動テストの開発資産の寿命を縮める*4ので）避けるべきである。
*1 処理を⾼速化するため、グレースケールまたは2値画像で矩形検出を⾏う。
*2 OpenCVは円や多⾓形、直線など様々な機能を備えている。
*3 既存の検出器で対応できない場合、オリジナルの検出器を作成することもできる。
*4 画⾯レイアウトが変更になった場合に⾃動追従できない。
13

【画像解析】オブジェクトの検出

テストスクリプトからダイアログボックスを操作する際、次のようなオブジェクトの座標を動的に検出する必要がある。
• テキスト⼊⼒フィールド• チェックボックス• ラジオボタン• ドロップダウンリスト
• リンク
• ボタン
Webアプリの場合には、DOMというオープンな技術基盤があるため、JavaScript や Selenium を使って検出できる。
スマホアプリの場合には、後述するテンプレートマッチングを使うことによってオブジェクトを検出する。
14

テンプレートマッチング

テンプレートマッチングとは、ターゲット画像中に含まれるオブジェクトを検出する技術である。主な⽤途は次の通り。
• アサーション
表⽰されている画⾯を判定する。
• バリデーションコンポーネントの状態を取得する。
• ロケーション
コンポーネントの座標を取得する。
これまでに開発したテンプレートマッチングは次のように進化してきた。それぞれの特性に応じた利⽤が肝要である。
Ø 【第1世代】画像の照合
Ø 【第2世代】特徴点の照合
Ø 【第3世代】⽂字列の照合15【テンプレートマッチング】第1世代

第1世代のテンプレートマッチングでは、画像データを使ってオブジェクトの検出を⾏う。
# OKボタンのクリック（テンプレート画像のパスを間接指定）
button = self.container.find_image(":ok_button")button.click()

OpenCVに⽤意されたメソッドを呼び出すだけなので、とても簡単に実装できる。しかし、次のような課題がある。
• 背景画像が変化する場合に対応できない*1• ボタンの⾊が状態に応じて変化する場合に対応できない*2• テンプレート画像を事前に⽤意する必要がある*3*1 テンプレート画像に背景を含まないようにトリミングすることで回避できる。
*2 それぞれの状態ごとにテンプレート画像を⽤意すれば回避できる。ただし、照合回数もその分だけ増える。
*3 ⼊⼒画像に合わせてリサイズし、背景画像を含まないようにトリミングするのは思ったよ
りも⼿間がかかる。
16【テンプレートマッチング】第2世代

第2世代のテンプレートマッチングでは、特徴点データを使ってオブジェクトの検出を⾏う。
# OKボタンのクリック（特徴点データのパスを間接指定）
button = self.container.find_feature(":ok_button")button.click()

OpenCVが独⾃実装したロイヤリティ不要のアルゴリズム
ORBを使うことで、テンプレート画像に⽐べて⼤幅なデータ容量の軽量化に成功した。しかし、次のような課題がある。
• テンプレート画像に⽐べて直感的ではない*1• 特徴点データを⽣成するツールが必要である*2• 特徴点データを事前に⽤意する必要がある*3*1 特徴点データの中⾝を⾒ても、⼀体何に対応するものかが⼈間には理解できない。
*2 テンプレート画像から特徴点データを⾃動⽣成できるようにする。
*3 ⼊⼒画像に合わせてリサイズし、適切にトリミングした画像ファイルを保存しておけば、（必要に応じて）特徴点データが⽣成されるようにする。

17

【テンプレートマッチング】第3世代

第3世代のテンプレートマッチングでは、⽂字列を使ってオブジェクトの検出を⾏う。
# OKボタンのクリック（⽂字列を直接指定）
button = self.container.find_string("OK")button.click()

OCRを使うことで、⽂字列を引数にしてオブジェクトが検出できるようになった。事前準備が⼀切不要なので、⽣産性や保守性が向上する。しかし、次のような課題がある。
• ⽂字列を含まないオブジェクトには対応できない*1• ⽇本語に対応したOCRが必要である*2• OCRの呼び出しによるオーバーヘッドが発⽣する*3*1 第1世代、第2世代のテンプレートマッチングを利⽤する。
*2 画⾯遷移のトリガーは⽂字列が含まれること多いので、OCRを利⽤するメリットは⼤きい。
*3 対象領域の画像データと判定結果をキャッシュすることにより2回⽬以降は⾼速化できる。
18

⽇本語OCR

第3世代のテンプレートマッチングに必要不可⽋なのが、⽇本語OCRである。その調達⽅法について検討する。
コスト

機能性

可⽤性拡張性

市販プロダクト×○

×*1

×

Webサービス

○

×*2

△*3×

OSSライブラリ

○

△*4○

○

⾃作ライブラリ

△*5○

○

○

⽇本語OCRに求めるのは次のような仕様である。
• アンダーラインやドロップシャドウに対応 せっかくなので、• ⼿書き⽂字は対象外（⽇英フォントのみ）

⽇本語OCRを⾃作してみた。

*1 対応するOSが限定され、ランタイムの配布にも制約がある。
*2 画像データのアップロードが必要になるため、レスポンスが遅くなる。
*3 ダウンタイムなくサービスを利⽤し続けられるのか不透明である。
*4 英語のように単語間にスペースが存在する前提のものが多いので、改造範囲が広い。
*5 ディープラーニングを応⽤すれば、実装すべきコード量は極めて少ない。
19

【⽇本語OCR】クローラーの開発

⽇本語OCRの教師データ（⽂字認識⽤、⽂章解析⽤）を⼊⼿するために専⽤のクローラー *1 を開発する。
利⽤⽬的
Selenium

HTMLファイルとスクリーンショットの取得

Beautiful Soup

HTMLファイルからDOM構造を解析し、コンテンツを抽出OpenCV

スクリーンショットに含まれるコンテンツ領域の切り出し

MongoDB

画像データとメタ情報、テキスト情報の管理

このクローラーによって⾃動収集された下記の情報が⽇本語OCRの教師データとなる。
• HTMLファイルに含まれるテキスト情報• スクリーンショットに含まれる画像データ
⽂字認識⽤は、フォントの種類やスタイルを切り替えて、複数のスクリーンショットを同時に取得する。
*1 基本的な仕組みはWebページのスクレイパーそのものである。

20

【⽇本語OCR】⽂字認識⽤の教師データ

クローラーによって⼊⼿した画像データを1⽂字ごとに切り出すことによって教師データを⽣成する。
利⽤⽬的
MongoDB

画像データとメタ情報の管理

OpenCV

画像データから⽂字の切り出し

Chainer *1

深層学習ライブラリ

⽂字単位の画像切り出し作業は意外と⼤変である。お薦めなのは下記のようなWebページを動的に⽣成し、クローラーに収集させることである。
• HTMLのTABLEタグを使って1マスに1個の⽂字を配置• TABLEタグの罫線は⾮表⽰（border=0）• ページャーを使って1ページあたりの⽂字数を制限*1 TensorFlowなどの他の使い慣れた深層学習ライブラリでも構わない。
21【⽇本語OCR】⽂章解析⽤の教師データ

クローラーによって⼊⼿したテキスト情報を形態素解析したものを（必要に応じて*1）Word2Vec で機械学習させる。
利⽤⽬的
MongoDB

テキスト情報の管理

MeCab

テキスト情報の形態素解析

Chainer *2

深層学習ライブラリ

⽂字単体の認識ができるようになっても、促⾳や濁⾳、拗⾳などの区別は難しい。次のようにして変換精度を向上させる。
• 辞書データを⽤意する*3• 情報源を厳選する*4*1 ボタンやリンクに含まれる名詞だけではなく、まとまった⽂章を扱うとき。
*2 TensorFlowなどの他の使い慣れた深層学習ライブラリでも構わない。
*3 最⻑⼀致する単語を調べる際に⽤いる。専⾨⽤語の辞書があると変換精度が向上する。
*4 テキスト情報に誤字脱字が含まれていると学習結果にも悪影響がある。コンテンツをしっかりと校閲しているWebサイトの利⽤が好ましい。
22

性能改善

これまでに説明した技術を組み合わせれば、スマホアプリのUIテストを⾃動化するための準備は揃うはずである。
• 画像解析
Webカメラ経由で⼊⼿した画像を解析する。
• テンプレートマッチング
イベントのトリガーを動的に検出する。
• ⽇本語OCR画⾯に表⽰された⽂字データを取得する。
さらなる性能改善や機能拡張を⽬論む場合、次のアプローチを採⽤してみてはどうだろう。
Ø 処理速度の向上
Ø 聴覚のサポート23

【性能改善】処理速度の向上

アクション性の⾼いゲームでは、60fpsでレンダリングされる画⾯に対しての即応性が求められる。処理を⾼速化するためには、下記のような⼯夫を適切に組み合わせ、計算量を減らす必要がある。
• 対象領域のクリッピング• 照合対象のカスケード• 判定結果のキャッシュ• フレームバッファの差分抽出
それでもなお処理落ちが発⽣してしまう場合、次のような選択肢を考慮しておく。
• ⼊⼒画像のサイズ縮⼩• 画像処理エンジンのクラスター化
24

【性能改善】聴覚のサポート

ゲームの場合、プレイヤーの没⼊感を⾼めるためにサウンドが果たす役割は⼤きい。⾃動テストツールに聴覚が備わると応⽤範囲も拡⼤するが、次のような検証が必要になる。
• ON/OFFの切り替え• ボリュームの制御• ビジュアルとサウンドの同期確認
USBマイクやライン⼊⼒を利⽤することもできるが（イヤホン端⼦のないスマホも増えているので）Bluetoothスピーカーに擬態して⾳声データを取り込む*1のがスマートである。
• フィルターを使った周波数帯域の分離*2• 波形データからの特徴点抽出*3*1 Linuxであれば BlueZ などのプロトコルスタックが使える。
*2 フーリエ変換とローパスフィルターといったシンプルな組み合わせでも⼗分に使える。
*3 ⾳声データの場合、スナップショットではなく、ストリームとして扱う必要がある。

25

まとめ

スマホアプリのUIテストを⾃動化する際、どのようにしてスクリーンに表⽰されている情報を取り込むのか？ ⾝近にある「Webカメラ」というデバイスを活⽤することで、次のようなメリットが得られる。
• 低コストでハードウェアを揃えられる• OS標準のドライバをそのまま使える• OpenCVから映像を直接制御できる
OSSの普及によって、画像解析や⾳声解析、ディープラーニングといったパワフルなツールを個⼈レベルでも使えるようになった。⽇本語OCRのような複雑なソフトウェアをほんのわずかなコードで実現できたことに⾃分でも驚いた。
案ずるより産むが易し・・・思考実験に留めるより、実際にアクションを起こすことが重要である。
26

ご静聴ありがとうございました。

27