ソフトウェアテストの種別（スコープによる分類）

1. コンポーネントテスト

• モジュール単位での動作検証
• ユニットテストとかUTとも呼ぶ
• ユニットテストフレームワーク（JUnit、PHPUnitなど）を利用するのが主流
• テスト方針はホワイトボックステストが基本
• モジュールの処理経路（条件分岐、関数呼び出しなど）のカバレッジの網羅も観点
• 外部への副作用を生じさせたり、外部の状態に依存するコードはモック化できるよう設計することが重要になる

2. 統合テスト

• モジュールを統合し、実環境に近い状態での動作検証
• 統合試験、インテグレーションテスト、ITとも呼ぶ（更に細かい区分がある会社もある）
• テスト方針はブラックボックステストになる（テスト観点によってはホワイトボックステスト的なテストも入る）
• テストレベルは複数の段階がある
  • (1) アプリケーションは結合済み + 外部環境（DB、外部API）はダミー
  • (2) アプリケーションは結合済み + 外部環境（DB、外部API）は本番相当（ステージング環境）
  • (3) アプリケーションは結合済み + 外部環境（DB、外部API）は本番環境、ただしユーザーには公開されない隔離環境
• 一般的には(2)まではやることが多い
• 大規模なWEBサービスは(3)までやっているケースもある（この場合は動作検証というよりはユーザーの反応を検証する目的が強い）

3. システムテスト

• より本番環境に近い環境で行われる結合テスト
• 最近はクラウドサービスが普及したので結合試験段階で本番相当の環境が手に入るのであえて結合試験と区別する必要が薄れてきた
• 以前はコストの問題から結合試験の環境とシステムテストの環境が全く異なることが多かった（結合試験にはPCサーバ、システムテストにはラックマウントサーバのような）
• その為、クラウドサービスを利用している場合はシステムテストを省く（結合試験に吸収する）プロジェクトも多く見られる

4. 受け入れテスト

5. ストレステスト

• システムの最大処理能力の確認及び検証
• 意図的にシステムに負荷を掛け、システムが要件通りの処理性能を持つことを確認する
• 負荷を掛けるツールは色々ある（Apache Bench、JMeter、etc...）

6. 回帰テスト

• システムの改修などで既存機能に悪影響を与えていないことを確認するテスト
• 単体テスト、結合試験のいずれでも行うが、結合試験を主としているケースが多い
• 単体テストを整備した上でCIツールで自動化しておくのが最近のスタイル