はじめに ==================== ---------------------- 前提知識 ---------------------- このマニュアルを読み進めるにあたっては、以下の知識が必要です。 * FTテスト仕様書作成編 + Web画面テスト 　Web画面のテストを行うにあたっては、タグと属性およびjavascript等への基礎知識が必要です。 + Javaロジックテスト Javaメソッドのテストを行うにあたっては、Javaの基本的な開発スキルが必要です。 * アーキテクト編 + 共通 # データベースを操作できること # コマンド、シェルを作成できること + Web画面テスト # javascriptでプログラムできること # jQueryを利用できること # xpathの基礎知識 # Javaでプログラムできること # + Javaロジックテスト # Javaでプログラムできること # インタフェースの策定ができること ※ マニュアルで説明不足の箇所が多々ありますが、その場合、サンプルのExcelファイルが参考になるかと思います。 -------------------------------------------------- 著作権および商標について -------------------------------------------------- * FTについての知的財産権は、Toyoaki Furusawaに帰属します。 利用するための許諾書は、GNU一般公衆利用許諾書(GNU General Public License)の第三版に基づいています。但し、GPL 第三版により定められた本ソフトウェアの利用および配布の条件を満たさない場合には、別途契約が必要になります。 * JavaおよびすべてのJava関連の商標は、米国およびその他の国における米国 Oracle社 の商標または登録商標です。 * PostgreSQLは、PostgreSQLの米国およびその他の国における登録商標または商標です。 -------------------------------------------------- 特長 -------------------------------------------------- * アプリケーションフレームワークに依存しません 　対象は次のいずれかのタイプのアプリケーションです。 + Webアプリケーション ※ お試しには、環境構築後に添付のコントロール辞書を用いて既存のWebページを読み込んでみることをお勧めします。 + Javaアプリケーション * テストのための資産はテスト仕様書だけです。追加のテストスクリプト開発は不要です。 * テスト仕様書は、プログラム開発と並行して作成し、開発終了と同時にテスト実行を開始することができます。 * Webアプリケーションにおいては、jQueryやJavascriptに不慣れな一般の開発者でもテストの自動化が可能です。共通画面部品（コントロール）のxpathを辞書化することにより、設計変更時においても画面項目を動的に検知し、的確に操作します。 * デシジョンテーブルのようにテストのバリエーションを簡単に記述でき、網羅性を確保することが容易になります。 * 画面遷移ルートについても、バリエーションを簡単に設定することができます。 -------------------------------------------------- テストのために必要な最小限の作業とは？ -------------------------------------------------- Web画面やメソッドのテストを実行するにあたって、必要最小限の作業とは何でしょうか？テストの実行とは、テスト計画およびテスト仕様書に基づき、 * Web画面 + 画面の入力項目に値を設定する。 + データベースや画面の状態を変更するための操作を行う。 + 画面の項目やデータベースの状態を確認し検証する。 * メソッド + オブジェクトの属性を設定する。 + メソッドの引数の属性を設定する。 + メソッドを起動する。 + オブジェクト、引数、返却値やデータベースの状態を確認し検証する。 という作業になります。上記は必要最小限の作業であり、作業コストをそれ以下にすることはできません。 一方、既存のテスト自動実行のツールを調べてみますと、上記の作業ための準備に、多くの作業が必要になります。例えば、Web画面のテストでは、コントロールに値を入力するために、コントロールの構成が完了するのを待ち、可視化するのを待ち、必要であれば、表示領域にスクロールしたり、不活性なコントロールを活性化するための操作を行ったり、タイミングを計るためにタイマーを仕掛ける等々の処理を行う必要があります。 結果として、テストを自動化するためには高いスキルと多くの作業コストが必要になってしまいます。メソッドのテストも、バリエーションを十分に増やすと、冗長なテストプログラムの規模が指数関数的に増大して、やがてアンタッチャブルな資産になってしまいます。 本ツールでは、それらの冗長でコストのかかる作業を、アーキテクトによる標準化、コントロールや共通クラスの辞書、およびFTによって、リーズナブルなものにする方法を示しています。 ※ WebアプリケーションがHTML標準のコントロールで構成されている場合には、特別なアーキテクトの出番はなく、FT標準のCntrlDictionary_*.xlsmをベースにすればスムーズにテストの自動化を実現できるでしょう。 これにより、少しでも多くの人が良質なソフトウェアを快適に開発できるようになることを望みます。