5. FTのカバー範囲と作業の流れ

5.1. テストの観点とFTのカバー範囲

テスト観点の主なものについて、おおよその考え方を表に示します。アプリケーションの特性とリソースを勘案して、計画してください。

観点

Web画面

Java

コメント

データのチェック

A

B

自動化可能

データの変換

B

A

自動化可能

データ長・境界値

B

A

自動化可能

特殊文字

B

A

自動化可能

表示

A

従来の手法と自動を併用。文言・画像・レイアウトは目視

画面制御

A

自動化可能

画面遷移

A

自動化可能

セキュリティ

従来の手法を推奨

環境のバリエーション

従来の手法を推奨

データベース(基本的CRUD)

B

A

自動化可能

データベース(排他など)

B

従来の手法と自動を併用

バッチ

B

人手と自動を併用。自動化の場合、検証用プログラム開発が必須

競合・輻輳

自動化不可

性能

専用ツールを推奨

業務シナリオ

従来の手法を推奨

運用

従来の手法を推奨

※ 上記の表は、インターネットで「テスト観点表」をキーワードに検索した資料を参考にまとめたものです。（URLがエンコードされていたようなので）

※ 画面・ロジック欄は、自動テストや人手のテストに限らず、自動化に向いているかどうかをABで表記しています。空欄の場合、自動化は非推奨です。Bの場合、従来の手法との併用が必須です。

※ Aは必ずしも100%自動化が可能というわけではありません。自動化に向いているカテゴリーという意味と捉えてください。

※ 「画面制御」とは、条件によりコントロールの表示非表示を切り替えたり、メニュー項目を入れ替えたり、メッセージを制御したりすることです。

※ 環境のバリエーションとして、複数のブラウザで動作検証する場合があります。注意すべきは、ブラウザの版数、Seleniumの版数、Seleniumとブラウザを連携させるドライバの版数の組み合わせが重要であり、例えば、テスト環境を統合し、全ての組み合わせで一括でテストを実行できる組み合わせを維持し続けることは非常に難しいものです。テスト環境は、ブラウザ種ごとに構築するくらいの気持ちで行った方がよいでしょう。

5.2. テストの準備から実行までの流れ

5.2.1. アーキテクトの作業の流れ

(1) 標準化
・共通：命名規約など
・Web画面のテスト⇒画面部品を決める
・Javaメソッドのテスト⇒共通のインタフェース、テーブルを標準化する
(2)辞書を作る
・ 共通⇒
- 埋め込みJavaクラス：特殊日付など
- テーブルアクセス法
- 外部プロセスのコマンド
・Web画面のテスト⇒コントロール辞書を作成する
- コントロール一覧(構造、操作法など)
- Javascript評価関数
・Javaメソッドのテスト⇒オブジェクト辞書(Javaメソッド)を作成する
- インタフェース
(3) 業務開発チームへの提供
辞書におけるプロジェクト固有の規約の展開

アーキテクトは、開発者が開発・テストを行うための標準化とコントロール辞書の作成を行います。 この作業はテスト仕様書作成を開始するの時点で完了しておく必要があります。

※ コントロール辞書の規約とは、例えば、選択リストの項目を属性で指定するのか、表示文字列で指定するのかなどの取り決めです。

5.2.2. 開発者の作業の流れ

(1) FTで行うテスト範囲を決める
・Web画面
- 自動化の範囲、手動操作・目視確認の範囲の分類
- バリエーションの決定
- C型：画面単体の表示・チェック・制御（単体画面内のみ）の確認
- S型：ログイン画面からの遷移、遷移直後の表示、DBなどの状態の確認
・Javaメソッド
(2) テスト仕様書を生成する
- Web画面：画面項目仕様書もしくはHTMLから読み込む
- Javaメソッド：クラスファイル（メソッドは空実装でよい）を読み込む
(3) テストのためのパラメータを設定する
(4) 設定完了後にパラメータをデータベースに保存する。
(5) 実行する。（必要に応じてCIツールに実行コマンドを組み込む）
(6) 結果を確認する。
・実行結果を統計情報化する。
・Web画面でキャプチャーした画像があれば正常な画像と比較する。

開発者は、担当する機能のテストの計画、実施、運用を行います。

5.3. 画面のテストの予備知識

画面のテストの守備範囲。

  • 操作チェック（C型）

画面単体の表示やチェックロジックを検証します。

  • 入力チェック動作の確認

  • 入力操作の後の表示状態の確認

URLを直接指定できる画面単体のテスト工程で使用するとよいでしょう。

  • 画面遷移（S型）

複数の画面のつながりとアプリケーションの状態の遷移が正しいことを検証します。

  • 遷移フローが設計通りであることの確認

  • 実行前と後におけるデータベースなど外部環境の変化の確認

ログイン画面から通して行うテストで行うとよいでしょう。

