Seleniumでキーワード駆動テストを実践した時のあれこれ

18th-Dec-2016

Naoya Kojima

@jugemix

Profile

I am …

Father / Husband / A just application developer interested in Application design & Testing

I love making / drinking coffee very much (^^)v

Specialty

Automation Test ( with JavaSE AspectJ Junit/TestNG Selenium WebDriver )

I make a keyword-driven test system.

伝えたいことセッションの主旨をお伝えします

テストの自動化に興味ある皆さんへ

テストの自動化をはじめるにあたり、皆さんが気になるであろうポイントを、キーワード駆動テストの実践を通してご紹介します

難しく考えずに、できる範囲ではじめてみてください

テストを自動化する目的を明らかにしてみてください

テストをシステム化する上で重要だと思うことを、テストシステムの開発方針に取り入れてみてください

取り組んだ結果をぜひ皆さんに教えてください

Selenium を使う自動テストの手法は状況に応じて千差万別だと思います。私の伝えたいことが皆さんとって適切なシステム構築の一助になれば幸いです

話の流れ

伝えたいこと

キーワード駆動テストに取り組む前に考えたこと

キーワード駆動テストとは

構造化スクリプティングとの比較

キーワード駆動テストを実践した話

深く考えずにまずはやってみた編

リファクタリング編

テストシステムの構造、機能の検討

テストのしやすさの検討

ICONIX によるテストシステムの要求分析設計の実施

適切なキーワードの検討

まとめ

キーワード駆動テストに取り組む前に考えたこと• キーワード駆動テストとは

• 構造化スクリプティングとの比較

キーワード駆動テストとはテストシステムを実装する立場からの考察

自動化アプローチの種類

システムテスト自動化標準ガイドによると

スクリプティング技法

リニアスクリプト

テスト対象への操作をレコーディングして、何度も実行出来るようにするアプローチ

構造化スクリプト

「テスト対象の操作方法」を"テストコード"を書き、何度も実行出来るようにするアプローチ

データ駆動スクリプト

構造化スクリプトを構成するテストコードからテストデータを独立させて、テストコードに柔軟性を持たせたアプローチ

キーワード駆動スクリプト

特定のルールに基づき構成されたスクリプトをテストシステムが解釈（プリプロセス）してから実行するアプローチ

概要

ISO/IEC/IEEE 29119-5 によると

一般的に、次の２つで構成される

自動テスト

テスト自動化フレームワークの開発

すべてのテストレベルで使用できる

システム様々なタイプのテスト

例）機能テスト、信頼性テスト

キーワード駆動テストの基本的な考え方

プログラミングやテストツールの専門知識を詳しく知らなくても、手動または自動のテストケースの作成に使用する「キーワード」と呼ばれる一連の「構成要素」を提供する

この為、各キーワードをソフトウェアで実装する必要がある

「キーワード駆動テストとは」 まとめ

目的

構造化/データ駆動の課題の、「テスト対象の操作方法」を１つ１つテストシステムに伝える、という手間を軽減する

実現方法

テストシステムが「テスト対象の操作方法」を解釈してから、テストを実行できるようにする

解釈（プリプロセス）の為に、テストシステムには特定のルールに基づいて抽出した「キーワード」を知識として与える

効果

テストシステムが「解釈」出来るようになった結果、テスト実装者は「テスト対象の操作方法」をある纏まりとして扱うことが可能になる

特定のドメインにフォーカスして、一定のルールに基づき「ある纏まり」を構成することで、テストコードを書けない組織でも比較的容易にスクリプトを記述出来るようになり、自動化の敷居を下げることが出来る

構造化スクリプティングとの比較採用するアプローチの決定にあたり、組織の状況と照合する為の観点

自動テストのライフサイクル

テストシステ

ム開発テスト実装 テスト実行

テストシステ

ム保守

観点 構造化 キーワード

・テストシステム開発要員のスキル

テスト計画、分析、設計に関する知識や経験例）どのようにテストを実施していくか

必要 必要

各々が置かれた状況から導かれた要求に対して適切に設計をするスキル例）保守、拡張しやすい構造にするスキル、キーワードの設計スキル

必要 必要

・コーディングスキル 必要 必要

・テストシステムの開発工数（相対比較） 低 高

テストシステム開発時の比較観点

テスト実装時の比較観点

観点 構造化 キーワード

・テスト実装者のスキル

テスト技法に関する知識例）どのように効果的なテストを実施するか

必要 必要

コーディングスキル 必要 不要

