テストの種類とbdd #33testing

テストの種類とBDD

2015.02.28 モバイル向けテスト手法勉強会 at Sansan株式会社 @nowsprinting / Koji Hasegawa

自己紹介• id: @nowsprinting

• フリーランス（iOS/Androidアプリ受託開発）

• アプリ『山吹色の茸疾走』『フットサルルールと雑学』『電エースQuiz - 河崎実監督と特撮映画の世界』

• コミュニティ：テスト自動化研究会、Androidテスト部、VR部

著書

アジェンダ

• テストの目的

• テストの種類（テストレベル、テストタイプ）

• UIを操作するテスト

• BDD(Behavior Driven Development)

テストの目的

テストの目的• 欠陥を摘出する

• 対象ソフトウェアの品質レベルが十分であることを確認する

• 意志決定のための情報を示す

• 欠陥の作りこみを防ぐ

『ISTQB ソフトウェアテスト標準用語集日本語版』より引用

テストの目的• 欠陥を摘出する

• 対象ソフトウェアの品質レベルが十分であることを確認する

• 意志決定のための情報を示す

• 欠陥の作りこみを防ぐ


←これだけではない

テストレベル

V字モデル

テストレベル

テストレベル

テスト工程

テストレベル

テスト工程

結合度

テストレベル

開発者

QA

顧客

誰が実施するかで区切る、と考える

ユニットテストについて• ユニットテスト==ホワイトボックステスト、とは限らない

• 機能テスト：テスト対象が「何をするのか」を機能仕様に基づいてテストする

• 性能テスト：このレベルで処理時間を測定・評価できるようにしておく

• 原則自動化すべき。でも無理に全部やらない（カバレッジを追わない）。

システムテスト• アプリを端末にインストールし、UIを操作する（リリースビルド、proguard）

• サーバと通信する場合、ステージングもしくはプロダクション環境を使用する（End to End）

• 一般に、独立したテストチーム（QA）が行なう

• 機能要件、非機能要件を満たしているか、多角的に検証を行なう

（ISTQBにおける定義）

受け入れテスト• アプリが要求仕様（ユーザのニーズ）を満たしていることを確認する

• 出荷判断を行なうプロダクトオーナーや、受託開発の場合は顧客が行なう（UAT）

• B to Cの場合、アルファテスト、ベータテストもここに分類される

（ISTQBにおける定義）

テストレベルについて

• 考え方であり、厳密に全部分類・実施するものではない（モバイルアプリは小規模なので）

• 視点（誰が実施すべきか、誰のためのテストか）は意識したほうが良い。

テストタイプ

テストタイプの例• 機能テスト（機能仕様に基づいたテスト）、ユースケーステスト、シナリオテスト

• 確認テスト（修正後の動作を確認する）、回帰テスト（リグレッションテスト。エンハンスバグが無いことの確認、複数OS・機種での動作）

• 使用性（ユーザビリティ）テスト、性能テスト、信頼性テスト、etc…

テストタイプ• テスト活動をまとめたもの

• たとえば機能テスト、使用性テスト、回帰テストなどのように特定のテスト目的に焦点を当てたもの

• 一つ又は複数のテストレベルで行なわれる


自動化に向くテストタイプ

• ユニットテスト

• 統合テスト（インタフェースに着目したテスト）

• システムレベルの機能テスト

• 性能テスト

『TABOK Guidebook』より

テストレベル（結合度）と自動化• 下層ほど自動化しやすいテストダブル（スタブ、モック）の使用、UIからは指定できないパラメタなど。

• UIを操作するテストは、実行時間が多め。また、UI変更によるメンテナンスコストが嵩む傾向にある。

• システムテスト（End to End）では、日時、天気、株価、為替、乱数などがあると成否判定は困難

UIを操作するテスト

UIを操作するテスト

• 様々な呼ばれ方

• テストツールなどで”Functional test”

• End to End test

• BDD（振る舞い）のテスト、受け入れテスト

UIを操作するテスト• 判定方法の違い

• スクリーンショットを比較・判定する（monkey runner, Sikuli, 目grep, アニメGIF）

• DOMツリー（ヒエラルキー）を辿って、特定のコンポーネントの状態・属性を判定する（ほとんどのテスティングフレームワークがこれ）


• スクリーンショットを比較・判定する（monkey runner, Sikuli, 目grep, アニメGIF）


• レイアウト崩れまで評価できる（ユーザビリティテストの領域？） • UIの変更にとても弱い（メンテナンスコストがかかる）


• スクリーンショットを比較・判定する（monkey runner, Sikuli, 目grep）


• UIの変更に比較的強い • レイアウト崩れ、文字のトランケートなどは判定できない（機能テストに絞る）

UIを操作するテスト• 自動化テスティングフレームワークの分類

• 統合テスト：KIF, Robotium, Espresso

• システムテスト：UI Automation, uiautomator, Calabash, Appium, MonkeyTalk, etc…




• テストダブルを利用するなど、自由度が高い • 比較的高速 • End to Endの「安心感」は得られない




• 厳密なシナリオテストは困難（不可能ではないが、テストが複雑になるとメンテナンスも困難） • 実行時間がかかる（項目数を減らしたい）

UIテストの自動化にあたって• 機能テストに絞る。困難であればスモークテスト

• レイアウトはスクリーンショットを目視など

• ユーザビリティは人間が触って評価すべき

• 自動化しても、実行時間はゼロではない

• 複雑なテストを書けば、メンテナンスも大変。メンテなしで長く使いまわせるテストを目指す

機種依存について

• 機種依存とは何か、を考えなおす

• 機種固有のバグ：テスト以前に回避する作りにすべきで、テストで見つけようと考えない

• OS・解像度のフラグメンテーション：レイアウト崩れは、スクリーンショットを目視で判断

テスト自動化に関する情報

• テスト自動化研究会https://sites.google.com/site/testautomationresearch/

• テスト自動化パターン言語プロジェクトhttps://github.com/KenColle/AutomationPatternLanguage

https://sites.google.com/site/testautomationresearch/

https://github.com/KenColle/AutomationPatternLanguage

BDD(振る舞い駆動開発)• Behavior Driven Development

• 元々の考え方はTDD

• TDDの適用範囲が当初より縮小され、ユニットテストだけを指すようになったため改めて提唱された

• ATDD(Acceptance TDD)も同様の背景で生まれ、現在では同義語としていい（はず）

BDDの特徴• Feature（機能を実現するテストシナリオ）を先に定義し、それを満たす実装を行なう

• Featureは可読性が高く、「動くドキュメント」として関係者がレビューできるものになる

• Featureはユースケースの粒度で書かれる

※Scenario BDDの話であり、Spec BDDには触れません

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"

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で表現する



各ステップで実際にどうアプリを操作するかは “Stepファイル”に記述される

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層 |

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

http://www.atmarkit.co.jp/ait/kw/tdd_bdd.html

http://www.atmarkit.co.jp/ait/kw/smapho_testtool.html

まとめ

まとめ

• 「テスト」は意外と広く、多角的

• そのうち、自動化が効果的なものを狙って自動化するべき（機械が得意なものは機械、人間が得意なものは人間がやる）

• テストコードは「動くドキュメント」を目指す

テストの種類とbdd #33testing

Software