tabok skill category2解説

+

テスト自動化・ TABOK 研究会 Skill Category 2 : Test Automation Types and Interfaces

担当者：朱峰錦司 (@kjstylepp)

2+Skill Category 2 導入

テスト自動化には多様な分野・種類が存在異なる種類同士の違いを理解することで得られる

メリット知識・技術の体系化できる組織間のコミュニケーションが円滑になる新技術の成熟が促進される

12/05/13テスト自動化・ TABOK 研究会

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


+

2.1Test Automation Types


5+2.1 概要

テスト自動化は一般的に以下の 4 種類に分類できる1. ユニットテスト自動化2. 統合テスト自動化3. 機能システムテスト自動化4. パフォーマンステスト自動化


ユニットテス

ト

統合テスト

機能システムテスト

パフォーマンステスト

V 字モデルの右側のイメージ

非機能要件代表※ 他は自動化の必要なし or 困難

ホワイトボックステスト扱い

は一般的か？

6+2.1.1 Unit Test Automation(1)

ユニットテストテスト可能な最小単位の振る舞いをテスト

テスト時はドライバ／スタブを利用コード変更時の問題（≒デグレ）早期発見に有効

ビルド時に自動実行されると効力が最大化

手動＋目視確認でも実施可能だが、コードが複雑になるにつれて厳しくなるカバレッジの確保が大変実施が退屈


定義は人によってまちまち

ユニットテスト自動化

7+2.1.1 Unit Test Automation(2)

ユニットテスト自動化テストコードはたいていプロダクトコードと同じ

言語で実現（ ex. Java -> JUnit ）

プロダクトコードより前、または同時に書くのが理想構成管理もプロダクトコードと同等に実施プロダクトコード開発者がテストコードも書くの

が一般的方法論によっては、テスト専門家がシナリオを作成を支

援テストハーネス等を用いて、複数のユニットテス

トをまとめて定期的に実行可能


テスト実装・実施環境などを含んだフレームワーク※ 詳細は ISTQB を参照のこと

8+2.1.2 Integration Test Automation統合テスト

ユニットを統合して振る舞いをテスト

統合テスト自動化自動化のアプローチはユニットテストと一緒 2 つの統合していく順序の方針

1. トップダウン呼び出し階層が上位のユニットから順に統合ドライバが減るがスタブが増える

2. ボトムアップ統合呼び出し階層が下位のユニットから順に統合スタブが減るがドライバが増える


どっちがいいかはCase by Case?

9+2.1.3 Functional System Test Automation機能システムテスト

機能テスト、かつ、システムテスト完全に統合されたアプリケーションに対し、ブラック

ボックスアプローチで振る舞いをテスト本書では簡単のため「 functional test 」と表記

たいていテスト自動化の対象はこの工程

機能システムテスト自動化 GUI アプリケーションに対する回帰テストを対象

にすることが多い


10+2.1.4 Performance Test Automation(1)パフォーマンステスト

レスポンスタイムのボトルネックを特定／スループットを測定

システム機能テストが完了した段階で実施するのが理想

手動での実施は困難多数のユーザによる同時利用などの場合、人手不足とな

る正確な測定が難しい


理想すぎやしないか？

パフォーマンステスト自動化

11+2.1.4 Performance Test Automation(2)パフォーマンステスト自動化

仮想ユーザによる同時多数接続、データ量とパフォーマンスの相関算出などを実施

ボトルネック発見時はレイヤーを切り分けて詳細に原因究明レイヤーごとに有識者を確保する必要あり


レイヤー原因の例

プレゼンテーション層

効率の悪いアルゴリズム

DB 層効率の悪いクエリ

OS 層リソース不足

ネットワーク層狭い帯域

12+2.1.4 Performance Test Automation(3)パフォーマンステストと似たテスト

ロードテスト基本的にはパフォーマンステストと一緒上限に向けて徐々にデータ量を増やしていくのが特徴

ストレステスト上限を超えて、実際にアプリケーションが正常に動作し

なくなるまで実施するのが特徴


パフォーマンステストの定義が明確でないため、差異がよくわかっていません…

+

2.2Application Interfaces


14+2.2 概要

テスト自動化に適したアプリケーションインタフェースは以下の 4 つである1. CLI2. API3. GUI4. Webサービス・インタフェース


ユーザの操作の再現という点で一番相性がよい

テスト実装がしやすい

※@snsk さんのブログでの説明のニュアンスはちょっと違うかも？※ 「 CUI 」は和製英語なので英語圏で使うとかっこわるいかも？

15+2.2 各インタフェースについて (1)

Command Line Interface コマンドを効率よくやり取りするテキストベースのメ

カニズムたいていのスクリプト言語はコマンドラインインタプ

リタを実現可能なため、これを用いてテスト自動化を実現可能

Application Programming Interface プログラム呼び出し等で利用可能なアプリケーション再利用メカニズム

たいていのスクリプト言語は外部プログラム呼び出しが可能なため、これを用いてテスト自動化を実現可能


なぜスクリプト言語限定？

16+2.2 各インタフェースについて (2)

Graphical User Interface アイコンなどの操作によりアプリケーションを利用可能と

するメカニズム UI の変更時、内部構造の変更時に比べて自動テスト資産の

保守性の維持が困難しかし、直感的な自動化のため需要は多く、たいていの取

り組みは GUI アプリケーションが対象

Web Service Interface ネットワークごしに利用可能なアプリケーション再利用メ

カニズムメッセージベースのオープンなプロトコルによる利用を想

定してるため、これを再現することでテスト自動化を実現可能


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

tabok skill category2解説

Technology