キーワードの設計スキル 不要 必要

・テストの実装環境

開発環境 必要 不要

・テストの実装工数（相対比較） 高 低

テスト実行時の比較観点

観点 S/K

テスト実行者のスキル

コーディング不要/不要

テスト失敗時の原因分析スキル不要/不要

テストの実行環境

テストシステム稼働環境必要/必要

テストスクリプト実行環境必要/必要

観点 構造化 キーワード

・テスト実行者のスキル

コーディング 不要 不要

テスト失敗時の原因分析スキル 不要 不要

・テストの実行環境

テストシステム稼働環境 必要 必要

テストスクリプト実行環境 必要 必要

テストシステム保守時の比較観点

観点 構造化 キーワード

・テストシステム保守要員のスキル

テストプロセスに関する知識例）どのようにテストを実施していくか

必要 必要

開発時の方針 に従って保守・拡張設計をするスキル例）キーワード設計方針に従いキーワードを拡張する

必要 必要

コーディングスキル 必要 必要

・テストシステムの保守工数（相対比較） 低 高

構造化スクリプティングとの比較 まとめ

自動化のアプローチを決定する上で大切な事

自動テストのライフサイクル別に必要なリソースを検討すること

ライフサイクルの一部だけに「テストシステム開発」だけ、「テストの実装」だけに焦点を当ててしまうと、想定していないフェーズで必要となってくるリソース不足で、自動テストを継続できなくなってしまう

状況に応じて判断、選択すること

判断基準となる観点を導くポイント

ヒト、モノ、カネ

自分が置かれた状況にどれだけあるか 、手配できるかを踏まえて判断すること

キーワード駆動テストを実践した話深く考えずにまずはやってみた編

実践の背景

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

約 30 時間

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

約 20 時間

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

間違えたらやり直し

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

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

ビジネス要求

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

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

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

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

機能要求

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

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

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

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

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

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

ユースケース

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

POI

TestNG

DataProvider 、Suite、Assertion、Report

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

Maven

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

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

テストシステムビルダー（Maven）

テストランナー（TestNG）

テストケース

ローダ（POI）

WebDriverの

管理キーワードエンジン

テストケース

ファイル

（Excel）

テストステップ

ファイル

（Excel）

キーワードページオブ

ジェクト

レポーター

（TestNG）

作ったもの 1/3

テストシステムの構造Programming Part

selenium-javaを利用した「WebDriver」、「操作」、「ロケータ」の記述箇所

作ったもの 2/3

テストケースファイル

作ったもの 3/3

テストステップファイル

成果

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

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

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

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

さらに

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

課題 1/2

1. テストシステムのあるべき姿が分からなかった

テストシステムがどのような構造を持つべきか分からなかった

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

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

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

課題 2/2

3. 脆いテストになった

画面上の要素の変更を伴う改修により、テストケース表毎にロケータを書き直す羽目になってしまった

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

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

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

スクリーンショットに基づいたブラウザ間の差異の比較を出来なかった

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

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

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

対応方針 1/2

1. テストシステムの構造、機能の検討

先駆者のテストシステムを参考にした

現状の構造と比較し、改善した

テストシステムの目的を明確化した

テストシステムは一つのシステムであると捉え、テストシステムへの要求、及び機能を整理した

2. テストスクリプトにおける適切なキーワードの検討

先駆者の考え方を参考にした

シナリオテストに登場するドメインの用語をキーワードとした

デザインパターンを参考にした

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

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

OOADによるオブジェクト抽出方法を参考にした

ICONIXのドメイン分析手法から、特定のドメインからオブジェクトを抽出できるようにした

対応方針 2/2

3. 脆いテストへの対策

テストシステムに実装したロケータをテストケース表に取込可能にした

4. テストシステムの実装の省力化

Pitaliumにテストシステムの基本機能を委譲した

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

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

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

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

Selenium Server をdaemon（サービス）化した

Java Service Wrapperを利用した

キーワード駆動テストを実践した話リファクタリング編

テストシステムの構造、機能の検討• 先駆者のテストシステムを参考にした

• テストシステムの目的を明確化した

先駆者のテストシステムを参考にした

参考にしたテストシステム、考え方

SQiP 併設チュートリアル 2「キーワード駆動による自動テスト構築」

http://jugemix.hatenablog.com/entry/2016/09/20/230954

テストシステムの目的を明確化した

テストシステムは一つのシステムであると捉え、テストシステムへの要求、及び機能を整理した

