Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Selenium2でつくるテストケースの
構成について
2014/06/19
徳田 ゆい
なにを発表するの?
 最近、Selenium2 + Ruby + RSpec でブラウザ
テストの自動化に取り組んでます
 「ブラウザテスト」?
 ここでは「テスターがブラウザを操作して眼で結果
を確認する行為」という意味で使います
 ...
もくじ
 Selenium2って何?
 デモ
 現状のテストケースの構成
 メンテナンス性向上の工夫
 テストシナリオとページ操作の分離
 テストシナリオとテストデータの分離
Slenium2って何?
 OSSのブラウザテストツール
 プログラム言語でテストスクリプトを書いて使う
 何ができるの?
 手動テストの代替
 手動テストで行うのと同様に、実際にWebブラウザを起
動して操作できる
 ボタン押した...
デモ
現状のテストケースの構成
spec
├ features
│ ├ 機能A
│ └ 機能B
├ fixtures
│ ├ 機能A
│ └ 機能B
├ operators
│ ├ 機能A
│ └ 機能B
├ pages
│ ├ 機能A
│ └ 機能...
 なんで色々わかれてるの?
 メンテナンス性向上のためです
 テストにメンテナンス性って大事なの?
書いて1回実施してOKつけば終わりじゃん。
 そんなことないです。
 そもそも、手動のテストケースでもメンテ
ナンス性は大事です。メン...
メンテナンス性が大事な理由
 自動テストがある = 長期保守プロダクト
 1回テスト書いて流して納品すればOK!なプロ
ジェクトなら、そもそもテスト自動化しない
 長期保守 = 将来プロダクト改修がある
 機能追加、バグフィックス、環境...
メンテナンス性向上のために
 大きくわけて以下2点を心がけてます
① テストシナリオとページ操作の分離
② テストシナリオとテストデータの分離
 上記2点について、それぞれ発表します
①テストシナリオと
ページ操作の分離
②テストシナリオと
テストデータの分離
この部分の説明です
spec
├ features
│ ├ 機能A
│ └ 機能B
├ fixtures
│ ├ 機能A
│ └ 機能B
├ operators
│ ├ 機能A
│ └ 機能B
├ pages
│ ├ 機能A
│ └ 機能B
└...
予備知識:ベタ書きの恐怖
ページに何か入力するテスト
入力項目5個×10ページ
困ります
① 可読性・メンテナンス性が低い
 同じようなことがあちこちに大量に書いてある
 HTMLが変更されたら、テストコードをすべて
修正しなくてはならない
② 対象のHTML&Selenium2の操作 を知ら
ないとテストが書けない
...
対処法
 テストシナリオとページ操作の分離
=> PageObjectデザインパターン
…というのがあります
PageObjectデザインパターン
 Selenium公式で推奨されてるデザインパターン
https://code.google.com/p/selenium/wiki/PageObjects
 publicメソッドはページが提供するサー...
具体的にどういうこと?
 「テストシナリオ」と
「テスト対象のページを表現するクラス」
を分離する
 テストシナリオ内では、直接ページ操作を
行わない
(すべてページクラスのAPIを通す)
テストシナリオn
テストシナリオ⑥
テストシナリオ⑥
テストシナリオ⑥
図にするとこんな感じ
テスト対象
ページ
ページクラス
テストシナリオ①
テストシナリオ②
テストシナリオ③
テストシナリオ④
テストシナリオ⑤
テストシナリオ⑥
ページクラスの内容
 そのページが提供する機能 (publicメソッド)
 メールアドレス入力欄に引数で受け取った値を入力
する
 登録ボタンをクリックする
 エラーメッセージ表示領域に出力されてる文字列を
取得する
 ページ内要素の...
テストケースの内容
 テスト手順
① テスト対象ページを開く
② メールアドレス入力欄に “めあど” と入力す
る
③ 登録ボタン押下する
 合否判定
 エラーメッセージ入力欄に “メールアドレスが
不正です” と表示されていればOK
どう変わるの?
① 可読性・メンテナンス性
 テストシナリオ中に、テスト手順/合否判定に関係ない
