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