要求、機能整理の為に採用したアプローチ

「テストのしやすさ」の検討

テストのしやすい状況、テストを検討してテストシステムの目的を明確にする

ICONIX （OOADのプロセスの一つ）によるテストシステムの要求分析設計の実施

ICONIXでは、ビジネス要求→機能要求→ユースケースというOOA（分析）を経て、ユースケースは機能設計へと落とし込まれていきます。そこで、ICONIXの要求分析アプローチに基づき、テストシステムへの要求を明確化していきます。

「テストのしやすさ」の検討

自動テストにしやすい状況

手動テストがテストスクリプトに基づいて実施されていること

テスト実行者への指示となるもの（ドキュメント等）があること

これはアドホックなテストを否定する意味ではなく、テストを実行するテストシステムへの指示が物理的な形になっていることを意味する

一般に知られる方法だが、ドキュメントに従い作られた正しさが証明されたテストのアウトプット（ログ）と、今回実行したテストのアウトプットを比較することで、テスト対象に変更が無いことを回帰的に確認することも出来る

効果的なテストがあること

テストがテストとしての目的を果たしている

テスト対象を適切に分析、設計できること

不適切な（意味のない）テストを自動化しても時間と労力が無駄になるだけである

テスト技法はテストプロセスを示すものではなく、効果的に欠陥を発見する為のものであることを理解する

自動テストにしずらい状況

テストスクリプトの無い機能が多い場合

テストを実装する為には、その元（ドキュメント等）が必要である為

アドホックなテストを否定しているわけではない

以下の投稿でアドホックな手動テストが必要、大切とされる理由を参照して頂きたい

http://qiita.com/ledsun/items/b6c22afe321ac3052182

頻繁に改修のある機能

改修が加われば、成功していたテストも失敗するようになる。手動テストなどを経た上で、成功するように誤りがなく適切な自動テストを実装する必要がある為。

実施しやすいテスト 1/2

複数のテストレベルに焦点を当てた場合

テストレベル

テストタイプ

単体テスト

ユニットテスト

統合テスト

機能テスト

機能間テスト

システムテスト

ユースケーステスト

サイクルテスト

性能テスト

実施しやすいテスト 2/2

システムテストに焦点を絞った場合

テストレベル

テストタイプ

目的

システムテスト

ユースケーステスト（シナリ

オテスト）

アクターにとってのシステム目的

の、様々なシナリオによる検証

サイクルテスト 性能テスト

Easy to test relatively

テストの実施時期と自動化の対象

いつどのテストを実施すべきかーという判断は、開発の効率に影響する

例えば、単体テストで発見できる欠陥がその後工程で発見されれば、その分の手戻りが発生する

一方、開発の効率を抜きにして考えれば、実施すべきテストはいつ実施さても良いことになる

よって、テストレベル毎のテストタイプに縛られずに、対象に必要なテストと実施手法を検討してその中から自動化すべきテストを決定する

ユースケーステスト

ユースケーステスト

ユースケーステストは、「ユースケース記述」で表現する基本シナリオ・代替シナリオから、比較的テストシナリオを導きやすい

参考情報

https://www.ibm.com/developerworks/jp/rational/library/04/r-3217/

テストシナリオを導きやすい為、テストスクリプトの準備が容易になりやすい

ただし、テストシナリオ導出の為には、テスト対象の分析、設計の実施が前提である

そこで、次スライドからOOADによるテスト対象の要求分析設計手法を紹介する

ICONIX によるテストシステムの要求分析設計の実施• Object-Oriented Analysis and Design

• The ICONIX Practical Method of OOAD

Object-Oriented Analysis and Design

Abstract OOAD Structure

Requests

Application

Architecture

Components

Object Object Object Object

Analysis

Design

Object

Roles

Responsibilities

Task Info

has

Roles

The ICONIX

Practical Method of OOAD

Quote from 「Use Case Driven Object Modeling with UML Theory and Practice」Doug Rosenberg, others.

Abstraction of ICONIX

ICONIX自体はOOADよりも広い範囲をサポートする開発手法

静的＋動的なワークフローが構成するイテレーティブなプロセス

１イテレーションでは、ユースケースまたはその論理的な集合に対して、要求分析〜単体テストをスコープとする実践的な手法

イテレーティブな為、agileプラクティスとの親和性が高い

UP（統一プロセス）よりも使用するUMLやドキュメントの種類が少なく、軽量である

他の手法との折衷案を採用してもよい（私見）

