Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
受託開発プロジェクトでAppiumによるテスト自動化を試す / Appium Trial...
Search
TOYAMA Sumio
March 23, 2016
Technology
1
1.9k
受託開発プロジェクトでAppiumによるテスト自動化を試す / Appium Trial on Contracted Development
Android Testing Bootcamp #1
の発表資料です。
TOYAMA Sumio
March 23, 2016
Tweet
Share
More Decks by TOYAMA Sumio
See All by TOYAMA Sumio
Understand the mechanism! Let's do screenshots tests of Compose Previews with various variations / 仕組みから理解する!Composeプレビューを様々なバリエーションでスクリーンショットテストしよう
sumio
6
3.4k
Roborazziでスクリーンショットを撮るときに役立つTips集 / A collection of useful tips for taking screenshots in Roborazzi
sumio
2
5.2k
DroidKaigi 2022: Gradle Managed Virtual Devicesで変化するエミュレータ活用術
sumio
2
8.8k
DeNA TechCon 2021 - スマホ向けゲームの辛い部分をコード自動生成技術で克服する / Overcoming the Painful Part of Smartphone Games Development with Automatic Code Generation
sumio
0
540
Robolectricの限界を理解してUIテストを高速に実行しよう / Let's run UI Test faster with understanding limit of Robolectric
sumio
3
9k
EspressoではじめるAndroid UIテスト / Android UI Testing Starting with Espresso
sumio
2
2.4k
Espressoの知識ゼロでも書ける!Android UIテストはじめの一歩 / The First Step of Android UI Testing
sumio
1
8.3k
EspressoのテストをAndroidの最新トレンドに対応させよう / Make Espresso testing follow the cutting edge in Android development
sumio
3
18k
KotlinでEspressoテストがもっと書きやすくなるKakaoを試してみた / Trying Kakao which makes Espresso test easier to write
sumio
2
1k
Other Decks in Technology
See All in Technology
JAWS-UG 横浜支部 #76 AWS re:Invent 2024 宇宙一早い Recap LT3Amazon EKS Auto Modeと遊び(パーティ)の話
tjotjo
0
170
ソフトウェアエンジニアとしてキャリアの螺旋を駆け上がる方法 - 経験と出会いが人生を変える / Career-Anchor-Drive
soudai
13
3k
2024/12/05 AITuber本著者によるAIキャラクター入門 - AITuberの基礎からソフトウェア設計、失敗談まで
sr2mg4
2
600
ナレッジベースはどのようにSQLを生成するのか / Knowledge Bases supports structed data retrieval
hayaok3
2
180
ネットワークの Microsoft MVP だけど、SASE が万能すぎてもう俺いらなくね?
skmkzyk
0
170
10分で学ぶKubernetesコンテナセキュリティ/10min-k8s-container-sec
mochizuki875
1
120
ABEMA スマートテレビアプリケーションのパフォーマンス改善 〜業界トップクラスを目指して〜 / Performance Improvements on ABEMA Smart TV App
nodaguti
0
250
Kubernetes環境のオブザーバビリティの次の一歩をOpenTelemetryで実現すると何がどうなるの? - CloudNative Days Winter 2024
katzchang
0
120
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
muziyoshiz
1
110
B10-ひと目でわかる(といいなぁ)Microsoft Purview
seafay
PRO
0
660
『GRANBLUE FANTASY: Relink』続・最高の「没入感」を実現するカットシーン制作手法とそれを支える技術
cygames
0
100
イベントをどう管理するか
mikanichinose
1
120
Featured
See All Featured
Designing for Performance
lara
604
68k
Code Reviewing Like a Champion
maltzj
520
39k
BBQ
matthewcrist
85
9.3k
Rails Girls Zürich Keynote
gr2m
94
13k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
95
17k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Navigating Team Friction
lara
183
15k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
Unsuck your backbone
ammeep
669
57k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.8k
Transcript
受託開発プロジェクトで Appiumによるテスト⾃動化を試す 2016.3.23 @sumio_tym (TOYAMA Sumio) 1 Android Testing Bootcamp
#1
⾃⼰紹介 • ⽒名: 外⼭ 純⽣ (TOYAMA Sumio) @sumio_tym (Twitter) / @sumio
(GitHub) • 所属: NTTソフトウェア株式会社 • 業務内容: 社内Android関連プロジェクトの技術⽀援 • プライベート: • STAR(テスト⾃動化研究会) • @IT連載「スマホ向け無料システムテスト⾃動化ツール」 uiautomator/Appiumの回を書きました http://www.atmarkit.co.jp/ait/kw/smapho_testtool.html 2
お話しすること 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.13 http://appium.io/ • 使⽤⾔語: Java 12
⾃動化の体制 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? 対応API text (表⽰⽂字列) ×
制限なし 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 ご清聴ありがとうございました ご質問・コメント歓迎です!