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
Roborazziでスクリーンショットを撮るときに役立つTips集 / A collection of useful tips for taking screenshots in Roborazzi
sumio
2
3.5k
DroidKaigi 2022: Gradle Managed Virtual Devicesで変化するエミュレータ活用術
sumio
2
8.5k
DeNA TechCon 2021 - スマホ向けゲームの辛い部分をコード自動生成技術で克服する / Overcoming the Painful Part of Smartphone Games Development with Automatic Code Generation
sumio
0
520
Robolectricの限界を理解してUIテストを高速に実行しよう / Let's run UI Test faster with understanding limit of Robolectric
sumio
3
8.7k
EspressoではじめるAndroid UIテスト / Android UI Testing Starting with Espresso
sumio
2
2.3k
Espressoの知識ゼロでも書ける!Android UIテストはじめの一歩 / The First Step of Android UI Testing
sumio
1
7.7k
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
Espressoテストコードの同期処理を究める / Synchronization capabilities of Espresso
sumio
6
6.5k
Other Decks in Technology
See All in Technology
データウェアハウス製品のSnowflakeでPythonが動くって知ってました?
foursue
1
150
Datadog を使ったプロダクトとクラウドの セキュリティモニタリング
mrtc0
0
450
Azure SQL Database Hyperscale HA レプリカの監視
sansantech
PRO
0
190
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
520
Evolving DevOps Teams and Flexible Organizational Culture
kakehashi
1
130
Autonomous Database Cloud 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
15
39k
音声AIエージェントの世界とRetell AI入門 / Introduction to the World of Voice AI Agents and Retell AI
rkaga
3
470
バックログを導入し やっぱやめた話
ota42y
0
170
OCI コスト管理
ocise
1
110
20240906_JAWS_Yamanashi_#1_leap_beyond_the_AWS_all_certifications
tsumita
1
100
Chunk computing
matyo91
0
270
Javaにおける関数型プログラミンへの取り組み
skrb
5
110
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
35
6.9k
The Pragmatic Product Professional
lauravandoore
30
6.2k
Debugging Ruby Performance
tmm1
72
12k
Adopting Sorbet at Scale
ufuk
72
8.9k
Building Flexible Design Systems
yeseniaperezcruz
324
37k
The World Runs on Bad Software
bkeepers
PRO
64
11k
Typedesign – Prime Four
hannesfritz
38
2.3k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
What the flash - Photography Introduction
edds
67
11k
Robots, Beer and Maslow
schacon
PRO
157
8.1k
Clear Off the Table
cherdarchuk
90
320k
No one is an island. Learnings from fostering a developers community.
thoeni
18
2.9k
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 ご清聴ありがとうございました ご質問・コメント歓迎です!