Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
テストの種類とBDD
2015.02.28 モバイル向けテスト手法勉強会 at Sansan株式会社
@nowsprinting / Koji Hasegawa
自己紹介
• id: @nowsprinting
• フリーランス

(iOS/Androidアプリ受託開発)
• アプリ『山吹色の茸疾走』『フットサル ルールと雑学』

『電エースQuiz - 河崎実監督と特撮映画の世界』
• コミュニティ:...
著書
アジェンダ
• テストの目的
• テストの種類(テストレベル、テストタイプ)
• UIを操作するテスト
• BDD(Behavior Driven Development)
テストの目的
テストの目的
• 欠陥を摘出する
• 対象ソフトウェアの品質レベルが十分であることを
確認する
• 意志決定のための情報を示す
• 欠陥の作りこみを防ぐ
『ISTQB ソフトウェアテスト標準用語集 日本語版』より引用
テストの目的
• 欠陥を摘出する
• 対象ソフトウェアの品質レベルが十分であることを
確認する
• 意志決定のための情報を示す
• 欠陥の作りこみを防ぐ
『ISTQB ソフトウェアテスト標準用語集 日本語版』より引用
←これだけではない
テストレベル
V字モデル
テストレベル
テストレベル
テスト工程
テストレベル
テスト工程
結合度
テストレベル
開発者
QA
顧客
誰が実施するかで区切る、と考える
ユニットテストについて
• ユニットテスト==ホワイトボックステスト、とは限らない
• 機能テスト:テスト対象が「何をするのか」を機能仕様
に基づいてテストする
• 性能テスト:このレベルで処理時間を測定・評価できる
ようにしておく
• 原則自...
システムテスト
• アプリを端末にインストールし、UIを操作する(リリー
スビルド、proguard)
• サーバと通信する場合、ステージングもしくはプロダ
クション環境を使用する(End to End)
• 一般に、独立したテストチーム(QA...
受け入れテスト
• アプリが要求仕様(ユーザのニーズ)を満たしてい
ることを確認する
• 出荷判断を行なうプロダクトオーナーや、受託開発
の場合は顧客が行なう(UAT)
• B to Cの場合、アルファテスト、ベータテストもこ
こに分類される
...
テストレベルについて
• 考え方であり、厳密に全部分類・実施するものでは
ない(モバイルアプリは小規模なので)
• 視点(誰が実施すべきか、誰のためのテストか)は
意識したほうが良い。
テストタイプ
テストタイプの例
• 機能テスト(機能仕様に基づいたテスト)、

ユースケーステスト、シナリオテスト
• 確認テスト(修正後の動作を確認する)、

回帰テスト(リグレッションテスト。エンハンスバ
グが無いことの確認、複数OS・機種での動作)
•...
テストタイプ
• テスト活動をまとめたもの
• たとえば機能テスト、使用性テスト、回帰テストな
どのように特定のテスト目的に焦点を当てたもの
• 一つ又は複数のテストレベルで行なわれる
『ISTQB ソフトウェアテスト標準用語集 日本語版』より...
自動化に向くテストタイプ
• ユニットテスト
• 統合テスト(インタフェースに着目したテスト)
• システムレベルの機能テスト
• 性能テスト
『TABOK Guidebook』より
テストレベル(結合度)と自動化
• 下層ほど自動化しやすい

テストダブル(スタブ、モック)の使用、UIからは
指定できないパラメタなど。
• UIを操作するテストは、実行時間が多め。また、UI
変更によるメンテナンスコストが嵩む傾向にある。
...
UIを操作するテスト
UIを操作するテスト
• 様々な呼ばれ方
• テストツールなどで Functional test
• End to End test
• BDD(振る舞い)のテスト、受け入れテスト
UIを操作するテスト
• 判定方法の違い
• スクリーンショットを比較・判定する(monkey
runner, Sikuli, 目grep, アニメGIF)
• DOMツリー(ヒエラルキー)を って、特定の
コンポーネントの状態・属性を判定する...
UIを操作するテスト
• 判定方法の違い
• スクリーンショットを比較・判定する(monkey
runner, Sikuli, 目grep, アニメGIF)
• DOMツリー(ヒエラルキー)を って、特定の
コンポーネントの状態・属性を判定する...
UIを操作するテスト
• 判定方法の違い
• スクリーンショットを比較・判定する(monkey
runner, Sikuli, 目grep)
• DOMツリー(ヒエラルキー)を って、特定の
コンポーネントの状態・属性を判定する

(ほとんどの...
UIを操作するテスト
• 自動化テスティングフレームワークの分類
• 統合テスト:

KIF, Robotium, Espresso
• システムテスト:

UI Automation, uiautomator, Calabash,
Appiu...
UIを操作するテスト
• 自動化テスティングフレームワークの分類
• 統合テスト:

KIF, Robotium, Espresso
• システムテスト:

UI Automation, uiautomator, Calabash,
Appiu...
UIを操作するテスト
• 自動化テスティングフレームワークの分類
• 統合テスト:

KIF, Robotium, Espresso
• システムテスト:

UI Automation, uiautomator, Calabash,
Appiu...
UIテストの自動化にあたって
• 機能テストに絞る。困難であればスモークテスト
• レイアウトはスクリーンショットを目視など
• ユーザビリティは人間が触って評価すべき
• 自動化しても、実行時間はゼロではない
• 複雑なテストを書けば、メンテ...
機種依存について
• 機種依存とは何か、を考えなおす
• 機種固有のバグ:テスト以前に回避する作りにす
べきで、テストで見つけようと考えない
• OS・解像度のフラグメンテーション:レイアウ
ト崩れは、スクリーンショットを目視で判断
テスト自動化に関する情報
• テスト自動化研究会

https://sites.google.com/site/testautomationresearch/
• テスト自動化パターン言語プロジェクト

https://github.com/K...
テスト自動化パターン言語プロジェクト(一部)
©2014 .reviewrc
BDD
BDD(振る舞い駆動開発)
• Behavior Driven Development
• 元々の考え方はTDD
• TDDの適用範囲が当初より縮小され、ユニットテ
ストだけを指すようになったため改めて提唱された
• ATDD(Acceptan...
BDDの特徴
• Feature(機能を実現するテストシナリオ)を先に
定義し、それを満たす実装を行なう
• Featureは可読性が高く、「動くドキュメント」と
して関係者がレビューできるものになる
• Featureはユースケースの粒度で書...
Featureの例(1/2)
Feature:
顧客を追加できること。一覧画面では氏名とマーケティング区分が表示されること
Scenario:
"Add"ボタンをタップすると顧客を1件追加し、編集画面に遷移する
Given I launch t...
Featureの例(2/2)
Scenario:
顧客は男性・35歳に設定。一覧に戻ると、マーケティング区分はM2層となること
Given I should see a navigation bar titled "Detail"
When I...
Featureの例(2/2)
Scenario:
顧客は男性・35歳に設定。一覧に戻ると、マーケティング区分はM2層となること
Given I should see a navigation bar titled "Detail"
When I...
Featureの例(2/2)
Scenario:
顧客は男性・35歳に設定。一覧に戻ると、マーケティング区分はM2層となること
Given I should see a navigation bar titled "Detail"
When I...
Featureの例(3/3)
Scenario Outline:
顧客をn件追加する
(snip)
When I type "<name>" into the "name" text field using the keyboard
And I ...
BDDについての情報
• @IT連載『いまさら聞けないTDD/BDD超入門』

http://www.atmarkit.co.jp/ait/kw/tdd_bdd.html
• 同『スマホ向け無料システムテスト自動化ツール』

http://ww...
まとめ
まとめ
• 「テスト」は意外と広く、多角的
• そのうち、自動化が効果的なものを狙って自動化す
るべき

(機械が得意なものは機械、人間が得意なものは人間がやる)
• テストコードは「動くドキュメント」を目指す
Upcoming SlideShare
Loading in …5
×

32

Share

Download to read offline

テストの種類とBDD #33testing

Download to read offline

【iOS/Android】最新事例から学ぶ!モバイル向けテスト手法勉強会 発表資料

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

テストの種類とBDD #33testing

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

    Feb. 15, 2020
  • tatsushikiryu

    Apr. 7, 2017
  • ssuser843b0e

    Mar. 12, 2017
  • kentoueda

    Jun. 17, 2016
  • h-nishijo

    Jan. 6, 2016
  • shoma2da

    Dec. 6, 2015
  • hasedge

    Oct. 16, 2015
  • nagaminehiromasa

    Sep. 24, 2015
  • ssuser0272f4

    Jul. 24, 2015
  • gilpa80

    Jul. 2, 2015
  • shinjiyamaguchi180

    Jun. 27, 2015
  • shogito

    Jun. 16, 2015
  • haru01

    Jun. 14, 2015
  • tsubasatakasaki

    Apr. 24, 2015
  • takehiroterashima5

    Mar. 8, 2015
  • ueharatakumi

    Mar. 5, 2015
  • MasaoTakahashi

    Mar. 4, 2015
  • libero_18

    Mar. 1, 2015
  • yosukekawano

    Mar. 1, 2015
  • a2c765

    Mar. 1, 2015

【iOS/Android】最新事例から学ぶ!モバイル向けテスト手法勉強会 発表資料

Views

Total views

15,153

On Slideshare

0

From embeds

0

Number of embeds

9,140

Actions

Downloads

23

Shares

0

Comments

0

Likes

32

×