システム開発において、効率性の高いテストを行うことは大切なポイントと言えます。なぜなら、テストの実施方法や種類によって、コストや納期に影響を及ぼすためです。
特に結合テストは、システム開発の中でも重要な位置を占める動作確認テストです。
この記事では、結合テストの概要やテスト手法の紹介に加えて、実施方式やポイントも解説します。
関連記事:システム開発の見積りで見るべき項目とは?失敗しないためのポイントも解説
そもそもシステム開発において結合テストを行なう目的は、単体テスト後の動作を確認することにあります。
プロジェクトの中盤から終盤にかけて実施されるのが一般的で、テスト期間はおよそ2ヵ月程度です。「IT(Integration Test)」もしくは「JT(Joint Test)」と呼ばれる場合もあります。
単体テストで動作確認を終えたコンポーネント(構成要素)を、実際の動作に近い環境でチェックすることが大きな特徴です。
なお、単体テストでは、モジュール単体やプログラム単位で事前にテストを行なっており、結合テストはこれらの要素を組み合わせた”集合体のテスト”を実施するイメージです。
結合テストでは、データを受け渡すタイミングや、正常な受け渡しの検証などを行ない、要件定義書に対して整合性の取れたシステムが構築できているかを確認します。
なお、結合テストを”自動化”する際は、適用する対象を見極めることが大切です。というのも、テスト自動化の実現には「テスト・スクリプト」が必要になるためです。
テスト・スクリプトとは、テストの自動化を行うために必要な“一連の命令”のことです。
一般に、「動作を確認する検証」のテスト・スクリプトは作成工数が少なく、「入力に対して、出力結果を確認する検証」のテスト・スクリプトは作成工数が多くかかるとされています。
つまり、自社のシステム開発の比重の多くが、後者の検証に置かれていた場合、結合テストの自動化にそれだけ多くのコストがかかることになります。
自動化が適しているのか分からないというときは、経験豊富な外部のサポートを検討してみるのも一つの手です。
結合テストは、内部結合テストと外部結合テストの大きく2つに分かれることも特徴です。
まず、内部結合テストは、サブシステム(大きなシステムの一部を構成している小さな単位のシステムのこと)内の機能連携を検証することが目的です。
例えば、サブシステムA、Bのように複数の種類がある場合、内部結合テストは”サブシステムA、B、それぞれの機能連携における不具合を検出すること”に重点が置かれています。
一方、外部結合システムは、サブシステム間、もしくは他のシステムに対する機能連携を検証することが目的です。
上記例と同じく、サブシステムA、Bと複数の種類がある場合、外部結合システムは”サブシステムA-サブシステムB間の機能連携における不具合を検出すること”に重点が置かれているのです。
このように、内部結合テストと外部結合テストは、テストを行なう目的に違いがあります。
結合テストについて把握する上で、システム開発とWebシステムの違いについて知っておくことも大切です。両者の主な違いとして、以下の特徴が挙げられます。
・システム開発:組み込み型、ハードウェアも対象とした開発手法
・Webシステム:Webで利用するシステムやアプリケーションを構築する開発手法
まず、システム開発の定義は”業務を効率化させる仕組み”であることです。そのため、家電製品や自動車などの制御も対象で、「組み込み型」「ハードウェア」も含むことになります。
それに対し、Webシステムとは、基本的にWebサイトで利用するシステムやアプリケーションを構築することを指します。例えば、SNSサービスやECサイトの構築などは、“Webシステム”に該当します。
関連記事:Webシステム開発にかかる費用の相場は?コストを最適化してシステム開発を進めよう
それでは、システム開発における結合テストの手法にはどのような種類があるのでしょうか。以下の項目では、4つの手法の特徴をご紹介します。
結合テストの中で最もスタンダードなテスト手法とも言えるのが、インターフェーステストです。
そもそもインターフェースとは、モジュールを組み合わせた際に、データの授受を仲介する仕組みを指します。
そのため、インターフェーステストでは、主に以下の項目について検証を行ないます。
・機能間、モジュール間でデータの引き渡しが正常に実施できているか
・連携したモジュールが仕様書に沿った動作を実施できているか
これらのテストを実施しておくことで、システムとして正常な動作が可能であるか確認できます。
ブラックボックステストとは、プログラムの内部構造を考慮せずに、データの入力と出力に対して重点を置いたテスト手法のことです。
具体的には、入力に対して、仕様に沿った正しい出力が得られるかを検証します。
また、ブラックボックステストは主に以下3つの技法に分けられることも特徴です。
・同値分割
・境界値分析
・デシジョンテーブル
1つ目の「同値分割」とは、より少ないテスト回数で広範囲の対象をカバーできるテスト手法です。
「同値分割」では、まず入力条件が類似しているデータをクラス分けした上で、それぞれのクラスから任意の値を1つ選んで、テストを実施します。
クラス内のデータ一つひとつをテストする工数が省けるため、効率的にテストを進められる点がメリットです。
2つ目の「境界値分析」では、仕様上の「以下」「以上」など、判定の境界値を中心にテストすることが特徴です。
特に、境界部分はミスが発生しやすい傾向にあるため、「境界値分析」でテストしておくことによって、後工程へのミスの流出を防ぐ効果が期待できます。
3つ目の「デシジョンテーブル」とは、入力と出力を整理した表を用いて、それぞれの組み合わせごとにテスト条件を確認する手法です。
あらかじめ入出力を表にして整理しているため、より網羅性の高いテストケース作成を実現できます。
実際の業務を想定して実施するテストを、業務シナリオテストと呼びます。実際に取り組む業務フローや工程に合わせてテスト仕様書を作成して、検証を実施します。
基本的には正常に稼働した状態を想定してテストを行ないますが、イレギュラーな操作を考慮したテストを実施することもポイントです。
というのも、稀に発生するイレギュラー操作に対応できなければ、不具合につながる恐れもあるためです。
業務で発生しうるイレギュラー操作のパターンを抽出し、できる限り網羅性の高いテスト検証を行っておくことが大切です。
負荷テストとは、その名の通りシステムの限界まで”負荷”をかけた状態で、システムパフォーマンスの低下や、動作停止が発生しないかを確認するテストのことです。
例えば、Webシステムにおいては、アクセス数が最大数に達した際に「レスポンスの低下が起こらずに正常に処理できるか」という観点でテストを実施します。
また、想定する連続稼働時間でシステムを動作させた際に、意図せぬ動作停止が起こらないか検証することもあります。
負荷テストを実施しておくことで、ユーザー満足度が高いシステムを提供できる可能性が高まるでしょう。
結合テストの実施方式は、「増加テスト」と「非増加テスト」の大きく2つに分けられます。
増加テストとは、テストを終えたモジュールに対して、未検証のモジュールを足してテストを行なう手法のことです。
一方、モジュールを段階的に追加しないテスト手法のことを、非増加テストと呼びます。
以下の項目では、増加テストと非増加テストそれぞれの特徴について解説します。
増加テストには、以下のように3つの種類があります。さっそくそれぞれの特徴を見ていきましょう。
上位から下位のモジュールに向かってテストを進める手法を、トップダウンテストと呼びます。
上位モジュールは、常にシステム上の様子を把握しながら、下位モジュールを呼び出すという役割を担っています。
そのため、トップダウンテストでは、システム開発で重要なポジションを占める上位モジュールを、早い段階から検証できるという利点があります。
ただし、利用できない下位モジュールがある場合は「スタブ」と呼ばれるダミーのモジュールを作成しなければなりません。
つまり、スタブの必要数が多ければ多いほど、その作成に開発工数を取られてしまうため、テスト対象となるシステムによってはコストが増える恐れもあります。
トップダウンとは反対に、下位モジュールからテストを始めるのがボトムアップテストです。
下位モジュールからテストに着手できるため、初期の段階から、開発と並列的にテストを実施できるという利点があります。
さらに、テスト仕様書やテストケースの作成、結果の確認が容易にできる点もメリットと言えるでしょう。
ただし、上位モジュールに関わるテストが後回しになるため、システム開発終盤で不具合が発覚した場合は、修正によって開発工数が膨らむ恐れもあります。
また、ボトムアップテストにおいても、上位モジュールが利用できないときは、ダミーの「ドライバ」を作成する必要があります。
サンドイッチテストは、アップダウンテストとボトムアップテストが持つそれぞれの性質を持つテストです。
というのも、サンドイッチテストでは、システムの中間部分からテストを開始するためです。
上位と下位のモジュールに”サンド”された状態からテスト検証を行なうため、「折衷テスト」と呼ばれる場合もあります。
中間部分のテストを行った後は、上位モジュールと下位モジュールを段階的に追加していきます。
しかし、中間部分のどのモジュールからテストを始めるかによって、作業の効率が損なわれる可能性もあります。
業務効率性の高いテストを実現するには、システム開発全体に対する俯瞰的な視点が不可欠と言えるでしょう。
非増加テストに該当するテスト手法として、ビッグバンテストがあります。
ビッグバンテストは、モジュールの単体テストを終えたのち、全てのモジュールを結合してテストを実施します。
モジュールが全て作成されていることが前提であるため、増加テストで必要なケースがある「スタブ」や「ドライバ」を作成する必要がない点はメリットです。
一方、終盤で実施するビッグバンテストで不具合が発生すると、原因を調べるのは困難を極めます。
そのため、一般的には小規模な案件で取り入れられるテスト手法です。
システム開発における結合テストをスムーズに実施するには、以下3つのポイントが大切です。
・スケジュールに余裕を持たせる
・テスト環境を本番に近づける
・データベースのデータを書き換えない
結合テストで不具合が発覚した場合、処理対応にある程度の工数がかかることを想定しておかなければなりません。
全体的な工程の遅延とならないよう、あらかじめスケジュールに余裕を持たせておくことで、細かな納期調整を行なわずに済みます。
また、テスト環境を本番に近づけることも重要です。なぜなら、実際に起こる不具合の多くは、動作環境に影響されている傾向が高いためです。
結合テストの段階で本番の環境に近づけておけば、実際に起こりうる不具合に対して、早い段階で手を打つことが可能です。
さらに気を付けたいのは、データベースのデータを書き換えないようにすることです。
テスト検証を行う際、利便性やコストなどの観点から、データベースを直接編集してテストデータを作成するケースもあります。
しかし、必要なデータを誤って削除してしまう可能性も否めません。そのため、テストを実施するにあたり、事前にテスト用のデータを準備しておくことが望ましいでしょう。
関連記事:DeFactoryのソフトウェア開発・プロダクト開発支援について
システム開発における結合テストでは、単体テスト後のモジュールに対してテストを実施します。
結合テストのテスト手法や実施方式は複数あるため、自社のニーズに合ったものを選ぶことで、コストダウンや業務効率化が見込めるでしょう。
ただし、結合テストを行う上で、実績豊富な専門家のサポートが必要な場面は多々あります。
DeFactoryでは、アイディア着想、ユーザーヒアリング、テストマーケティング、アジャイル・MVP開発と、プロダクト開発における立ち上げ支援を全力サポートいたします。
また、経験豊富なエンジニアと事業開発経験者で、開発だけでなく事業設計から「一気通貫」した伴走を行ないます。
事業開発や立ち上げを検討しているご担当者様がいましたら、問い合わせページから資料請求や無料相談などお気軽にご連絡くださいませ。
【DeFactoryの3つの特徴】
・最短14営業日程度で納品
・事業構築力、スピード、高品質を実現する体制
・キャンペーンにより事業構想フォローを無料実施