キーワード駆動テストを実践した話まずは作ってみた編

実践の背景

定期的に同じ操作のテストを繰り返していた

約 30 時間

依頼通りに値が設定されてることを検証する必要があった

約 20 時間

テストデータは間違いなく入力する必要があった

間違えたらやり直し

間違いなく入力されていることを検証（受入）する必要があった

テストコードを書ける人がいなかった

ビジネス要求

同じテスト内容を何度も繰り返し入力したくない

受入検証で誤ったテストを発見するような運用はやめたい

例え誤りを発見しても、迅速に修正、短時間で再実行したい

テストコードを書けない人でも自動テストを実装出来るようにしたい

機能要求

１つのテストケースで何度も同じテストを実施出来なければならない

テストは自動実行される必要がある

テストの実施中にテストの合否を誤りなく判定しなければならない

誤りがあったテストケースだけを実行出来る仕組みが必要である

キーワード駆動テスト手法を採用しなければならない

さらに、テストケース表は自然言語で記述される必要がある

ユースケース

テストケース取り込み、実行、合否判定、結果報告

POI

TestNG

DataProvider 、Suite、Assertion、Report

実行有無の判定処理の追加

Maven

キーワード駆動テスト専用のテストケース表の作成

テスト対象への自然言語による操作を、テストシステムが処理可能な形に変換するテストケース表の作成

作ったもの1

テストシステムの構造

テストシステムビルダー

テストランナー

テストケースローダ キーワードエンジン

テストケースファイル

テストステップファイル

ロケータ リポーター

作ったもの2

テストケースファイル

作ったもの3

テストステップファイル

成果

同じ内容のテストを繰り返し操作しなくて済むようになった

受入検証ではテスト結果と証跡を確認するだけで済むようになった

テストシステムが意図した通りに動作することが保証されている為

誰でも自動テストを実装出来るようになった

さらに

ちょっとしたテストデータの変更にも対応できるようになった

課題1

適切なキーワードの実装方法が分からなかった

汎用性の高いキーワードはテストケースが長くなり、テストケースが短くする為にキーワードの独自性を強めると汎用性に欠けて再利用性の低いキーワードが増えてしまった

非常に脆いテストになった

WebElementの変更を伴う改修があると、テストケース表毎にロケータを書き直す必要があった

課題2

テストの実装よりテストシステムの実装に工数を取られた

マルチブラウザのテストを独自に実装する必要があった

ブラウザのバージョンアップに合わせて、対応するドライバのバージョンに合わせるのが大変だった

ブラウザの種類によりスクリーンショットの範囲が異なる

ブラウザ間の差異の比較が出来なかった

失敗したテストの原因を特定する為に適切なロギングを設計する必要があった

テストの実行を並列化出来ず、実行に時間が掛かってしまった

テストの実行により画面を占有されてしまい、別の端末が必要になった

正しいテストシステムの構造、必要な機能が分からなかった

テストシステムの目的が不明確だった

対応方針1

適切なキーワードの実装方法

自分で考えた

保守性と拡張性の為に、オブジェクトとして実装する

キーワード駆動テストを実践している方に聞いた

システムテストでは、対象とするドメインの用語をキーワードとすると良い

デザインパターンからヒントを得た

クラス階層と機能階層を分離するBridgeパターン

オブジェクトをコマンド化するCommand パターン…etc

オブジェクト設計方法からヒントを得た

ICONIXのドメイン分析手法から、オブジェクトを抽出、設計する手法を参考にする

非常に脆いテスト

テストケース表のロケータが、テスト対象システムと同期する様にする

対応方針2

テストシステムの実装に工数を取られた

以下をPitaliumに委譲する

マルチブラウザテスト対応

スクリーンショットの範囲補正、取得

テストログ（stacktrace含む）取得

テストのマルチスレッド実行

以下をJava Service Wrapperを利用してdaemon（サービス）化する

Selenium Grid Node / Selenium Grid Hub

正しいテストシステムの構造、必要な機能

JUnitやSeleniumを使わないテストシステムの構造を参考にする

テストシステムの目的を明確化する

OOADの実践プロセスを参考に、要求に応じた設計をする