スキルカテゴリー6は、「自動テストのスクリプトのコンセプト」（Automated Test Script Concepts）です。
よくわからないカテゴリー名ですが、カテ5で学んだフレームワーク選択後の、以下の3つのアクティビティに関する内容になっています。テスト自動化の運用の概要ですかね。
- テストの選択
- テスト設計と作成*1
- テストの実行・分析・レポート
6.1 テストの選択
「選択」というのは、手でやっているテストのうち、どれを自動化するかの選択のこと。
1.3学んだように、組織が何を目的に自動化を進めているかによって決めます。リスク低減なのか、コスト削減なのか。
1.3学んだように、組織が何を目的に自動化を進めているかによって決めます。リスク低減なのか、コスト削減なのか。
TABOKではその判断基準をチェックリストにしています。
たとえば以下は、コスト・効率面でのチェック項目（の一部）。
たとえば以下は、コスト・効率面でのチェック項目（の一部）。
- 繰り返し実行される
- 様々な環境で実行される
- 手動化でやるには面倒すぎる
6.2 テスト設計と作成
ここでの「テスト設計(Test Design)」は、IEEEとか、テスト設計コンテストでいうテスト設計とは、ちょっと別のもののようですね。
言葉として、以下の3つがポイントっぽいので、かいつまんで。
言葉として、以下の3つがポイントっぽいので、かいつまんで。
- 自動テストのインタフェース
- 自動テストの要素
- 自動テストのモード
自動テストのインタフェース
ちとわかりづらいのですが、自動化された個々のテストの「見た目」と理解しています。
アプリケーションへの操作がベタ書きしてあるイメージの「コードベースド(code-based)」。まとまった操作がスクリプト部品として切り出され、スクリプト本体にはその部品の呼び出しが記述される「機能分解(Functional Decomposition)」。表形式の見た目になる「キーワード駆動(Keyword Driven)」。
アプリケーションへの操作がベタ書きしてあるイメージの「コードベースド(code-based)」。まとまった操作がスクリプト部品として切り出され、スクリプト本体にはその部品の呼び出しが記述される「機能分解(Functional Decomposition)」。表形式の見た目になる「キーワード駆動(Keyword Driven)」。
以上の3つがインタフェースの種類として定義されています。フレームワークとほぼ対応していると考えてよいですね。
自動テストの要素
以下の4つです。
- 初期条件のセットアップ
- テストアクション
- 検証ポイント
- 後始末
(1)と(4)に本質的な違いはなさそうです。テストの1つ1つごとに条件を元通りにし、後続のテストに影響を与えないようにします。
(2)のテストアクションは、本来のテスト部分。アプリケーションへの操作を自動化した部分ですね。
(3)検証ポイントは、テストアクションによる操作の結果、たとえば画面に表示される値の想定の値（Expected）と実際の値（Actual）が一致するかをチェックする部分。
(2)のテストアクションは、本来のテスト部分。アプリケーションへの操作を自動化した部分ですね。
(3)検証ポイントは、テストアクションによる操作の結果、たとえば画面に表示される値の想定の値（Expected）と実際の値（Actual）が一致するかをチェックする部分。
自動テストのモード
「モード」という概念が出ています。
インタフェースは、一群の操作をどのように表現するか。人にとっての見た目でしたね。
一方モードは、アプリケーションの操作の指示をどのように表現するか。コンピュータにとっての見た目と理解しています。
一方モードは、アプリケーションの操作の指示をどのように表現するか。コンピュータにとっての見た目と理解しています。
画面系であれば、以下の3つのモードがあります。
- コンテント・センシティブ（アナログ）: マウスクリック、キーボード入力によって画面が操作される。画面上の部品の座標が大事。
- コンテキスト・センシティブ（オブジェクト指向）: 画面上の部品を「オブジェクト」として認識し、操作する。座標を見ない。
- イメージベースド: 画面上の部品を、画像として認識して操作する
画面上の部品をどのように識別し、指定するかという課題については、JaSST'12 Tokyoで、ACCESSの于澎さんが発表されていました。発表資料P.31からですね。上の3つのモードに分類されないものもありそうです。
6.3 実行・分析・レポート
テストの数がある程度大きくなったら、グルーピングと順序付けが必要になってきます。
グルーピングの基準は、たとえば優先度ごと、機能ごと、目的ごと、などが考えられます。
グルーピングの基準は、たとえば優先度ごと、機能ごと、目的ごと、などが考えられます。
順序付けは、実行時間と手間を最小化するように決める必要があります。グループ化されたテスト群をシリアルで流していく場合、1つのグループのどこかでコケたら後続のグループも道連れで実行されない、ということでは困ります。エラーハンドリングをきちんと設けることである程度回避することはできますが、リスクの小さい順序を考える必要があります。
たとえば、コケる心配のない、「穴あけ」的な正常ケースを前に持ってくるとか。他の作戦としては、全シリアルじゃなく、パラレルで流したり、マシンリソースの空いている夜間に流す、といったことのの説明があります。
たとえば、コケる心配のない、「穴あけ」的な正常ケースを前に持ってくるとか。他の作戦としては、全シリアルじゃなく、パラレルで流したり、マシンリソースの空いている夜間に流す、といったことのの説明があります。
実行後は、テスト実行のログ・結果レポート・欠陥レポートが出力されます。詳細はカテゴリー12で。
*1:「development」って何て訳すといいでしょう。「作成」ってカッコ悪いんですけど、「実装」だとimplement な感じがするし、「開発」も違和感が・・・。
