Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Test Automation PatternsにおけるDesign Patterns

1,234 views

Published on

for STAR

Published in: Technology
  • Be the first to comment

Test Automation PatternsにおけるDesign Patterns

  1. 1. goyoki 2015/1/18 @STAR TEST AUTOMATION PATTERNS Design Patterns 1
  2. 2. ¡ Test Automation PatternsにおけるDesign Patternの全体像を解説するための資料 § http://testautomationpatterns.wikispaces.com/ Design+Patterns ¡ Descriptionの翻訳と、「一部内容抜粋+ 口頭」の補則で、各パターンを紹介 § ※(作成途上なのか)多くの対象がパターン 言語の形式を満たしていない そのため本資料では、コンテキスト、フォー スなどには触れていない 2 この資料について
  3. 3. ¡ 位置づけ § 自動テストのテストウェア設計についてのパターン集 § Design Issueへの対応手段を示す § 設計のパターンだけでなく、設計の進め方についての 原則・アプローチ・心がけも含む ¡ 完成度 § ごった煮・中途半端・作成途中多い § 洗練されたデザインパターン集を欲するなら xUnit Test Patternsがおすすめ DESIGN PATTERNSの内容 3
  4. 4. ¡ Description § 1つ以上の抽象化レイヤをテストウェアに設ける ¡ 補則 § 保守性の改善のため § レイアアーキテクチャをテストウェアの様々なと ころで活用するというもの § 実施例 § データ駆動テスト、キーワード駆動テスト、モデルベー ステストなど 4 ABSTRACTION LEVELS
  5. 5. ¡ Description § ROIがもっとも良くなるテストを自動化する ¡ 補則 § 典型的な候補はスモークテスト、リグレッ ションテスト、複数環境に対するテスト、複 雑なテストなど 5 AUTOMATE GOOD TESTS
  6. 6. ¡ Description § メトリクス収集を自動化する ¡ 補則 § テスト自動化環境では、メトリクス収集の自動化 が容易 § 実現が難しいならテスト自動化フレームワークの 導入を検討しよう § メトリクス § 実行したテストの数、パスしたテストの数、テスト実行 時間、除去されたエラー数、再テスト数など 6 AUTOMATE THE METRICS
  7. 7. ¡ Description § ツールでマニュアルテストの操作を記録。 次回以降のテストではそれを自動リプライす る ¡ 補則 § DDT導入時の事前ステップとして紹介されて いる 7 CAPTURE-REPLAY
  8. 8. ¡ Description § 事前定義したシーケンスにしたがってテスト を実行する ¡ 補則 § 全体の初期化を行い、そして順序付けしたテ ストを実行していく 8 CHAINED TESTS
  9. 9. ¡ Description § 外部ファイルからデータを読むこむ形式で、 テストケースのスクリプトを記述する ¡ 補則 § 既知の通り。詳細割愛 § テストデータをデータのリストで表現。 9 DATA-DRIVEN TESTING
  10. 10. ¡ Description § 単純なデータ入力では、デフォルトデータを 用いる ¡ 補則 § 大量かつ複雑なデータを扱う際に、データ管 理を簡便化するために実施 § 何でもよい値にデフォルトデータを用いて、 大事なデータに注力 10 DEFAULT DATA
  11. 11. ¡ Description § テストウェアを再利用可能に設計する ¡ 補則 § モジュール化しよう。凝集性を高めよう。変 更の影響範囲を限定するようにしよう § 実装例 § Single Page Scripts、Tool Independence 11 DESIGN FOR REUSE
  12. 12. ¡ Description § テストが日付条件から独立するように、テス トケースを作成する ¡ 補則 § 実装例 § テスト開始前に時刻を任意の値に設定し、テスト終 了後元に戻すシーケンスなど 12 DATE INDEPENDENCE
  13. 13. ¡ Description § テスターが自動テストを書くためのDSLを開発 する ¡ 補則 § テスト自動化フレームワークを必要とする § 紹介されているDSLの記述例 § New_Partner (FirstName, LastName, Street, StreetNo, ZipCode, City, State) 13 DOMAIN-DRIVEN TESTING
  14. 14. ¡ Description § できれば既知のノウハウ、ツール、プロセス を活用する ¡ 補則 § 「車輪の再発明を避ける」の文字通り 14 DON'T REINVENT THE WHEEL
  15. 15. ¡ Description § 各テストの実行前に、スクラッチで初期状態 を準備する。テスト後のクリーンアップを行 わない ¡ 補則 § テストの独立性を高められる § 実装例 § VMのスナップショット、ファイルコピー、DBの テーブルコピーなど 15 FRESH SETUP
  16. 16. ¡ Description § 自己完結するようにそれぞれの自動テスト ケースを作る ¡ 補則 § 目指すもの § 各テストケースをばらばらに実行できる。テスト ケースが失敗しても、他のテストケースに影響を与 えない § 実装例 § Fresh Setup 16 INDEPENDENT TEST CASES
  17. 17. ¡ Description § 考えられる中で最もシンプルな解決方法を使 う ¡ 補則 § 言葉通り。アジャイルでよく言われるKISSの 原則と同じ 17 KEEP IT SIMPLE
  18. 18. ¡ Description § テストのアクション、入力データ、期待結果 を表現するキーワードで、テスト実行を駆動 する ¡ 補則 § 既知なので詳細割愛 § テストのアクション含めて、キーワードのリ ストでテストを記述 § フレームワーク必須 18 KEYWORD-DRIVEN TESTING
  19. 19. ¡ Description § SUTの小さな変更ごとに更新しなくてすむよう に、テストウェアを設計する ¡ 補則 § 様々な観点でテストウェアの保守性を高める § 推奨されるプログラミングプラクティスを使う § Object Mapなど § よい開発プロセスに従う § ドメイン駆動テストを導入する 19 MAINTAINABLE TESTWARE
  20. 20. ¡ Description § SUTのモデルからテストケースを派生させる。 一般的に自動テストケースのジェネレータを 使用する ¡ 補則 § モデルに対するカバレッジの向上、テストの 保守工数削減に有効 § 開発初期から、開発を巻き込んで対象をモデ リングしていかなければならない 20 MODEL-BASED TESTING
  21. 21. ¡ Description § テストはゴミを作らないか、ゴミを作っても テストが削除する ¡ 補則 § コンテンツほぼなし。 21 NO LITTERING
  22. 22. ¡ Description § 一つの明確な目的ごとにテストを作成する ¡ 補則 § 効率的で保守性の高いテストウェアを構築す るために実施 § 1つのビジネス・ルールに紐づくテスト目的 の1つのみに、各テストケースが対応する 22 ONE CLEAR PURPOSE
  23. 23. ¡ Description § 読み手が理解しやすいようにレポートを設計 する ¡ 補則 § 工夫の例 § テストがパスしたかどうか、失敗した場合なぜかを 見やすくする § マネジメント上の課題の傾向を示すメトリクスを生 成する § 読み手に応じたレベル分けを行う 23 READABLE REPORTS
  24. 24. ¡ Description § インタラクションレベルごとのアプローチとリス クを把握する ¡ 補則 § インタラクションレベルのリスクを理解すること § インタラクションレベルに応じて、効果、実装や リスクが異なる § エンドユーザのIFでSUTを操作 §  SUTは改造されず、リスク少ない。組み込みでは高価 § テスト用のIFや設計をSUTに組み込む §  SUTの改造で、不具合の誤検出・見逃しリスクを高める 24 RIGHT INTERACTION LEVEL
  25. 25. ¡ Description § 全テストのためのデータやその他事前条件は、 自動テストスイートの開始前にセットする ¡ 補則 § 長時間のセットアップへの対策などが理由 § 各テストケースのSetup、Clean Upの実装が必 要 25 SHARED SETUP
  26. 26. ¡ Description § 画面あるいはページを単位にテストスクリプ トを開発する ¡ 補則 § SeleniumでいうPage Objectである § 既知のため割愛 26 SINGLE PAGE SCRIPTS
  27. 27. ¡ Description § テスト自動化フレームワークを使用する ¡ 補則 § テスト自動化の様々な課題を解決するための フレームワークを使おう § レイヤ構造の導入、テスト結果の報告、テストの記 述支援など § いろいろなものが存在するし、自分たちで 作っても良い 27 TEST AUTOMATION FRAMEWORK
  28. 28. ¡ Description § テストを実行するかどうかの選択基準につい て、様々な基準を使えるようにテストケース を実装する ¡ 補則 § スモークテスト、リグレッションテストなど 特定のテストを選択実行できるように、タグ といった仕組みを用いる 28 TEST SELECTOR
  29. 29. ¡ Description § テストオートメータやテスターが、出来る限り効率的 に動けるように、テストウェアの構造を設計する ¡ 補則 § 速く・楽に作業ができるように、様々な観点でテスト ウェアのアーキテクチャを工夫する § テストデータの編集競合を防ぐため、構成管理を整備しよう § ツールは便利だが、長期的な視点で見るとツールに縛られマ イナスの影響が大きくなるかもしれない § テストログは必要なもののみ管理 § 構築には手間と工数が必要だが、成果は大きい 29 TESTWARE ARCHITECTURE
  30. 30. ¡ Description § 最高の自動化ソリューションは、しばしば最もク リエイティブなものである ¡ 原則 § クリエイティブにいこう § クリエイティブなやりかた § KEEP IT SIMPLE、TAKE SMALL STEPでとにかく進もう § 開発者含めみんなで問題を共有して解決を目指そう § インターネットで調べよう。解決情報が載ってるかも § 寝よう 30 THINK OUT-OF-THE-BOX
  31. 31. ¡ Description § ツールのための技術的な実装を、機能的な実 装から切り離す ¡ 補則 § ツール依存のコードとテストを分離する § マルチプラットフォーム対応やツールの切り 替えを容易にする 31 TOOL INDEPENDENCE
  32. 32. ¡ Description § 可能な限り効率的に、他ツールへ移植する ¡ 補則 § Descriptionのみ。 コンテンツ無し(空白ページ) 32 TOOL MIGRATION

×