単体テストとはどの範囲を単体テストと呼べば良いのでしょうか？
また同様に結合テストとはどの範囲を結合テストと呼ぶのでしょうか？
下記のような機能が二つある場合
【モジュール①（住所検索機能）】
Java1
Java2 この３つのモジュールで１機能とする場合
Java3
【モジュール②（情報データ登録機能）】
JavaA
JavaB この３つのモジュールで１機能とする場合
JavaC
モジュール①で、検索機能が正常動作するかを確認することを「単体テスト」
（１機能が正常に動くかどうかを視点とみるものが単体テスト）
モジュール①の検索機能を使用して、
モジュール②の情報データの登録を行う、１機能と１機能を併せて正常動作の確認することを「結合テスト」と呼ぶのでしょうか？
（２つ以上の機能を併せて動作確認を行う事が結合テストと呼ぶのでしょうか？）
参考サイトでは、
単体テストは仕様を十分満たしているかの確認、
システムテストはシステム全体が稼動するかどうかの確認と書かれていたのですが、
具体的に範囲を付けるとしたらどう境目を付ければ良いのでしょうか？
No.4
1782
96
70pt
他から切り離せる（外部仕様がある）モジュールに、他のモジュールがない状態で試験を行うものを「単体テスト」
単体でテストしたモジュールを複数組み合わせてテストするものを「結合テスト」といいます。
当然、見方によって、色々変わってきます。
例えばサーバークライアントシステムで
Ａ社がクライアント側ソフト(モジュールＡ，Ｂ)、Ｂ社がサーバー側ソフト(モジュールＣ，Ｄ)を作る場合に、モジュールＡはモジュールＢがないと動作せず、モジュールＣはモジュールＤがないと動作しないとします。また、サーバー側ソフト、クライアント側ソフトも単体では動かないとします。
モジュールＡ，モジュールＢをそれぞれ別な人が作っている（仕様がそれぞれ決まっているとする）とします。
モジュールＡをデバッグするためには擬似的にモジュールＢの代わりをするものが必要になります。
（モジュールＢもモジュールＡの代わりをするものが必要になります）
モジュールＢの代わりをするものを仮につくり、モジュールＡだけでデバッグすることを「単体テスト」といいます。
１）[モジュールＡ]-[擬似モジュールＢ]：モジュールＡの単体テスト
２）[擬似モジュールＡ]-[モジュールＢ]：モジュールＢの単体テスト
モジュールＢとモジュールＡがそれぞれ単体テストが終わった後、両方を同時に動かしてみることを「結合テスト」といいます。
３）[モジュールＡ]-[モジュールＢ]：モジュールＡ，Ｂの結合テスト
ここでＡ社がクライアントソフトを動かす時に、サーバー側ソフトが出来ていなければ、擬似のサーバーソフトが必要になります。
これはクライアントソフトの単体テストになります。
４）[[モジュールＡ]-[モジュールＢ]]-[擬似サーバー]:クライアントソフトの単体テスト
同じようにサーバー側も擬似のクライントソフトが必要になります。
５）[擬似クライアント]-[[モジュールＣ]-[モジュールＤ]]:サーバー側の単体テスト
サーバー・クライアントの双方のデバッグが終わると結合テストになります。
６）[クライアント]-[サーバー]:サーバーとクライアントの結合テスト
ここで３）と４）はほとんど同じような試験ですが、それぞれ視点により単体テストとも結合テストとも呼べます。
プログラムは小さなモジュールが組み合わさって大きな機能モジュールになり、それがまた組み合わさってさらに大きなモジュールになり・・・という入れ子構造になっているため、下からみると結合テストだが、上からみると単体テストになるというのを繰り返しているわけです。
http://e-words.jp/w/E58D98E4BD93E38386E382B9E38388.html
そのため、どこまでが単体テストでどこからが結合テストかというのは複雑なシステムほどわかりにくくなるわけです。
No.1
3542140
30pt
単体テスト、結合テストをしやすい構造で作ることが前提です。
作ってから区別するのは至難の技です。
単体テストは、できる限りの範囲で範囲を小さくしてテストします。
結合テストは、単体テストではできない機能の組み合わせのテスト
となります。
WEBアプリとかのような場合は、単体テストと結合テストの切り分けが
きちんとできない場合が多いです。重要なのはテスト漏れがないように
テストするということです。
＞具体的に範囲を付けるとしたらどう境目を付ければ良いのでしょうか？
単体テストは、テストできる最小単位にするしかありません。
ご回答ありがとうございます。
＞単体テストは、できる限りの範囲で範囲を小さくしてテストします。
ありとうございます。
目の前がパーーっと開けたような感じです。
１機能がどうこう言うよりも、
「最小の範囲でテストを行うこと」が単体テストなのですね。
＞WEBアプリとかのような場合は、単体テストと結合テストの切り分けが
＞きちんとできない場合が多いです。
おっしゃられている通りが数々の現場では、
幾つか現場で両方を行ったのですが、切り分けが抽象的なところがあったと思います。
現場のリーダーさんに聞いてみても、
「うちではこれを単体テストとしています」
という話の内容が多く、結局どこまでがどの工程なのか？
というところが明確に解りませんでした。
ある現場Ａでは、
「単体テストと結合テストの内容、ケース数がほぼ同じ」という場所ありました。
（厳密には単体テストで使用する値は「アアア」などＯＫ
結合テストで使用する値は「実際のシステムで使用される値」で検証。
という形でした。）
ある現場Ｂでは、
単体テストでは凄く時間を掛けて沢山のケースを行ったのに反して、
結合テストでは１０分の１ほどのケースしか存在しないものがありました。
切り分けの視点としては
おっしゃられる「単体テストは、テストできる最小単位」と考えると、
色々な現場でテスト検証のポイントが違ったのも納得がいきました。
ありがとうございます、とても参考になります。
No.2
5960633
30pt
あくまで個人的な意見ですが、Javaでしたらこんな感じです。
設計書が、単体テスト／結合テストの違いを意識した構成になっていないと、単体テストに時間がかかったり、必要な結合テストをやり損ねたりします。
ご回答ありがとうございます。
個人的な意見、とても嬉しいです。
「変数に対して仕様を確認」、
こちら、ご確認をお願いしたいのですが
単体テストですと、
性別 "男性""女性" という変数が対象だった場合、
"男性"と"女性"の両方で試して、正常処理が行われるか（エラーが発生しないか）を確認する。
これをホワイトボックステストと呼ぶ、いう認識で良いでしょうか？
結合テストですと、
性別 "男性""女性" という変数が対象だった場合、
"男性"が"女性"どちらかだけ試して、正常処理が行われるか（エラーが発生しないか）を確認する。
どちらかだけで良い理由としては、実際には単体テストで処理が正常に通る事が確認されているので、
動作確認だけで良い。
これをブラックテストと呼ぶ、という認識で合っていますでしょうか？
＞設計書が、単体テスト／結合テストの違いを意識した構成になっていないと、単体テストに時間がかかったり、必要な結合テストをやり損ねたりします。
こちら、ありがとうございます。
設計書についてまだ良く分かっていないため、注意点について、とても為になります。
No.3
550
60pt
モジュール① として Java1, Java2, Java3 があって、「この３つのモジュールで１機能」と表現されています。
ここで、モジュール①は「モジュール群」と考え、Java1,Java2,Java3 をそれぞれ「単体モジュール」と呼ぶことにして、以下に回答します。
・単体テスト：単体モジュール単位のテスト。つまり Java1,Java2,Java3 それぞれでのテストになります。したがって、 たとえば Java1 のテストをするためには、Java1 を稼動させるためのドライバを作成したりします。
・結合テスト：「モジュール群」としてのテストは結合テストになります。したがって、モジュール① の機能テストも、モジュール②の機能テストも、いづれも「結合テスト」です。
なお、結合テストはその結合の度合いから、複数の段階に分類されることがよくあります。例えば、「結合テストＡ」「結合テストＢ」と２段階に分けた場合、第一段階の「結合テストＡ」では、機能単位のテストのこと。「結合テストＢ」はサブシステム間のテストを意味します。
ご質問の例ですと、たかだか、Javaモジュール ６個程度ですし、モジュール群②は、モジュール群①が存在しないと稼動できないようなので、いづれの機能テストも「結合テストＡ」の範囲と思われます。検索システム と 情報データ登録システム というように、それぞれ独立した大きなサブシステムに分割が可能であるなら、「統合テストＢ」でテストすることになるでしょう。サブシステムとは、通常ある程度大きな単位のシステムです。
＞Java1,Java2,Java3 それぞれでのテストになります。
既にご回答下さった中で出ております「最小単位でのテスト」の観点から、
１機能ではなく、モジュール単位でテストできる場合は各モジュールが単体テストの対象となる、
という認識で合っていますでしょうか？
＞・結合テスト：「モジュール群」としてのテストは結合テストになります。したがって、モジュール① の機能テストも、モジュール②の機能テストも、いづれも「結合テスト」です。
こちら分かったような気がします。
結合テストの見分け方としては、
１機能と１機能でというよりは、
モジュールとモジュールが２つ以上合わさってテストを行うものは、
結合テストになる、ということですよね？
（もっと厳密に言うと、他機能との関連が関係して動作する機能をテストの視点としておくものが、
結合テストである、ということで合っていますでしょうか？）
私にはシステムの切り分けの概念が無かったため、
今回のお話とても為になりました。
ありがとうございます。
No.4
178296
ここでベストアンサー
70pt
他から切り離せる（外部仕様がある）モジュールに、他のモジュールがない状態で試験を行うものを「単体テスト」
単体でテストしたモジュールを複数組み合わせてテストするものを「結合テスト」といいます。
当然、見方によって、色々変わってきます。
例えばサーバークライアントシステムで
Ａ社がクライアント側ソフト(モジュールＡ，Ｂ)、Ｂ社がサーバー側ソフト(モジュールＣ，Ｄ)を作る場合に、モジュールＡはモジュールＢがないと動作せず、モジュールＣはモジュールＤがないと動作しないとします。また、サーバー側ソフト、クライアント側ソフトも単体では動かないとします。
モジュールＡ，モジュールＢをそれぞれ別な人が作っている（仕様がそれぞれ決まっているとする）とします。
モジュールＡをデバッグするためには擬似的にモジュールＢの代わりをするものが必要になります。
（モジュールＢもモジュールＡの代わりをするものが必要になります）
モジュールＢの代わりをするものを仮につくり、モジュールＡだけでデバッグすることを「単体テスト」といいます。
１）[モジュールＡ]-[擬似モジュールＢ]：モジュールＡの単体テスト
２）[擬似モジュールＡ]-[モジュールＢ]：モジュールＢの単体テスト
モジュールＢとモジュールＡがそれぞれ単体テストが終わった後、両方を同時に動かしてみることを「結合テスト」といいます。
３）[モジュールＡ]-[モジュールＢ]：モジュールＡ，Ｂの結合テスト
ここでＡ社がクライアントソフトを動かす時に、サーバー側ソフトが出来ていなければ、擬似のサーバーソフトが必要になります。
これはクライアントソフトの単体テストになります。
４）[[モジュールＡ]-[モジュールＢ]]-[擬似サーバー]:クライアントソフトの単体テスト
同じようにサーバー側も擬似のクライントソフトが必要になります。
５）[擬似クライアント]-[[モジュールＣ]-[モジュールＤ]]:サーバー側の単体テスト
サーバー・クライアントの双方のデバッグが終わると結合テストになります。
６）[クライアント]-[サーバー]:サーバーとクライアントの結合テスト
ここで３）と４）はほとんど同じような試験ですが、それぞれ視点により単体テストとも結合テストとも呼べます。
プログラムは小さなモジュールが組み合わさって大きな機能モジュールになり、それがまた組み合わさってさらに大きなモジュールになり・・・という入れ子構造になっているため、下からみると結合テストだが、上からみると単体テストになるというのを繰り返しているわけです。
http://e-words.jp/w/E58D98E4BD93E38386E382B9E38388.html
そのため、どこまでが単体テストでどこからが結合テストかというのは複雑なシステムほどわかりにくくなるわけです。
具体的なご回答ありがとうございます。
「単体テスト」「結合テスト」境目が掴めた気がします。
擬似モジュール、擬似サーバーとありますが、
因みにこちら、必ずしも擬似モジュールではなくてはならない、
というものではなく、場合によっては本モジュールを使用する場合もあるという認識で良いでしょうか？
（擬似を、本として使う場合が現場で実際にありましたので。
もしかしたら、現場でそう知らされていないため、そう思い込んでいただけかもしれないのですが…汗）
＞そのため、どこまでが単体テストでどこからが結合テストかというのは複雑なシステムほどわかりにくくなるわけです。
現場で定義が曖昧だった理由（説明を大体で覚えておいてくれ）と言われる理由が少し分かった気がします。
私の知識不足、理解不足な点もあり、余計に分かり辛くなっていたのかもしれません（汗）
サーバー側の単体テストについては行った事も無く、
別の視点として知ることができました。ありがとうございます。
No.5
5960633
60pt
#2で回答した者です。コメントが付けられないので、回答欄でレスします。
単体テストですと、
性別 "男性""女性" という変数が対象だった場合、
"男性"と"女性"の両方で試して、正常処理が行われるか（エラーが発生しないか）を確認する。
これをホワイトボックステストと呼ぶ、いう認識で良いでしょうか？
仕様上、「男性」「女性」の2値しかとらないなら、それで結構です。
結合テストですと、
性別 "男性""女性" という変数が対象だった場合、
"男性"が"女性"どちらかだけ試して、正常処理が行われるか（エラーが発生しないか）を確認する。
違います。「男性」「女性」以外の値も投入し、プログラムが仕様通りに動作することを確認します。
つまり、ホワイトボックステストは仕様書通りに動くことを確認するだけで済みますが、ブラックボックステストはあらゆるケース（悪意を持った攻撃を含めて）を想定して実施しなければなりません。当然、ブラックボックステストには莫大な工数がかかります。
よって、結合テストの工数を押さえ込む意味でも（もちろん、プログラムの安全性を担保するためにも）、設計時に、publicやI/Fメソッドなど結合テストの対象になる機能は限定すべきです。
再度のご回答ありがとうございます。
＞仕様上、「男性」「女性」の2値しかとらないなら、それで結構です。
＞違います。「男性」「女性」以外の値も投入し、プログラムが仕様通りに動作することを確認します。
ありがとうございます。
ホワイトボックスとブラックボックスの検証視点としては
ホワイトボックス：想定した範囲内の値で検証（主に単体テストの検証）
ブラックボックス：想定内と想定外の範囲外の値を含めての検証（主に結合テストの検証）
という認識で合っていますでしょうか？
また質問が多くて申し訳ないのですが、
もしご回答頂けましたらお願いしたいと思います。
「単体テスト」後の「結合テスト」を行う理由について
--------------------------------------------
・結合テストでは「異常値」を入れてテストする事でより深いテストを行う
・結合テストでモジュールの結合によって思わぬ不具合が発生しないかの確認をする
という認識で合っていますでしょうか？
「I/Fメソッド」について
----------------------
こちらはどのようなメソッドなのでしょうか？
No.6
550
60pt
＃３で回答した BAZZ です。
コメントが付けられないので、ご質問に対して回答欄でレスします。
>１機能ではなく、モジュール単位でテストできる場合は各モジュールが単体テストの対象となる、
>という認識で合っていますでしょうか？
はい、正しい理解です。
>結合テストの見分け方としては、
>１機能と１機能でというよりは、
>モジュールとモジュールが２つ以上合わさってテストを行うものは、
>結合テストになる、ということですよね？
はい、正しい理解です。
>（もっと厳密に言うと、他機能との関連が関係して動作する機能をテストの視点としておくものが、
> 結合テストである、ということで合っていますでしょうか？）
厳密に言うと、２つ以上のモジュールを結合して行うテストが結合テストです。
他機能との関連、とか視点は、その結果であったり、結合テストを行うときの標準化の基準です。
この基準の決め方は、プロジェクトによって様々ですが、結合テストの次のフェーズに対して
十分な品質を確保できる（手戻りとならない）テストをしておくことが重要です。
＃２のコメントに、「"男性","女性" の２値をテストする場合が単体テストで、結合テストでは、いづれかで良いのか？」という質問がありましたが、単体テストや結合テストを、ホワイトボックスやブラックボックスなど、どのテスト手法で行うかは規定されません。また、本来、単体テストでテストされた項目をを再度結合テストで行う必要はありません。
ただし、単体テストは、モジュールの内部仕様が問題ないかを確認することが目的ですから、
ホワイトボックステストが効率的に実施可能であると言えます。
通常モジュールは階層構造になっていて、外部入出力（画面、印刷物、ファイル授受など）の部分は階層構造の最上位部分です。結合テストでは、必ずこの最上位部分でのテストを行うことになりますが、この場合には外部仕様を満たすことが必要ですから、結果的にブラックボックステストが効率的な場合が多いと言えます。
ご確認に対してご回答頂きありがとうございます。
＞厳密に言うと、２つ以上のモジュールを結合して行うテストが結合テストです。
＞他機能との関連、とか視点は、その結果であったり、結合テストを行うときの標準化の基準です。
＞単体テストや結合テストを、ホワイトボックスやブラックボックスなど、どのテスト手法で行うかは規定されません。また、本来、単体テストでテストされた項目をを再度結合テストで行う必要はありません。
ありがとうございます。
つまり、現場では実際に単体テストをしたものをそれと酷似したケースを結合テストで叩いたケースというのは、
本来の概念とは違った、特別に現場で設けられたルールによって、単体テストと結合テストをほぼ同じ内容で行っていたのですね。
時に、ふと思ったのですが、
今のところのブラックボックステストでは
「想定内、想定外のケース」をテスト必要する必要があるという認識です。
単体テスト：ホワイトボックステスト（想定内の条件を検証）
結合テスト：ブラックボックステスト（想定内、想定外の条件を検証）
と検証方法がなっていた場合、
単体テストでホワイトボックステストをした後のブラックボックステストでは、
想定内の範囲の検証は不要になる、という認識で良いのでしょうか？
No.7
1120
40pt
プログラム仕様書から作成するもの→単体テスト
機能仕様書から作成するもの→結合テスト
基本設計書から作成するもの→ＸＸテスト
ユーザが作成するもの-＞業務テスト
単体テストの前に、机上確認（机上テスト）とかやる場合もあります。
結合テストのあとにＸＸテストとかいうのをやることもあります。
ＸＸは会社によって名前が違うので、ＸＸとしました。
ウォーターフォールモデルで開発してると仮定した場合です。
ご回答ありがとうございます。
「単体テスト」と「結合テスト」の分け方として、
プログラム仕様書からと、機能仕様書と分けてみるととても分かり易かったです。
＞ユーザが作成するもの-＞業務テスト
こちら知りませんでした。
業務テストはユーザーが実際に作成したものなのですね（驚）
因みにこちらは、
設計者の意図とは違う視点をもった、設計要求者の視点を入れて検証を行うことで、
バグを発見するためのテスト、という認識で良ろしいでしょうか？
like_aoihana
2008/03/22 21:57:44
17
16
BAZZ
1
1
1
具体的なご回答ありがとうございます。
「単体テスト」「結合テスト」境目が掴めた気がします。
擬似モジュール、擬似サーバーとありますが、
因みにこちら、必ずしも擬似モジュールではなくてはならない、
というものではなく、場合によっては本モジュールを使用する場合もあるという認識で良いでしょうか？
（擬似を、本として使う場合が現場で実際にありましたので。
もしかしたら、現場でそう知らされていないため、そう思い込んでいただけかもしれないのですが…汗）
＞そのため、どこまでが単体テストでどこからが結合テストかというのは複雑なシステムほどわかりにくくなるわけです。
現場で定義が曖昧だった理由（説明を大体で覚えておいてくれ）と言われる理由が少し分かった気がします。
私の知識不足、理解不足な点もあり、余計に分かり辛くなっていたのかもしれません（汗）
サーバー側の単体テストについては行った事も無く、
別の視点として知ることができました。ありがとうございます。