結合テストとは

テストエンジニア テスト手法 品質保証QA

結合テストとは、単体テストが完了したプログラムモジュールや外部モジュールを本番環境同様に組み合わせ、正しく動作するか検証を行うテストです。
単体テストがプログラム単体の振る舞いの確認であるのに対し、結合テストでは複数のプログラムが組み合わさった状態での振る舞いを確認します。
確認内容としては、全体を通した機能の正しさや(機能テスト)、単体テストでは検出できないプログラム間のデータの受け渡しなどの確認します。
テスト条件とテスト観点を元にしたデシジョンテーブル(条件組み合わせの総当たり表)を作成し、これをテスト項目とすると良いでしょう。

参考: デシジョンテーブルとは
参考: 単体テスト(ユニットテスト)とは

 

Web システムにおける結合テスト
例えば Web システムの開発においては、Cypress などのテストツールや、puppeteer などのライブラリからヘッドレスブラウザを操作するテストプログラムを自作して E2E テストを行うケースが多いかと思います。

E2E テストとは

E2E(End to end)テストとは、ブラウザの操作からサーバ側の処理まで含めた Web アプリケーション全体を通したテストです。 主にヘッドレスブラウザと呼ばれる GUI のないブラウザを操作するテストプログラムからテストを行う場合のことを指します。
ヘッドレスブラウザといえば、chromium が有名ですね。chromium の制御なら puppeteer という Node ライブラリがおすすめです。

参考: Cypress を利用した E2E テスト
参考: GitHub – puppeteer / puppeteer



単体テストと結合テストの違い

単体テストでは検出できない障害
単体テスト以降の検証工程においてのみ検出される障害としては以下のようなものがあります。
(下記以外の障害が本工程で多く検出されるようであれば、前工程、特に単体テストが不十分である可能性があります)

機能実装誤り・機能不完全
全体を通した出力結果や振る舞いの誤り、機能仕様書との差異。
データの生成箇所と因果関係を持つ箇所との不整合。
例:
登録データの更新はできるが削除ができない、登録機能と一覧参照画面との不整合、回答機能と集計結果画面との不整合など。

インターフェースミス
単体テスト工程で結合できなかった他コンポーネントやミドルウェア、API 連携、ライブラリなどとのインタフェースを持つ部分の誤り。
例:
メソッド呼び出しの引数誤り、API のパラメタエラーなど。

タイミング制御不良
マルチスレッド、マルチプロセスでの並列動作によるデータ不整合。
DBの並列トランザクションによるデータ不整合。
例:
複数の同時ユーザ登録での二重登録、ユーザへのメール送信バッチ処理中のユーザ削除、DB同一レコードへの同時更新など。

性能不良、外部要因、環境不良
性能要件に満たない応答遅延、ミドルウェアや外部連携サービスの不具合など。


●単体テストと結合テストの境界値の違い
単体テストにおける機能テスト(ブラックボックステスト)と結合テストにおける機能テストでは、求める境界値に違いが生じます。
例えば入力されるテキストの最大文字数が HTML フォームタグや JavaScript によって文字数制限されている場合、内部のユニットではこの仕様に引っ張られることなく、例えば DB カラムの最大バイト数などで境界値を設定しておくと良いでしょう。
こうしておくことで機能仕様の変更や他モジュールの誤りに対する影響を抑えることができ、堅牢なプログラムとなるでしょう。

結合テストの種類

システムテスト
本番運用と同等のシステム環境やデータでの機能要件の検証
例: 外部連携、システムダウン

負荷テスト(性能テスト)
大量データや大量同時アクセスによるシステム負荷における性能要件の検証
例: 応答時間、長時間稼働、パフォーマンスモニタリング

セキュリティテスト
システムの脆弱性の検証
例: 不正アクセス、セキュリティホール

受入テスト
発注者の最終確認テスト
例: 検収、納品物

参考: 結合テストとシステムテストの違い

OAOO 原則

OAOO 原則や DRY 原則に基づいてプログラムを最適化することの重要性は、テストの観点からも明白です。
プログラムの最適化はテスト項目数を減少させ、テストにかかる工数を削減させます。

コメント