Transcript

• 1. テストの種類とBDD 2015.02.28 モバイル向けテスト手法勉強会 at Sansan株式会社 @nowsprinting / Koji Hasegawa
• 2. 自己紹介 • id: @nowsprinting • フリーランス
 （iOS/Androidアプリ受託開発） • アプリ『山吹色の茸疾走』『フットサル ルールと雑学』
 『電エースQuiz - 河崎実監督と特撮映画の世界』 • コミュニティ：
 テスト自動化研究会、Androidテスト部、VR部
• 3. 著書
• 4. アジェンダ • テストの目的 • テストの種類（テストレベル、テストタイプ） • UIを操作するテスト • BDD(Behavior Driven Development)
• 5. テストの目的
• 6. テストの目的 • 欠陥を摘出する • 対象ソフトウェアの品質レベルが十分であることを 確認する • 意志決定のための情報を示す • 欠陥の作りこみを防ぐ 『ISTQB ソフトウェアテスト標準用語集 日本語版』より引用
• 7. テストの目的 • 欠陥を摘出する • 対象ソフトウェアの品質レベルが十分であることを 確認する • 意志決定のための情報を示す • 欠陥の作りこみを防ぐ 『ISTQB ソフトウェアテスト標準用語集 日本語版』より引用 ←これだけではない
• 8. テストレベル
• 9. V字モデル
• 10. テストレベル
• 11. テストレベル テスト工程
• 12. テストレベル テスト工程 結合度
• 13. テストレベル 開発者 QA 顧客 誰が実施するかで区切る、と考える
• 14. ユニットテストについて • ユニットテスト==ホワイトボックステスト、とは限らない • 機能テスト：テスト対象が「何をするのか」を機能仕様 に基づいてテストする • 性能テスト：このレベルで処理時間を測定・評価できる ようにしておく • 原則自動化すべき。でも無理に全部やらない（カバレッジ を追わない）。
• 15. システムテスト • アプリを端末にインストールし、UIを操作する（リリー スビルド、proguard） • サーバと通信する場合、ステージングもしくはプロダ クション環境を使用する（End to End） • 一般に、独立したテストチーム（QA）が行なう • 機能要件、非機能要件を満たしているか、多角的に検 証を行なう （ISTQBにおける定義）
• 16. 受け入れテスト • アプリが要求仕様（ユーザのニーズ）を満たしてい ることを確認する • 出荷判断を行なうプロダクトオーナーや、受託開発 の場合は顧客が行なう（UAT） • B to Cの場合、アルファテスト、ベータテストもこ こに分類される （ISTQBにおける定義）
• 17. テストレベルについて • 考え方であり、厳密に全部分類・実施するものでは ない（モバイルアプリは小規模なので） • 視点（誰が実施すべきか、誰のためのテストか）は 意識したほうが良い。
• 18. テストタイプ
• 19. テストタイプの例 • 機能テスト（機能仕様に基づいたテスト）、
 ユースケーステスト、シナリオテスト • 確認テスト（修正後の動作を確認する）、
 回帰テスト（リグレッションテスト。エンハンスバ グが無いことの確認、複数OS・機種での動作） • 使用性（ユーザビリティ）テスト、性能テスト、
 信頼性テスト、etc…
• 20. テストタイプ • テスト活動をまとめたもの • たとえば機能テスト、使用性テスト、回帰テストな どのように特定のテスト目的に焦点を当てたもの • 一つ又は複数のテストレベルで行なわれる 『ISTQB ソフトウェアテスト標準用語集 日本語版』より引用
• 21. 自動化に向くテストタイプ • ユニットテスト • 統合テスト（インタフェースに着目したテスト） • システムレベルの機能テスト • 性能テスト 『TABOK Guidebook』より
• 22. テストレベル（結合度）と自動化 • 下層ほど自動化しやすい
 テストダブル（スタブ、モック）の使用、UIからは 指定できないパラメタなど。 • UIを操作するテストは、実行時間が多め。また、UI 変更によるメンテナンスコストが嵩む傾向にある。 • システムテスト（End to End）では、日時、天気、 株価、為替、乱数などがあると成否判定は困難
• 23. UIを操作するテスト
• 24. UIを操作するテスト • 様々な呼ばれ方 • テストツールなどで Functional test • End to End test • BDD（振る舞い）のテスト、受け入れテスト
• 25. UIを操作するテスト • 判定方法の違い • スクリーンショットを比較・判定する（monkey runner, Sikuli, 目grep, アニメGIF） • DOMツリー（ヒエラルキー）を って、特定の コンポーネントの状態・属性を判定する
 （ほとんどのテスティングフレームワークがこれ）
• 26. UIを操作するテスト • 判定方法の違い • スクリーンショットを比較・判定する（monkey runner, Sikuli, 目grep, アニメGIF） • DOMツリー（ヒエラルキー）を って、特定の コンポーネントの状態・属性を判定する
 （ほとんどのテスティングフレームワークがこれ） • レイアウト崩れまで評価できる（ユーザビリティ テストの領域？） • UIの変更にとても弱い（メンテナンスコストが かかる）
• 27. UIを操作するテスト • 判定方法の違い • スクリーンショットを比較・判定する（monkey runner, Sikuli, 目grep） • DOMツリー（ヒエラルキー）を って、特定の コンポーネントの状態・属性を判定する
 （ほとんどのテスティングフレームワークがこれ） • UIの変更に比較的強い • レイアウト崩れ、文字のトランケートなどは判 定できない（機能テストに絞る）
