Upload
h-iseri
View
432
Download
2
Embed Size (px)
Citation preview
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 § 1つ以上の抽象化レイヤをテストウェアに設ける
¡ 補則 § 保守性の改善のため § レイアアーキテクチャをテストウェアの様々なところで活用するというもの
§ 実施例 § データ駆動テスト、キーワード駆動テスト、モデルベーステストなど
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 § 一つの明確な目的ごとにテストを作成する
¡ 補則 § 効率的で保守性の高いテストウェアを構築するために実施
§ 1つのビジネス・ルールに紐づくテスト目的の1つのみに、各テストケースが対応する
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