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

17. +
ご清聴ありがとうございました