ＳＷ品質まとめ⑪結合テスト

結合テストも、単体テスト同様、プロジェクトによってテストする「単位」が異なりますが、その後に控えているテスト工程が「システムテスト」または「総合テスト」と呼ばれるモノであれば、十中八九ここで行われるテストの単位は『ソフトウェア機能』となるでしょう。むしろ、そうでなくてはなりません。

テスト対象に影響する因子を考えます。また、テスト対象そのものだけでなく、システム全体を捉えてバリエーションを考えると次のようになります。

テスト観点作成手順

結合テストでは、実際のテストケースよりもテスト観点の作成にこそ重きが置かれます。観点そのものがズレていれば、テストケースがどんなに精緻でも間違ったテストしかできないからです。

　「何を」
　「どこまで」
　「どのように」

確認するかは、大前提として次の条件が求められます。

　・単体テストと重複してはならない
　・システムテストとの間に隙間があってはならない

そのためにはまず過去のプロジェクトなどから「観点を収集する」、それらを「分類化する」、そして「階層化して整理（チャンクダウン）する」と言う流れが必要になってきます。

■単体テストでやったことを結合テストでは実施しない…はずが

単体テストの観点と重複しないこと。また、利用者の操作ミス時の挙動についても仕様としてどのようにすべきなのか確認した上で、テストケースに盛り込んでおくこと。

そうしておかないと、リリース後のトラブルが絶えず発生することになります。そもそも、単体テストと結合テストでは、保証すべき品質の対象が全く異なるため、重複していること自体がプロジェクト進行として色々問題があると言えるでしょう。

仮に単体テストで「プログラムとして妥当な動きかどうか」が確認できたとしても、結合テストによって１つの機能単位でなければその動きは「仕様として正しく実現されているかどうか」の検証ができません。

結合テストになってからそのことに気づいても時すでに遅く、不毛な冗長作業に費やした時間が戻ってくることはありません。こうした事態を避けるためにも、単体テストの時点で結合と単体で何をどう切り分けるのかを明確にしておかなければならないのです。

観点

結合テストの本質は、インターフェース（インプット／アウトプット）にあります。これは項目や値などだけでなく「状態」も含む。そのため、入力前の状態、出力後の状態などまで視野を広げることを忘れてはなりません。

当然、プログラムとして作成したソフトウェア処理間だけの話ではなく、

　「ソフトウェア⇔ミドルウェア」
　「ソフトウェア⇔外部リソース」
　「ソフトウェア⇔他システム」

などでも同様のことが言えます。ただし他システムとの連携の場合、結合テスト環境では他システム側が用意できないことも多く、システムテストで実施することも多いでしょう。また、インターフェースにはバイナリ、テキスト両方の観点から確認しなければなりません。

■保証すべきポイント

結合テストにおけるインターフェース上の観点では、大別して4つの保証ポイントが存在します。

*1…EIS…executive information system

業務システムの場合であれば、①については「DBに保存できる型とサイズ、システムでエラーにならない値を持つ」ためのチェックであり、②については「利用者が必要とする情報の形である」を念頭にいれてDB等で管理すると言うことになります。③については「入力値同士お互いの相互関係を崩さないようにする」ために、お互いの関係性をチェックすることであり、④については「入力値自体に問題はなくても、それで業務が正常に稼働できるかどうかは別問題」と言う観点から、業務上関係する全ての情報との整合性を確認するというチェックであると言えるでしょう。それぞれ、

・（顧客の意図する）入力値をそのままDBで保管できるのか？
　しても良いのか？
・（顧客の認識する）『値』はそのままの状態でシステムは
　正常に運用できるのか？
・DBに登録された値の"形"は利用者が望んだ形に則しているか？
・入力項目が複数ある場合は、それぞれの値に相関的なズレはないか？
・入力値をそのままシステムとして次のステップに進めて
　業務上問題はないか？

と言う観点で実施しなければなりません。
たとえば、①の場合は

・必須項目は入力されていなければならない
・生年月日に英字を入れてはならない
・30byte制限項目に100byteもの文字を入力してはならない

等、EISの定義環境やシステム構成に依存して、定型の運用規則が求められる観点がこれにあたります。②の場合は

・都道府県コードは47都道府県のいずれかと一致しなければならない
・有無フラグは 0（無） or 1（有）以外の値が入力されてはならない

等、①の条件を満たしていたとしてもシステム…ひいては「運用のルールとして問題はないか」と言う観点でみるこのチェックもまた重要となります。③は

・「業種」= "警察" の場合、「職種」 = "国家公務員"が選択されてはならない
・「理由」= "その他"の場合、「その他備考」欄に理由を記入しなくてはならない

と言ったように、同一スコープ上で入力した複数の項目に設定した値によって他の項目のチェック制約が変化するというケースがこれにあたります。複数項目をチェックの対象として参照するため、『結合項目チェック』と呼びます。また、④の観点は

・業務進捗="承認"が選択できていいのは、当該懸案に対して"申請"された場合だけである
・業務進捗="承認"が選択していいのは、ログイン者権限が"承認者"の場合だけである

など、同一スコープにある項目間のチェックではなく、入力された１つの項目からデータベース、ファイル、メモリ、セッション、etc.…様々なリソースに対して、その入力値が妥当であることを問合せ、確認します。完全に業務仕様や運用上の流れに依存するため、業務ロジックの一部であると解釈することもできるでしょう。

ここから先はファイルにて。

11. 結合テスト
　11.1 テスト観点作成手順
　　11.1.1. 単体テストでやったことを結合テストでは実施しない…はずが
　11.2 観点
　　11.2.1. 保証すべきポイント
　　11.2.2. 単項目チェック
　　11.2.3. 属性保証（システム保証）
　　11.2.4. 整合性保証（原則保証、前提保証）
　　11.2.5. 結合項目チェック
　　11.2.6. 相関関係保証（操作保証）
　　11.2.7. 要求保証