マイルストーンと確認ポイントが示されているので分かりやすい

The ICONIX

Practical Method of OOAD 2

Abstraction of ICONIX Process （One Iteration）

要求定義 機能要求 振る舞い要求ドメイン分析

ドメインモデリングレビュー

要求分析

予備設計

ロバストネス分析属性追加（ドメイン

モデルの更新）

コントローラオブ

ジェクトの識別レビュー

詳細設計 シーケンス図作成操作の追加（ドメイ

ンモデルの更新）シーケンス図の更新 レビュー

実装コーディング

ユニットテスト実施

統合テスト、テスト

シナリオの実施コードレビュー 各モデルの更新

To Next

Iteration

The ICONIX

Practical Method of OOAD 3

要求定義

機能要求

•システムができることを記述する。

•例）1ヶ月ログインのないユーザは、パス

ワードを再設定しなければならない。

振る舞い要求

•アクター（ユーザ、システム等）との対話

を叙述的に記述（ユースケース記述）する。

•例）ログイン画面で、ユーザはIDとパス

ワードを入力する。システムは、ユーザの

最終ログイン日を取得し、現在日付との比

較結果が１ヶ月以内かを判定する。また、

ログイン情報と一致するかを判定する。シ

ステムは、判定結果を元にメニュー画面を

表示する。

ドメイン分析、モデリング

•ユースケース記述から問題領域のオブジェ

クトを抽出する。

•抽出にはCRCカードを使うとオブジェクト

の目的、責務、相互作用先の候補を挙げや

すい。（私見）

•ドメインオブジェクト同士を相互作用の観

点で結ぶ。

The ICONIX

Practical Method of OOAD 4

分析・予備設計

ロバストネス分析

•ユースケース記述をロバストネス図上に表

現する。

• UC記述中、オブジェクトはバウンダリ、エ

ンティティとし、タスク・処理はコント

ローラとする。

•例）ログイン画面で、ユーザはIDとパス

ワードを入力する。システムは、ユーザの

最終ログイン日を取得し、現在日付との比

較結果が１ヶ月以内かを判定する。また、

ログイン情報と一致するかを判定する。シ

ステムは、判定結果を元にメニュー画面を

表示する。

ドメインモデルの更新１

•ロバストネス図を記述した結果、ドメイン

モデルに不足するオブジェクトがあれば追

加する。

•例えば、UC記述上ではユーザはアクターだ

が、判定処理を行う際にIDとパスワードは

どこに格納しておくのか？

•結果、「ユーザ情報」というエンティティ

（タスクの実行を補助判断する情報を格納

するオブジェクト）が必要であると考える

ことができる。

• IDとパスワードはユーザ情報の属性とする。

コントローラオブジェクトの識別

•ロバストネス分析の結果、次の箇所をコン

トローラの候補とする。

•「ユーザの最終ログイン日を取得」

•「現在日付との比較結果が１ヶ月以内かを

判定する」

•「ログイン情報と一致するかを判定する」

The ICONIX

Practical Method of OOAD 5

詳細設計

シーケンス図作成

•ロバストネス図から、バウンダリ、エン

ティティ、コントローラをシーケンス図に

反映する。

•例）ログイン画面とユーザ情報はオブジェ

クトとして表現する。

•例）「ユーザの最終ログイン日を取得」、

「現在日付との比較結果が１ヶ月以内かを

判定する」、「ログイン情報と一致するか

を判定する」、「メニュー画面を表示す

る」は相互作用（オブジェクト間のメッ

セージ）として表現する。

ドメインモデルの更新２

•シーケンス図を記述した結果、ドメインモ

デルのオブジェクトにメッセージを追加す

る。

•その他、メッセージのインプット（引数）、

アウトプット（戻り値）等からオブジェク

トに不足する属性を判断する。

•この結果、ドメインモデルはクラス図とし

て完成する。

シーケンス図の更新

• Java EEやフレームワークを利用する場合は、

RequestDispatcherの実装オブジェクトも

シーケンス図上で表現することでActorとオ

ブジェクト間の相互作用がより詳細に分か

るようになる。

The ICONIX

Practical Method of OOAD 6

実装

コーディング・ユニットテストの記述

•完成したクラス図を元にクラスを実装する。

•設計を元にユニットテストを記述する。

統合テスト・テストシナリオの実施

•設計を元に統合テスト、テストシナリオを

実装する。

•テストシナリオにおいては、ユースケース

を元に実装することでユースケーステスト

を設計することができる。

