goyoki 2015/1/18 @STAR

TEST AUTOMATION PATTERNS

Design Patterns

1

¡ Test Automation PatternsにおけるDesign Patternの全体像を解説するための資料 § http://testautomationpatterns.wikispaces.com/Design+Patterns

¡ Descriptionの翻訳と、「一部内容抜粋＋口頭」の補則で、各パターンを紹介 § ※（作成途上なのか）多くの対象がパターン言語の形式を満たしていない そのため本資料では、コンテキスト、フォースなどには触れていない

2

この資料について

¡ 位置づけ § 自動テストのテストウェア設計についてのパターン集

§ Design Issueへの対応手段を示す

§ 設計のパターンだけでなく、設計の進め方についての原則・アプローチ・心がけも含む

¡ 完成度 § ごった煮・中途半端・作成途中多い § 洗練されたデザインパターン集を欲するならxUnit Test Patternsがおすすめ

DESIGN PATTERNSの内容

3

¡ Description § １つ以上の抽象化レイヤをテストウェアに設ける

¡ 補則 § 保守性の改善のため § レイアアーキテクチャをテストウェアの様々なところで活用するというもの

§ 実施例 § データ駆動テスト、キーワード駆動テスト、モデルベーステストなど

4

ABSTRACTION LEVELS

¡ Description § ROIがもっとも良くなるテストを自動化する

¡ 補則 § 典型的な候補はスモークテスト、リグレッションテスト、複数環境に対するテスト、複雑なテストなど

5

AUTOMATE GOOD TESTS

¡ Description § メトリクス収集を自動化する

¡ 補則 § テスト自動化環境では、メトリクス収集の自動化が容易

§ 実現が難しいならテスト自動化フレームワークの導入を検討しよう

§ メトリクス § 実行したテストの数、パスしたテストの数、テスト実行時間、除去されたエラー数、再テスト数など

6

AUTOMATE THE METRICS

¡ Description § ツールでマニュアルテストの操作を記録。 次回以降のテストではそれを自動リプライする

¡ 補則 § DDT導入時の事前ステップとして紹介されている

7

CAPTURE-REPLAY

¡ Description § 事前定義したシーケンスにしたがってテストを実行する

¡ 補則 § 全体の初期化を行い、そして順序付けしたテストを実行していく

8

CHAINED TESTS

¡ Description § 外部ファイルからデータを読むこむ形式で、テストケースのスクリプトを記述する

¡ 補則 § 既知の通り。詳細割愛 § テストデータをデータのリストで表現。

9

DATA-DRIVEN TESTING

¡ Description § 単純なデータ入力では、デフォルトデータを用いる

¡ 補則 § 大量かつ複雑なデータを扱う際に、データ管理を簡便化するために実施

§ 何でもよい値にデフォルトデータを用いて、大事なデータに注力

10

DEFAULT DATA

¡ Description § テストウェアを再利用可能に設計する

¡ 補則 § モジュール化しよう。凝集性を高めよう。変更の影響範囲を限定するようにしよう

§ 実装例 § Single Page Scripts、Tool Independence

11

DESIGN FOR REUSE

¡ Description § テストが日付条件から独立するように、テストケースを作成する

¡ 補則 § 実装例 § テスト開始前に時刻を任意の値に設定し、テスト終了後元に戻すシーケンスなど

12

DATE INDEPENDENCE

¡ Description § テスターが自動テストを書くためのDSLを開発する

¡ 補則 § テスト自動化フレームワークを必要とする § 紹介されているDSLの記述例 § New_Partner (FirstName, LastName, Street, StreetNo,

ZipCode, City, State)

13

DOMAIN-DRIVEN TESTING

¡ Description § できれば既知のノウハウ、ツール、プロセスを活用する

¡ 補則 § 「車輪の再発明を避ける」の文字通り

14

DON'T REINVENT THE WHEEL

¡ Description § 各テストの実行前に、スクラッチで初期状態を準備する。テスト後のクリーンアップを行わない

¡ 補則 § テストの独立性を高められる § 実装例 § VMのスナップショット、ファイルコピー、DBのテーブルコピーなど

15

FRESH SETUP

¡ Description § 自己完結するようにそれぞれの自動テストケースを作る

¡ 補則 § 目指すもの § 各テストケースをばらばらに実行できる。テストケースが失敗しても、他のテストケースに影響を与えない

§ 実装例 § Fresh Setup

16

INDEPENDENT TEST CASES

¡ Description § 考えられる中で もシンプルな解決方法を使う

¡ 補則 § 言葉通り。アジャイルでよく言われるKISSの原則と同じ

17

KEEP IT SIMPLE

