6.1 テストツールの種類 ★★
6.1.1 ツールによるテストへの支援 ★★
・テストツールの種類
- テストに直接利用されるツール
- テスト実行ツール、テストデータを生成するツール、テスト結果を比較するツール等
- テストプロセスのマネジメントを支援するツール
- テストやテスト結果、データ、要件、インシデント、欠陥などをマネジメントするために用いられるツールや、テスト実行をモニタしたりレポートしたりするためのツール等
- 調査や探索のために用いられるツール
- アプリケーションのファイル使用状況を監視するツール等
- テストを支援するあらゆるツール
- 表計算ソフトウェアもテストツールに該当
・テストツールの導入目的
- 反復作業を自動化したり、テスト計画やテスト設計、テストレポート、モニタリングのような主導で行うテストの活動を支援したりすることによって、テストの活動の効率を改善する
- 手動で行うと大きなリソースを要する活動（たとえば、静的テスト）を自動化する
- 手動では実行できない活動（たとえば、クライアントサーバアプリケーションの大規模な性能テスト）を自動化する
- たとえば、大量のデータの比較を自動化したり、動作をシミュレーションしたりすることによって、テストの信頼性を上げる
・テストフレームワーク
- テストツールに組み込まれている、再利用可能で拡張可能なテストライブラリ（テストハーネスとも呼ばれる）
- テスト自動化のための設計の種類（たとえば、データ駆動やキーワード駆動）
- テストの中で行われるプロセス全体
6.1.2 テストツールの分類 ★★
6.1.3 テストマネジメントの支援用ツール ★
・テストマネジメントツール
テストプロジェクトのマネージャやリーダを支援するためのツール。
テストの要件とテストケースのトレーサビリティを確保することにより作成したテストケースがテスト要件を満たしていること、またテスト実施、欠陥発見と改修状況などの実績を管理することによりプロジェクトのリスクを把握することができる。
「TestLink」などがある。
・要件マネジメントツール
プロジェクトの要件の管理を目的とし、それらの要件の作成と変更や、関連する別の要件やテストへのトレーサビリティを確保する際に使用する。
これも「TestLink」などが代表的。
・インシデント管理ツール（欠陥追跡ツール）
インシデントの統合的な管理を目的とし、インシデントの属性情報、たとえば概要、発生日、アプリケーションのバージョンや、サーバやOSなどの環境情報、インシデントがユーザへ与えるインパクトなどの情報の登録を行う。また、インシデントの改修状況、改修に対応した検証状況などインシデントのステータスを追跡する。
「Mantis」や「Bugzilla」がある。
・構成管理ツール
テストプロジェクトに存在するさまざまなテストウェアを共有し、体系的な状態で分類し、バージョンを管理するために使用する。
「CVS」や「Subversion」がある。
6.1.4 静的テスト支援ツール ★
・レビューツール
レビューの精度の向上を目的とし、レビューの実施のログとしてレビューの開催情報やその種類、参加者、指摘事項やコメント、レビュー対象となるドキュメントやコードなどの情報を記録したり、それらをプロジェクトメンバー内で共有することでレビューをより効果的に実施する。
「ReviewBoard」がある。課題管理システムの「Redmine」や「Trac」を使用してレビューの実施結果の記録や指摘事項を共有するなどの支援を行うことが可能。
・静的解析ツール
プログラム中の問題をツールにより検出する。たとえば、インスタンスを生成したオブジェクトをその後使用しなかったり、物理的に到達不可能なコードがあったりといった問題を発見する。
また、コーディング規約が適用されているかチェックすることも行う。
Java向けの「FindBugs」や「Checkstyle」、C向けの「Splint」などがある。
・モデリングツール
システムの機能やプログラムのクラスなどはモデリングすることで、それら個々の目的や振る舞いに不整合がないかチェックすることが可能。たとえば、ERモデルをGUIを使用して作成することでエンティティの不整合などを検出することが可能なツールが該当する。
「astah*」などがある。
6.1.5 テスト仕様の支援ツール ★
・テスト設計ツール
テスト設計の生産性を向上させるためのツール。
たとえば、GUIを用いた、組み合わせのテストで組み合わせ要素を指揮に当てはめたテストケースを生成したり、条件による処理フローごとのテストケースを生成するなどが該当する。
「PictMaster」などがある。
・テストデータ準備ツール
大量なパターン、もしくはセンシティブなデータを作成するときは人の手で作成することが困難な場合がある。それらの場合にデータベースやファイルからテストデータを生成する。
6.1.6 テスト実行と結果記録の支援ツール ★
・テスト実行ツール
テスト実行を自動／半自動で実行することを目的とする。スクリプトはキャプチャ／プレイバックツールによって自動生成したり、スクリプト言語などを使用して作成していく。
「Selenium」などがある。
・テストハーネス、ユニットテストフレームワークのツール
テストハーネスとは、ドライバやスタブを含むテスト環境の一種。
ユニットテストフレームワークのツールとは文字通りユニットテストを支援するためのツールで、IDEにも組み込まれる傾向にある。
Java向けの「JUnit」や.NET Framework向けの「NUnit」、Http通信を疑似的に行うことでWebアプリケーションのテストを実施する目的の「HttpUnit」などがある。
・テスト比較ツール
テストの期待値となる値、文字列、ファイル、データベース内のデータなどの比較、検証を行う。多くの場合、テストの合否判定に使用する目的で内蔵される。
「DbUnit」などがある。
・カバレッジ計測ツール
ソースコードのカバレッジを計測する。クラス、メソッド、プロシージャ、ファンクションといったソースコードレベルのテスト対象に対して、実行したテストがコード構造をどの程度網羅できているのかを測定する目的で使用する。
「Cobertura」や「EMMA」がある。
・セキュリティツール
ソフトウェアのセキュリティを評価するために用いる。
「Nessus」などがある。
6.1.7 性能・モニタリング支援ツール ★
・動的解析ツール
ソースコードの実行中に発生する欠陥を摘出する目的で使用する。具体的には実行時のメモリの割り当てや解放に関係する問題や、マルチスレッドのアプリケーションにおけるスレッド間の並列処理に起因する問題を検出したりする。
コンポーネントテストやコンポーネント統合テストなどで実行される。
「Valgrind」などがある。
・性能テスト／ロードテスト／ストレステストツール
アプリケーションの処理能力の計測や、アプリケーションが継続して動作できる時間の検証を目的とする。
顧客からの同時接続数や同時注文数などの想定される最大値等を検証する。
高負荷となる大量データの処理を行った際にすべて正常にトランザクションが処理されるか、高負荷状態でもメモリやCPUなどのシステムリソースに問題が発生していないかなどの観点でモニタしながら検証する。
「JMeter」などがある。
・モニタリングツール
JMeterがある。
6.1.8 特定のテストに対する支援ツール ★
・データ品質評価
データ品質評価とは、データの変換や移行が正しく行われているか検証したり、データウェアハウスなどのソフトウェアが使用するデータの検証を行うこと。
6.2 ツールの効果的な使い方：利点とリスク ★★
6.2.1 ツールでテストを支援する利点とリスク（全ツール） ★★
・ツールを使用することで期待できるメリット
- 反復作業が減る
- 一貫性や再実行性が増加する
- 客観的な評価が可能になる
- テストやテストケースの情報へのアクセスが容易になる
・ツールを使用することで期待できるメリット
- テストツールの効果を過大に期待する
- テストツールを初めて導入する場合に要する時間、コスト、工数を過小評価する
- 大きな効果を継続的に上げるために必要な時間や工数を過小評価する
- ツールが生成するテスト資産を保守するために必要な工数を過小評価する
- ツールに過剰に依存する
- ツール内にあるテスト資産のバージョン管理を怠る
- 複数のツールの運用が適切になされない
- ツールベンダーに潜むリスクを想定しない
- ツール事態に潜むリスクを想定しない
6.2.2 個別ツールの使用上の注意 ★
・テスト実行ツール
自動または半自動でテストを実行する。
テストスクリプト作成をするため、以下に示す2つのアプローチを駆使する。
- データ駆動方式
- テストデータをスプレッドシートなどで管理し、テストスクリプトから呼び出して使用することで、テストスクリプトを汎用化して沢山のテストケースを作成する。
- キーワード駆動方式
- テストデータに加えてキーワードをスプレッドシートなどで管理する。特定のキーワードと一部のテストスクリプトと関連付けることでスクリプト言語の知識が無くても、キーワードを使用してテストスクリプトを定義しテストが作成可能。
・静的解析ツール
作成済みのソースコードに適用した場合には大量の警告メッセージが表示され、すぐには対応が困難である場合がある。
・テストマネジメントツール
テストプロジェクトに関係するデータのインポートやエクスポートを目的とした汎用的なインターフェースを提供している場合や、レポート出力機能を持つ場合がある。
6.3 組織へのツール導入 ★
テスト支援ツールを組織に導入する際の原則や注意事項について確認する。
組織とは、開発対象とするソフトウェアの種類や規模、要員数や予算など様々な特性が異なるプロジェクトの集合体である。それらのプロジェクトが同じツールを使おうとすると、ツールを使えるようにするための改善が伴う場合もある。しかし、組織に対してツールをうまく導入すれば、組織内の各プロジェクトの品質や生産性が向上するだけでなく、ツールをきっかけに改善が進み、組織自体の成熟度も向上する。
6.3.1 組織にツールを導入するための原則 ★
・ツールを活用するためのテストプロセス改善の機会や組織の成熟度、長所と短所を評価する
組織の成熟度を評価するモデルとして、CMMI(Capability Maturity Model Integrated)が有名で、5段階の成熟度レベルが設定してあり、それぞれのレベルに対して実施すべきプロセスエリアとゴールを定義している。
・（ツールに対する）明確な要件や客観的な基準を背景に評価する
・コンセプトの証明（proof-of-concept）
機能検証という意味。ツールがテスト対象に使用できるかどうか、使用して効果が出るのかどうかを立証する。
・ツールベンダー、もしくはサービスサポート提供者の評価
・教育や訓練に対する組織内の必要事項の特定
・テスト自動化スキルを考慮したトレーニングの必要性の評価
・費用対効果の見積り
6.3.2 パイロットプロジェクトの目的 ★
コンセプトの証明を検証する場合、小規模のパイロットプロジェクトで試行的に行うと良い。以下の点を重点的に確認する。
・ツールの詳細の学習
・プロセスや作業手順への適合または変更
・ツールやテストの関連物の仕様、管理、格納、保守方法の決定
・期待する効果が妥当なコストで実現可能かどうかの見極め
6.3.3 組織内でツールの展開を成功させるには ★
ツールを導入すればすぐに利点が得られるわけではなく、むしろツールの導入当初は導入前に比べコストが増えることが一般的。ツールの効果を持続できるよう組織内でツールを展開するには、以下のような取り組みが必要になる。
・ツール未使用の部署へのツールの展開
・ツールに合わせたプロセスの適用、改善
・新規ユーザに対するトレーニング、指導、助言
・利用ガイドの作成
・ツール活用ノウハウを集める方法の実装
・ツールの利用状況や効果のモニタリング
・テストチームへの支援の提供
・教訓の収集
Follow me!
