Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
機械学習を活用した
テスト自動化システムの設計
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βユーザー先行登録受付中
ありがとうございました!
機械学習を活用したテスト自動化システムの設計
Prochain SlideShare
Chargement dans…5
×

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

1 459 vues

Publié le

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

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

Publié dans : Logiciels
  • Soyez le premier à commenter

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

  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. ありがとうございました!

×