Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
機械学習を活用した
テスト自動化システムの設計
2017.3.19	
株式会社TRIDENT
伊藤望
About Me
p 伊藤 望(いとう のぞみ)
p 株式会社TRIDENT	代表取締役
n テスト自動化支援・テストツール開発
p 執筆
これまでに作ったテストツール
1. Windowsアプリの記録・再生テストツール
n 記録・再生のエンジンから自作
2. Webの記録・再生テストツール
n エンジンから自作しようとして失敗
3. Excelベースのテストツール
これまでに作ったテストツール
4. ユニットテスト基盤フレームワーク
5. Selenium基盤フレームワーク
6. Seleniumテストレポートツール「Sahagin」
7. 機械学習を活用したテストツール「Magic	Pod」[NEW!]
今日のお話
1. Magic	Podの概要
2. Magic	Podを設計する
2.1 テスト実行エンジン
2.2 スクリプトの生成
2.3 スクリプトの形式
3. Magic	Podの細かい機能デモ
1.	Magic	Podの概要
Magic	Podとは
p 機械学習(ML)の技術を活用した自動テストWeb
サービス
n ディープラーニング技術などを利用
n 現在はモバイルアプリ向けのみ
p これまで作った数々のツールのノウハウを凝縮
p 「Magic	Pot」から改名し...
デモ(動画)
開発状況
p アルファユーザーテスト(1社)を開始
p 先行登録ユーザー限定体験ハンズオンを開催
p 現在は機能ギャップを埋めているフェーズ
Magic	Podの最終目標
p 人間向けの手動テストケースをAIが理解し自動実行
user@example.com	/	pass01	でログイン
user@example.com pass01
Magic	Podの最終目標
多くが「UI手動テスト」
1. Excel(など)でテストケース作成
2. 人間がUIからテスト実施
世界で毎年テストに
費やされている金額
15兆円 (推定)
この部分を置き換える
2.	Magic	Podを設計する
p Magic	Podをどう考えて開発してきたか
p 今後どんなことを実現しようとしているか
2.1	テスト実行エンジン
操作対象の指定方法は何がいい?
1. 画像テンプレートマッチ
n 例:				click(				 )
2. 座標指定
n 例: click(125,	230);
3. システム情報で指定
n 例: findElement(By.id("use...
操作対象の指定方法は何がいい?
1. 画像テンプレートマッチ
n 例:				click(				 )
n 環境・画面変化に弱い
2. 座標指定
n 例: click(125,	230);
n 環境・画面変化に弱い
3. システム情報で指定
n...
操作対象の指定方法は何がいい?
- システム情報指定の問題点 -
p 内部構造を理解しないと読めない
p システム情報に外部からアクセスできないことがある
p 見つからない時のエラー原因がわかりにくい
p 開発者が変更することがある
n システ...
操作対象の指定方法は何がいい?
- 人間はどうしているのか -
p 人間は、座標もシステム情報も見ていない!
p 画像マッチもしていない!
p 手動テストケースには、「検索ボタン」「名前入力エリ
ア」のように書いてある
検索ボタン 名前入力エリア
操作対象の指定方法は何がいい?
- 人間はどうしているのか -
p 人間は、見た目から「検索」アイコンや「ボタン」っぽい
ものを探している!
p 人間は、位置関係でUI要素のラベル付けをしている!
検索ボタン
名前入力エリア
操作対象の指定方法は何がいい?
- 目指すべき要素指定方法 -
p 人間のように要素を認識したい
p 「Magic」ロケータ
driver.findElement(By.magic("検索ボタン"));
driver.findElement(B...
操作対象の指定方法は何がいい?
- Magicロケータのメリット -
p 手動テストケースと同じ言葉。読みやすい
p 目で見える情報には必ずアクセスできる
p 見つからない時のエラーが目で見てわかる
p このレベルの見た目は、開発者はみだりに変...
Magicロケータ実装の要素技術
p 「検索アイコン」「ボタン」を見た目から特定する
p 位置関係でUI要素のラベル付けをする(Captioning)
検索ボタン
名前入力エリア
Magicロケータ実装の要素技術
p 「検索アイコン」「ボタン」を見た目から特定する
n ディープラーニング技術の得意分野
n 畳み込みニューラルネットワーク(CNN)を使用
n 画像の種類を人間が教えた上で、大量に学習させる
n Google...
p CNNを学習させる様子
これは「search」
クラスだよ
これは「button」
クラスだよ 学習させたデータに応じて、
重みパラメータが変化していく
Magicロケータ実装の要素技術
p 学習したネットワークを使う様子
この画像は
何のクラス?
「button」だよ!!
Magicロケータ実装の要素技術
p 学習していないアイコンは認識できない
p 見慣れないアイコンにはラベルが付いていることが多
いので、意外と大丈夫
この画像は
何のクラス?
わかりません..
Magicロケータ実装の要素技術
p 位置関係でUI要素のラベル付けをする(Captioning)
p ここは他の機械学習の手法を使用
「お名前」入力エリア
「ログイン」ボタン
「ICカード」エリア
Magicロケータ実装の要素技術
p 画像解析
1. 領域分割(独自ロジック)
2. 各領域をCNNにかけて物体認識
3. OCR(文字認識)
4. Captioning
5. 2.	3.	4.の結果をマージして表示
p 1.&	2.	が時代遅れ&低速なので改善したい。。
Ma...
p 2通りの方式がある
1. テスト実行時ロケータ計算方式
n Magicロケータの理想をきちんと実現
n デモで見せた方式
2. テスト作成時ロケータ計算方式
n もう少しシステム情報を活用した方式
n 画像解析が間違っていたら手直しできる
...
1.	テスト実行時ロケータ計算方式
1.	テスト実行時ロケータ計算方式
-テストを作成する-
①画像解析
②選んでテスト作成
1.	テスト実行時ロケータ計算方式
-テストを実行する-
③Mochaテストコードに変換
④コマンドラインから実行 ④CIで実行
1.	テスト実行時ロケータ計算方式
-テストを実行する-
⑤実行時に再度画像解析
⑥対応するAppium要素を取得
UIATextField[1]
⑦Appiumで実行
1.	テスト実行時ロケータ計算方式
-テストを実行する-
⑤実行時に再度画像解析
⑥対応するAppium要素を取得
UIATextField[1]
⑦Appiumで実行
「名前」入力エリア UIATextField[1]
の対応はキャッシュし、...
2.	テスト作成時ロケータ計算方式
2.	テスト作成時ロケータ計算方式
-テストを作成する-
②画像解析&
ロケータ計算
①Magic	Pod	Desktopで画像と
UIツリー情報をアップロード
2.	テスト作成時ロケータ計算方式
-テストを作成する-
③選んでテスト作成
テストスクリプト
UIマップ
④実行前に
UIマップを作成可能
2.	テスト作成時ロケータ計算方式
-テストを作成する-
テストスクリプト
UIマップ
• 画像解析で生成されたラベル
• 人間が書き換えてもよい
2.	テスト作成時ロケータ計算方式
-テストを実行する-
⑤そのままAppiumで実行
テスト実行エンジンの改良
p 物体認識ロジックの改善
n Fast	R-CNN、Faster	R-CNN、Single	Shot	MultiBox Detector
p UI操作をAppium非依存に
n 強化学習でUIコンポーネントの種類ごと...
2.2	スクリプトの生成
- キャプチャ&リプレイをサポートすべきか -
キャプチャ&リプレイを
サポートすべきか?
p キャプチャ&リプレイ(操作自動記録)には問題が多い
n スクリプトの可読性が極めて低い
n 画面定義の共通化などができない
だがそれはしょぼい記録再生ツールの話
キャプチャ&リプレイを
サポートすべきか?
p UIマップを使って記録すれば、問題は解決可能
n 可読性が高い &	共通化もできている
p あのSelenium	IDEですら、
n UIマップを事前に作っておけば、
n キレイなスクリプトとして...
キャプチャ&リプレイを
サポートすべきか?
p が、キャプチャ&リプレイには、他にも問題がある
p 間違えた時の試行錯誤が地味に面倒
n スクリプトの一部だけを再記録したい
n 押し忘れたボタンがあったことに後から気づいた
p 記録対象の画面に...
Magic	Podのアプローチ
p 実UIの画面をサーバ上に再現し、そこでテスト作成
p 目的の画面に高速に遷移できる
p 実環境よりも動作が軽快
Magic	Podのアプローチ
p クリックだけでコマンド行追加できれば、キャプチャ&
リプレイと同じテスト作成スピートに
Magic	Podのアプローチ
- デメリット -
p 1つのUIが複数の画面状態を持つケース
n スクロール・ポップアップ,	etc
p 現状は、複数枚アップロードする必要がある
2.3	スクリプトの形式
- 表形式かプログラムコードか -
スクリプトはどんな形式にすべきか?
1. 表形式
n Excel、etc
2. プログラムコード
n Java、Ruby、etc
1. 表形式
n メリット:ノンプログラマでも扱える
n デメリット:高度な処理・柔軟な処理が難しい
2. プログラムコード
n メリット:高度な処理・柔軟な処理でも書ける
n デメリット:プログラマでないと辛い
スクリプトはどんな形式にすべき...
Magic	Podのアプローチ
相互変換可能にすればいい!
Magic	Podのアプローチ
画面要素を選ぶだけの単純作業は、
Web画面で効率よく!
複雑な処理はプログラムコードで!
開発者・QAの協調作業も容易に!
p で、どうやるの?
Magic	Podのアプローチ
既にできている
この時のために、
昔作ったやつがある
p Sahagin
n Seleniumテスト結果を表形式レポートにするツール
プログラムコード =>	表形式 変換
p Sahaginの仕組み
プログラムコード =>	表形式 変換
inputById("userInput", "Magic太郎");
inputById
"userInput" "Magic太郎"
抽象構文木(AST)
表形式
静的に構文解析...
p UIテストで必要な主な構文は、ほぼ扱える見込み
p ASTの仕様も決めてドキュメント化した
p Java(静的型)でもGroovy(動的型)でもできた
p GebみたいなASTがやばそうなヤツでもできた
プログラムコード =>	表形式 変換
p Sahaginの構文解析ロジックをnode.jsに移植
p ほぼできた
p これを今後組み込んで行く予定
プログラムコード =>	表形式 変換
p あらゆるテストコードを表形式に変換できるのか
プログラムコード =>	表形式 変換
できない
p Selenium	IDE(+プラグイン)で表現できる
「If」「for」「while」「変数」「返り値」程度まで
n それ以上やると、表形式で...
p 複雑な処理側
p 表形式テストケース側
n 複雑さを意識せず使える
プログラムコード =>	表形式 変換
次の祝日でない月曜を取得
3.	Magic	Podの細かい機能デモ
お知らせ
pβユーザー先行登録受付中
ありがとうございました!
機械学習を活用したテスト自動化システムの設計
Nächste SlideShare
Wird geladen in …5
×

機械学習を活用したテスト自動化システムの設計

1.312 Aufrufe

Veröffentlicht am

2017年3月19日に行われたテスト自動化カンファレンス2017の発表資料です。

https://testautomationresearch.connpass.com/event/50928/

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

機械学習を活用したテスト自動化システムの設計

  1. 1. 機械学習を活用した テスト自動化システムの設計 2017.3.19 株式会社TRIDENT 伊藤望
  2. 2. About Me p 伊藤 望(いとう のぞみ) p 株式会社TRIDENT 代表取締役 n テスト自動化支援・テストツール開発 p 執筆
  3. 3. これまでに作ったテストツール 1. Windowsアプリの記録・再生テストツール n 記録・再生のエンジンから自作 2. Webの記録・再生テストツール n エンジンから自作しようとして失敗 3. Excelベースのテストツール
  4. 4. これまでに作ったテストツール 4. ユニットテスト基盤フレームワーク 5. Selenium基盤フレームワーク 6. Seleniumテストレポートツール「Sahagin」 7. 機械学習を活用したテストツール「Magic Pod」[NEW!]
  5. 5. 今日のお話 1. Magic Podの概要 2. Magic Podを設計する 2.1 テスト実行エンジン 2.2 スクリプトの生成 2.3 スクリプトの形式 3. Magic Podの細かい機能デモ
  6. 6. 1. Magic Podの概要
  7. 7. Magic Podとは p 機械学習(ML)の技術を活用した自動テストWeb サービス n ディープラーニング技術などを利用 n 現在はモバイルアプリ向けのみ p これまで作った数々のツールのノウハウを凝縮 p 「Magic Pot」から改名しました
  8. 8. デモ(動画)
  9. 9. 開発状況 p アルファユーザーテスト(1社)を開始 p 先行登録ユーザー限定体験ハンズオンを開催 p 現在は機能ギャップを埋めているフェーズ
  10. 10. Magic Podの最終目標 p 人間向けの手動テストケースをAIが理解し自動実行 user@example.com / pass01 でログイン user@example.com pass01
  11. 11. Magic Podの最終目標 多くが「UI手動テスト」 1. Excel(など)でテストケース作成 2. 人間がUIからテスト実施 世界で毎年テストに 費やされている金額 15兆円 (推定) この部分を置き換える
  12. 12. 2. Magic Podを設計する
  13. 13. p Magic Podをどう考えて開発してきたか p 今後どんなことを実現しようとしているか
  14. 14. 2.1 テスト実行エンジン
  15. 15. 操作対象の指定方法は何がいい? 1. 画像テンプレートマッチ n 例: click( ) 2. 座標指定 n 例: click(125, 230); 3. システム情報で指定 n 例: findElement(By.id("userInput")).click();
  16. 16. 操作対象の指定方法は何がいい? 1. 画像テンプレートマッチ n 例: click( ) n 環境・画面変化に弱い 2. 座標指定 n 例: click(125, 230); n 環境・画面変化に弱い 3. システム情報で指定 n 例: findElement(By.id("userInput")).click(); n 環境・画面変化に強い 既存手法では「システム情報」指定がベストだが..
  17. 17. 操作対象の指定方法は何がいい? - システム情報指定の問題点 - p 内部構造を理解しないと読めない p システム情報に外部からアクセスできないことがある p 見つからない時のエラー原因がわかりにくい p 開発者が変更することがある n システム情報のキープは、開発者はあまり考えてくれない
  18. 18. 操作対象の指定方法は何がいい? - 人間はどうしているのか - p 人間は、座標もシステム情報も見ていない! p 画像マッチもしていない! p 手動テストケースには、「検索ボタン」「名前入力エリ ア」のように書いてある 検索ボタン 名前入力エリア
  19. 19. 操作対象の指定方法は何がいい? - 人間はどうしているのか - p 人間は、見た目から「検索」アイコンや「ボタン」っぽい ものを探している! p 人間は、位置関係でUI要素のラベル付けをしている! 検索ボタン 名前入力エリア
  20. 20. 操作対象の指定方法は何がいい? - 目指すべき要素指定方法 - p 人間のように要素を認識したい p 「Magic」ロケータ driver.findElement(By.magic("検索ボタン")); driver.findElement(By.magic("名前入力エリア"));
  21. 21. 操作対象の指定方法は何がいい? - Magicロケータのメリット - p 手動テストケースと同じ言葉。読みやすい p 目で見える情報には必ずアクセスできる p 見つからない時のエラーが目で見てわかる p このレベルの見た目は、開発者はみだりに変えない n ユーザーフローが変わってしまうので
  22. 22. Magicロケータ実装の要素技術 p 「検索アイコン」「ボタン」を見た目から特定する p 位置関係でUI要素のラベル付けをする(Captioning) 検索ボタン 名前入力エリア
  23. 23. Magicロケータ実装の要素技術 p 「検索アイコン」「ボタン」を見た目から特定する n ディープラーニング技術の得意分野 n 畳み込みニューラルネットワーク(CNN)を使用 n 画像の種類を人間が教えた上で、大量に学習させる n Googleの写真分類(1000クラス以上)ですらこのアプローチ
  24. 24. p CNNを学習させる様子 これは「search」 クラスだよ これは「button」 クラスだよ 学習させたデータに応じて、 重みパラメータが変化していく Magicロケータ実装の要素技術
  25. 25. p 学習したネットワークを使う様子 この画像は 何のクラス? 「button」だよ!! Magicロケータ実装の要素技術
  26. 26. p 学習していないアイコンは認識できない p 見慣れないアイコンにはラベルが付いていることが多 いので、意外と大丈夫 この画像は 何のクラス? わかりません.. Magicロケータ実装の要素技術
  27. 27. p 位置関係でUI要素のラベル付けをする(Captioning) p ここは他の機械学習の手法を使用 「お名前」入力エリア 「ログイン」ボタン 「ICカード」エリア Magicロケータ実装の要素技術
  28. 28. p 画像解析 1. 領域分割(独自ロジック) 2. 各領域をCNNにかけて物体認識 3. OCR(文字認識) 4. Captioning 5. 2. 3. 4.の結果をマージして表示 p 1.& 2. が時代遅れ&低速なので改善したい。。 Magicロケータ実装の要素技術
  29. 29. p 2通りの方式がある 1. テスト実行時ロケータ計算方式 n Magicロケータの理想をきちんと実現 n デモで見せた方式 2. テスト作成時ロケータ計算方式 n もう少しシステム情報を活用した方式 n 画像解析が間違っていたら手直しできる テスト実行エンジンの全体像
  30. 30. 1. テスト実行時ロケータ計算方式
  31. 31. 1. テスト実行時ロケータ計算方式 -テストを作成する- ①画像解析 ②選んでテスト作成
  32. 32. 1. テスト実行時ロケータ計算方式 -テストを実行する- ③Mochaテストコードに変換 ④コマンドラインから実行 ④CIで実行
  33. 33. 1. テスト実行時ロケータ計算方式 -テストを実行する- ⑤実行時に再度画像解析 ⑥対応するAppium要素を取得 UIATextField[1] ⑦Appiumで実行
  34. 34. 1. テスト実行時ロケータ計算方式 -テストを実行する- ⑤実行時に再度画像解析 ⑥対応するAppium要素を取得 UIATextField[1] ⑦Appiumで実行 「名前」入力エリア UIATextField[1] の対応はキャッシュし、 2回目からは高速に動作
  35. 35. 2. テスト作成時ロケータ計算方式
  36. 36. 2. テスト作成時ロケータ計算方式 -テストを作成する- ②画像解析& ロケータ計算 ①Magic Pod Desktopで画像と UIツリー情報をアップロード
  37. 37. 2. テスト作成時ロケータ計算方式 -テストを作成する- ③選んでテスト作成 テストスクリプト UIマップ ④実行前に UIマップを作成可能
  38. 38. 2. テスト作成時ロケータ計算方式 -テストを作成する- テストスクリプト UIマップ • 画像解析で生成されたラベル • 人間が書き換えてもよい
  39. 39. 2. テスト作成時ロケータ計算方式 -テストを実行する- ⑤そのままAppiumで実行
  40. 40. テスト実行エンジンの改良 p 物体認識ロジックの改善 n Fast R-CNN、Faster R-CNN、Single Shot MultiBox Detector p UI操作をAppium非依存に n 強化学習でUIコンポーネントの種類ごとに操作法を学習 させるアプローチは? p 内部で使用するロケータを、よりRobustなものに n Selenium IDEより63% Robustなロケータで記録する論文を 先日発見 p 主に論文を読んで頑張る感じ p ピンと来た方はお話しましょう!
  41. 41. 2.2 スクリプトの生成 - キャプチャ&リプレイをサポートすべきか -
  42. 42. キャプチャ&リプレイを サポートすべきか? p キャプチャ&リプレイ(操作自動記録)には問題が多い n スクリプトの可読性が極めて低い n 画面定義の共通化などができない だがそれはしょぼい記録再生ツールの話
  43. 43. キャプチャ&リプレイを サポートすべきか? p UIマップを使って記録すれば、問題は解決可能 n 可読性が高い & 共通化もできている p あのSelenium IDEですら、 n UIマップを事前に作っておけば、 n キレイなスクリプトとして記録されます!
  44. 44. キャプチャ&リプレイを サポートすべきか? p が、キャプチャ&リプレイには、他にも問題がある p 間違えた時の試行錯誤が地味に面倒 n スクリプトの一部だけを再記録したい n 押し忘れたボタンがあったことに後から気づいた p 記録対象の画面に遷移するまでの手数が面倒 p テスト環境がシステムが低速なことがある n Appium・エミュレータ起動 n 貧弱なテストサーバ、低速な通信
  45. 45. Magic Podのアプローチ p 実UIの画面をサーバ上に再現し、そこでテスト作成 p 目的の画面に高速に遷移できる p 実環境よりも動作が軽快
  46. 46. Magic Podのアプローチ p クリックだけでコマンド行追加できれば、キャプチャ& リプレイと同じテスト作成スピートに
  47. 47. Magic Podのアプローチ - デメリット - p 1つのUIが複数の画面状態を持つケース n スクロール・ポップアップ, etc p 現状は、複数枚アップロードする必要がある
  48. 48. 2.3 スクリプトの形式 - 表形式かプログラムコードか -
  49. 49. スクリプトはどんな形式にすべきか? 1. 表形式 n Excel、etc 2. プログラムコード n Java、Ruby、etc
  50. 50. 1. 表形式 n メリット:ノンプログラマでも扱える n デメリット:高度な処理・柔軟な処理が難しい 2. プログラムコード n メリット:高度な処理・柔軟な処理でも書ける n デメリット:プログラマでないと辛い スクリプトはどんな形式にすべきか? このトレードオフをどうするか
  51. 51. Magic Podのアプローチ 相互変換可能にすればいい!
  52. 52. Magic Podのアプローチ 画面要素を選ぶだけの単純作業は、 Web画面で効率よく! 複雑な処理はプログラムコードで! 開発者・QAの協調作業も容易に!
  53. 53. p で、どうやるの? Magic Podのアプローチ 既にできている この時のために、 昔作ったやつがある
  54. 54. p Sahagin n Seleniumテスト結果を表形式レポートにするツール プログラムコード => 表形式 変換
  55. 55. p Sahaginの仕組み プログラムコード => 表形式 変換 inputById("userInput", "Magic太郎"); inputById "userInput" "Magic太郎" 抽象構文木(AST) 表形式 静的に構文解析 テストコード
  56. 56. p UIテストで必要な主な構文は、ほぼ扱える見込み p ASTの仕様も決めてドキュメント化した p Java(静的型)でもGroovy(動的型)でもできた p GebみたいなASTがやばそうなヤツでもできた プログラムコード => 表形式 変換
  57. 57. p Sahaginの構文解析ロジックをnode.jsに移植 p ほぼできた p これを今後組み込んで行く予定 プログラムコード => 表形式 変換
  58. 58. p あらゆるテストコードを表形式に変換できるのか プログラムコード => 表形式 変換 できない p Selenium IDE(+プラグイン)で表現できる 「If」「for」「while」「変数」「返り値」程度まで n それ以上やると、表形式でも読めなくなる p 複雑な処理は、補助メソッドを作って隠蔽してもらう
  59. 59. p 複雑な処理側 p 表形式テストケース側 n 複雑さを意識せず使える プログラムコード => 表形式 変換 次の祝日でない月曜を取得
  60. 60. 3. Magic Podの細かい機能デモ
  61. 61. お知らせ pβユーザー先行登録受付中
  62. 62. ありがとうございました!

×