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

20161218 selenium study4-part1

Jan 28, 2018

Download

Engineering

Naoya Kojima
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 20161218 selenium study4-part1

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

Page 2: 20161218 selenium study4-part1

実践の背景

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

約 30 時間

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

約 20 時間

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

間違えたらやり直し

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

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

Page 3: 20161218 selenium study4-part1

ビジネス要求

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

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

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

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

Page 4: 20161218 selenium study4-part1

機能要求

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

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

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

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

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

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

Page 5: 20161218 selenium study4-part1

ユースケース

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

POI

TestNG

DataProvider 、Suite、Assertion、Report

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

Maven

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

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

Page 6: 20161218 selenium study4-part1

作ったもの1

テストシステムの構造

テストシステムビルダー

テストランナー

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

テストケースファイル

テストステップファイル

ロケータ リポーター

Page 7: 20161218 selenium study4-part1

作ったもの2

テストケースファイル

Page 8: 20161218 selenium study4-part1

作ったもの3

テストステップファイル

Page 9: 20161218 selenium study4-part1

成果

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

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

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

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

さらに

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

Page 10: 20161218 selenium study4-part1

課題1

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

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

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

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

Page 11: 20161218 selenium study4-part1

課題2

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

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

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

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

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

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

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

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

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

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

Page 12: 20161218 selenium study4-part1

対応方針1

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

自分で考えた

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

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

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

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

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

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

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

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

非常に脆いテスト

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

Page 13: 20161218 selenium study4-part1

対応方針2

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

以下をPitaliumに委譲する

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

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

テストログ(stacktrace含む)取得

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

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

Selenium Grid Node / Selenium Grid Hub

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

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

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

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