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という便利ツールを使ってます
 自動テストは手動テスト以上にメンテナンス性
が大事です
 なので以下に気をつけてます
 テストシナリオとページ操作の分離
 テストシナリオとテストデータの分離

以上です。