テスト仕様書の作り方大公開:結合テストの勘所

みなさん、こんにちは。
早いもので、テスト仕様書の作り方大公開もいよいよ最終回を迎えました。 今回は結合テストをどのようなスコープで行ったらよいのか、また、検証ポイントをどう考えたらよいのかについて、単体テストとの比較をしながら一例を示してみたいと思います。

前回記事はこちら

結合テスト恐るに足らず

いざ結合テストの設計をすることになったとしたら、最初は途方に暮れてしまうことでしょう。 よく陥りがちなのは、複数のプログラムを単純につなげて動かせばよいと思って、単体テストのテストケースを寄せ集めてしまうことです。そうでなくても、テスト粒度(細かさ)のさじ加減がわからないままテスト設計を始めたために、気が付くと単体テストと同じようになってしまったということも多いのではないでしょうか。

実は、結合テスト設計は少しも難しくなどありません。確かに結合テスト特有のテスト観点というものはあります。しかし意外に思われるかもしれませんが、機能要件の確認を行う限りにおいては【単体テストの延長線上】にあるのです。

単体テストのスコープ

単体テストは、読んで字のごとく1つのプログラムを単独で動かして【設計された機能を満足すること】を確認します。定義した機能が単独で正しく動作することを確認する最も基本的な「機能テスト」と位置付けられ、ブラックボックステスト手法に基づいたアプローチで機能単独の動作を確認します。

クラスやメソッド単位でJunitなどのツールを使ってホワイトボックステストを行う[UT1]と、1つのトランザクション処理を行う単位(画面・バッチ・APIなど)でブラックボックステストをする[UT2]の2段階に分けるのが一般的です。前回まで説明してきたテスト設計はまさに[UT2]にあたります。図-1に単体テスト(UT2)のスコープを示します。 

図1単体テスト(UT2)のスコープ 

単体テストの検証ポイント

実装された機能が単独で動作する場合に与えられる入力(ファイルや引数)、操作と動作条件の組み合わせに対して、正しい出力や結果となることを外部仕様(設計書)に基づいて検証します。 したがって、図-1でいえば入力ファイルのデータ内容及び画面からの操作のバリエーションに対応する出力結果を確認します。(図-1の★)

結合テストのスコープ

一方、結合テストは複数のプログラムを連結して動かすことによって【インターフェイスに齟齬がないこと】【業務目的が達成できること】を確認するためのテストです。ひとまとまりの業務を実現する一連の機能を組み合わせた「ユースケーステスト」として位置付けられ、ブラックボックステスト手法に基づいたアプローチで単一業務の動作を確認します。 これをどういう単位で行うかはテスト計画の段階で検討されることで、対象プロダクトの規模や特性、組織・プロジェクトの方針といった要素により千差万別ですが、よく見られるのが「内部結合」と「外部結合」に分ける考え方です。

同じ機能群またはサブシステムの中での結合テストを「内部結合(ITa)」などと呼ぶことがあります。 【例】会員登録画面に入力した内容を確認画面で確認し仮登録→メールによる本人認証を経て本登録 図-2に内部結合テスト(ITa)のスコープを示します。

図2 内部結合テスト(ITa)のスコープ

それに対して、異なる機能群またはサブシステムにまたがって行う結合テストを「外部結合(ITb)」と呼ぶことがあります。 【例】ユーザーが商品をカートに入れ支払を済ませる→店舗側で在庫引き当てと受注処理が動く また、連携する先は真の意味での外部(他システムや外部のサービス)である場合もあります。 【例】ユーザーが支払方法でクレジットカードを選択→外部の決済代行サービスに連携し決済を受ける 図-3に外部結合テスト(ITb)のスコープを示します。

図3 外部結合テスト(ITb)のスコープ

結合テストの検証ポイント

ひとつの業務を構成する一連の機能が動作する場合に与えられる入力(ファイルや引数)、操作と動作条件の組み合わせに対して、正しい出力や結果となることを外部仕様(設計書)に基づいて検証します。 したがって、図-2の内部結合テストでいえば入力ファイルのデータ内容及び画面からの操作のバリエーションに対応する【最終的な】出力結果を確認します。(図-2の★) 一方、図-3の外部結合テストの場合は、それに加えてサブシステム間の【インターフェイスとなる】出力結果も(正しく受け継がれたかどうかの意味で)確認します。(図-3の◆)

基本的な考え方としては、一連の業務なりサブシステムを【ひとつの大きなプログラム】としてとらえ、それに対してブラックボックス的なアプローチ(入力と出力を見る)をとることになります。 そして、入力・操作・動作条件の違いによって異なる画面(機能)に遷移して別のルートをたどる、といった処理の分岐が起きるポイントをケースとして押さえればよいのです。

いかがでしょうか?これで少しも難しくないことがおわかりいただけたと思います。 もちろん結合テストはこれだけではなく、他にも様々な要素や観点があります。それについては機会をとらえて詳しく掘り下げてみたいと思います。

ご愛読、ありがとうございました。

テストに関するお役立ち資料

テスト設計・仕様書の作り方に役立つ資料を多数ご用意しています。ぜひDLしてご利用下さい。
資料一覧は【こちら】

最近の記事

  • 関連記事
  • おすすめ記事
PAGE TOP