コードレビュー・各モデルの更新

•コードレビューを実施し、パターンの適用

や適切な責務の実装を促す。

•次のIterationに備えてモデルを更新する。

新たなテストシステムのビジネス要求

テストシステムの目的

想定するユースケースにおける欠陥の発見

テストシステムの構築方針

利用者の学習コストが少ないこと

利用者が既存の開発プロセスでも受け入れ易いテスト手法であること

利用者がテストの実装に専念できる事

テストシステム開発者（Java User）が保守し易いこと

OOADに基づきドメインオブジェクトとその相互関係を表したドメインモデルを作ること

複数の問題領域で共通するドメインオブジェクトの実装には既存のツールを積極活用し、個別に考察を必要とするドメインオブジェクトの実装に専念する

テストシステムがテスト対象システムの変更に強いこと

ドメインモデルとは

特定の領域（問題領域）を解決領域へと導く為に、それを構成する抽象的な概念（オブジェクト）同士の関係でその領域を表した図のこと

例えば、「テストをする」という行為を１つの業務（ビジネス領域）と捉え、「〇〇業務システムの回帰テストを実行したい」というビジネス要求を受けたとする

ドメインモデルを作ると、ビジネス要求から「〇〇業務システム」、「回帰テスト」というワードを元に、それらを構成するオブジェクトを抽出し、ビジネス要求が対象とするオブジェクトとオブジェクト間の関係をモデルとして表現出来る

ドメインオブジェクトとは

問題領域を構成する要素

例えば「〇〇業務システムの回帰テストを実行する」という問題領域では、以下をドメインオブジェクトの一例として挙げられる

〇〇業務システムへの要求、機能仕様

テストケース

テストシナリオ

テストシステム

テスト結果

「〇〇業務の回帰テストを達成すること」が一番の問題（本質）であり、「どのように回帰テストを達成するか」は一番では無い

どちらも実装される必要はあるが、本質的な部分（テストケース、テストシナリオ）の作り込みに専念する為に、ここでは本質でない部分（テストシステム）には外部の解決策を利用する手段を採用した

新たなテストシステムの機能要求

テストシステムの利用目的

シナリオの実行を通してユースケースの正しさを検討すること

対策も加味した新たな機能要求

テストケース表は従来の書式を踏襲しなければならない

従来のテスト実装から、キーワード駆動テストケース表が導出される必要がある

Pitalium、JUnitを活用して適用対象システムの改修、変更時に実装するオブジェクトを以下に限定する必要がある

テストケース表の取り込み（TestcaseLoader）

キーワード（Keyword）

ページオブジェクト（PageObject）

WebElementの変更による影響を一箇所に集約する必要がある

新たなテストシステムのユースケース

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

POI

Junit、Pitalium、AspectJ

ParameterizedRunner 、Parameters 、AssertView

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

Maven

テストケース表の作成

テスト対象への自然言語による操作を入手すると、テストシステムが処理可能なキキーワードを選択するセルを従来の表に追加

レイアウトは従来のままとし、テストケース表が参照するページオブジェクト一覧表の作成

テストシステムの要求分析設計の成果物

ユースケース図

ユースケース記述

ドメインモデル

ロバストネス図

シーケンス図

クラス図

テストスクリプトにおける適切なキーワードの検討• キーワードの粒度の検討ー先駆者の考え方を参考にした

• キーワードの実装方法の検討ーデザインパターンを参考にした

• キーワードの抽出方法の検討ーOOADによるオブジェクト抽出方法を参考にした

キーワードの粒度の検討ー 先駆者の考え方を参考にした

粒度の調整

「ドメイン言語 ＞ スクリプト言語 ＞ プログラム言語」

参考情報 51スライド

http://www.slideshare.net/koido1961/2015-56092163

「ISO/IEC/IEEE 29119-5」でも上記と同様に以下の表現で言及されている

ドメインレイヤーキーワード

例）ファイルを保存する（＝アクターに提供する一連の画面操作の組み合わせ）

コンテンツを取得する→メニューを選択する→保存する

アクターへ提供するシステムの振る舞いを表す為、ユースケースに近いと思う（私見）

テストインタフェースレイヤーキーワード（キーワードの実装部分）

例）メニューを選択する

キーワードの実装方法の検討 1/2

ー デザインパターンを参考にした

Command Pattern

「キーワード」をクラスとして定義し、OOADの恩恵（保守/拡張性）を受ける

DomainLayerKeyword Class

例）

Class ファイルを保存する

