Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

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

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 33 Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Selenium2でつくるテストケースの構成について (20)

Publicité

Plus récents (20)

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. 以上です。

Notes de l'éditeur

  • ・Selenium2 = Selenium WebDriver
    ・「Selenium = Firefox のアドオン。キャプチャ&リプレイツール」って認識が主だと思いますが、少し違います。が、それには深く触れません。
  • 詳しくはこれから説明します
  • ・機械は~のくだり
     ・別に手動テストでもテスト改修しなきゃいけないけど、実施が人間の場合は「とりあえずテストしてケースは後で直す」ができなくはない
  • ・メールアドレス入力欄に “めあど” と入力して登録ボタン押下し、表示されるエラーメッセージが正しいか確認するテスト
  • ③について
    ・「この要素はどうすれば特定できるか」とか、「特定したこの要素をどうやれば操作できるか」とかを知らないと、テストが書けない
  • ・Google翻訳を整形したので、合ってると思います
    ・検索するといくつか解説が見つかります。日本語のも何個かあります。
  • ・単に「プログラム言語から使える」という Selenium2 のメリットを享受できるようになっただけですが…
    ・③について。現状の「テストケースもページクラスも1人で書いてる状態」にはあまり関係ないですが、他社では「ページクラスは開発や社員のテストエンジニアが書き、テストケースはアルバイトが量産する」といった事例もあるそうです。
  • ・operators
     ・実際のテストではひとことで「ユーザ登録する」といっても「項目1~10に値を入れる → ボタンA押下する → ボタンB押下する …」みたいに操作が多いので、定番操作をまとめるために作ってます。
  • ・マンション名が空のケースについて
     ・「マンション名が空でも登録できること」のテストを行うためには 必須項目(苗字etc)が正しく入力されてる必要があるので、こうなります
  • ・「なんでもいいから適当なユーザつくりたい」という場合は結構多いです
     ・ユーザ削除テストでつかうユーザがほしい
     ・ユーザと紐付く他データ(コミュニティとか)のテストでつかうユーザがほしい
     ・ユーザ100人いるときの動作テストをしたいetc…

×