プログラムやシステムができたら,正しく処理できるか,処理速度は適切か,操作性はどうかなどの確認のためのテストをします。この工程が不十分だと稼動後になって大きなトラブルが発生する危険もあるし,利用者と開発者の間の責任問題にもなります。
情報処理技術者試験では,テストに関する問題が多く出題されます。ここでは,よく出題されるものを集めました。
単体テスト、ブラックボックステスト、網羅率(カバレッジ)、命令網羅、分岐網羅(判定条件網羅)、条件網羅、組合せテスト,
動的テスト、トレース、スナップショットダンプ、インスペクタ、アサーションチェック、ブラックボックステスト、テストデータ、型チェック、フォーマットチェック、リミットチェック、論理チェック、シーケンスチェック、照合チェック、バランスチェック、チェックデジット、静的テスト、レビュー、リバースエンジニアリング、デバッガ、構文チェッカ、コードオーディタ、モジュールインタフェースチェックツール、メトリクス計測、メモリダンプ(静的ダンプ)、結合テスト、トップダウンテスト、ボトムアップテスト、状態遷移テスト、システムテスト、受入れテスト、移行テスト、運用テスト、性能テスト、負荷テスト、耐久テスト、ベンチマークテスト、レグレッションテスト、退化テスト、バグ管理図、バーンダウンチャート
テストの体系
テストとは、開発したソフトウェアのエラーや不具合(バグbug=虫)を発見して修正する(デバッグバグ(debug)することです。
テストには多様なプロセスや方法があります。
共通フレームでは、企画開発工程とテストの関係を次のように示しています(図示)。
企画開発工程 共通フレームでの 下図での
テスト・評価名称 テスト名称
事業レベル
経営戦略 経営評価
システム化の方向性 情報化評価
システム化評価 運用評価
業務レベル
要件定義 運用テスト 運用テスト
システムレベル
システム要件定義 システム適格性確認テスト
システム方式設計 システム結合 システムテスト
ソフトウェアレベル
ソフトウェア要件定義 ソフトウェア適格性確認テスト
ソフトウェア方式設計 ソフトウェア結合 結合テスト
ソフトウェア詳細設計 ソフトウェアテスト 単体テスト
これを単純化して
単体テスト→結合テスト→システムテスト→運用テスト
に区分することが広く行われています。
テストの主体者
テストは,開発者と利用者が協力して行う必要がありますが,単体テスト、結合テストでは,プログラムに密着したチェックになるので,開発者が主体になり,それより後のテストは,システム全体の検収や運用での場面になるので,利用者が中心になります。
システムテストは、システム全体のプログラムを対象にした結合テストとする狭義の観点では、開発者が中心になりますが、システム要件を満たしていること、すなわち外部設計仕様書通りになっていることを確認するテストとする観点では、外部設計者が担当することになります。その外部設計者には利用部門が参画しているので、開発者と利用者の両方が主体になるといえます。さらには、システムテストの最終段階が承認テスト(受入れテスト)であるとすれば、利用部門が主体になるともいえます。
運用テストは、実際にシステムが稼働している環境でのテストが一般的なので、利用者が中心になります。しかし、利用者は問題発見はできても、その原因解明やテスト環境の設定などは専門的な知識が必要になるので、開発者の関与が必要です。また、稼働以前に負荷テストをするというような場合では、開発者が主体になることもあります。
単体テスト
一つのソフトウェア単体(1本のプログラム=モジュール)を対象としたテストです。単純な文法ミスはプログラム作成段階で解決しているものとします。テストの方法により、次のように区分できます。
動的テスト:実際にテストデータを与えてプログラムを実行し、正しく処理されることを確認する。
ホワイトボックステスト:ソースプログラムの内部構造を知って,テストデータを作成する。
ブラックボックステスト:ソースプログラム内部を見ずに、仕様書からテストデータを作成する。
静的テスト:プログラムの実行をせずに、プログラムの分析を行うことによって確認する。
ホワイトボックステスト
ホワイトボックステストは、プログラムが正しく動くことを確認するテストです。プログラムの内部構造を知って,分岐命令や繰返し命令が正しく動くかをテストする方法です。
- 網羅性
- ソースプログラムには多くの分岐やループなどがあります。それらのケースをくまなくテストすることが求められます。すべてのプログラムステップに対してテストで実行したステップの割合を網羅率(カバレッジ)といいます。また、カバーした結果を測定・評価することを、カバレッジ分析といい、それを支援するツールをテストデータ支援ツールといいます。
テストケースの設計方法には、命令網羅、分岐網羅(判定条件網羅)、条件網羅、判定条件・条件網羅、複数条件網羅があります。すべてのケースが網羅できるのは複数条件網羅だけで、それ以外はテストされないケースが残ります。
「if (A>0 or B>0) 処理1 else 処理2」のプログラム(右図はそのフローチャート)を例にします。
- 命令網羅
すべての命令を少なくとも1回は実行
(1)A>0、B≦0 →Yes →処理1を実行
(2)A≦0、B≦0 →No →処理2を実行
欠点:この2組で網羅するので、「A>0、B>0」「A≦0、B>0」のときのテストをしていない。このとき正しく実行されるか否か不明。「if (A>0) ~」と間違っていても発見できない。
- 分岐網羅(判定条件網羅)
判定条件の真偽(全ての分岐)を少なくとも1回は実行される。
(1)A>0、B≦0 →Yes
(2)A≦0、B≦0 →No
欠点:命令分岐と同じ。
- 条件網羅
判定条件が複数ある場合に、それぞれの条件が真・偽となるテストケース。
(1)A>0、B≦0
(3)A≦0、B>0
欠点:この2組であっても、A、Bがそれぞれ真・偽となるテストケースになるが、処理2を実行するテストケースがない
- 判定条件・条件網羅
判定条件網羅と条件網羅を組み合わせてテストケース
(1)A>0、B≦0 →Yes
(2)A≦0、B≦0 →No
(3)A≦0、B>0 →Yes
欠点:これでYes/Noのケース、Aの真偽・Bの真偽を網羅しているが、「A>0、B>0」のテストケースがない。
- 複数条件網羅
判定条件のすべての可能な結果の組合せを網羅し、かつ、すべての命令を少なくとも1回は実行するようにテストケースを作成する。
(1)A>0、B≦0 →Yes →処理1
(2)A≦0、B≦0 →No →処理2
(3)A≦0、B>0 →Yes →処理1
(4)A>0、B>0 →Yes →処理1
これで、すべてのケースが網羅される。
- 組合せテスト
- 組合せテストとは、多数の入力条件の値をいろいろと組み合わせて実施するテストです。条件に用いる変数、各変数の条件数が大きいと、全体の条件数は、その組合せの数になるので、非常に大きくなります。カバー率を100%にしようとすると、時間も費用もかかるので、実務的に不適切です。
実務的には、何らかの合理的な制限を設けて、一部の組合せを設定し、それだけをテストすることになります。その設定には実務の観点から重要な条件を抽出こともありますが、実験計画法の「オールペア法」や「直交法」を用いると、少ないテスト回数で100%の網羅性を実現できることが証明されています。そのようなテスト方法を「組合せテスト」といいます。
非常に魅力的な手段ではありますが、適用にあたっては高度な数学的知識と実務知識が必要です。
動的テストの支援
ホワイトボックステストでの動的テスト(対象プログラムを実行しながらのテスト)をするときの手法を列挙します。
これらは、プログラマがソースプログラムに明示的に記述することもありますが、プログラミング言語での付帯機能、あるいはテスト支援ツールを用いるのが通常です。それをデバッカーといいます。
- トレース(コード追跡)
プログラムを1命令ごとに実行させ、必要な時点で、その時のメモリやレジスタの内容を出力する方法です。
- スナップショットダンプ
プログラム中の特定の命令文が実行されるたびに、その時のメモリやレジスタの内容を出力する方法です。
- インスペクタ
指定した対象の現在の状態や内部構造を示す情報を一覧表示する機能です。単純な変数だけでなく構造体やオブジェクトのプロパティなどの内容も表示できます。
- アサーションチェック(assertion checker)
プログラム実行中の特定の時点で成立する変数間の関係や条件を記述した論理式を埋め込んで,そのプログラムの正当性を検証する手法です。
ブラックボックステスト
ブラックボックステストとは、プログラムの内部構造を考慮せず(ブラックボックスだとして),外部仕様書に基づいたさまざまな入力データを与えて、仕様書どおりの出力が得られるかどうかを確認します。
ホワイトボックステストでは,プログラマが理解したことが正しく作られているかどうかはテストできますが,プログラマが外部仕様書を正しく理解しているかの確認ができない、すなわち、設計者の意図した機能を実現しているかわからないので,それをブラックボックステストで確認するのです。
そのため、テストデータはプログラマではなく、外部仕様書作成者あるいは利用者が作成すべきです。
ブラックボックステストでは,プログラムの中を見ないので、カバー率がどの程度かわかりません。プログラムに冗長なコードがあっても検出できません。極端にいえば,プログラマが特殊な状況のときだけに動く不正なプログラムを忍ばせていても,それを発見することができません。
チェック目的とテストデータ
テストを効果的に行うには,適切なテストデータを作成することが大切です。正しいデータが正しく処理されるだけでなく,わざと誤りのデータを与えて,誤りであることを正しく認識されることを確かめる必要があります。
誤った入力データが入力されると、誤った結果になりますが、いったんコンピュータに入った誤りデータを発見するには多大な手間がかかります。それで、入力時点で誤りを防ぐことが重要です。
- 型チェック
- 入力変数には型(タイプ)があります。それと異なる型のデータを入力したとき、誤りであることを検出させるテストです。
数量などの数値項目に数字以外のデータを与えるとか,月日のデータに1345のような値を与えたときに誤りとして処理するテストです。特に数字項目に数字以外の文字を入れた場合のチェックのことをニューメリックチェックといいます。
- フォーマットチェック
- 4桁の得意先コードに3桁,5桁のデータを与えるというように、項目の境界を間違えたデータを与えます。複数の項目を連続した文字列として入力するときの誤り発見をします。
- 同値分割法・境界値分析(リミットチェック、限界値チェック)
- 同値分割法とは、仕様からデータを同値クラス(意味のあるグループ)に分類し,各グループから代表値を選ぶ技法です。例えば10≦X≦20の条件があるとき,有効同値クラス (10~20)、無効同値クラス1(~9)、無効同値クラス2(21~)の3ケースを与える必要があるという考え方です。
さらに厳密にテストするには、条件の境界であるX=9,10,20,21を与えることが必要です。このような分析を境界値分析といい、境界値分析によるテストをリミットチェックあるいは限界値チェックといいます。
なお、「昨日までの売上金累計に今日の売掛金データを加えると信用限度をオーバーする」というようなチェックをリミットチェックということもあります。
- 論理チェック
- 例えば、「注文日が入力日以前の営業日のはずがない」とか「○○支店では△△商品を取り扱わない」などのチェックです。
- シーケンスチェック,重複チェック
- これらはプログラムでなくデータファイルのチェックで、順序正しく並んでいるか、重複はないかのチェックをします。小さい順に並んでいるファイルを入力とするプログラムに,順序が異なるファイルを入力したら,それを発見できるか。出力されたファイルが順序正しくなっているかなどの確認をします。
- 存在チェック(照合チェック)
-
- 例えば「売上データで得意先マスタに存在しない得意先コードを与えた」というように、他のファイルと照合するチェックです。
- バランスチェック
- 例えば「仕訳データの借方と貸方の最終的な合計が異なる」というように、異なる処理による結果をチェックします。これは結合テストやシステムテストで行うのが一般的ですが、既に集計値がある場合に、明細データ以外に集計データの入力して入力誤りを発見するなど、単体テストでも行うことがあります。
●チェックデジット(チェックキャラクタ)
特に長い数字列のコードの場合は入力誤りをしがちです。それで、コードの末尾に1桁たチェック用の桁をもうけておき、例えばコードの各桁を加算したときの1の位の数字を入れておき、コード入力したときに計算をして、答が合致するかどうかをチェックする方法があります。そのチェック用の桁をチェックデジットといいます。
POSシステムではJANコード(バーコード)をスキャンしますが、読み取りエラーを防ぐために、JANコードにはチェックデジットがつけられています。また、厳しく誤りを発見するために、複雑な計算方法を採用しています。
人的静的テスト
実際にプログラムを実行するのではなく、ソースプログラムやデータを机上で調べてテストするのを静的テストといいます。
後に使用されない変数への代入などプログラムの静的解析ツールで検出できます。
- レビュー
複数の人を集まり、討議をすることによりエラー等を発見Wすることです。次の形態がります。
- ウォークスルー
開発者が主体となって、参加者全員がソースプログラムを目で追いながらエラー等を調べるレビュー形態です。
- インスペクション
事前に役割を決められた参加者が、責任のある第三者(モデレータ)の下でエラー等を調べるレビュー形態です。
- リバースエンジニアリング
ソースコードからフローチャートや各種のUML図表を作成するツール
- 高度な静的テストツール
表示的意味論、公理的意味論、操作的意味論、抽象解釈などの形式手法を用いて、多様な観点から分析結果を提供するツール
静的解析ツール
- デバッガ
プログラム中の文法上のエラー(バグ)個所を色を変えて表示。エラーの理由を示すものもあります。
- 構文チェッカ
プログラムが、言語で定めれらた構文に従って記述されているかをチェックします。
- コードオーディタ
プログラムのソースコードが、独自に定めたコーディング規約にのっとっているかどうかをチェックするツールです。
- モジュールインタフェースチェックツール
モジュール間のインタフェース(例:実引数と仮引数の個数)の不一致などを検出します。
- メトリクス計測
ソースコードの保守性や可読性を定量的に評価するツールです。
ソースコードの規模や複雑さ、モジュール間の強度・結合度、モジュールの深さなどを、数値として計測する手法で、可読性・保守性の悪いソースコード、バグが潜在しやすいソースコードを発見することができます。
- メモリダンプ(静的ダンプ)
プログラムの異常終了時にメモリやレジスタの内容を出力します。
●CASE(Computer Aided Software Engineering、コンピュータ支援ソフトウェア工学)
一般には、仕様書やUML図表からソースプログラムを自動作成するツールですが、これを用いてテストすることもできます。
結合テスト
単体のプログラムは正しくても,複数のプログラム間でデータの受け渡しなどのインタフェースで誤りがないかをテストします。特に異なるプログラマが作成したプログラムでは,思い違いが発生する危険があります。
上位のプログラムから下位のプログラムを呼び出す構成もあります。例えば上位のプログラムでいくつかのメニューが示され,そこで指定されたの処理を,それぞれの下位のプログラムで行うようなケースです。このようなときの結合テストのときには,次の2通りがあります。
- トップダウンテスト
- 上位のプログラムにデータを与えて,正しく下位プログラムが呼び出されるかというように,上位のプログラムからテストします。このとき,下位のプログラムが未完成のときは,ダミーのプログラムを用意することになります。そのダミープログラムをスタブといいます。
早期に全体の構成を把握して下位プログラムの仕様を確認できる利点があります。
- ボトムアップテスト
- 呼び出される下位のプログラムを先にテストする方法です。上位のプログラムが未完成のときは,ドライバというダミープログラムを用います。
システム開発の当初から,単体のプログラミングと結合テストの並行作業ができる利点があります。
トップダウンとボトムアップを組み合わせたテストをサンドイッチテストといいます。また、複数のモジュールを結合させたプログラムを、全てのモジュールを組み合わせてから一気に動作検証するテストをビッグバンテストといいます。
結合テストの対象として、上位プログラムでの入力指示や計算結果により呼び出す下位プログラムを特定したり、下位プログラム間で同様なことを行うことが多くあります。状況により呼び出すプログラムを図示するのが状態遷移図です。主に外部設計段階で作成されます。状態遷移図が正しく反映されていることを確認するテストを状態遷移テストといいます。結合テストの重要な部分です。
システムテスト(総合テスト)
システム全体を通してテストします。システム要件定義、それをまとめた外部設計書、請負契約の場合は契約でのシステム仕様書の内容が正しく実現されているかを確認するテストです。単体テストと結合テストの段階は,開発者が主体になりますが,システムテスト(総合テスト)では,外部設計者(開発者と利用者が参加している)が主体になります。
システムテストを狭義にとらえれば、システムとして正しく動作することの確認テストになりますが、広義に、受入れテストや移行テスト、さらには運用テストの一部(負荷テストなど)も含めた総合テストととらえることもあります。
- 受入れテスト(承認テスト)
- 利用者がこのシステムを受け入れるための確認テスト。これに合格することにより,システムが検収されます。システムテストの最終段階が承認テストになることもあります。
システム要件が満たされていることの確認ですのでシステムテストと同様なテストになりますが、利用者側が実際の運用と同様の条件でソフトウェアを使用し,正常に稼働することを確認することも目的なので、試運転期間を設けて、その間に不都合な個所を発見するというように、運用テストの一部を受入れテストで行うこともあります。
受入れテストの性格から取得者(発注者、利用者)が主体になりい,開発者は受入れを支援する体制になります。(不適切な例)。
ところが、利用者はテストに関心が低いのが通例です。しかも、テストには非常な労力を伴います。そのため、十分なテストが行えないことがよくあるのです。
ひどい場合には、先月のデータをもってきて「先月と同じ結果になればいいよ」などという利用者もいます。
- 確かにデータ量は多いのですが、ほとんど同じようなデータなので、プログラムの一部だけが実行されただけで、大部分はテストされないままです。
- このなかには、コンピュータに入らなかった誤ったデータがありません。誤データ、誤操作のテストができません。
「君たちはプロだし、誠実だから、君たちを信用するよ」という人もいます。テストの段階になると、奇妙に提供者は信用されるのですね。
- 移行テスト
- さらに細分化するならば、受入れから運用までの移行の円滑化を目的とした移行テストがあります。業務遂行の立場で安全性・効率性の観点から、既存システムから新システムへの切換え手順や切換えに伴う問題点を確認します。この実施とともに、利用者マニュアルを整備し,利用者への教育訓練を実施します。
運用テスト
実際に運用してみて,問題点を発見するテスト。半年とか1年の期間を設けて,この間に発見された誤りは開発者の責任で修正するのが通常です。
ここでは、単にロジックが正しいことを確認するだけではなく,実務環境での総合的な観点からテストします。機能面のチェック以外に、システムの処理能力面でのテストが重視されます。
- 性能テスト
- 応答時間や一定時間内の処理量など、処理能力に関連する事項の確認テストです。通常の環境を対象にするのが通常ですが、以下の負荷テストや耐久テストを含めて性能テストということもあります。
- 負荷テスト(ストレステスト)
- 一度に大量のデータが発生しても処理できるかをテストします。想定される最大業務負荷に耐えられるかどうかの確認です。過酷の環境での性能テストだともいえます。
- 耐久テスト
- 負荷テストの一種ですが,長時間にわたって負荷状況がどのように変化するかを調査します。
ベンチマークテスト
性能テストの一つですが、コンピュータの処理性能を比較・評価するために行われるテストです。この分野の支援組織により、いろいろな典型的な処理について標準的なテストプログラムがあり、典型的なコンピュータ(OSも含む)構成での処理時間が公表されています。
システムで採用しようとするコンピュータ環境で、システムと類似した処理内容の標準テストプログラムを実行した測定結果を上記の公表値と比較することにより、適切なコンピュータ構成を検討したり、処理効率を上げるべき重点個所を特定したりできます。
このテストは運用中にテストするよりも、初期の段階でハードウェアを選択するために行うのが通常です。
レグレッションテスト(退行テスト、回帰テスト)
保守段階でのテストです。システムの修正や機能追加をしたとき,それが他の部分に影響を及ぼし、いままで正常に処理したいた部分でエラーになることがあります。それを確認するテストです。
例えば、「日次処理の部分を変更して、それが正しく動作することは確認したのだが、月次処理への影響に気付かず、月次処理でエラーが発生した」といようなことが発生するのを防ぐためのテストです。
このような場合には、
・影響を及ぼすプログラムを特定することが難しい
システムの可視化の徹底が必要
・短期間での解決が求められるので、正規の体制ではなく担当者個人で対処することになりやすい
変更管理ルールの徹底が必要
など、テストの方法よりも管理体制が重要になります。
テストの管理
バグ管理図
システムに含まれるエラーのことをバグといい,それを発見して修正することをデバッグといいます。
最初の時点では単純なエラーが多く見つかるが,次第に発見が困難になるし,複雑なエラーで修正も困難になります。それで、バグ累積数をグラフにすると,指数曲線のようになると考えられます。ところが、最初の段階では準備などに時間がとられるため、実際にはゴンペルツ曲線のようになることが多いのです。
理想的にはすべてのバグを無くさなければならないのですが,システムにある真のバグ数は誰にもわかりません。でも,このような曲線を描くことにより,残っているバグの数を想定することができます。
ある時点を過ぎると、残っているバグは少ないのに,それを発見して修正する時間や費用が多くかかることになります。それで,実務的には致命的なバグが解決できているならば,この時点でテストを終了し,次の段階で発見されるのを待つことにするのが一般的です。
バーンダウンチャート
burndownとは「全焼する,焼け落ちる」に意味です。XPなどアジャイル開発でのプロジェクト管理に用いられます。イテレーション単位でプロジェクトの時間と残り作業量をグラフ化したものです。プロジェクトのバックログを縦軸に取り、時間を横軸に取り。次の3本の線が表示されます。
- 理想線
全ての作業量合計を期間で平均した理想の線です。通常は右下がりの直線になります。計画線と比較して、計画が妥当かどうかの目安となります。
- 計画線
イテレーションの計画を基に、設定した期日と残り作業量を表示したものです。当初計画では、理想線に上下して全体の終了日が一致しますが、プロジェクトの進行により変更されます。
- 実績線
測定日での残りの作業量を表示します。計画線と一致するように管理します。差異が大きくなると対策をとり、計画線の変更が必要になることもあります。
テスト方法論
ここまでは、テストの方法について記述してきました。ここでは、テストをソフトウェア開発プロジェクトのサブプロセスとして捉え、テストプロセスをどのように管理するかにつて記述します。
テストプロセスの特徴
- 開発段階でテストの規模や環境が異なる
単体テストならば、開発と同じ環境で小規模なテストになりますが、システムテストでは大規模になります。運用テストでは実働環境に影響を与えないように、テスト環境を設けなければなりません。
- ソフトウェアの品質を決定する
デストは、ソフトウェアの欠陥(バグ)を発見して修正するプロセスです。発見できないバグは後工程に影響を与えます。実働後にまで持ち越されると深刻な事態になることがあります。
- テスト内容の多様性
単にソースプログラムのバグだけでなく、応答時間の制約やセキュリティ対策など。非機能要件や業務要件の一部までテストの範囲になることが多くあります。
また、ソースプログラムがコーディング規約に合致しているかのチェックも含まれることもあります。
- 期間推定が困難
バグの個数は不確定ですから、精度の良いテスト期間を推定できません。しかしテスト期間の延長は、ソフトウェアの開発スケジュールに大きく影響します。
- 打切り決断
すべてのバグを発見するのは不可能ですから、どこかで打ち切ることになります。納期と品質のバランスによる決断が重要になります。
- テストデータ
テストの大部分は、ソフトウェアにテストデータを与えて結果をチェックすることになりますが、「if x < a 処理1 else 処理2」をテストするだけで、x1 < a. x2 = a, x3 > a の3つのデータが必要になります。さらに、入力ミスを防ぐために、誤ったデータを与えて、正しく排除することを確認することも必要です。
そのため、テストの網羅率を上げるには膨大なテストデータが必要となり、その生成や管理が大きな労力になります。
- テスト支援ツール
テストデータの生成や、それをソフトウェアに与えたときの結果の収集や分析には、多様な支援ツールがあります。適切なツールを導入し使いこなす技量が求められます。
テストプロセス体系
テストプロセスは、ソフトウェア開発プロジェクトのサブプロジェクトですから、プロジェクトマネジメントとして、PDCAサイクルとして管理する必要があります。
共通フレームに「ソフトウェアテスト」と「ソフトウェア適格性確認テスト」がありますが、ここではソフトウェア開発プロジェクト内でのテストチームとして、実務的にテストをするときのプロセスとして記述します。
要件定義
- テスト要件(範囲)の確認
単にソースプログラムのバグ発見だけなのか、デバッグも含むのか、応答時間やセキュリティ、負荷対策など、非機能要件や業務要件もテスト対象に含むのか、テストの範囲を明確にする。
- 対象ソフトウェアに求められる品質レベル(実施段階でのエラーの影響度)
テストの準備・計画
- コーディング段階でのテストプロセスの把握
テスト種類(単体テストやシステムテストなど)、時期、規模など
- 個別対象テストの特徴把握
- リソース割り当て
物理的リソース:テスト実行に必要な機材や環境
人的リソース:テスト実行者
- コントロール
個別テストでの、テスト責任者、テスト要件事項、その実現のためのテスト計画書作成、進捗状況の把握・是正等の体制、要求事項の解決結果報告などに関する一般的ルール
テスト環境の整備
- テスト体制の確認
- 支援ツールの選択
テストデータ生成ソフト、静的テストツール、動的テストツールなど、必要なものをテスト環境で使えるようにして、テスト要員に習得させる。
- テストケース(テスト要件事項とテスト手順書)の作成
- テスト環境の設定
実働環境とは別のテスト環境で行うことが必要な場合、ハードウェアやソフトウェアを準備する。
テストの実行
- テストデータの生成
- テストケースの実行
バグ発見の記録、デバッグ後の確認記録、そのときのレビューの記録など
- 打切り
テスト実行を完了したとき、そこまでのテスト要求事項との一致性の記録、打ち切った判断理由、レビューの記録など
テストプロセスの終了
ソフトウェア開発プロジェクト終了時に、テスト報告書として提出するのが通常
- 全資料の整理
準備、環境整備、実行で作成した全資料を整理してインデックスを付ける。
- 要件との適合性確認
ソフトウェア要件、システム要件、業務要件のどこまでを対象にするかは、テストプロジェクトの任務により異なるが、該当する要件との適合性を確認する。
未確認および不適合の要件に関して、報告書を作成する。
- 報告
- 総括
テストチームおよび関係者によるレビューを行い、テスト作業の成熟度の改善に利用する