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

Selenium2でつくるテストケースの構成について 2014/06/19 徳田ゆい

なにを発表するの？  最近、Selenium2 + Ruby + RSpec でブラウザテストの自動化に取り組んでます  「ブラウザテスト」？  ここでは「テスターがブラウザを操作して眼で結果を確認する行為」という意味で使います  具体的にどんなことをやってるのかを紹介します。 (主にテストケースの構成について話します)

もくじ  Selenium2って何？  デモ  現状のテストケースの構成  メンテナンス性向上の工夫  テストシナリオとページ操作の分離  テストシナリオとテストデータの分離

Slenium2って何？  OSSのブラウザテストツール  プログラム言語でテストスクリプトを書いて使う  何ができるの？  手動テストの代替  手動テストで行うのと同様に、実際にWebブラウザを起動して操作できる  ボタン押したり、文字列を入力したり取得したりetc  特徴・メリット  ブラウザテストツールのデファクトスタンダード  情報＆使用経験者の数が多い  開発が活発  幅広いOS/ブラウザ/言語に対応

デモ

現状のテストケースの構成 spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオテストデータページに対する定型操作をまとめたクラスページクラス一般的なユーティリティクラス

 なんで色々わかれてるの？  メンテナンス性向上のためです  テストにメンテナンス性って大事なの？書いて1回実施してOKつけば終わりじゃん。  そんなことないです。  そもそも、手動のテストケースでもメンテナンス性は大事です。メンテナンスするから。  そして自動テストの場合はもっと大事です。なんでこの構成なの？

メンテナンス性が大事な理由  自動テストがある = 長期保守プロダクト  1回テスト書いて流して納品すればOK！なプロジェクトなら、そもそもテスト自動化しない  長期保守 = 将来プロダクト改修がある  機能追加、バグフィックス、環境移行…  プロダクト改修 = テスト実施 = テスト改修  変更したらテストしなきゃ危険  機械は「最新仕様をふまえてよしなに読み替えてテスト」できない

メンテナンス性向上のために  大きくわけて以下2点を心がけてます ① テストシナリオとページ操作の分離 ② テストシナリオとテストデータの分離  上記2点について、それぞれ発表します

①テストシナリオとページ操作の分離 ②テストシナリオとテストデータの分離

この部分の説明です spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオテストデータページに対する定型操作をまとめたクラスページクラス一般的なユーティリティクラス

予備知識：ベタ書きの恐怖ページに何か入力するテスト

入力項目5個×10ページ

困ります ① 可読性・メンテナンス性が低い  同じようなことがあちこちに大量に書いてある  HTMLが変更されたら、テストコードをすべて修正しなくてはならない ② 対象のHTML＆Selenium2の操作を知らないとテストが書けない  「テストシナリオを考えられる」だけじゃテストが書けない

対処法  テストシナリオとページ操作の分離 => PageObjectデザインパターン …というのがあります

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

具体的にどういうこと？  「テストシナリオ」と「テスト対象のページを表現するクラス」を分離する  テストシナリオ内では、直接ページ操作を行わない (すべてページクラスのAPIを通す)

テストシナリオn テストシナリオ⑥ テストシナリオ⑥ テストシナリオ⑥ 図にするとこんな感じテスト対象ページページクラステストシナリオ① テストシナリオ② テストシナリオ③ テストシナリオ④ テストシナリオ⑤ テストシナリオ⑥

ページクラスの内容  そのページが提供する機能 (publicメソッド)  メールアドレス入力欄に引数で受け取った値を入力する  登録ボタンをクリックする  エラーメッセージ表示領域に出力されてる文字列を取得する  ページ内要素の特定 (plivateメソッド)  メールアドレス入力欄・登録ボタン・エラーメッセージ表示領域etc… を具体的にCSSセレクタや XPathで指定する (これがないとページ操作できない)

テストケースの内容  テスト手順 ① テスト対象ページを開く ② メールアドレス入力欄に “めあど” と入力する ③ 登録ボタン押下する  合否判定  エラーメッセージ入力欄に “メールアドレスが不正です” と表示されていればOK

