テストの種類とBDD #33testing
33 likes15,641 views
テストの種類とBDD #33testing
- 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. テストレベル テスト工程 結合度
- 14. ユニットテストについて • ユニットテスト==ホワイトボックステスト、とは限らない • 機能テスト：テスト対象が「何をするのか」を機能仕様 に基づいてテストする • 性能テスト：このレベルで処理時間を測定・評価できる ようにしておく • 原則自動化すべき。でも無理に全部やらない（カバレッジ を追わない）。
- 15. システムテスト • アプリを端末にインストールし、UIを操作する（リリー スビルド、proguard） • サーバと通信する場合、ステージングもしくはプロダ クション環境を使用する（End to End） • 一般に、独立したテストチーム（QA）が行なう • 機能要件、非機能要件を満たしているか、多角的に検 証を行なう （ISTQBにおける定義）
- 16. 受け入れテスト • アプリが要求仕様（ユーザのニーズ）を満たしてい ることを確認する • 出荷判断を行なうプロダクトオーナーや、受託開発 の場合は顧客が行なう（UAT） • B to Cの場合、アルファテスト、ベータテストもこ こに分類される （ISTQBにおける定義）
- 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・解像度のフラグメンテーション：レイアウ ト崩れは、スクリーンショットを目視で判断
- 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層 ¦
- 44. まとめ
- 45. まとめ • 「テスト」は意外と広く、多角的 • そのうち、自動化が効果的なものを狙って自動化す るべき （機械が得意なものは機械、人間が得意なものは人間がやる） • テストコードは「動くドキュメント」を目指す