部分がなくなる
 HTMLが変更されても、ページクラスだけ直せばいい
② 対象のHTML&Selenium2の使い方 を知らなくて
もテストが...
なので こうしてます
spec
├ features
│ ├ 機能A
│ └ 機能B
├ fixtures
│ ├ 機能A
│ └ 機能B
├ operators
│ ├ 機能A
│ └ 機能B
├ pages
│ ├ 機能A
│ └ 機能B
...
①テストシナリオと
ページ操作の分離
②テストシナリオと
テストデータの分離
この部分の説明です
spec
├ features
│ ├ 機能A
│ └ 機能B
├ fixtures
│ ├ 機能A
│ └ 機能B
├ operators
│ ├ 機能A
│ └ 機能B
├ pages
│ ├ 機能A
│ └ 機能B
└...
予備知識
 「ユーザを新規作成する」だけでも、「どんな内容で作
成したいか」は色々あります
 設定項目の例
 ユーザ名
 苗字
 苗字かな
 名前
 名前かな
 パスワード
 メールアドレス
 携帯
 PC
 性別
 ...
これらの内容をすべて
テストケース内に書くと
必須項目だけ指定するケース 全項目指定するケース マンション名が空のケース
入力値の指定だけでこれだけ書かなきゃいけない
(このあとにやっとテストケースを書ける)
困ります
 可読性・メンテナンス性
 「そのケースのテスト観点としては不要だけど、
入れざるを得ない項目」が多い (マンション名の例)
 「ケースAとケースBで指定する入力値の違い( = テスト観点)
は何か?」が読み取りづらい
 ある...
対処法
 テストシナリオとテストデータ(入力値
セット)を分離する
 テストシナリオ中では「○○用の入力値セッ
ト」を呼び出すだけ
 「基本となる入力値セット」を用意する
 必須項目のみ && 入力許容値のみ のセット
 これを元にバ...
具体的にはこんな感じ
どう変わるの?
 可読性・メンテナンス性
 「基本の入力値セット」があるので、その他のセッ
トでは「そのテスト観点に必要な部分」だけ指定す
ればいい
 項目の増減があっても「基本の入力値セット」だけ
修正すればいい
 仕様に詳しくなくて...
なので こうしてます
spec
├ features
│ ├ 機能A
│ └ 機能B
├ fixtures
│ ├ 機能A
│ └ 機能B
├ operators
│ ├ 機能A
│ └ 機能B
├ pages
│ ├ 機能A
│ └ 機能B
...
まとめ
 QAチームでは現在、ブラウザテストの自動化
に取り組んでます
 Selenium2という便利ツールを使ってます
 自動テストは手動テスト以上にメンテナンス性
が大事です
 なので以下に気をつけてます
 テストシナリオとページ...
以上です。
Próxima SlideShare
Cargando en…5
×

Selenium2でつくるテストケースの構成について

20.643 visualizaciones

Publicado el

社内勉強会での発表に使った資料。

Publicado en: Software
  • Sé el primero en comentar

