第三者検証
独立したテスト機関が実施する検証や評価のこと。
投稿者 tips-com : 2005
大容量テスト
システム・テストのカテゴリーの一つ．
プログラムに大量のデータをあつかわせることである．大容量テストの目的は，プログラムがその目的仕様書で指定されたデータ量をあつかうことができないことをしめすことである．
大容量テストは，あきらかにコンピュータと人間の時間にとって高くつくので，しすぎてはいけない．しかし，すべてのプログラムは少なくとも数個の大容量テストをつかってしらべなければならない．
プログラムが扱える最大の入力をチェックするテスト。
投稿者 tips-com : 2005
探索型テスト
探索型テストでは、テスト計画、チェックリスト、行うべき作業などが必ずしもあるとは限らない。このテストの方法は、まずプログラムの中で問題がありそうな場所や機能を、これまでのテスト経験から推測する。次に、これらの問題領域に焦点を絞ってテストを実施するのである。このテストは、スケジュールに組み入れることもできるし、他のテスト作業中に予期せずエラーが発生した際に行うこともできる。
投稿者 tips-com : 2005
単体テスト
単体テストは、ソフトウェアコードを他のソフトウェアと統合する前に、単体でその完全性を評価するテストである。単体テストは通常、開発側で実施される。これは開発者が独自に、自分たちの開発したソフトウェアをテストしエラーを修正するもので、ソフトウェアテストの集1段階を示している。
モジュールテスト、ユニットテストと呼ぶこともある。
プロセスやプログラムの最小構成単位をテストすること。
投稿者 tips-com : 2005
テスト計画
テスト使用とする範囲、やり方、資源、そしてスケジュールを記述したドキュメント。テスト項目、テスト対象の特徴、テスト作業、各テスト作業の担当者、そして危機管理計画を必要とする全てのリスクを定義する。（「ANSI/IEEE Standard 829-1983 for Software Test Documentation」の定義）
テスト計画はたいてい厚みのあるドキュメントである。時には巨大なドキュメントとなることもあるが、通常は小さなドキュメントを多数集めた形をとっている。
投稿者 tips-com : 2005
テスト計書書
テストのリスク、優先度、スケジュールについて概説した管理用文書。
投稿者 tips-com : 2005
テストケース
（理想的には）単一の明確に定義されたテスト対象（たとえば、ある機能の特定の条件のもとでの特定の動作）を確認するテスト。テストの初期の段階においては、概してテストケースはきわめて単純である。しかし、プログラムが安定するにしたがって、有用な情報を得ようとするためには、より複雑なテストケースが必要となってくる。
投稿者 tips-com : 2005
テスト仕様書
特定のもしくは一連の機能をテストするための、テストケース、テスト用入カデータ、テスト用条件を1つにしたもの。テスト仕様書には、期待するテスト結果が含まれることがある。
投稿者 tips-com : 2005
テストスイート
製品の論理的あるいは物理的な領域に対し、バグの修正を確認（あるいは新しいバグを発見）するための一連のテストスクリプトないしテストケース。たとえば、受け入れテストスイートは、ソフトウェアがあらかじめ定義された受け入れ規準を満たすかどうかを検査するために使用される、一連のテストケースを集めたものである。これに対し、回帰テストスイートは、すでに修正されたはずのバグが、現在でもすべて修正された状態にあるかどうかを再確認するための全テストケースである。
投稿者 tips-com : 2005
テストスクリプト
テストケースをどのように実行するか、その操作を段階的に記述したもの。1つのテストスクリプトに複数のテストケースが含まれることもある。
投稿者 tips-com : 2005
テスト要求仕様書
ある特定の条件のもとでテストされる機能、項目に関して記述した文書。
投稿者 tips-com : 2005
徹底的な入力テスト
テスト・ケースとしてすべての可能な入力条件をつかうことである．
エラーのすべてをみつけようとすれば，すべての正しい入力データだけでなく，すべての可能性のある入力データをつかってテストしなければならない．
そのようなテストは不可能である．
かぎられたテストケースでみつけることのできるエラーの数を最大にすべきである．
投稿者 tips-com : 2005
手続きテスト
システム・テストのカテゴリーの一つ．
多くのプログラムは，人手による手続きをふくんだ，大きな完全には自動化されないシステムの一部分になっている．システム・オペレータ，データ・ベース管理者，端末のユーザによる手続きのように，すでに述べてきた人手による手続きは，システム・テスト中にテストしなければならない．
投稿者 tips-com : 2005
統合テスト
単体同士を組み合わせてテストすること。すべてのモジュールを統合するまで続く。
投稿者 tips-com : 2005
同値
二つのテストを実行して同じ結果を期待するとき、二つは同値であるという。
投稿者 tips-com : 2005
動的テスト
プログラムを実行してテストする。必然的に、コードの中身を細かくチェックすることはない。
ホワイトボックステストやブラックボックステストは、どちらも動的テストである。プログラムにテストデータを入力し、処理結果をチェックする。
投稿者 tips-com : 2005
導入テスト
この目的は，ソフトウェア・エラーをみつけることではなく，導入のエラーをみつけることであるので，特殊な型のテストである．
多くのソフトウェア・システムを導入するときは，ユーザは多種多様のオプションをえらばなけれはならず，ファイルとライブラリが割り当てられ，ロードされなけれはならず，また，有効なハードウェア構成が存在し，プログラム同士が連結されたりしなければならない．導入テストの目的は，この導入過程中に発生するエラーをみつけることである．
追記
インストールテストとも呼びます。
投稿者 tips-com : 2005
ドキュメントテスト
リファレンスガイドやユーザガイドのテストでは、すべての機能が正しく記述されているかを確認する。ドキュメントのすべてのページに対して、以下のエラーがないかどうかを一字一句確認する必要がある。
投稿者 tips-com : 2005
トップダウンテスト（法）
増加テスト手法の一つ。
トップダウン法は，プログラムの頂上つまり最初のモジュールからはじめる．その後，増加的にテストすべき次のモジュールをえらぶための“正しい”手順はない．唯一のルールは，次のモジュールになる資格を得るためには，少なくとも，そのモジュールを呼んでいるモジュールのうちの一つはすでにテストずみでなければならないことである．
インクリメンタルテストの手法の一つ。
最上位モジュールからテストする。ドライバは作る必要がない。スタブは使うが、最上位モジュールが正しく動くことが確認できたら、スタブを現物の次レベルのモジュールと置き換える。
投稿者 tips-com : 2005
ドライバ（モジュール）
テスト時において，被テスト・プログラムのすぐ上位のプログラム動作をシミュレートする仮のプログラム．ボトムアップ統合時に用いられる．
テストされるモジュールにテスト・ケースを送ったり，それをテスト・ケースで“操作（ドライブ）”したりするためにつくられた小さなモジュールである．（そのかわりに，テストツールをつかうこともできる．）
ドライバ・モジュールは，またテストする人にテストモジュールの結果を表示しなけれはならない．
ある関数をテストする場合、その関数を呼び出すテスト用プログラム。
使い捨てるのが普通だが、一度書いておくと、プログラム変更時の再テストで何度も再利用できる。
投稿者 tips-com : 2005 有限会社ティプス・コムプリートへのお問合せはこちら