結合テストについて

前回の記事（テスト大事ですよ～と単体テストについて）の続きです。技術的な内容ではないので、エンジニアにとってはつまらないかもしれないですが。 重要じゃない工程はないのですが、テストは品質と直結していて評価につながっていく、本当にだいじな工程だと思うので。 要件と仕様のギャップの発見、システムが期待通りに動作しユーザーが満足する品質であるか、の確認を行うために、とくに結合テストが重要になると思います。 テストをしないエンジニアにとっても、機能や画面の目的、機能間の目的を意識することは大切です。

1.結合テスト（IT：Integration Test）について

今回は結合テストでの目的や種類について、お伝えします。 結合テストは、V字モデルでいうと基本設計工程に対応したテスト工程です。 基本設計では開発システムの全体像（機能ごとに、機能がどのようなものなのか、何をするためのものなのか、他の機能とのつながりなど）を決めていきます。 したがって結合テストは、一連の流れの機能が問題なく動作しているのかを確認します。 ひとつ前の工程である単体テストで正常に動作するようになったコンポーネントやシステムを組み合わせることで、実際の動作に近い状態でソフトウェアの挙動を確認します。

2.V字モデルにおける結合テストの観点

V字モデルにおける結合テストの目的は、システムの各コンポーネントが単独で正しく動作することを確認するだけでなく、これらのコンポーネントが統合されたときに、期待通りに相互作用し、全体として機能することを確認することです。 結合テストでは、以下の点を重点的に確認します。

インターフェースの整合性 モジュール間のインターフェースが正しく機能し、データの受け渡しが正確に行われているかを確認します。

機能の連携 個々の機能が統合されたときに、期待される動作をするかを確認します。期待される結果とは仕様で決まっていること、を意味します。

データの確認 さまざまな種類のデータを入力して、モジュール間の相互作用をテストする必要があります。

障害の検出 モジュール間の相互作用によってエラーが発生する可能性を検討します。また、単体テストでは見つけられなかった不具合やバグも早期に発見し、修正することを目指します。

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

単体テストは、システムの最小単位であるプログラムやモジュール単体をテスト対象とするのに対し、結合テストでは、単体テストをクリアしたモジュールとモジュールをつなぎ、まとまった範囲をテスト対象とします。 そのため、コンポーネントテストはその機能に焦点を当ててテストを行い、結合テストでは全体のデータの流れに焦点を当ててテストを行います。

よくあるログイン画面の機能を例にしましょう。

①ログイン画面がデザインどおりに表示される └ユーザーIDが、textが表示される、入力できる └パスワード、textが表示される、入力できる、マスキングされる └ログインボタンが表示される

②ログインボタン押下時にバリデーションチェック └エラーの場合、エラーメッセージが表示される

③バリデーションチェックがOKの場合ログイン処理 └パスワードが一致していなければエラーメッセージが表示される └パスワードが一致していれば、ログイン処理を行う └ログイン日時を更新 └○○ステータスを××に更新 └ログイン情報（名前とID）を返却する

④ログイン成功した場合、○○画面が表示される └ログイン情報が△△に表示される

この1行ごとの各機能は単体テストで行いますが、①～④の一連の流れが問題なく動作しているかを確認するのが結合テストです。

4.基本設計の重要性

今回、私が最も伝えたいことはこちらです。 結合テストを効果的に行うためには、基本設計で決めた仕様が明確であることが重要です。 仕様が明確でないと、何をテストすべきか、どのような結果を期待するべきかが判断できません。 基本設計では、システム全体の構造や機能の詳細を定義します。これに基づいて結合テストを行うことで、システムが期待通りに動作するかを正しく確認することができます。

さきほどのログイン画面の例だと 例えば、どういうケースがバリデーションチェックでエラーとなるのか、エラーメッセージの文言、ログイン時の処理は何か、ログインしたあとどの画面に遷移するのか、などが明確でないと、内在的に期待される設計や実装がなされず、何をテストするのか、テスト時に何が正しいのかわからなくなり、適切なテストも実行されません。

