回帰テスト
バグ修正後に、バグが確実に修正されているか、修正に際し別の新たなバグが組み込まれていないか、すでに正しく機能すると確認されたはずの機能が揖なわれていないか、を確認する目的で実施される。回帰テストはプロジェクトの大きさにもよるが、マイルストーンごとに1回、もしくはビルドごとに1回実施される。特に重要なバグに的を絞った回帰テストが、各受け入れテスト時に実施されることもある。なお、回帰テストも自動化することができる。
以下の二つの意味で使う。
・バグを見つけて修正した後、当該バグを検出したテストデータを再実行する。修正箇所を確認するため、基本テストにテスト項目を追加することもあるが、これも回帰テストの一部と見なせる。想定したとおりにプログラムが修正できたか確認するためのテストである。
・同じようにバグを修正し、テストするが、変更が他の機能に悪影響を与えていないことを確認するために標準テストをおこなうこと。プログラム全体の保全性を検証するもの。
一般に、バグ修正後の回帰テストという場合は、両方を指すことが多い。
デグレートテストといった用語が使われることもある。
投稿者 tips-com : 2005
回復テスト
システム・テストのカテゴリーの一つ．
オペレーティング・システム，データ・ベース管理システム，テレプロセシング・プログラムなどは，回復についての目的仕様をもつことがよくある．これは，プログラミング・エラー，ハードウェアの故障，データ・エラーからどのようにシステムを回復させるかについて述べたものである．システム・テストの一つの目的は，これらの回復機能が正しく働かないことをしめすことである．
投稿者 tips-com : 2005
関数等価テスト
二つのプログラムが同じ計算を行うかどうかのテスト。同じ計算をさせて常に同じ結果が得られるのであれば、式や関数の実装が等価であるといえる。
投稿者 tips-com : 2005
完成度テスト
誌上の製品レビューで叩かれる可能性のある項目や、契約上の防御策として出荷後数ヶ月間に受け取るユーザのクレームを予想するためのテスト。厳密度の高い出荷テストといえる。機能テストとシステムテストが終了していることを前提とする。意識的に、バグを検出しないようにするのが普通で、プログラムをユーザドキュメントや初期の要求仕様書と詳細に比較する。
競合製品と比較することもありうる。
投稿者 tips-com : 2005
記憶（領）域テスト
システム・テストのカテゴリーの一つ．
ばあいによっては，プログラムは記憶域についての目的仕様が定められている．たとえば，プログラムで使用する主記憶域と2次記憶域の量と，必要な一時的なファイルの大きさについてである．テストケースは，このような記憶域の目的仕様がみたされていないことをしめすようなものである．
プログラムがメモリやディスクの領域をどのように扱うかをチェックする。この量に限界がある場合、限界を超えるとどうなるかをテストする。
投稿者 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
検証（Verification）
ソフトウェア開発サイクルにおける連続する各ステップの結果が前段階のステップの目的を正しく包含していることを保証する作業．
プログラムを設計ドキュメントや仕様書と照らし合わせてチェックすること。
投稿者 tips-com : 2005
検定（Validation）
ソフトウェア製品が要求条件仕様書によって規定された特性及び性能をもっていることを保証する作業．
投稿者 tips-com : 2005
構成テスト
システム・テストのカテゴリーの一つ．
オペレーティング・システム，データ・ベース管理システム，メッセージ交換プログラムといったものは，いろいろな種類のハードウェア構成をサポートしている（たとえば，入出力機器と通信回線の型式と数，いろいろな大きさの記憶域）．可能な構成の組合せがあまりにも多くて，それぞれについてプログラムをテストすることができないことがよくあるが，しかし，少なくとも各型式のハードウェア機器と最小・最大の構成でプログラムをテストしなければならない．プログラムそれ自体が構成できるばあい（たとえば，そのプログラムの構成要素が省略できたり，別のプロセッサに置けたりするばあい），そのプログラムの可能な各構成をテストしなければならない．
プログラムが正常動作することを保証しているハードウェアの組み合わせなのに、実際には動かないものを見つけること。
投稿者 tips-com : 2005
後退テスト
システムに機能追加を行った場合に既存機能が影響を受けていないことを保証するための再テスト．システム変更を行った場合にも適用される．デグレード・テストと呼ばれることもある．
追記
回帰テストとも呼びます。
投稿者 tips-com : 2005
効率テスト
システム・テストのカテゴリーの一つ．
多くのプログラムは，効率または能力の目的仕様，すなわち，ある実働負荷と構成条件のもとでの応答時間や処理出力といった性質が指定されている．このばあいのテスト・ケースは，プログラムがその効率目標をみたさないことをしめすようなものでなけれはならない．
投稿者 tips-com : 2005
互換性（／変換）テスト
システム・テストのカテゴリーの一つ．
開発されるプログラムの大部分は，完全に新規なものは少ない．これらは，データ処理であれ，人手によるシステムであれ，不十分なシステムにたいする置きかえであることが多い．そんなばあい，プログラムは，既存のシステムとの互換性と変換手順にかんする目的仕様をもつことが多い．このばあいも，これらの目的でプログラムをテストするときは，テスト・ケースの方針は，互換性をもつという目標がみたされていないこと，変換手順が働かないことをしめすことである．
他のプログラムと共存できるかをチェックする。同じデータファイルを共有したり、同じメモリ上に同時に存在できれば、二つのプログラムには互換性があると見なす。
投稿者 tips-com : 2005
コード検査
グループによるコード読合せのための一連の手続きとエラー検出技法のことをいう．
プログラマは，プログラムの論理を１命令ずつ読みあげる．その読みあげているあいだに疑問点があげられ，エラーがあるかどうかを考えながらすすめていく．経験からすると，発見されるエラーの多くは，読みあげている最中に，他の参加者によってよりも，そのプログラマ自身によってみつけられることが実際には多い．いいかえれは，自分のプログラムを声を出して読みあげるという，この単純な行為が，いちじるしい効果をあげるエラー検出技法だといえる．
これまでの経験からつくられた共通のプログラミング・エラーのリストを見ながら，プログラムを分析する．
投稿者 tips-com : 2005 有限会社ティプス・コムプリートへのお問合せはこちら