結合テストとシステムテストの違いについて

2018年11月11日

今回は、結合テスト(連結テスト、統合テスト)とシステムテスト(総合テスト)の違いについて、初心者の方向けに書いていきます。

ウォータフォール型開発をイメージしていますので、しっくり来ない方は読み飛ばしてください。なお、今回は単体テストを除外しています。

結合テストとシステムテストの呼び方

名称の差

違いを確認する前に、名称について考えてみたいと思います。各テストの名称は、ITベンダーによって呼び方が異なりますが、一般的に次のように使われているのではないでしょうか。

結合テスト

  • 連結テスト
  • 統合テスト
  • ソフトウエア適格性確認テスト

システムテスト

  • 総合テスト
  • システム適格性確認テスト

管理人がよく使っている名称が「結合テスト」、「システムテスト」なので、この名称で統一していきます。違和感がある方は、読み替えてもらえればと思います。

ちなみに「ソフトウエア適格性確認テスト」・「システム適格性確認テスト」は、”共通フレーム2013”で使用されている用語です。情報処理技術者試験でもおなじみの言葉ですね。実務では残念ですが、全くなじみがありません・・・

違いを知らない

さて、意外に”結合テスト”と”システムテスト”の違いを知らない方がいます。管理人も協力会社の担当者に違いを尋ねることもあるのですが、明確に答えてくれないことがあります。

違いを知らないと、テストの観点がぶれたり、あいまいだったりしてしまい、結合テストでやるべきことをやらなくて、システムテストで問題が発覚することがあります。

なんちゃってプロマネの管理人は、そこそこSE暦があるので、協力会社の方たちには諭すように説明しています。

結構厳しいのが、単体テストレベルのバグが、結合テストで続々発見されることです。これは単体テスト時のチェックや、受け入れをサボった結果だったりします。

結合テストとシステムテストの違いについて

管理人の考え(ざっくり)

ざっくりいうと、次のとおりです。異論がある方は指摘していただければありがたいと思います。

結合テスト

  • テスト機・環境を使用して、すべての機能要件を検証する

システムテスト

  • 本番機・環境を使用して、実運用を想定した検証を行う。

大きな違いは、テスト機を使うのか、本番機を使うのかというところです。ちなみに、工程の流れは次のようなイメージです。(例のV字モデルは今回は記載しません)

工程のフロー(一部)

単体テストが完了した後に、結合テストを実施。結合テストが完了した後に、システムテストを実施という流れです。

システムテストは結合テストの後工程です。そのため、観点が異なることに注意してください。さらにざっくりまとめてしまうと次のようなイメージです。

結合テスト

  • 機能に問題ないか検証

システムテスト

  • 実運用に問題ないか検証

各テスト工程についてはさまざまな手法・観点・ノウハウがあります。ここでは細かくなるのであげませんが、各社それぞれの方法論があることと思います。

管理人が重きを置いたほうがよいと思われる、各テストでのやるべきことをあげてみます。

結合テストの概要について

結合テストはテスト機・環境を使用して実施します。単体テストをパスしてきた機能をすべて結合して、利用者が使用する機能として問題がないかを検証します。

オンライン機能もバッチ機能もすべて対象です。外部(他システム)とのインターフェースがあれば、そのテストも行います。ただし双方テスト機を使うことがポイントです。

機能要件は結合テストでほぼすべてのバグを取り除きたいところです。機能面での品質はここで確定させます。

ここで発生した障害はプログラムレベルではなく、仕様にまで遡る(さかのぼる)こともある、重大な障害となりえます。

システムテストの概要について

システムテストは、本番機を使用してテストを行い、実際の運用に支障がないことを検証します。

具体的には、結合テストで実施した機能要件と、非機能要件をテストします。

機能要件の品質は結合テストで担保されていることが前提ですので、機能面における細かい検証の比率は下がります。

代わりに、業務運用を想定した検証が中心です。また、本番機を使用して実際の運用時と同等の性能面、運用面の検証を行います。

具体的には、本番時と同等のデータを投入して、各機能のレスポンスを計測する、夜間バッチの処理時間を計る、自動運転(バックアップ運用など)を行うなど、実運用を想定した検証を行っていきます。

ここで発生した障害も、機能面だと仕様レベルの問題であることが多く、非機能の場合、ハードウエアやネットワーク、データベースソフトウエアの見直しなどの致命的な問題になることがが多々あります。

まとめ

ウォータフォール型の開発を想定したので、若干違和感のある方もいらっしゃったことと思います。

アジャイル型や、オブジェクト指向開発の場合だと、フェーズの捉え方が違うので、一緒にできません。特に単体テストの考え方(今回は取り上げません)が違っていますね。

また、”ざっくり”と違いを書いたのですが、本来なら、この話題だけで1冊の本と同レベルの内容になってしまうくらいのボリュームです。あくまでもとっかかりとして参考にしてください。

追記

機能要件と非機能要件についても説明なしに書いてしまいました。別の機会で説明したいと思いますのでご容赦ください。

また、単体テストの観点について、次の記事を投稿しました。あわせてご覧ください。

単体テストの観点がプロマネと開発者では違う

SE

Posted by wpmaster