単体テストはプログラムが組み込まれたモジュールやコンポーネントと呼ばれる機能単位をそれぞれ単一で動作させることでそれら1つ1つは動作に問題が無いことを保証するためのテストです。

（実際にプログラムをどこまで分解して"単一"とするかは現場ごとに異なる）

ユニットテスト（UnitTest：UT）と呼ばれる場合もあります。

例えば家計簿の管理ができるアプリであれば「支出を入力し、入力した情報が画面に表示される」で単一のモジュールとなります。


また実際に完成されたプログラムでは各機能が独立して動作するというようなケースはほぼ皆無です。

しかし単体テストを行う段階では機能と関連する上位・下位のモジュールが完成されているとは限りません。

そのため、単体テストでは対象となる機能を呼び出す「ドライバ」と、その対象機能から呼び出されて結果を返すための「スタブ」という代替品を用意することになります。

目的は対象機能が要件通りの動作を実現できているかなので、ドライバは対象機能を呼び出すだけ、スタブは決まった結果を返すだけという程度の振る舞いであることが多いです。

1.ホワイトボックステスト

単体テストには更に2つの種別に分けられ、一方は「ホワイトボックステスト」と呼ばれます。

ホワイトボックスという名の通りソースコードが明らかな状態で行われるテストで、各命令や条件分岐などコード内におけるあらゆる処理経路が設計した通りに動作していることを網羅的に確認する「制御フローテスト」。

データや変数が「定義→使用→消滅」というライフサイクルを持つ中で定義される前に使用が発生したり、消滅後に再度消滅するなどエラーを起こしかねないパターンを見つける「データフローテスト」があります。

2.ブラックボックステスト

「ブラックボックス」テストはホワイトボックステストと対をなす名前の通り、ソースコードが不明な状態で行うテストです。

正確にはコード自体の振る舞いは考慮せず、表面的な側面から仕様通り動作しているかを確認するためのテストとなります。

「有効同値（正常処理ができる値）」と「無効同値（エラーとなることが期待される値）」を使って、それぞれ正常処理とエラー処理をテストする「同値分割法」。

有効同値と無効同値から正常とエラーの境界となる値をテストする「境界値分析法」があり、これらによって入力と出力の整合性を確認してきます。

また、ソースコードの中身を見る必要がないので開発者ではない人にテスト実行を担当してもらうことが可能な単体テストであることも特徴です。

単体テストでは1つ1つのモジュールに対して個別で動作確認していましたが、結合テストでは実際にモジュール同士を結合させた時に各モジュールが正常に動作することを保証するためのテストです。

例えばユーザー認証を行う画面の機能について、

①パスワードの入力フォームが表示される（画面①）

②入力したパスワードが伏字で表示される（機能①）

③パスワードがユーザー情報と一致することで認証に成功する（機能②）

といった流れが仕様通りに動作することなどが挙げられます。


単体テストの項では代替品を用意していた上位・下位のモジュールがここでは実際にプログラムが組み込まれたものとなるため、モジュール間での振る舞いが更に複雑になり単体テストでは起きなかった不具合が発見されやすくなり、また単体テストよりも更に多くの状況や観点でテストされるため評価工程の中では実施期間が最も長大になりやすいです。

行われるテスト種別は様々ですが、結合テストの工程自体は主に以下の目的をもって実施されます。

1.インターフェースの適合性

モジュール間でインターフェースが正しく設計されており、モジュール間での関数の呼び出しやAPIなどの動きが適切であることを確認します。

2.データの整合性

単体テストでは代替品によるモジュールを使用し「モジュール間のやり取り」自体は正常に通過する前提の環境となっていました。

結合テストでは実際のモジュール同士で連携する為、データに損失や変換がなく適切に受け渡されることを確認します。

3.機能の連携

各モジュールの機能が正しく連携し、システム全体として期待される動作を達成できることを検証します。

例えばユーザーが商品を検索し、カートに追加し、最終的に注文できるかどうか等のフローを確認します。

4.パフォーマンス

モジュール間の連携において、システム全体のパフォーマンスが適切であり、応答時間や処理速度がユーザーにとって十分なレベルであることを検証します。

5.エラーハンドリング

システム内の各モジュール内でエラーや例外が発生した場合、これらを適切に処理し予期しない動作やクラッシュが発生しないことを確認します。

6.セキュリティ

モジュール間の通信において、暗号化や認証、アクセス制御などによって安全性が担保され、外部の攻撃やデータ漏洩が防止されているかを確認します。

単体テストで個々のモジュール、結合テストでいくつかの結合されたモジュール間の動作をテストしたのであれば、最後は全てのモジュールを実装した状態でのテストとなります。

システムテストと呼ばれる場合も。

本番環境と同等の環境で、要件定義に定められた仕様が全て満たされていることを確認します。

1.機能テスト

本番環境と同じ状態で要件を満たしているか否かを確認するテスト。

要件定義で定められた通りにシステムが動作するかの確認はもちろん、追加・修正した機能も漏れなく対応していることもテストします。

2.性能テスト

対象の性能要件に基づき、時間効率や資源効率といたシステムのパフォーマンスを評価します。

3.ユーザビリティテスト

システムの操作性・学習性・見やすさ・理解しやすさ・満足度といった観点からユーザーが満足する性能を満たしているかどうかを確認。

「使い方がわかりやすく誰でも簡単に使える」ことが主なポイント。

4.セキュリティテスト

各機能が、仕様書通り作動した上でセキュリティが保たれているかを確認するテスト。

サーバーやシステム、Webサイトの不具合や欠陥がないかを検証し、サイバー攻撃や情報漏洩、システムダウンなど企業の社会的信用性にも関わる欠陥に対して迅速な対策を講じる目的があります。

5.回帰テスト

これまでのテストを通じて改修したシステムに対し、改修範囲以外でも新たな不具合が発生していないか確認するテスト。

変更が加わるたびに、機能テスト・非機能テストを実行して確認する必要があります。