事例 アジャイルと自動化 後半(ヤフオク!アプリでの自動テストの事例紹介) at Ques vol.7( #ques7 ) 11/20/2015
•
37 likes•34,434 views
2015/11/20 開催のQues vol.7( #ques7 )での講演「事例 アジャイルと自動化」の後半部分の資料です ヤフオク!アプリでの自動テストの事例紹介です This is a slide of "Example of Agile and Test Automation" that used by Ques vol.7( #ques7 ) 11/20/2015
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to 事例 アジャイルと自動化 後半(ヤフオク!アプリでの自動テストの事例紹介) at Ques vol.7( #ques7 ) 11/20/2015
Similar to 事例 アジャイルと自動化 後半(ヤフオク!アプリでの自動テストの事例紹介) at Ques vol.7( #ques7 ) 11/20/2015 (20)
More from Yahoo!デベロッパーネットワーク
More from Yahoo!デベロッパーネットワーク (20)
Recently uploaded
Recently uploaded (8)
事例 アジャイルと自動化 後半(ヤフオク!アプリでの自動テストの事例紹介) at Ques vol.7( #ques7 ) 11/20/2015
- 2. ⾃自⼰己紹介 • ⻘青野彰太朗 • Androidエンジニア • Webエンジニア • 開発チームのスクラムマスター • @shota_̲low 2
- 3. 今⽇日お話することの概要 1.⾃自動テストを導⼊入した経緯 2.導⼊入時のノウハウ 3.導⼊入後の結果 4.今後の予定 3
- 5. 本資料料での ⾃自動テスト = UIテスト 5
- 7. 2015年年4⽉月当時に困っていた問題 • 特定の画⾯面を開くと100%クラッシュ • 古い端末やOSで起動すると100%クラッシュ 7 リリース後に発覚
- 8. アプリのリリース前テスト 8 • 関係者全員がアプリを実際に触ってテスト • 1999年年からある歴史あるサービス • -‐‑‒>画⾯面/条件/機能が多岐にわたり、確認漏漏れ がどうしても発⽣生してしまう状況
- 9. Androidの場合 • 即時に修正版をリリース可能 • 段階的公開機能を使⽤用(5%-‐‑‒>20%-‐‑‒>100%) • リリースする割合をコントロールできる 9 被害は最⼩小限に留留めることが可能
- 10. iOSの場合 • 即時に修正しても審査が必要 • 審査期間は不不確実 • 公開範囲をAndroidのように指定できない 10 致命的
- 11. 困った… 11 写真：アフロ
- 14. 2.導⼊入時のノウハウ 14
- 15. 解決したいこと • まずはiOSにフォーカス • 致命的なクラッシュはリリース前に検知したい • 主要画⾯面は網羅羅してテストしたい • 古いOSでのテストも実⾏行行したい • iOS9対応に間に合うようにしたい 15
- 16. ⾃自動テストツールの選択 • UI Automation • UI Testing • Appium • Calabash-‐‑‒iOS • KIF • Remote TestKit 16
- 17. ⾃自動テストツールの選択 • UI Automation • UI Testing • Appium • Calabash-‐‑‒iOS • KIF • Remote TestKit 17
- 19. Appiumを選択した理理由(1) • OSSの更更新頻度度が⾼高い • 企業サポートも付いているため、将来性がある • ライセンスが社内でも使い易易い • -‐‑‒>Apache License, Version 2.0 19
- 20. Appiumを選択した理理由(2) • クライントが複数⾔言語に対応している • GUIツールがわかりやすくインスペクターがある • iOS、Android両⽅方対応している • テスト対象のアプリには⼿手を加える必要がない 20
- 21. 他のツールについて UI Automation • ⾔言語がJS固定 、instrument上での作業に慣れが必要 • 実際はAppiumはこれを内部で利利⽤用しているラッパー 21
- 22. 他のツールについて UI Testing • まだ実装間もないため、ノウハウが蓄積されておら ず、機能的にもまだ不不⼗十分。 • 新製品の宿命であるバグの懸念念があった 22
- 23. Calabash-‐‑‒iOS • Xpath取得のために都度度コマンドを叩く必要がある • 開発がほぼ⽌止まっており、iOS９サポートなどが期待で きなかった • 公式リファレンスが不不⼗十分であり、込み⼊入ったことす るためにはソースを読む必要がある 23 他のツールについて
- 24. KIF • objective-‐‑‒cで書けるためiOSエンジニアのみが使う場合 は良良いが、Androidエンジニアにはハードルが⾼高い • 公式リファレンスが不不⼗十分であり、込み⼊入ったことする ためにはソースを読む必要がある • nameで指定されていないと取れない. xpath で取るため の⽅方法が不不明 24 他のツールについて
- 25. Remote TestKit • テストフレームワークではないが、クラウド系に代表されるテス ト環境ツール • これだけあっても⾃自動化はできない. テスト実⾏行行＋テスト環境を 揃える必要がある • 実⾏行行モジュールを外部へ⼀一時的に送ることになるため、社内フ ローを作るところから始める必要があり、ミニマムスタートにそ ぐわない 25 他のツールについて
- 26. テストコードの⾔言語の選択 • Java • JavaScript(Node.js) • Python • Ruby • Perl • PHP 26
- 27. テストコードの⾔言語の選択 • Java • JavaScript(Node.js) • Python • Ruby • Perl • PHP 27
- 28. Pythonを選択 • チーム内で話し合って決定 • 経験者が多かった • 誰が書いても読みやすそう • とりあえずPythonでやってみよう 28
- 29. 対象画⾯面の決定 • 全画⾯面を対応するのは⾮非現実的 • 主要機能の画⾯面から優先度度をつけて対応 • -‐‑‒>出品、⼊入札、検索索など 29
- 36. ⾃自動テストの概要 36 github Mac ファイルサーバ シミュレータ 社内チャットツール (3-‐‑‒3)XMLを解析し、 表⽰示されている要素に対し、 クリックやテキスト⼊入⼒力力を⾏行行う
- 37. ⾃自動テストの概要 37 github Mac ファイルサーバ シミュレータ 社内チャットツール (3-‐‑‒1)シミュレータのスクリーン ショットをファイルサーバに保存 (3-‐‑‒2)Appiumでシミュレーターに 表⽰示されているXMLを取得 (3-‐‑‒3)XMLを解析し、表⽰示されている要素に対し、 クリックやテキスト⼊入⼒力力を⾏行行う (4)(3-‐‑‒1)〜～(3-‐‑‒3)を繰り返す
- 39. 開発時の苦労話(1) • Appiumが不不安定 • -‐‑‒>UI要素の取得に失敗することが多々ある • -‐‑‒>マシンによっては処理理の同期が取れず、テスト失 敗してしまうことがある → ⾃自前で同期処理理を書いて 対応 39
- 40. 開発時の苦労話(2) • デバッグに時間がかかる • アプリのUI要素にIDが振られていなかったので、１つ １つxpathを取得する作業が⼤大変 • 画⾯面の修正が⼊入ると、xpathが変わってしまう可能性 があり、その度度に修正が必要 → 覚悟はしていたがやっ ぱり⼤大変 40
- 41. 開発時の苦労話(3) • Pythonでの実装が結構⼤大変 • -‐‑‒>unit testのドキュメントが少なく、実装⽅方法を試 ⾏行行錯誤 • -‐‑‒>デバッグしやすい⾔言語、使⽤用するライブラリのド キュメントが豊富な⾔言語等がないか、もう少し検討す るべきだった？ 41
- 42. 開発時の苦労話(4) • Pythonでの実装が結構⼤大変 • -‐‑‒>結局⾃自分たちで「Appiumサーバー+unit test」の フレームワークを作ることになった • -‐‑‒>メタプログラミングをサポートしている⾔言語を使 うことで、ある程度度内部処理理を抽象化できた→ソース コードの可読性◯ 42
- 43. 開発時の苦労話(5) • iOS9で、アラートダイアログやキーボード⼊入⼒力力の xpath構造が変更更されてしまった → 該当箇所を全て修 正 • AppiumのiOS9の対応が遅く(1週間程度度)、iOS9リ リース前に直接appiumのライブラリを修正しないとい けなかった 43
- 44. 3.導⼊入後の結果 44
- 45. 解決したかったことのおさらい • まずはiOSにフォーカス • 致命的なクラッシュはリリース前に検知したい • 主要画⾯面は網羅羅してテストしたい • 古いOSでのテストも実⾏行行したい • iOS9対応に間に合うようにしたい 45
- 52. 現状の運⽤用 • 毎⽇日1回定期実⾏行行 • ⽇日々更更新される開発⽤用ブランチが対象 • リリース前はリリース⽤用ブランチを対象に実⾏行行 • テストに失敗した場合 • 理理由はすぐに調査 • プロダクトバックログに積んでスプリント内で解消 52
- 53. 4.今後の予定 53
- 54. 今後の予定 • CIツールとの連携 • ⾃自動テストのバリエーションを増やす • 任意タイミング/任意リポジトリ/任意シナリオ… • 処理理の⾼高速化/並列列化 • Androidについても対応を進める(Espresso) 54
- 55. まとめ • ⽀支援という形で背中を押していただくことがきっかけ • 形になるまでは試⾏行行錯誤の連続 • ⼿手動によるテスト+毎⽇日の⾃自動テスト = 安⼼心 • より恩恵を受けるための作業はまだ沢⼭山ある • 今回の事例例を、導⼊入のネタとして使ってください:) 55
- 56. 56 ⼀一緒に働く仲間募集中！