¡ Description § テストのアクション、入力データ、期待結果を表現するキーワードで、テスト実行を駆動する

¡ 補則 § 既知なので詳細割愛 § テストのアクション含めて、キーワードのリストでテストを記述

§ フレームワーク必須

18

KEYWORD-DRIVEN TESTING

¡ Description § SUTの小さな変更ごとに更新しなくてすむように、テストウェアを設計する

¡ 補則 § 様々な観点でテストウェアの保守性を高める § 推奨されるプログラミングプラクティスを使う

§ Object Mapなど

§ よい開発プロセスに従う § ドメイン駆動テストを導入する

19

MAINTAINABLE TESTWARE

¡ Description § SUTのモデルからテストケースを派生させる。一般的に自動テストケースのジェネレータを使用する

¡ 補則 § モデルに対するカバレッジの向上、テストの保守工数削減に有効

§ 開発初期から、開発を巻き込んで対象をモデリングしていかなければならない

20

MODEL-BASED TESTING

¡ Description § テストはゴミを作らないか、ゴミを作ってもテストが削除する

¡ 補則 § コンテンツほぼなし。

21

NO LITTERING

¡ Description § 一つの明確な目的ごとにテストを作成する

¡ 補則 § 効率的で保守性の高いテストウェアを構築するために実施

§ １つのビジネス・ルールに紐づくテスト目的の１つのみに、各テストケースが対応する

22

ONE CLEAR PURPOSE

¡ Description § 読み手が理解しやすいようにレポートを設計する

¡ 補則 § 工夫の例 § テストがパスしたかどうか、失敗した場合なぜかを見やすくする

§ マネジメント上の課題の傾向を示すメトリクスを生成する

§ 読み手に応じたレベル分けを行う

23

READABLE REPORTS

¡ Description § インタラクションレベルごとのアプローチとリスクを把握する

¡ 補則 § インタラクションレベルのリスクを理解すること § インタラクションレベルに応じて、効果、実装やリスクが異なる § エンドユーザのIFでSUTを操作

§  SUTは改造されず、リスク少ない。組み込みでは高価 § テスト用のIFや設計をSUTに組み込む

§  SUTの改造で、不具合の誤検出・見逃しリスクを高める

24

RIGHT INTERACTION LEVEL

¡ Description § 全テストのためのデータやその他事前条件は、自動テストスイートの開始前にセットする

¡ 補則 § 長時間のセットアップへの対策などが理由 § 各テストケースのSetup、Clean Upの実装が必要

25

SHARED SETUP

¡ Description § 画面あるいはページを単位にテストスクリプトを開発する

¡ 補則 § SeleniumでいうPage Objectである § 既知のため割愛

26

SINGLE PAGE SCRIPTS

¡ Description § テスト自動化フレームワークを使用する

¡ 補則 § テスト自動化の様々な課題を解決するためのフレームワークを使おう § レイヤ構造の導入、テスト結果の報告、テストの記述支援など

§ いろいろなものが存在するし、自分たちで作っても良い

27

TEST AUTOMATION FRAMEWORK

¡ Description § テストを実行するかどうかの選択基準について、様々な基準を使えるようにテストケースを実装する

¡ 補則 § スモークテスト、リグレッションテストなど特定のテストを選択実行できるように、タグといった仕組みを用いる

28

TEST SELECTOR

¡ Description § テストオートメータやテスターが、出来る限り効率的に動けるように、テストウェアの構造を設計する

¡ 補則 § 速く・楽に作業ができるように、様々な観点でテストウェアのアーキテクチャを工夫する § テストデータの編集競合を防ぐため、構成管理を整備しよう § ツールは便利だが、長期的な視点で見るとツールに縛られマイナスの影響が大きくなるかもしれない

§ テストログは必要なもののみ管理

§ 構築には手間と工数が必要だが、成果は大きい

29

TESTWARE ARCHITECTURE

¡ Description §  高の自動化ソリューションは、しばしば もクリエイティブなものである

¡ 原則 § クリエイティブにいこう § クリエイティブなやりかた § KEEP IT SIMPLE、TAKE SMALL STEPでとにかく進もう § 開発者含めみんなで問題を共有して解決を目指そう § インターネットで調べよう。解決情報が載ってるかも § 寝よう

30

THINK OUT-OF-THE-BOX

¡ Description § ツールのための技術的な実装を、機能的な実装から切り離す

¡ 補則 § ツール依存のコードとテストを分離する § マルチプラットフォーム対応やツールの切り替えを容易にする

31

TOOL INDEPENDENCE

¡ Description § 可能な限り効率的に、他ツールへ移植する

¡ 補則 § Descriptionのみ。 コンテンツ無し（空白ページ）

32

TOOL MIGRATION