どう変わるの？ ① 可読性・メンテナンス性  テストシナリオ中に、テスト手順/合否判定に関係ない部分がなくなる  HTMLが変更されても、ページクラスだけ直せばいい ② 対象のHTML＆Selenium2の使い方を知らなくてもテストが書ける  データ入力したければそれ用のメソッドを呼べばいい。テストシナリオだけ考えれば、「データ入力するために、具体的にどうやって画面要素を特定し、どんな操作が必要か」を知らなくてもテストが書ける。

なのでこうしてます spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオテストデータページに対する定型操作をまとめたクラスページクラス一般的なユーティリティクラス

①テストシナリオとページ操作の分離 ②テストシナリオとテストデータの分離

この部分の説明です spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオテストデータページに対する定型操作をまとめたクラスページクラス一般的なユーティリティクラス

予備知識  「ユーザを新規作成する」だけでも、「どんな内容で作成したいか」は色々あります  設定項目の例  ユーザ名  苗字  苗字かな  名前  名前かな  パスワード  メールアドレス  携帯  PC  性別  生年月日  住所  郵便番号  都道府県  市区町村  丁目＆番地  マンション名  電話番号  携帯  自宅  テスト上の要求  必須項目のみ指定してユーザ作成したい  全項目指定してユーザ作成したい  「苗字」を最大文字数にしてユーザ作成したい  「名前かな」に漢字を入力して結果を見たい  携帯とPCのメールアドレスに同じ文字列を入力して結果を見たい  マンション名が空のユーザを作成したい  削除テスト用の適当なユーザを作成したい  ユーザを100人作成したい(内容は何でもいい)  etc…

これらの内容をすべてテストケース内に書くと必須項目だけ指定するケース全項目指定するケースマンション名が空のケース入力値の指定だけでこれだけ書かなきゃいけない (このあとにやっとテストケースを書ける)

困ります  可読性・メンテナンス性  「そのケースのテスト観点としては不要だけど、入れざるを得ない項目」が多い (マンション名の例)  「ケースAとケースBで指定する入力値の違い( = テスト観点) は何か？」が読み取りづらい  ある項目が指定されてないとき、その理由が分かり辛い  データ作成だけが目的だから、必須項目以外空にした？  バリデーションテストのために空にした？  ヒューマンエラー？  入力項目が増減するたび、全テストケースの修正が必要  仕様に詳しくないと入力値を指定できない  「なんでもいいから適当なユーザつくりたい」ときでも、「何が必須項目か＆どんな入力値が許可されてるのか」を知らないとつくれない

対処法  テストシナリオとテストデータ(入力値セット)を分離する  テストシナリオ中では「○○用の入力値セット」を呼び出すだけ  「基本となる入力値セット」を用意する  必須項目のみ＆＆入力許容値のみのセット  これを元にバリエーションを増やす

具体的にはこんな感じ

どう変わるの？  可読性・メンテナンス性  「基本の入力値セット」があるので、その他のセットでは「そのテスト観点に必要な部分」だけ指定すればいい  項目の増減があっても「基本の入力値セット」だけ修正すればいい  仕様に詳しくなくても入力値を指定できる  「なんでもいいからユーザが100人ほしい」なら、「基本の入力値セット」を使えばいい

なのでこうしてます spec ├ features │ ├ 機能A │ └ 機能B ├ fixtures │ ├ 機能A │ └ 機能B ├ operators │ ├ 機能A │ └ 機能B ├ pages │ ├ 機能A │ └ 機能B └ support テストシナリオテストデータページに対する定型操作をまとめたクラスページクラス一般的なユーティリティクラス

まとめ  QAチームでは現在、ブラウザテストの自動化に取り組んでます  Selenium2という便利ツールを使ってます  自動テストは手動テスト以上にメンテナンス性が大事です  なので以下に気をつけてます  テストシナリオとページ操作の分離  テストシナリオとテストデータの分離

以上です。

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

by yui Yui, Working at 株式会社ガイアックス

on Jun 20, 2014

Statistics

Views

Actions

1 Embed 1

Accessibility

Categories

Upload Details

Usage Rights

Report content

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