テストの期待する結果とは、仕様で定められた結果であり、ユーザーが期待する結果です。 結合テストでは、これらの期待する結果が得られることを確認することが目的となります。したがって、基本設計の段階で詳細かつ明確な仕様を定めることが、結合テストの大前提になります。

5.結合テストの種類

結合テストにはいくつかの種類があります。代表的なものを紹介します。

• 疎通テスト 疎通テストは、結合テストの前段階です。詳細なテストではなく、システムの基本的な操作や機能を簡単に確認します。 モジュール間をつないだ際に動作するか、データの行き来ができるかを確認します。つまり、「とりあえず、動くかどうか」結合テストを実施するにあたって問題が無いかをテストします。
• 目的 基本機能の確認：システムやソフトウェアが致命的なエラーなく動作することを確認します。 早期不具合検出：大きな問題を早期に発見し、開発の初期段階で修正を行う。
• 特徴 高頻度で実施：開発の初期段階や新しいビルドのリリース時に頻繁に実施されます。 簡易的なテスト：詳細なテストではなく、システムの基本的な操作や機能を簡単に確認します。
• 機能テスト 機能テストは、システムが仕様通りに動作するかを確認するテストです。先ほどのログイン機能で例に挙げたようなテストを、各機能について行います。
• 目的 要求仕様の検証：システムが仕様に基づいて正しく動作することを確認します。 機能の動作確認：個々の機能や機能間の連携が正しく行われるかを検証します。
• 特徴 詳細なテスト：各機能の細部にわたるテストを行い、正確な動作を確認します。 仕様に基づく：テストケースは仕様書に基づいて作成されます。
• 回帰テスト リグレッションテストや退行テストとも呼ばれます。 回帰テストは、システムやソフトウェアの修正や変更が他の部分に影響を及ぼしていないかを確認するテストです。 システムが複雑になると変更や修正を行った箇所とは別の機能に影響が出ることがあります。その際に改修を行っていない部分に不具合が発生していないか検証するテストです。
• 目的 影響確認：修正や新機能の追加が既存の機能に悪影響を与えていないことを確認します。 品質維持：修正による新たな不具合を早期に発見し、品質を維持します。
• 特徴 繰り返し実施：修正や変更が行われるたびに繰り返し実施されます。 包括的テスト：システム全体を対象に広範囲なテストを行います。
• ユーザビリティテスト ユーザビリティテストは、システムやソフトウェアがユーザーにとって使いやすいかを確認するテストです。 実際に業務を行ったり、シナリオを想定してユーザーの操作感や使用感などを検証します。
• 目的 利便性の確認：システムがユーザーにとって直感的で使いやすいことを確認します。 ユーザー満足度の向上：ユーザーの操作性や満足度を向上させるための改善点を発見します。
• 特徴 ユーザー視点：実際のユーザーやターゲットユーザーに近い条件でテストを実施します。 インタラクションの確認：ユーザーインターフェースの使い勝手や操作感を重点的に評価します。

他にも「性能テスト」「セキュリティテスト」などがあり、この段階で行うことがあります。

まとめ

• 結合テストは、各モジュールや機能が統合されたときに、一連の流れが正しく機能するかを確認することが目的。
• 基本設計で決めた仕様が明確であること（基本設計の段階で詳細かつ明確な仕様を定めること）が、そもそも大事！！！
• テストの種類 疎通テスト、機能テスト、回帰テスト、ユーザビリティテストなど。それぞれのテストを適切に実施することで、システムの品質を確保し、ユーザーが期待する動作の実現ができる。

「仕様を明確にする意識」「データや画面間のつながりを意識」することで、開発の工程でも仕様の確認不足や考慮不足に気づくことができ、より良い実装ができるのではないかと思います。