*制限事項

  • ファイルダウンロードなどOSの機能を呼び出す操作については、FTでは対象外です。但し、デフォルドのダウンロード設定を行えるなど、自動化できるブラウザもあります。

  • プロキシサーバを設定している環境で認証が必要な場合、自動化が最優先であるならば、ブラウザに認証情報を記憶させる方法が推奨いたします。

5.3.1. C型シート

FTツールにおいて、「C_」から始まる名前のシートに、テスト仕様を記述する。 画面単体の表示・チェック・制御（単体画面内のみ）の確認を行う。

5.3.2. S型とV型シート

FTツールにおいて、「S_」もしくは「V_」から始まる名前のシートに、テスト仕様を記述する。 「S_」から始まる名前のシートには、その画面において遷移操作までの操作のバリエーションを記述する。 「V_」から始まる名前のシートには、遷移後の画面の検証方法を記述する。

　入力の累積。参照画面の遷移だけならチェックだけでも可能。

　正しく遷移している。 　遷移ルートがある。 　遷移の結果の表示やDBなどの状態が正しい。

5.3.3. TestSuite名

  1. Webアプリケーションの場合、画面項目仕様書もしくはWeb画面から読み込むことができる。

  2. シート名は画面IDとモードにより自動合成される。

5.4. Javaメソッドのテストの予備知識

Javaクラスとテスト対象のメソッドに対して一つのTestSuiteが割り当てられます。

TestSuiteに含まれる一つのテスト項目は、メソッドの引数の属性の値のセットもしくはデータベースの状態に対して設定されます。テスト項目の数は、バリエーションの数と一致します。

FTでは、引数の属性の組み合わせを決定表（デシジョンテーブル）のように設定できるようにしています。これにより、バリエーションを俯瞰的に可視化し、より効果的なテストを実施できるようになります。

また、実行するためのテストコードを極力ゼロに近づけることで、テスト資産をExcelファイル（事実上のテスト仕様書）のみにすることができ、メンテナンスのコストも最小にできるでしょう。

※ ほとんどのExceptionはコーディング以前には、開発者に認識されないものです。またその役割は、テスト工程で意図しない形で発生した障害検出時の情報出力と考えています。従って、現時点ではテスト結果としてExceptionを判定する機能はサポートしていません。安定稼働時に動くロジックとして、当たり前にExceptionを発行するのは適切ではありません。稼働時に当たり前のロジックとしてExceptionを使うよりも、条件分岐を使用すべきでしょう。

5.4.1. TestSuite名

  1. Javaアプリケーションの場合、クラスファイル(メソッドの内部は未実装でもよい)から読み込むことができます。

  2. シート名はアーキテクトが定めた規約をもとに命名することができます。（TestSuiteの名前になります）

5.5. テスト実行と検証の予備知識

5.5.1. テストを実行するコマンド

CIでテストを自動的に実行するためには、jarなどの開発物にたいして、次のようなコマンドを紐づけます。

java -jar FTのjarファイル(パス付) -nodisplay -testcase:["キーワード%","ログファイルパス.log",0,0,true] -onlyauto:true

キーワードは、命名規約を参考にして、文字列を作成します。あいまい検索のための「%」が使用できます。 %を入れることで、like文として機能し、検索結果のTestSuiteを全て実行します。

Web画面のテストのキーワードは、

  • C型の場合： C.画面ID#モード　の先頭からの任意文字列

  • S型の場合: S.画面ID#モード　の先頭からの任意文字列

  • S型、C型を同時に行う場合: _.画面ID#モード　の先頭からの任意文字列

Javaメソッドのテストのキーワードは、シート名の先頭からの任意文字列です。JavaメソッドのためのExcelブックにおいて、シート名はアーキテクトの定めた規約に基づいて命名されるでしょう。

テスト結果はXUnit形式のXMLでログファイルに出力します。 出力先は、環境設定ダイアログにおいて行います。

※ CIによるテスト自動化について注意すべきは、Web画面テストの全てが自動化できないということです。画面テストにおいては、どうしても手動操作や目視確認が必要だったりすることがあります。

従って、まず画面テストの自動実行（手動を一部含む）は開発者のクライアント環境で行い、CIサーバでの自動化はリグレッションテストにとどめる運用から始めることを推奨します。

5.5.2. 検証について

※ 継続的インテグレーションのためには、自動検証のみを実行するコマンドをセットします。

5.5.2.1. Web画面の検証

  • 人による検証

    • 目視

    • 画面キャプチャー

  • 自動検証:画面の状態とは

    • コントロールが可視かどうか

    • コントロールが有効であるかどうか

    • コントロールが実際に操作できること

    • コントロールを操作後の状態と事前の期待値との比較

      • 大小比較

      • 文字列一致

    • エラーメッセージの有無

    • 複数のコントロールの保持する状態の関係が期待通り（項目間チェック）

    • データベースの状態確認

    • その他の状態確認

5.5.2.2. Javaメソッドの検証

  • 引数、返却値、オブジェクト自身の状態が、メソッド実行後に、設計書通りであること。

  • データベース、ファイル、外部サービスの状態が、メソッド実行後に、設計書通りであること。