Android Testing Bootcamp #1 の発表資料です。
受託開発プロジェクトでAppiumによるテスト⾃動化を試す2016.3.23@sumio_tym (TOYAMA Sumio)1Android Testing Bootcamp #1
View Slide
⾃⼰紹介• ⽒名: 外⼭ 純⽣ (TOYAMA Sumio)@sumio_tym (Twitter) / @sumio (GitHub)• 所属: NTTソフトウェア株式会社• 業務内容:社内Android関連プロジェクトの技術⽀援• プライベート:• STAR(テスト⾃動化研究会)• @IT連載「スマホ向け無料システムテスト⾃動化ツール」uiautomator/Appiumの回を書きましたhttp://www.atmarkit.co.jp/ait/kw/smapho_testtool.html2
お話しすることAndroidアプリの受託開発プロジェクトで、Appiumによるテスト⾃動化を試してみました。その時に得られた知⾒を共有します。3
話の流れ1. 背景と⽬的2. 試⾏対象プロジェクトについて3. やってみたこと4. 得られた知⾒• コスト⾯• その他5. まとめ4
話の流れ1. 背景と⽬的2. 試⾏対象プロジェクトについて3. やってみたこと4. 得られた知⾒• コスト⾯• その他5. まとめ5
背景受託開発プロジェクトでは？(定型的なテストを⼿動でやるのはダルい)6勉強会で聴くシステムテスト⾃動化事例:⾃社プロダクト/サービスの話がほとんど
システムテスト⾃動化で良く⾔われること「繰り返しテストする項⽬を⾃動化しないと意味がない」追加開発が⾒込めるなら意味がありそう「⾃動化コストの⼤部分を占めるのは、テストスクリプト実装コスト・メンテナンスコスト」まずは、メンテナンスしやすさに気をつけて実装したときの、実装コストを計測してみよう7
試⾏の⽬的• 試⾏を通じて、以下の知⾒を得る• どれくらい繰り返せばペイするのか？• テストを書くときに気を付けるべきことは何か？ターゲット:複数回の機能追加が⾒込める受託開発プロジェクト⾃動化対象:正常系の画⾯遷移確認(毎回確実に実施する)※回帰テストの⾃動化は諸事情によりパス8
話の流れ1. 背景と⽬的2. 試⾏対象プロジェクトについて3. やってみたこと4. 得られた知⾒• コスト⾯• その他5. まとめ9
プロジェクト概要• ⾳声認識・⾳声読み上げ機能を使ったAndroidアプリ (Android 4.3向け)• 「設定画⾯」の追加を⾏う⼩規模なプロジェクト※前回納品時に基本機能は全て完成済み• 正式なテストは全て⼿動テスト※⾃動化した項⽬も含めて全て⼿動で実施10
アプリの画⾯遷移11ログインダイアログ起動モード選択チュートリアルチュートリアルチュートリアルチュートリアル①〜④メイン画⾯(⾳声認識・読み上げ機能)設定画⾯戻る 次へ設定左右スワイプでも①〜④間の移動が可能ImageButtonを押して選択
⾃動化に使ったツール• Appium 1.4.13http://appium.io/• 使⽤⾔語: Java12
⾃動化の体制13開発プロジェクトテストコード実装(Androidエンジニア)外⼭(技術⽀援)レクチャーテストの⼀部実装Appium初⼼者
話の流れ1. 背景と⽬的2. 試⾏対象プロジェクトについて3. やってみたこと4. 得られた知⾒• コスト⾯• その他5. まとめ14
教育1. ミニ勉強会 (2時間)@ITの記事を教材にポイントを絞って解説2. 環境構築・⾃習 (6時間)記事のサンプルアプリを元に動かしてみる3. ペア作業 (2時間)PageObjectパターンを意識して1つテストを書く• Pageの分割例• 遷移先ページが異なる場合は別メソッドに• etc.15
(補⾜)Page Objectパターンhttps://github.com/SeleniumHQ/selenium/wiki/PageObjects• 1画⾯(Page)＝1クラス• その画⾯でできる「ユーザーにとって意味のある操作」をメソッドとして定義• テストスクリプト側は、ここで定義したメソッドのみ使う• クラス＝メソッドの集合• 「操作できること」が変わるなら、同⼀画⾯でも別クラスにした⽅が良い• ダイアログ• Navigation Drawer• etc.16
設定画⾯⾃動化範囲のピックアップ• ⼿動で⾏うテスト項⽬表から、以下をピックアップ• 新しく作った「設定画⾯」内正常系シナリオ• 既存機能の画⾯遷移正常系シナリオ(⾳声認識・読み上げ系は除外)17ログインダイアログ起動モード選択チュートリアルチュートリアルチュートリアルチュートリアル①〜④メイン画⾯設定画⾯戻る 次へ設定※ 部分を⾃動化
テスト実装• Page分割⽅針を決めて、ひたすらテストを書く• 同じPageを複数⼈で担当しないように⼯夫• 「設定画⾯」係と「その他」で分担18
話の流れ1. 背景と⽬的2. 試⾏対象プロジェクトについて3. やってみたこと4. 得られた知⾒• コスト⾯• その他5. まとめ19
得られた知⾒(コスト⾯) (1/2)20前提: 以下のコストはゼロとみなす• ⾃動化の初期費⽤(学習コスト、マシン購⼊費⽤など)• ⾃動テストの実施コスト(無⼈でも実⾏できるため)⽐較対象• ⼿動テストの実施コスト(稼働)[⼈時]• ⾃動テストの開発コスト(稼働)[⼈時]結果テスト件数(カバレッジ)⼿動テスト実施コスト⾃動テスト開発コスト⾃動÷⼿動今回の⾃動化範囲 51件 (5.8%) 1.0h 14.0h 14.0⾃動化後14回テストしないとペイしない！
得られた知⾒(コスト⾯) (2/2)• 少しの改造で、更に⾃動化できる箇所を抽出• ⾃動化済みの操作の組み合わせだけで実現できるもの(Page Object実装は変更不要)• 新しく⾃動化が必要な操作が1つだけで済むもの• 抽出したテスト項⽬の⾃動化コストを⾒積ってみた21テスト件数(カバレッジ)⼿動テスト実施コスト⾃動テスト開発コスト⾃動÷⼿動今回の⾃動化範囲 51件 (5.8%) 1.0h 14.0h 14.0更に範囲を広げた場合(※)656件 (74.5%) 9.0h 24.0h 2.67⾃動化後3回テストすればペイする(はず)※本当にそうなるかは、次回計測してみます。
得られた知⾒(その他)① (1/2)ImageButtonの操作が⾟い• 操作対象コンポーネントの識別に使いやすいもの• text (表⽰⽂字列)• hint• contentDescription• リソースID ※Android 4.4以降のみ• どれも無いと「左からn個⽬のImageButton」といったUI変更に弱い条件にせざるを得ない22操作対象コンポーネントには、どれか1つは値を設定しておくと楽できる
得られた知⾒(その他)① (2/2)コンポーネントの識別に使うのはどれが良いか?23開発者が勝⼿に付けてOK?対応APItext (表⽰⽂字列) × 制限なしhint (EditText未⼊⼒時のヒント) × 制限なしcontentDescription(⾳声読み上げに利⽤)× 制限なしリソースID (R.id.xxxx) ○ 19以上• API 19以上: 操作しそうなものにリソースIDをつければOK• API 19未満: UI/UX検討時点でcontentDescriptionまで考えておく(後から付けるのは困難)
得られた知⾒(その他)②テストを書く⼤変さの度合い(⼤変な順)1. 新しい(⾃動化していない)画⾯の実装2. ⾃動化済み画⾯の、新しい操作の実装3. ⾃動化済み画⾯/操作の組み合わせでOKのもの⾃動化対象は、以下の⽅針で抽出するのが良さそう1. ⽬的を達成する最低限の項⽬を抽出する2. 「1」で操作する画⾯遷移内で確認できる項⽬まで⼿を広げる24※Page Objectパターンで実装する前提です。
まとめ• 受託開発プロジェクトでAppiumによるテスト⾃動化を試⾏してみました• ⾊々⼯夫すれば、現実的な繰り返し回数で初回コストは回収できそう• コンポーネントを識別できるようにする⼯夫(設計時から検討が必要なもの有り)• テスト項⽬抽出の⼯夫(画⾯数を増やさずに可能な範囲で⾃動化する)• Page Objectデザインパターンの適⽤• 今回試せなかったことも• メンテナンスコストを考えたときにペイするのか？• 回帰テスト⾃動化に⼿を出すとどうなるのか？25
26ご清聴ありがとうございましたご質問・コメント歓迎です！
sumio
kentosuzuki
masashi_sutou
shimashima35
lmi
sbtechnight
udzura
dena_tech
carta_engineering
nomu
megabitsenmzq
uzulla
marcelosomers
smashingmag
phodgson
tanoku
chriscoyier
edds
aarron
skipperchong
cassininazir
nonsquared
morganepeng