Weitere ähnliche Inhalte
Ähnlich wie TABOK Skill Category2解説 (20)
Mehr von Kinji Akemine (7)
Kürzlich hochgeladen (12)
TABOK Skill Category2解説
- 1. +
テスト自動化・TABOK研究会
Skill Category 2 : Test Automation Types and Interfaces
担当者:朱峰錦司(@kjstylepp)
- 2. + 2
Skill Category 2 導入
テスト自動化には多様な分野・種類が存在
異なる種類同士の違いを理解することで得られる
メリット
知識・技術の体系化できる
組織間のコミュニケーションが円滑になる
新技術の成熟が促進される
テスト自動化・TABOK研究会 12/05/13
- 3. + 3
目次
2.1 Test Automation Types
2.1.1 Unit Test Automation
2.1.2 Integration Test Automation
2.1.3 Functional System Test Automation
2.1.4 Performance Test Automation
2.2 Application Interfaces
テスト自動化・TABOK研究会 12/05/13
- 4. +
2.1
Test Automation Types
テスト自動化・TABOK研究会 12/05/13
- 5. + 5
2.1 概要
テスト自動化は一般的に以下の4種類に分類
できる
1. ユニットテスト自動化
2. 統合テスト自動化 V字モデルの右側のイメージ
3. 機能システムテスト自動化 機能システム パフォーマンス
4. パフォーマンステスト自動化 テスト テスト
非機能要件代表 統合
※他は自動化の必要なし or 困難 テスト
ユニッ ホワイトボックス
トテス テスト扱い
ト は一般的か?
テスト自動化・TABOK研究会 12/05/13
- 6. + 6
2.1.1 Unit Test Automation(1)
定義は人によってまちまち
ユニットテスト
テスト可能な最小単位の振る舞いをテスト
テスト時はドライバ/スタブを利用
コード変更時の問題(≒デグレ)早期発見に有効
ビルド時に自動実行されると効力が最大化
手動+目視確認でも実施可能だが、コードが複雑
になるにつれて厳しくなる
カバレッジの確保が大変
実施が退屈
ユニットテスト自動化
テスト自動化・TABOK研究会 12/05/13
- 7. + 7
2.1.1 Unit Test Automation(2)
ユニットテスト自動化
テストコードはたいていプロダクトコードと同じ
言語で実現(ex. Java -> JUnit)
プロダクトコードより前、または同時に書くのが理想
構成管理もプロダクトコードと同等に実施
プロダクトコード開発者がテストコードも書くの
が一般的
方法論によっては、テスト専門家がシナリオを作成を支援
テストハーネス等を用いて、複数のユニットテス
トをまとめて定期的に実行可能
テスト実装・実施環境などを含んだフレームワーク
※詳細はISTQBを参照のこと
テスト自動化・TABOK研究会 12/05/13
- 8. + 8
2.1.2 Integration Test Automation
統合テスト
ユニットを統合して振る舞いをテスト
統合テスト自動化
自動化のアプローチはユニットテストと一緒
2つの統合していく順序の方針
どっちがいいかは
1. トップダウン Case by Case?
呼び出し階層が上位のユニットから順に統合
ドライバが減るがスタブが増える
2. ボトムアップ統合
呼び出し階層が下位のユニットから順に統合
スタブが減るがドライバが増える
テスト自動化・TABOK研究会 12/05/13
- 9. + 2.1.3 Functional System Test Automation 9
機能システムテスト
機能テスト、かつ、システムテスト
完全に統合されたアプリケーションに対し、ブラックボッ
クスアプローチで振る舞いをテスト
本書では簡単のため「functional test」と表記
たいていテスト自動化の対象はこの工程
機能システムテスト自動化
GUIアプリケーションに対する回帰テストを対象
にすることが多い
テスト自動化・TABOK研究会 12/05/13
- 10. + 2.1.4 Performance Test Automation(1) 10
パフォーマンステスト
レスポンスタイムのボトルネックを特定/スルー
プットを測定
システム機能テストが完了した段階で実施するの
が理想 理想すぎやしないか?
手動での実施は困難
多数のユーザによる同時利用などの場合、人手不足となる
正確な測定が難しい
パフォーマンステスト自動化
テスト自動化・TABOK研究会 12/05/13
- 11. + 2.1.4 Performance Test Automation(2) 11
パフォーマンステスト自動化
仮想ユーザによる同時多数接続、データ量とパ
フォーマンスの相関算出などを実施
ボトルネック発見時はレイヤーを切り分けて詳細
に原因究明
レイヤーごとに有識者を確保する必要あり
レイヤー 原因の例
プレゼンテーション層 効率の悪いアルゴリズム
DB層 効率の悪いクエリ
OS層 リソース不足
ネットワーク層 狭い帯域
テスト自動化・TABOK研究会 12/05/13
- 12. + 2.1.4 Performance Test Automation(3) 12
パフォーマンステストと似たテスト
ロードテスト
基本的にはパフォーマンステストと一緒
上限に向けて徐々にデータ量を増やしていくのが特徴
ストレステスト
上限を超えて、実際にアプリケーションが正常に動作しな
くなるまで実施するのが特徴
パフォーマンステストの定義が明確でないため、
差異がよくわかっていません…
テスト自動化・TABOK研究会 12/05/13
- 13. +
2.2
Application Interfaces
テスト自動化・TABOK研究会 12/05/13
- 14. + 14
2.2 概要
テスト自動化に適したアプリケーションイン
タフェースは以下の4つである
1. CLI
テスト実装がしやすい
2. API
3. GUI
4. Webサービス・インタフェース
ユーザの操作の再現という点で一番相性がよい
※@snskさんのブログでの説明のニュアンスはちょっと違うかも?
※「CUI」は和製英語なので英語圏で使うとかっこわるいかも?
テスト自動化・TABOK研究会 12/05/13
- 15. + 15
2.2 各インタフェースについて(1)
Command Line Interface
コマンドを効率よくやり取りするテキストベースのメ
カニズム
たいていのスクリプト言語はコマンドラインインタプ
リタを実現可能なため、これを用いてテスト自動化を
実現可能
なぜスクリプト言語限定?
Application Programming Interface
プログラム呼び出し等で利用可能なアプリケーション
再利用メカニズム
たいていのスクリプト言語は外部プログラム呼び出し
が可能なため、これを用いてテスト自動化を実現可能
テスト自動化・TABOK研究会 12/05/13
- 16. + 16
2.2 各インタフェースについて(2)
Graphical User Interface
アイコンなどの操作によりアプリケーションを利用可
能とするメカニズム
UIの変更時、内部構造の変更時に比べて自動テスト資
産の保守性の維持が困難
しかし、直感的な自動化のため需要は多く、たいてい
の取り組みはGUIアプリケーションが対象
Web Service Interface
ネットワークごしに利用可能なアプリケーション再利
用メカニズム
メッセージベースのオープンなプロトコルによる利用
を想定してるため、これを再現することでテスト自動
化を実現可能
テスト自動化・TABOK研究会 12/05/13