Downloaded 22 times
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 FunctionalSystem Test Automation 9 機能システムテスト 機能テスト、かつ、システムテスト 完全に統合されたアプリケーションに対し、ブラックボッ クスアプローチで振る舞いをテスト 本書では簡単のため「functional test」と表記 たいていテスト自動化の対象はこの工程 機能システムテスト自動化 GUIアプリケーションに対する回帰テストを対象 にすることが多い テスト自動化・TABOK研究会 12/05/13
- 10. + 2.1.4 PerformanceTest Automation(1) 10 パフォーマンステスト レスポンスタイムのボトルネックを特定／スルー プットを測定 システム機能テストが完了した段階で実施するの が理想 理想すぎやしないか？ 手動での実施は困難 多数のユーザによる同時利用などの場合、人手不足となる 正確な測定が難しい パフォーマンステスト自動化 テスト自動化・TABOK研究会 12/05/13
- 11. + 2.1.4 PerformanceTest Automation(2) 11 パフォーマンステスト自動化 仮想ユーザによる同時多数接続、データ量とパ フォーマンスの相関算出などを実施 ボトルネック発見時はレイヤーを切り分けて詳細 に原因究明 レイヤーごとに有識者を確保する必要あり レイヤー 原因の例 プレゼンテーション層 効率の悪いアルゴリズム DB層 効率の悪いクエリ OS層 リソース不足 ネットワーク層 狭い帯域 テスト自動化・TABOK研究会 12/05/13
- 12. + 2.1.4 PerformanceTest 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. + ご清聴ありがとうございました