Selenium2でつくるテストケースの構成について

  1. 1. Selenium2でつくるテストケースの 構成について 2014/06/19 徳田 ゆい
  2. 2. なにを発表するの?  最近、Selenium2 + Ruby + RSpec でブラウザ テストの自動化に取り組んでます  「ブラウザテスト」?  ここでは「テスターがブラウザを操作して眼で結果 を確認する行為」という意味で使います  具体的にどんなことをやってるのかを紹介し ます。 (主にテストケースの構成について話します)
  3. 3. もくじ  Selenium2って何?  デモ  現状のテストケースの構成  メンテナンス性向上の工夫  テストシナリオとページ操作の分離  テストシナリオとテストデータの分離
  4. 4. Slenium2って何?  OSSのブラウザテストツール  プログラム言語でテストスクリプトを書いて使う  何ができるの?  手動テストの代替  手動テストで行うのと同様に、実際にWebブラウザを起 動して操作できる  ボタン押したり、文字列を入力したり取得したりetc  特徴・メリット  ブラウザテストツールのデファクトスタンダード  情報&使用経験者の数が多い  開発が活発  幅広いOS/ブラウザ/言語に対応
  5. 5. デモ
  6. 6. 現状のテストケースの構成 spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオ テストデータ ページに対する定型操作をまとめたクラス ページクラス 一般的なユーティリティクラス
  7. 7.  なんで色々わかれてるの?  メンテナンス性向上のためです  テストにメンテナンス性って大事なの? 書いて1回実施してOKつけば終わりじゃん。  そんなことないです。  そもそも、手動のテストケースでもメンテ ナンス性は大事です。メンテナンスするか ら。  そして自動テストの場合はもっと大事です。 なんでこの構成なの?
  8. 8. メンテナンス性が大事な理由  自動テストがある = 長期保守プロダクト  1回テスト書いて流して納品すればOK!なプロ ジェクトなら、そもそもテスト自動化しない  長期保守 = 将来プロダクト改修がある  機能追加、バグフィックス、環境移行…  プロダクト改修 = テスト実施 = テスト改修  変更したらテストしなきゃ危険  機械は「最新仕様をふまえてよしなに読み替えて テスト」できない
  9. 9. メンテナンス性向上のために  大きくわけて以下2点を心がけてます ① テストシナリオとページ操作の分離 ② テストシナリオとテストデータの分離  上記2点について、それぞれ発表します
  10. 10. ①テストシナリオと ページ操作の分離 ②テストシナリオと テストデータの分離
  11. 11. この部分の説明です spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオ テストデータ ページに対する定型操作をまとめたクラス ページクラス 一般的なユーティリティクラス
  12. 12. 予備知識:ベタ書きの恐怖 ページに何か入力するテスト
  13. 13. 入力項目5個×10ページ
  14. 14. 困ります ① 可読性・メンテナンス性が低い  同じようなことがあちこちに大量に書いてある  HTMLが変更されたら、テストコードをすべて 修正しなくてはならない ② 対象のHTML&Selenium2の操作 を知ら ないとテストが書けない  「テストシナリオを考えられる」だけじゃテ ストが書けない
  15. 15. 対処法  テストシナリオとページ操作の分離 => PageObjectデザインパターン …というのがあります
  16. 16. PageObjectデザインパターン  Selenium公式で推奨されてるデザインパターン https://code.google.com/p/selenium/wiki/PageObjects  publicメソッドはページが提供するサービスを表す The public methods represent the services that the page offers  ページの内部を露出させないようにしよう Try not to expose the internals of the page  一般的に、アサーションを行わない Generally don't make assertions  メソッドは他のページオブジェクトを返す Methods return other PageObjects  ページ全体を表す必要はない Need not represent an entire page  同じアクションに対して結果が異なる場合は別なメソッ ドとしてモデル化する Different results for the same action are modelled as different methods
  17. 17. 具体的にどういうこと?  「テストシナリオ」と 「テスト対象のページを表現するクラス」 を分離する  テストシナリオ内では、直接ページ操作を 行わない (すべてページクラスのAPIを通す)
  18. 18. テストシナリオn テストシナリオ⑥ テストシナリオ⑥ テストシナリオ⑥ 図にするとこんな感じ テスト対象 ページ ページクラス テストシナリオ① テストシナリオ② テストシナリオ③ テストシナリオ④ テストシナリオ⑤ テストシナリオ⑥
  19. 19. ページクラスの内容  そのページが提供する機能 (publicメソッド)  メールアドレス入力欄に引数で受け取った値を入力 する  登録ボタンをクリックする  エラーメッセージ表示領域に出力されてる文字列を 取得する  ページ内要素の特定 (plivateメソッド)  メールアドレス入力欄・登録ボタン・エラーメッ セージ表示領域etc… を具体的にCSSセレクタや XPathで指定する (これがないとページ操作できない)
  20. 20. テストケースの内容  テスト手順 ① テスト対象ページを開く ② メールアドレス入力欄に “めあど” と入力す る ③ 登録ボタン押下する  合否判定  エラーメッセージ入力欄に “メールアドレスが 不正です” と表示されていればOK
  21. 21. どう変わるの? ① 可読性・メンテナンス性  テストシナリオ中に、テスト手順/合否判定に関係ない 部分がなくなる  HTMLが変更されても、ページクラスだけ直せばいい ② 対象のHTML&Selenium2の使い方 を知らなくて もテストが書ける  データ入力したければ それ用のメソッドを呼べばいい。 テストシナリオだけ考えれば、「データ入力するため に、具体的にどうやって画面要素を特定し、どんな操 作が必要か」を知らなくてもテストが書ける。
  22. 22. なので こうしてます spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオ テストデータ ページに対する定型操作をまとめたクラス ページクラス 一般的なユーティリティクラス
  23. 23. ①テストシナリオと ページ操作の分離 ②テストシナリオと テストデータの分離
  24. 24. この部分の説明です spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオ テストデータ ページに対する定型操作をまとめたクラス ページクラス 一般的なユーティリティクラス
  25. 25. 予備知識  「ユーザを新規作成する」だけでも、「どんな内容で作 成したいか」は色々あります  設定項目の例  ユーザ名  苗字  苗字かな  名前  名前かな  パスワード  メールアドレス  携帯  PC  性別  生年月日  住所  郵便番号  都道府県  市区町村  丁目&番地  マンション名  電話番号  携帯  自宅  テスト上の要求  必須項目のみ指定してユーザ作成したい  全項目指定してユーザ作成したい  「苗字」を最大文字数にしてユーザ作成したい  「名前かな」に漢字を入力して結果を見たい  携帯とPCのメールアドレスに同じ文字列を入力 して結果を見たい  マンション名が空のユーザを作成したい  削除テスト用の適当なユーザを作成したい  ユーザを100人作成したい(内容は何でもいい)  etc…
  26. 26. これらの内容をすべて テストケース内に書くと 必須項目だけ指定するケース 全項目指定するケース マンション名が空のケース 入力値の指定だけでこれだけ書かなきゃいけない (このあとにやっとテストケースを書ける)
  27. 27. 困ります  可読性・メンテナンス性  「そのケースのテスト観点としては不要だけど、 入れざるを得ない項目」が多い (マンション名の例)  「ケースAとケースBで指定する入力値の違い( = テスト観点) は何か?」が読み取りづらい  ある項目が指定されてないとき、その理由が分かり辛い  データ作成だけが目的だから、必須項目以外空にした?  バリデーションテストのために空にした?  ヒューマンエラー?  入力項目が増減するたび、全テストケースの修正が必要  仕様に詳しくないと 入力値を指定できない  「なんでもいいから適当なユーザつくりたい」ときでも、 「何が必須項目か&どんな入力値が許可されてるのか」 を知らないとつくれない
  28. 28. 対処法  テストシナリオとテストデータ(入力値 セット)を分離する  テストシナリオ中では「○○用の入力値セッ ト」を呼び出すだけ  「基本となる入力値セット」を用意する  必須項目のみ && 入力許容値のみ のセット  これを元にバリエーションを増やす
  29. 29. 具体的にはこんな感じ
  30. 30. どう変わるの?  可読性・メンテナンス性  「基本の入力値セット」があるので、その他のセッ トでは「そのテスト観点に必要な部分」だけ指定す ればいい  項目の増減があっても「基本の入力値セット」だけ 修正すればいい  仕様に詳しくなくても 入力値を指定できる  「なんでもいいからユーザが100人ほしい」なら、 「基本の入力値セット」を使えばいい
  31. 31. なので こうしてます spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオ テストデータ ページに対する定型操作をまとめたクラス ページクラス 一般的なユーティリティクラス
  32. 32. まとめ  QAチームでは現在、ブラウザテストの自動化 に取り組んでます  Selenium2という便利ツールを使ってます  自動テストは手動テスト以上にメンテナンス性 が大事です  なので以下に気をつけてます  テストシナリオとページ操作の分離  テストシナリオとテストデータの分離
  33. 33. 以上です。

×