action()ファイルを保存する

1. コンテンツを取得する

2. メニューを選択する

3. 保存する

Class メニューを選択する

Action() メニューを選択する

1. メニューリンクをクリックする

Selenium-java等のライブラリを使い実装する

キーワードクラスのaction()内で別のキーワードクラスのaction()

を再帰的に呼び出している

キーワードの実装方法について 2/2

ー デザインパターンを参考にした

Bridge Pattern

機能のクラス階層が実装のクラス階層のインスタンスを保持し、役割を保持する

例）SaveFileAsXmlキーワードクラス

Implフィールド

SaveFileのインスタンス

or

SaveDBのインスタンス

saveFileAsXML_actionメソッド

rawSave_actionメソッドを実行する

機能のクラス階層（繰り返し階層化して深くなる）

実装のクラス階層（並列化して実装が増える）

キーワードの抽出方法についてー OOADによるオブジェクト抽出方法を参考にした

キーワードをオブジェクトとして扱うアーキテクチャにできた

テスト対象システムの要求分析設計にもICONIXを用いる

テスト対象システムのユースケース記述から、ドメインオブジェクトの抽出と同時に、「タスク・処理」の抽出も行うことになり、それを元にキーワードの抽出が出来る

また、この開発アプローチにより、同時にユースケーステストの為のシナリオを作成するテスト分析も出来た状態になる

この結果、キーワード駆動テストを実施しやすい環境を整えることができる

ICONIXによるテスト

対象の開発

「タスク・処理」の

抽出

キーワードの抽出キーワード駆動テス

トスクリプトの作成

キーワード駆動アプ

ローチによるテスト

キーワード駆動テストシステムの設計にもICONIXが使われている

ドメインオブジェクトからキーワードの抽出

「ファイルを保存する」ユースケース

ユースケース記述

「タスク・処理」の抽出

•ログイン画面で、ユーザはIDとパスワードを入力する。

•システムは、ユーザの最終ログイン日を取得し、

•現在日付との比較結果が１ヶ月以内かを判定する。•また、ログイン情報と一致するかを判定する。システムは、判定結果を元にメニュー画面を表示する。

•ユーザの最終ログイン日を取得する

•現在日付との比較結果が１ヶ月以内かを判定する

•ログイン情報と一致するかを判定する

•メニュー画面を表示する

キーワードの抽出

キーワードの精査

抽出結果を基に、キーワードを精査することで、無駄なくテストに必要なキーワードを抽出できる

•ログインする

＞Loginキーワード

•最終ログイン日を取得する

＞GetLastLoginTimestampキーワード

•現在日付との比較結果が１ヶ月以内かどうか比較する

＞AssertWithinAMonthキーワード

•一致するかどうか判定する

＞AssertAccountEqualsキーワード

•画面を表示する

＞DisplayKeywordキーワード

脆いテストへの対応• to be continued on Next time

• テストシステム上のロケータをテストケース表に取込可能にした

テストシステムの実装の省力化• to be continued on “Selenium AdventCalendar 2016”

• Pitaliumにテストシステムの基本機能を委譲した

• Selenium Server をdaemon（サービス）化した

テストシステムビルダー（Maven）

テストランナー（Pitalium based JUnit）

TestCaseLoder（POI）

テストケースファ

イル（Excel）

テストステップ

ファイル（Excel）

TestClass

KeywordInvokerClass

Abstruct Keyword Class

Concrete Keyword Class

PageLocator Class

リファクタリング後のテストシステム

テストシステムの構造Programming Part

Ptaliumに「WebDriverの管理」、「レポート」機能を委譲

selenium-javaを利用した「操作」、「ロケータ」の記述箇所

今後の展望

「脆いテストへの対応」への効果的な対策

キーワード駆動テストへ対応するテストタイプの拡張

まとめ実践を通して学んだこと、そして伝えたかったこと

大切だと思ったこと

難しく考えずに、はじめてみること

自動テストに対する要求が、課題として自然と湧いてくると思います

自動化する目的を明らかにすること

テスティングについて再考する場面に出会すと思います

テストの目的と自動テストの目的を分けて考えてみましょう

今大切にしたいと思うことを、開発方針に取り入れてみること

現状に合うテスト手法を検討することができると思います

取り組んだ結果を共有すること

誰かの助けになれば、それがいつか自分に返ってくると思います

より良い環境作りに向けて

これからもお互いに情報を提供し合い、より良い環境を整えていきましょう

本日はありがとうございました