結合テストの基礎
ソフトウェアテストというと、昨今ではテストの自動化などが人気ですよね。個人的にも好きです、自動化。ですが、必ずしもそう言ったトレンドが導入できないプロジェクトばかりではありません。というか、むしろ自動化が導入されているプロジェクトは、全体から見ればまだ少数派と言うのが実情です。
自動化によって得られる恩恵は「効率性」「再現性」になります。
効率性はQCDでいえば、CやDに影響を与えます。
再現性は副次的にQに影響を与えることになります。
ですが、自動化ツールをどんなに使えるようになっても、テストそのものの目的や意味、そこで検証したい品質やその品質を保証するために必要となる観点やテストケースの網羅性が確立されない限り、まったく意味がないということは覚えておきましょう。まずは基礎を正しく身につけることに注力しなくては本末転倒になりかねません。
結合テストは組織やチームなどによって名称が異なりますが、
「結合テスト」
「統合テスト」
「連結テスト」
「インターフェーステスト」
「インテグレーションテスト」
「サブシステムテスト」
「コンポーネント統合テスト」
「システム統合テスト」
などと呼ばれるものの総称です。 企業やプロジェクトなど、組織によってさまざまな実施形態があるため定義の固定が困難になっていますが、Join Test / Integration Test / Combined Testと言うように、結果として『結合』や『連結』と言う意味の単語がよく使われるため、本質的な部分は変わっていません。
一般的な定義としてはどうでしょうか。
結合テスト、統合テストは、英語では一般的に integration testing と呼ばれています。テストの用語集、JSTQB用語集を見てみましょう。
統合テスト(integration testing)
統合したコンポーネントやシステムのインターフェースや、相互作用の欠陥を摘出するためのテスト。component integration testing および system integration testing も参照のこと。
コンポーネント統合テスト(component integration testing)
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。
システム統合テスト(system integration testing)
システムとパッケージを統合するテスト。また、外部システム(たとえば電子データ交換やインターネット)とのインターフェースのテスト。
このように、コンポーネントの相互作用を確認するテスト、また何らかの結合時に実施するテストというのが一般的な理解となっています。
ソフトウェアシステムの構造には
システム ＞ サブシステム ＞ コンポーネント ＞ モジュール
… といった構造階層があります。こららの階層毎といった粒度で段階的に結合を行っていきます。どの階層で問題が発生しているのかを明確にできるため、段階的に結合を行うことが良いとされています。
また、最近では技術の進歩により「単体テスト」としての範囲の拡張や「システムオブシステムズ」や「ソリューション」といった上位概念が出てきており、統合テストの範囲は年々広がっています。
つまり、現段階で結合には以下のような粒度があると言っていいでしょう。
モジュール間結合
コンポーネント間結合
サブシステム間結合
システム間結合
そして結合テストは、どれか１つやればいい…というものではありません。原則としてすべての粒度で実施することが必要です。
目的
結合テストの目的は、「設計・構造の妥当性確認」です。
以下のような項目をテストします。
①インターフェースの完全性： 結合・構造自体に問題がないか
②機能の妥当性： 結合した状態の振る舞いに問題がないか
③データの内容： 結合した状態でやりとりするデータに問題がないか
④性能： 結合した状態での動作は狙い通りか
しかし、これらを「考えて」テストケースを洗い出しても意味はありません。考えるということは個人の記憶・認識から生み出すということです。しかし、それは本当に品質を保証することができる程度にまで信憑性を持つ取組みなのでしょうか。個人の記憶や認識に依存して「これで大丈夫です」と言われて本当に信用することができるのでしょうか。それでリリース後にシステム障害が発生した時、いったいだれが責任を取るというのでしょうか。
結合テストでは、結合されることによって成立する機能に対して、その機能仕様が正しく実装され、動作していることをテスト結果から証明する作業です。わかりやすく言えば「機能仕様との答え合わせ」を行うものです。
だからこそ
「何が答えなのか」
を明確にし、その答えから検証すべき内容を確定しない限り、品質を保証することは決して叶わないのです。
システムテストとの違い
システムテストも最終的な結合テストといえますが、結合テストは
設計・構造の妥当性を確認する
要求とそれに対するソフトウェア機能の妥当性を確認する
と言うものです。結合テストは対象物の内部構造に焦点を合わせ、システムテストでは人と物理的な対象物に焦点を合わせます。システムとはソフトウェアやハードウェア、ネットワーク、設備、仕組み、業務、そこに関わる人たち、運用するために必要な構成要素「すべて」を指します。ですのでソフトウェアも含みはしますが、ソフトウェアを主役とは考えません。
結合テストの分類
結合テストは、適用範囲と実施方法により分類できます。
範囲の分類
インターフェースに特化したテスト
「連結」テストと呼ばれることもある。
インターフェースのプロトコルやメッセージのやりとりに特化する。
「結合」できることを検証します。
シーケンス図等で定められた処理シーケンスに従った入出力において、正しいパターンやあり得ないパターンの通信を受けた時の動作が妥当なものかどうかを評価します。あるモジュールが出した命令を受けて、
正しい値を返すこと（動作後の結果）
期待通りに次のモジュールが動くこと（動作）
といった点が主な焦点になります。結合テストの目的のうち①をメインの確認対象とし、③もフォローすることになります。
サブシステムやシステムを結合した状態でのブラックボックステスト
・いわゆる「結合」テスト。
・既に「現在の対象が外部にリリースする単位」(=これを単体と定義する)では内部のテストが終了しており、他のモジュールとの連動や組み合わせによって表現される機能に対してのテストを行う。
結合した状態の動作をテストします。要求から一つ一つブレイクダウンした「実現方法」が主な焦点となります。
結合テストの目的のうち、②③④を確認対象とします。
この結合テストでいう単位がテストレベルになることもあります。 組織によっては細分化されたり、丸められたりします。品質を厳しく見る組織ではより細分化されたり、まったく異なる軸や観点のテストが定義されることもあります。
実施方法の分類
トップダウンテスト
いわゆるスタブを使ったテストです。
モジュール構造において下位にあたるモジュールを所定のインターフェースを持つスタブとして仮に生成し、上位モジュールから呼び出してテストします。
メインモジュールやモジュール間インターフェースに対して、早めの段階でのテストが可能になります。下位モジュールのテスト時にも上位モジュールのテストになるため、潜在バグを発見しやすい長所がある一方、以下のような短所もあります。
開発の初期の頃には、テストしながらの開発が難しい
スタブの作成が難しいことがある
ボトムアップテスト
いわゆるドライバを使ったテストです。
モジュール構造において、上位にあたるモジュールを仮生成して下位モジュールから呼び出してテストを行います。以下のような長所があります。
テストケースの作成や結果のチェックが容易
開発の初期からテストしながらの開発がしやすい
また、以下のような短所があります。
最終的に接続した際に、インターフェースのバグがあったりすると修正量が多くなってしまう
結合テストの特徴
システムテスト前の開発段階であることが多いため、スケジュールや対象物、環境によってパターンが変わりやすいという特徴があります。
たとえば、スタブとなるシミュレータがあらかじめ用意されている環境ではトップダウンの方式を取る場合があります。納期が非常に厳しいケースではボトムアップの方式を取ることがあります。
また、基本的には開発中と呼ばれるフェーズなので、
テスト期間中だが仕様が定まらずドキュメントが不十分
仕様が毎日変わる
連結先（連結モジュール/コンポーネント/サブシステム）の都合で止まる
シミュレータのバグに翻弄される
要求が変わる
スケジュールに余裕がない
といったことが当然のように発生します。これらは結合テストに限ったことではありませんが、結合テストのフェーズでより発生しやすいと認識しておきましょう（まぁここで困った事態を引き起こすようなマネジメントをしたくないのであれば、「設計」と「設計レビュー」を必要十分にしておくことをオススメします）。
やりやすい方法で、やりたいことだけするのがテストではありません。
動作さえすれば、その中身がどうでもいいというわけではありません。
テストとは、出荷前に会社の看板を背負って世の中に送り出す前の最終確認です。
テストだけは「どれだけ頑張った」とか「真摯に努めた」とか、「こんだけやればいいでしょう」ということは関係ありません。原則として完璧を求める姿勢でなくてはならないのです（人間がすることに完璧と言うことはありませんが…だからこそ仕組みやプロセスが重要になってくるわけですが）。
ＩＴに関するソフトウェアはそれが企業向けであっても、社会向けであっても、個人向けであっても求められているからこそ作成するものである以上、大惨事になるような品質であっていいはずがありません。
どのようなソフトウェアであっても、責任が持てないようなテストだけはしないよう最大限の注意を払って取り組むようにしましょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。