• 28. UIを操作するテスト • 自動化テスティングフレームワークの分類 • 統合テスト：
 KIF, Robotium, Espresso • システムテスト：
 UI Automation, uiautomator, Calabash, Appium, MonkeyTalk, etc…
• 29. UIを操作するテスト • 自動化テスティングフレームワークの分類 • 統合テスト：
 KIF, Robotium, Espresso • システムテスト：
 UI Automation, uiautomator, Calabash, Appium, MonkeyTalk, etc… • テストダブルを利用するなど、自由度が高い • 比較的高速 • End to Endの「安心感」は得られない
• 30. UIを操作するテスト • 自動化テスティングフレームワークの分類 • 統合テスト：
 KIF, Robotium, Espresso • システムテスト：
 UI Automation, uiautomator, Calabash, Appium, MonkeyTalk, etc… • 厳密なシナリオテストは困難（不可能ではないが、 テストが複雑になるとメンテナンスも困難） • 実行時間がかかる（項目数を減らしたい）
• 31. UIテストの自動化にあたって • 機能テストに絞る。困難であればスモークテスト • レイアウトはスクリーンショットを目視など • ユーザビリティは人間が触って評価すべき • 自動化しても、実行時間はゼロではない • 複雑なテストを書けば、メンテナンスも大変。
 メンテなしで長く使いまわせるテストを目指す
• 32. 機種依存について • 機種依存とは何か、を考えなおす • 機種固有のバグ：テスト以前に回避する作りにす べきで、テストで見つけようと考えない • OS・解像度のフラグメンテーション：レイアウ ト崩れは、スクリーンショットを目視で判断
• 33. テスト自動化に関する情報 • テスト自動化研究会
 https://sites.google.com/site/testautomationresearch/ • テスト自動化パターン言語プロジェクト
 https://github.com/KenColle/AutomationPatternLanguage
• 34. テスト自動化パターン言語プロジェクト（一部） ©2014 .reviewrc
• 35. BDD
• 36. BDD(振る舞い駆動開発) • Behavior Driven Development • 元々の考え方はTDD • TDDの適用範囲が当初より縮小され、ユニットテ ストだけを指すようになったため改めて提唱された • ATDD(Acceptance TDD)も同様の背景で生まれ、 現在では同義語としていい（はず）
• 37. BDDの特徴 • Feature（機能を実現するテストシナリオ）を先に 定義し、それを満たす実装を行なう • Featureは可読性が高く、「動くドキュメント」と して関係者がレビューできるものになる • Featureはユースケースの粒度で書かれる ※Scenario BDDの話であり、Spec BDDには触れません
• 38. Featureの例（1/2） Feature: 顧客を追加できること。一覧画面では氏名とマーケティング区分が表示されること Scenario: "Add"ボタンをタップすると顧客を1件追加し、編集画面に遷移する Given I launch the app When I touch the button marked "Add" Then I wait to see a navigation bar titled "Detail"
• 39. Featureの例（2/2） Scenario: 顧客は男性・35歳に設定。一覧に戻ると、マーケティング区分はM2層となること Given I should see a navigation bar titled "Detail" When I type "Newton Geizler" into the "name" text field using the keyboard And I select gender to "男性" And I select age to "35" And I navigate back Then I wait to see a navigation bar titled "Master" And I should see a cell name "Newton Geizler" and division "M2層"
• 40. Featureの例（2/2） Scenario: 顧客は男性・35歳に設定。一覧に戻ると、マーケティング区分はM2層となること Given I should see a navigation bar titled "Detail" When I type "Newton Geizler" into the "name" text field using the keyboard And I select gender to "男性" And I select age to "35" And I navigate back Then I wait to see a navigation bar titled "Master" And I should see a cell name "Newton Geizler" and division "M2層" Given, When, Thenで表現する
• 41. Featureの例（2/2） Scenario: 顧客は男性・35歳に設定。一覧に戻ると、マーケティング区分はM2層となること Given I should see a navigation bar titled "Detail" When I type "Newton Geizler" into the "name" text field using the keyboard And I select gender to "男性" And I select age to "35" And I navigate back Then I wait to see a navigation bar titled "Master" And I should see a cell name "Newton Geizler" and division "M2層" 各ステップで実際にどうアプリを操作するかは Stepファイル に記述される
• 42. Featureの例（3/3） Scenario Outline: 顧客をn件追加する (snip) When I type "<name>" into the "name" text field using the keyboard And I select gender to "<gender>" And I select age to "<age>" And I navigate back Then I wait to see a navigation bar titled "Master" And I should see a cell name "<name>" and division "<division>" Examples: ¦ name ¦ gender ¦ age ¦ division ¦ ¦ Newton Geizler ¦ 男性 ¦ 35 ¦ M2層 ¦ ¦ Hermann Gottlieb¦ 男性 ¦ 34 ¦ M1層 ¦ ¦ Mako Mori ¦ 女性 ¦ 22 ¦ F1層 ¦
• 43. BDDについての情報 • @IT連載『いまさら聞けないTDD/BDD超入門』
 http://www.atmarkit.co.jp/ait/kw/tdd_bdd.html • 同『スマホ向け無料システムテスト自動化ツール』
 http://www.atmarkit.co.jp/ait/kw/smapho_testtool.html • 第4回∼Calabash
• 44. まとめ
• 45. まとめ • 「テスト」は意外と広く、多角的 • そのうち、自動化が効果的なものを狙って自動化す るべき
 （機械が得意なものは機械、人間が得意なものは人間がやる） • テストコードは「動くドキュメント」を目指す