Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Test Automation PatternsにおけるDesign Patterns

1.571 visualizaciones

Publicado el

for STAR

Publicado en: Tecnología
  • Inicia sesión para ver los comentarios

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

×