STAR TABOK6.3-6.4

738 views

Published on

Published in: Technology
  • Be the first to comment

STAR TABOK6.3-6.4

  1. 1. TABOK  6.3Automated  Test  Execution,  Analysis,  and  Reporting⾃自動テストの実⾏行行、分析、報告 @goyoki
  2. 2. Short  Answer 「⾃自動テストの実⾏行行はやたら時間のかかる 退屈な作業であってはならない」 「テストは実⾏行行と分析が容易易になるようにグルーピングされ順序付けされなければならない」  
  3. 3. ⾃自動テストを開発したら•  次のステップ 1.  テストを組織化し、優先付けする 2.  テスト計画に基づいてAUTに実⾏行行。 そしてレポート結果を分析する
  4. 4. 6.3.1  Automated  Test  Grouping   ⾃自動テストのグルーピング
  5. 5. 6.3.1  Automated  Test  Grouping   ⾃自動テストのグルーピング•  ⾃自動テストのグルーピングは重要だ –  テストの数の増⼤大に対応するために –  テストの管理理や実⾏行行を容易易にするために•  グルーピングしておき、テスト実⾏行行の際 に必要なテストのグループを選択・実⾏行行 する
  6. 6. 6.3.1  Automated  Test  Grouping   ⾃自動テストのグルーピング•  グルーピングは合理理的な選択プロセスを 実現するために⾏行行う –  グルーピング例例 •  プライオリティ –  有⽤用度度のランキング •  機能の領領域 –  テストがカバーする主要なアプリケーションのサブシス テム •  テスト⽬目的 –  サニティテスト、リグレッションテスト等のテストオブ ジェクト
  7. 7. 6.3.1  Automated  Test  Grouping   ⾃自動テストのグルーピング•  テストのフレームワークは、保守や実⾏行行 をグループ単位で管理理できなければなら ない。結果報告もグループ単位でできる ようにならなければならない
  8. 8. 6.3.2  Automated  Test   Ordering  and  Execution  ⾃自動テストの順序付けと実⾏行行
  9. 9. 6.3.2  Automated  Test  Ordering  and  Execution   ⾃自動テストの順序付けと実⾏行行•  テストをグルーピングしたら次は実⾏行行•  テストの実⾏行行を確実に進めるためによく 考えよう –  実⾏行行・分析の時間が最⼩小化されていなければ ならない –  最も優先度度の⾼高い情報がすぐに得られなけれ ばならない
  10. 10. 6.3.2  Automated  Test  Ordering  and  Execution   ⾃自動テストの順序付けと実⾏行行•  注意すべきもの: –  テスト実⾏行行のドミノ効果 –  (Test  Execution  Domino  Effect)•  例例題 –  「Figure  6-‐‑‒6:  Test  Execution  Domino  Effect  」   –  100のテストのつらなり –  テスト2は他のテストから独⽴立立。失敗の影響はない –  テスト5は、失敗するとドミノ効果として残りのテ ストを崩壊させる –  例例外の適切切な対処で症状を軽減することはできても、 完全防⽌止は困難
  11. 11. 6.3.2  Automated  Test  Ordering  and  Execution   ⾃自動テストの順序付けと実⾏行行Test  Execution  Domino  Effect(テスト実⾏行行でのドミノ効果) ⾃自動テストの実⾏行行順序テスト テスト テスト テスト 延々と続く 問題発⽣生 後続のテストに悪影響を与える ドミノのように総崩れにさせる
  12. 12. 6.3.2  Automated  Test  Ordering  and  Execution   ⾃自動テストの順序付けと実⾏行行•  テスト実⾏行行をより効果的・効率率率的にする アプローチがいくつかある 1.  最初にサニティテストを実⾏行行する 2.  最初に⼩小さく不不安定でないテストを実⾏行行する 3.  複数マシンでテストを並列列実⾏行行する 4.  システム稼働率率率が低い時期にテストを実⾏行行する 5.  継続的インテグレーションプロセスの⼀一部としてテ ストを実⾏行行する
  13. 13. 1.最初にサニティテストを実⾏行行する•  サニティテスト: –  厳密なテストの実⾏行行前にアプリケーションの 安定性を確かめるハイレベルのテスト –  最初に実⾏行行することで、続く⾃自動テストを実 ⾏行行するかどうかの判断情報を把握できる –  サニティテストの結果に基づいて各種決定が できる
  14. 14. 2.最初に⼩小さく不不安定でない テストを実⾏行行する•  シンプル化戦略略は⼀一般的に良良い戦略略 –  ⻑⾧長⼤大なテストは、破局的な問題を誘発する•  ⼩小さく安定したテストから実⾏行行すると、 失敗の悪影響を抑えつつ、テスト実⾏行行を 問題なく完了了する可能性を⾼高める。
  15. 15. 3.複数マシンでテストを 並列列実⾏行行する•  複数マシンへの分散は、⾃自動テストスイート の実⾏行行時間を削減する有⽤用なアプローチ•  「Figure  6-‐‑‒7:  Parallel  Test  Execution  」•  並⾏行行テスト実⾏行行を実現するための仕組みの例例 –  複数マシンに対する⼿手動アクセス –  分散テスト –  サーバ仮想化
  16. 16. (複数マシンでテストを並列列実⾏行行する)複数マシンに対する⼿手動アクセス•  「複数マシンに対する⼿手動アクセス」は、 幾つかの物理理的なコンピュータラボを利利 ⽤用する組織にとって、⼀一般的なアプロー チであることがある•  このアプローチのControllerは、アクセス 担当の代表
  17. 17. (複数マシンでテストを並列列実⾏行行する) 分散テスト•  中央が他の複数ヶ所のテストを実⾏行行する•  ⼈人⼿手で機械にアクセスする⼿手間を省省く•  多くの⾃自動テストツールがサポートして いる。•  テスト実⾏行行機能以外にも、各環境間のコ ミュニケーションもサポートしている•  このアプローチでのControllerは中央のマ シン
  18. 18. (複数マシンでテストを並列列実⾏行行する) サーバ仮想化•  ⼿手動アプローチ、分散アプローチでも実⾏行行で きる•  Execution  Machineが物理理的なマシンでない•  形態はプロビジョニングであり、⼀一つのハー ドウェア上で複数のサーバを使⽤用する•  このアプローチではExecution  Machineは バーチャルマシンとなる –  ⾃自動テストツールを使⽤用する
  19. 19. 4.システム稼働率率率が低い時期 でのテスト実⾏行行•  テストシステムが多数のユーザや多数の プロセスをさばいている間は、システム がスローダウンする•  ⾃自動テストも同様に影響を受ける•  そのためテストシステムが頻繁に使⽤用さ れていない期間にテストを実⾏行行するアプ ローチが有効 –  多くの⼈人達が仕事をやめる⼣夕⽅方ごろがしばし ば有効期間
  20. 20. 5.  継続的インテグレーションサイクルの ⼀一部としてのテスト実⾏行行•  CIは⾃自動ビルドプロセスと⾃自動結合テストの 環境として頻繁に⽤用いられる•  CIでの⼀一般的な実⾏行行タイミング –  コードの追加・更更新が構成管理理へチェックインさ れたとき –  ⼀一⽇日あたり最低でも⼀一回以上のスケジューリング されたタイミング•  システムへのバグ混⼊入の特定に有効•  ⼀一般的にコードの変更更が⼩小さければ、結果分 析が簡便便かつ効果的になる
  21. 21. 6.3.3  Automated  Test  Results   Analysis ⾃自動テストの結果分析
  22. 22. テストが⽣生成するもの•  テスト実⾏行行ログ•  テスト実⾏行行レポート•  不不具合報告
  23. 23. テストが⽣生成するもの•  テスト実⾏行行ログ/テスト実⾏行行レポート –  しばしば⾃自動で⽣生成 –  AUTがどのように機能しているか理理解・分析 するための情報•  不不具合報告 –  しばしば⼈人⼿手で作成
  24. 24. 6.4  Resource  References  for   Skill  Category  6•  別途説明

×