最終受け入れテスト
受託でプログラムを開発した場合に、発注者が納入時に実施するテスト。大部分のプロジェクトでは、テストの詳細を事前に書面にして合意する。納入前に、最終受け入れテストに合格することを必ず確認しなければならない。徹底的にシステムをチェックする訳ではないので、最終受け入れテストは丸一日もかからないのが普通だ。
投稿者 tips-com : 2005
サービス性テスト
システム・テストのカテゴリーの一つ．
プログラムは，サービス性つまり保守能力の性質についても目的仕様をもっている．この種の目的仕様もすべてテストしなければならない．このような目的仕様は，つぎのようなことを定義する．すなわち，このシステムによってもたらされる補助サービス機能（たとえば，記憶域のダンプ・プログラム，診断プログラム），あるはっきりした問題をデバッグするための平均時間，維持のための手続き，そして内部論理の文書の質である．
投稿者 tips-com : 2005
システム検証ダイアグラム
ソフトウェア要求条件を一連の入力／出力のペアとして図式表現したもの．各入力／出力のペアは，スレッドとも呼ばれる．
投稿者 tips-com : 2005
システムテスト
システムまたはプログラムをもとの目的仕様書と比較することである．
完全なシステムまたはプログラムの機能をテストする過程ではない．なぜなら，そうすると機能テストの過程と重複することになるからである．
システム・テストは“システム”にかぎらない．製品がプログラムのばあいは，システム・テストは，いかにプログラムが目的仕様書の内容とあわないかをしめそうとする過程である．
なお、定義によって，プロジェクトがその製品について評価できる目的仕様書を作成しなければ，システム・テストは不可能である．
投稿者 tips-com : 2005
システムレベルテスト
システム全体を通して動作させ、統合されている各部分が正常に機能するかを確認する。また、その最終結果を要求仕様と比較し、プログラムの有用性を検証する。
投稿者 tips-com : 2005
出荷テスト
ユーザや生産業者に渡るものをすべて集め、正しいかどうかチェックした後、複製を作って保管しておくこと。
出荷テストにはウィルスチェックを含めることを強く勧める。
投稿者 tips-com : 2005
条件網羅（基準）
論理網羅の基準の一つ．
判定におけるあらゆる条件で，すべての可能な結果を少なくとも１回はとるようにテスト・ケースを書く．
条件分岐において条件の真・偽のすべての組み合わせをチェックする。
投稿者 tips-com : 2005
状態遷移テスト
プログラムがある状態から別の状態へ正確に移ることをチェックするテストである。例えば、データをソートしてから印刷し、データ入力用の画面を表示するプログラムがある場合、各処理を正しい順序で実行するかを検証する。また、実行順序を乱したり、現在の状態を狂わせるテストも実施すべきである。最後に、状態が遷移する瞬間に入力があった場合、プログラムが入力をどう処理するかもチェックする。
投稿者 tips-com : 2005
信頼性テスト
信頼性テストはアベイラビリティテストと似ているが、たとえば48時間とか72時間といった一定の時間にわたって操作可能となることを示す。信頼性テストはソークテストとも呼ばれる。トランザクション処理を連続させることで、メモリリーク、フリーズ、競合条件エラーを探す。システムが正常に稼働し続けるか、適切なフェイルオーバー処理が実行されたらテストは合格である。信頼性テストとは、システムの応答時間を考慮せず、一般的には72時間以上このようなリソースの少ない状態で稼働させ、動き続けるかどうかをテストするものである。
システム・テストのカテゴリーの一つ．
そのプログラムの目的仕様書に，信頼性について特別な記述があれば，特別な信頼性テストがおこなわれる．信頼性についてのテストはむずかしい．
投稿者 tips-com : 2005
スケーラビリティテスト
新システムへの移行や再設計をせずにシステムが拡張し機能し続けることを確認するのが、スケーラビリティテストの目的である。Webシステムのようなクライアントサーバシステムは、ユーザや機能の追加、あるいはその両方で拡大していく。費用の増大につながるシステムソフトウェアの変更ではなく、サーバ上のプロセッサやメモリの追加といった物理的方法でこの拡張をサポートしようという考えである。
投稿者 tips-com : 2005
スタプ（モジュール）
テスト時において，被テスト・プログラムのすぐ下位のプログラムの機能をシミュレートする仮のプログラム．トップダウン統合時に用いられる．
テストするモジュールが別の下位モジュールを呼ぶときに制御を受けるものがなにか存在していなければならない．これはスタブ・モジュールによっておこなわれる．その下位モジュールの機能をまねるようにつくられている．
テストする関数が別の関数をコールする場合、コールされる関数の代用として使うプログラム。本来の関数より単純な構造にすべきである。
使い捨てるのが普通だが、一度書いておくと、プログラム変更時の再テストで何度も再利用できる。
投稿者 tips-com : 2005
ストレステスト
限られたリソースのもとでプログラムを動作させる。このテストの目的は、プログラムを機能上の限界状態にし、その場合でもプログラムが正しく機能し、エラー条件を正しく処理できることを確認することである。ストレスの高い状態を作り出すために人為的に操作できるリソースとしては、メモリ、ディスクスペース、ネットワーク帯域幅などが挙げられる。他にもメモリに関わるテストが予定されているのであれば、ストレステストの一部として、ここで実施するべきである。ストレステストは自動化することが可能である。
システム・テストのカテゴリーの一つ．
プログラムに重い負荷または力をかけることを意味する．これを大容量テストと混同してはいけない．重いストレスとは，『短い時間に最大』容量のデータに出合うことをいう．
多くのストレス・テストは，プログラムが実際に使用されるあいだに経験しそうな状態をつくりだすのだが，ストレス・テストによっては，実際に“けっして起こらない”状況をつくりだしていることもある．と言っても，これらのテストが役にたたないというわけではない．もし，このような“ありえない”状態によってエラーが発見されれば，おなじようなエラーが現実的な，あまり力がかかっていない状況でも起こるかもしれないからである．
処理能力の限界状態でプログラムの動作をチェックするテスト。その処理量ぎりぎりかそれ以下でプログラムをクラッシュさせることを目的とする。
投稿者 tips-com : 2005
静的テスト
プログラムを実行せずにソースコードの内容をチェックする。
静的テストツールは多数ある。一番わかりやすいのはコンパイラである。コンパイラは、ソースコード中に構文エラーやその他の不良を見つけるとエラーメッセージを表示する。
静的テストは、人間の手でも実施できる。ソースコードを読み、レビュアが集まって議論してバグを叩き出す。ウォークスルー、コードインスペクション、コードレビューは、この例である。
投稿者 tips-com : 2005
セキュリティテスト
セキュリティ対策によって、Webシステムは、その内部外部両方の脅威から守られている。電子商取引事業に対する関心やWebベースアプリケーションの増大により、セキュリティテストの重要性は増してきている。ソフトウェアテストでは、機能テスト、強制エラーテスト、一定限度のアプリケーションレベルの侵入テストにその作業の重点がおかれている。これは、プログラムの実装ミスやWebサーバ、アブリケーションサーバの構成ミスから脆弱性あるいは情報漏れが発生していないかを探すことである。機能牲の実現によって引き起こされるセキュリティの副作用や脆弱性をテストする。同時に、セキュリティの実装によって引き起こされる機能性の副作用もテストする。
権限のないユーザがどれほど容易にプログラムへ侵入できるかをテストする。侵入できた場合、システムのどのデータに何ができるかもチェックする。
投稿者 tips-com : 2005
設計段階のテスト
設計段階ではコードはできていないため、検証するのはアイデアだけである。設計段階のアイデアは、最初に仕様書で書いたものより更に具体性を帯び、数字的な表記法も使っているだろう。レビュアは、設計ドキュメントをチェックし、設計通りに作ると、システムがどのように動くかを明確に思い描く必要がある。
レビュアは以下の点をチェックする。
（１）設計は正しいか？
（２）設計は要求を満たしているか？
（３）設計に漏れはないか？
（４）設計は実現可能か？
（５）エラー処理をどれだけカバーしているか？
投稿者 tips-com : 2005
設置テスト
システム・テストのカテゴリーの一つ．
ある種のソフトウェア・システムでは，システムを設置するのに複雑な手続きがいる．このような設置手続きは，システム・テスト過程の一部である．
投稿者 tips-com : 2005
増加テスト
テストすべき次のモジュールを，すでにテストしたモジュールのセットと結合してからテストする。
追記
インクリメンタルテスト法とも呼びます。
投稿者 tips-com : 2005 有限会社ティプス・コムプリートへのお問合せはこちら