単体テストと結合テストについて教えて下さい。


単体テストとはどの範囲を単体テストと呼べば良いのでしょうか?
また同様に結合テストとはどの範囲を結合テストと呼ぶのでしょうか?

下記のような機能が二つある場合


【モジュール①(住所検索機能)】
Java1
Java2 この3つのモジュールで1機能とする場合
Java3

【モジュール②(情報データ登録機能)】
JavaA
JavaB この3つのモジュールで1機能とする場合
JavaC

モジュール①で、検索機能が正常動作するかを確認することを「単体テスト」
(1機能が正常に動くかどうかを視点とみるものが単体テスト)

モジュール①の検索機能を使用して、
モジュール②の情報データの登録を行う、1機能と1機能を併せて正常動作の確認することを「結合テスト」と呼ぶのでしょうか?
(2つ以上の機能を併せて動作確認を行う事が結合テストと呼ぶのでしょうか?)

参考サイトでは、
単体テストは仕様を十分満たしているかの確認、
システムテストはシステム全体が稼動するかどうかの確認と書かれていたのですが、
具体的に範囲を付けるとしたらどう境目を付ければ良いのでしょうか?

回答の条件
  • URL必須
  • 1人3回まで
  • 登録:2008/03/16 17:52:35
  • 終了:2008/03/22 21:52:53

ベストアンサー

id:garyo No.4

garyo回答回数1782ベストアンサー獲得回数962008/03/17 00:14:55

ポイント70pt

他から切り離せる(外部仕様がある)モジュールに、他のモジュールがない状態で試験を行うものを「単体テスト」

単体でテストしたモジュールを複数組み合わせてテストするものを「結合テスト」といいます。

当然、見方によって、色々変わってきます。


例えばサーバークライアントシステムで

A社がクライアント側ソフト(モジュールA,B)、B社がサーバー側ソフト(モジュールC,D)を作る場合に、モジュールAはモジュールBがないと動作せず、モジュールCはモジュールDがないと動作しないとします。また、サーバー側ソフト、クライアント側ソフトも単体では動かないとします。

モジュールA,モジュールBをそれぞれ別な人が作っている(仕様がそれぞれ決まっているとする)とします。



モジュールAをデバッグするためには擬似的にモジュールBの代わりをするものが必要になります。

(モジュールBもモジュールAの代わりをするものが必要になります)

モジュールBの代わりをするものを仮につくり、モジュールAだけでデバッグすることを「単体テスト」といいます。


1)[モジュールA]-[擬似モジュールB]:モジュールAの単体テスト

2)[擬似モジュールA]-[モジュールB]:モジュールBの単体テスト


モジュールBとモジュールAがそれぞれ単体テストが終わった後、両方を同時に動かしてみることを「結合テスト」といいます。

3)[モジュールA]-[モジュールB]:モジュールA,Bの結合テスト


ここでA社がクライアントソフトを動かす時に、サーバー側ソフトが出来ていなければ、擬似のサーバーソフトが必要になります。

これはクライアントソフトの単体テストになります。


4)[[モジュールA]-[モジュールB]]-[擬似サーバー]:クライアントソフトの単体テスト

同じようにサーバー側も擬似のクライントソフトが必要になります。

5)[擬似クライアント]-[[モジュールC]-[モジュールD]]:サーバー側の単体テスト


サーバー・クライアントの双方のデバッグが終わると結合テストになります。

6)[クライアント]-[サーバー]:サーバーとクライアントの結合テスト


ここで3)と4)はほとんど同じような試験ですが、それぞれ視点により単体テストとも結合テストとも呼べます。


プログラムは小さなモジュールが組み合わさって大きな機能モジュールになり、それがまた組み合わさってさらに大きなモジュールになり・・・という入れ子構造になっているため、下からみると結合テストだが、上からみると単体テストになるというのを繰り返しているわけです。


http://e-words.jp/w/E58D98E4BD93E38386E382B9E38388.html


そのため、どこまでが単体テストでどこからが結合テストかというのは複雑なシステムほどわかりにくくなるわけです。

id:like_aoihana

具体的なご回答ありがとうございます。

「単体テスト」「結合テスト」境目が掴めた気がします。


擬似モジュール、擬似サーバーとありますが、

因みにこちら、必ずしも擬似モジュールではなくてはならない、

というものではなく、場合によっては本モジュールを使用する場合もあるという認識で良いでしょうか?

(擬似を、本として使う場合が現場で実際にありましたので。

 もしかしたら、現場でそう知らされていないため、そう思い込んでいただけかもしれないのですが…汗)


>そのため、どこまでが単体テストでどこからが結合テストかというのは複雑なシステムほどわかりにくくなるわけです。

現場で定義が曖昧だった理由(説明を大体で覚えておいてくれ)と言われる理由が少し分かった気がします。

私の知識不足、理解不足な点もあり、余計に分かり辛くなっていたのかもしれません(汗)


サーバー側の単体テストについては行った事も無く、

別の視点として知ることができました。ありがとうございます。

2008/03/22 21:18:39

その他の回答(6件)

id:KUROX No.1

KUROX回答回数3542ベストアンサー獲得回数1402008/03/16 20:24:09

ポイント30pt

単体テスト、結合テストをしやすい構造で作ることが前提です。

作ってから区別するのは至難の技です。

単体テストは、できる限りの範囲で範囲を小さくしてテストします。

結合テストは、単体テストではできない機能の組み合わせのテスト

となります。

WEBアプリとかのような場合は、単体テストと結合テストの切り分けが

きちんとできない場合が多いです。重要なのはテスト漏れがないように

テストするということです。

>具体的に範囲を付けるとしたらどう境目を付ければ良いのでしょうか?

単体テストは、テストできる最小単位にするしかありません。

http://q.hatena.ne.jp/answer

id:like_aoihana

ご回答ありがとうございます。


>単体テストは、できる限りの範囲で範囲を小さくしてテストします。

ありとうございます。

目の前がパーーっと開けたような感じです。


1機能がどうこう言うよりも、

「最小の範囲でテストを行うこと」が単体テストなのですね。


>WEBアプリとかのような場合は、単体テストと結合テストの切り分けが

>きちんとできない場合が多いです。

おっしゃられている通りが数々の現場では、

幾つか現場で両方を行ったのですが、切り分けが抽象的なところがあったと思います。

現場のリーダーさんに聞いてみても、

「うちではこれを単体テストとしています」

という話の内容が多く、結局どこまでがどの工程なのか?

というところが明確に解りませんでした。


ある現場Aでは、

「単体テストと結合テストの内容、ケース数がほぼ同じ」という場所ありました。

(厳密には単体テストで使用する値は「アアア」などOK

 結合テストで使用する値は「実際のシステムで使用される値」で検証。

 という形でした。)


ある現場Bでは、

単体テストでは凄く時間を掛けて沢山のケースを行ったのに反して、

結合テストでは10分の1ほどのケースしか存在しないものがありました。


切り分けの視点としては

おっしゃられる「単体テストは、テストできる最小単位」と考えると、

色々な現場でテスト検証のポイントが違ったのも納得がいきました。


ありがとうございます、とても参考になります。

2008/03/16 21:22:31
id:pahoo No.2

pahoo回答回数5960ベストアンサー獲得回数6332008/03/16 18:24:19

ポイント30pt

あくまで個人的な意見ですが、Javaでしたらこんな感じです。

  • 単体テスト‥‥javadocを走らせて、すべてのメソッド/変数に対して仕様を確認(ホワイトボックステスト)する。
  • 結合テスト‥‥publicなメソッド,I/Fメソッドなどに対してブラックボックステストを行う。

設計書が、単体テスト/結合テストの違いを意識した構成になっていないと、単体テストに時間がかかったり、必要な結合テストをやり損ねたりします。


参考サイト

id:like_aoihana

ご回答ありがとうございます。

個人的な意見、とても嬉しいです。


「変数に対して仕様を確認」、

こちら、ご確認をお願いしたいのですが


単体テストですと、

性別 "男性""女性" という変数が対象だった場合、

"男性"と"女性"の両方で試して、正常処理が行われるか(エラーが発生しないか)を確認する。

これをホワイトボックステストと呼ぶ、いう認識で良いでしょうか?


結合テストですと、

性別 "男性""女性" という変数が対象だった場合、

"男性"が"女性"どちらかだけ試して、正常処理が行われるか(エラーが発生しないか)を確認する。


どちらかだけで良い理由としては、実際には単体テストで処理が正常に通る事が確認されているので、

動作確認だけで良い。

これをブラックテストと呼ぶ、という認識で合っていますでしょうか?


>設計書が、単体テスト/結合テストの違いを意識した構成になっていないと、単体テストに時間がかかったり、必要な結合テストをやり損ねたりします。

こちら、ありがとうございます。

設計書についてまだ良く分かっていないため、注意点について、とても為になります。

2008/03/16 21:37:42
id:BAZZ No.3

BAZZ回答回数55ベストアンサー獲得回数02008/03/16 19:19:21

ポイント60pt

モジュール① として Java1, Java2, Java3 があって、「この3つのモジュールで1機能」と表現されています。

ここで、モジュール①は「モジュール群」と考え、Java1,Java2,Java3 をそれぞれ「単体モジュール」と呼ぶことにして、以下に回答します。

・単体テスト:単体モジュール単位のテスト。つまり Java1,Java2,Java3 それぞれでのテストになります。したがって、 たとえば Java1 のテストをするためには、Java1 を稼動させるためのドライバを作成したりします。

・結合テスト:「モジュール群」としてのテストは結合テストになります。したがって、モジュール① の機能テストも、モジュール②の機能テストも、いづれも「結合テスト」です。

なお、結合テストはその結合の度合いから、複数の段階に分類されることがよくあります。例えば、「結合テストA」「結合テストB」と2段階に分けた場合、第一段階の「結合テストA」では、機能単位のテストのこと。「結合テストB」はサブシステム間のテストを意味します。

ご質問の例ですと、たかだか、Javaモジュール 6個程度ですし、モジュール群②は、モジュール群①が存在しないと稼動できないようなので、いづれの機能テストも「結合テストA」の範囲と思われます。検索システム と 情報データ登録システム というように、それぞれ独立した大きなサブシステムに分割が可能であるなら、「統合テストB」でテストすることになるでしょう。サブシステムとは、通常ある程度大きな単位のシステムです。

http://e-words.jp/w/E58D98E4BD93E38386E382B9E38388.html

id:like_aoihana

>Java1,Java2,Java3 それぞれでのテストになります。

既にご回答下さった中で出ております「最小単位でのテスト」の観点から、

1機能ではなく、モジュール単位でテストできる場合は各モジュールが単体テストの対象となる、

という認識で合っていますでしょうか?


>・結合テスト:「モジュール群」としてのテストは結合テストになります。したがって、モジュール① の機能テストも、モジュール②の機能テストも、いづれも「結合テスト」です。

こちら分かったような気がします。

結合テストの見分け方としては、

1機能と1機能でというよりは、

モジュールとモジュールが2つ以上合わさってテストを行うものは、

結合テストになる、ということですよね?

(もっと厳密に言うと、他機能との関連が関係して動作する機能をテストの視点としておくものが、

 結合テストである、ということで合っていますでしょうか?)


私にはシステムの切り分けの概念が無かったため、

今回のお話とても為になりました。

ありがとうございます。

2008/03/16 21:44:29
id:garyo No.4

garyo回答回数1782ベストアンサー獲得回数962008/03/17 00:14:55ここでベストアンサー

ポイント70pt

他から切り離せる(外部仕様がある)モジュールに、他のモジュールがない状態で試験を行うものを「単体テスト」

単体でテストしたモジュールを複数組み合わせてテストするものを「結合テスト」といいます。

当然、見方によって、色々変わってきます。


例えばサーバークライアントシステムで

A社がクライアント側ソフト(モジュールA,B)、B社がサーバー側ソフト(モジュールC,D)を作る場合に、モジュールAはモジュールBがないと動作せず、モジュールCはモジュールDがないと動作しないとします。また、サーバー側ソフト、クライアント側ソフトも単体では動かないとします。

モジュールA,モジュールBをそれぞれ別な人が作っている(仕様がそれぞれ決まっているとする)とします。



モジュールAをデバッグするためには擬似的にモジュールBの代わりをするものが必要になります。

(モジュールBもモジュールAの代わりをするものが必要になります)

モジュールBの代わりをするものを仮につくり、モジュールAだけでデバッグすることを「単体テスト」といいます。


1)[モジュールA]-[擬似モジュールB]:モジュールAの単体テスト

2)[擬似モジュールA]-[モジュールB]:モジュールBの単体テスト


モジュールBとモジュールAがそれぞれ単体テストが終わった後、両方を同時に動かしてみることを「結合テスト」といいます。

3)[モジュールA]-[モジュールB]:モジュールA,Bの結合テスト


ここでA社がクライアントソフトを動かす時に、サーバー側ソフトが出来ていなければ、擬似のサーバーソフトが必要になります。

これはクライアントソフトの単体テストになります。


4)[[モジュールA]-[モジュールB]]-[擬似サーバー]:クライアントソフトの単体テスト

同じようにサーバー側も擬似のクライントソフトが必要になります。

5)[擬似クライアント]-[[モジュールC]-[モジュールD]]:サーバー側の単体テスト


サーバー・クライアントの双方のデバッグが終わると結合テストになります。

6)[クライアント]-[サーバー]:サーバーとクライアントの結合テスト


ここで3)と4)はほとんど同じような試験ですが、それぞれ視点により単体テストとも結合テストとも呼べます。


プログラムは小さなモジュールが組み合わさって大きな機能モジュールになり、それがまた組み合わさってさらに大きなモジュールになり・・・という入れ子構造になっているため、下からみると結合テストだが、上からみると単体テストになるというのを繰り返しているわけです。


http://e-words.jp/w/E58D98E4BD93E38386E382B9E38388.html


そのため、どこまでが単体テストでどこからが結合テストかというのは複雑なシステムほどわかりにくくなるわけです。

id:like_aoihana

具体的なご回答ありがとうございます。

「単体テスト」「結合テスト」境目が掴めた気がします。


擬似モジュール、擬似サーバーとありますが、

因みにこちら、必ずしも擬似モジュールではなくてはならない、

というものではなく、場合によっては本モジュールを使用する場合もあるという認識で良いでしょうか?

(擬似を、本として使う場合が現場で実際にありましたので。

 もしかしたら、現場でそう知らされていないため、そう思い込んでいただけかもしれないのですが…汗)


>そのため、どこまでが単体テストでどこからが結合テストかというのは複雑なシステムほどわかりにくくなるわけです。

現場で定義が曖昧だった理由(説明を大体で覚えておいてくれ)と言われる理由が少し分かった気がします。

私の知識不足、理解不足な点もあり、余計に分かり辛くなっていたのかもしれません(汗)


サーバー側の単体テストについては行った事も無く、

別の視点として知ることができました。ありがとうございます。

2008/03/22 21:18:39
id:pahoo No.5

pahoo回答回数5960ベストアンサー獲得回数6332008/03/16 22:18:18

ポイント60pt

#2で回答した者です。コメントが付けられないので、回答欄でレスします。

単体テストですと、

性別 "男性""女性" という変数が対象だった場合、

"男性"と"女性"の両方で試して、正常処理が行われるか(エラーが発生しないか)を確認する。

これをホワイトボックステストと呼ぶ、いう認識で良いでしょうか?

仕様上、「男性」「女性」の2値しかとらないなら、それで結構です。


結合テストですと、

性別 "男性""女性" という変数が対象だった場合、

"男性"が"女性"どちらかだけ試して、正常処理が行われるか(エラーが発生しないか)を確認する。

違います。「男性」「女性」以外の値も投入し、プログラムが仕様通りに動作することを確認します。


つまり、ホワイトボックステストは仕様書通りに動くことを確認するだけで済みますが、ブラックボックステストはあらゆるケース(悪意を持った攻撃を含めて)を想定して実施しなければなりません。当然、ブラックボックステストには莫大な工数がかかります。

よって、結合テストの工数を押さえ込む意味でも(もちろん、プログラムの安全性を担保するためにも)、設計時に、publicやI/Fメソッドなど結合テストの対象になる機能は限定すべきです。

id:like_aoihana

再度のご回答ありがとうございます。

>仕様上、「男性」「女性」の2値しかとらないなら、それで結構です。

>違います。「男性」「女性」以外の値も投入し、プログラムが仕様通りに動作することを確認します。

ありがとうございます。


ホワイトボックスとブラックボックスの検証視点としては


ホワイトボックス:想定した範囲内の値で検証(主に単体テストの検証)

ブラックボックス:想定内と想定外の範囲外の値を含めての検証(主に結合テストの検証)


という認識で合っていますでしょうか?


また質問が多くて申し訳ないのですが、

もしご回答頂けましたらお願いしたいと思います。


「単体テスト」後の「結合テスト」を行う理由について

--------------------------------------------

・結合テストでは「異常値」を入れてテストする事でより深いテストを行う

・結合テストでモジュールの結合によって思わぬ不具合が発生しないかの確認をする

という認識で合っていますでしょうか?



「I/Fメソッド」について

----------------------

 こちらはどのようなメソッドなのでしょうか?

 

2008/03/20 18:59:47
id:BAZZ No.6

BAZZ回答回数55ベストアンサー獲得回数02008/03/17 14:51:36

ポイント60pt

#3で回答した BAZZ です。

コメントが付けられないので、ご質問に対して回答欄でレスします。

>1機能ではなく、モジュール単位でテストできる場合は各モジュールが単体テストの対象となる、

>という認識で合っていますでしょうか?

はい、正しい理解です。

>結合テストの見分け方としては、

>1機能と1機能でというよりは、

>モジュールとモジュールが2つ以上合わさってテストを行うものは、

>結合テストになる、ということですよね?

 はい、正しい理解です。

>(もっと厳密に言うと、他機能との関連が関係して動作する機能をテストの視点としておくものが、

> 結合テストである、ということで合っていますでしょうか?)

 厳密に言うと、2つ以上のモジュールを結合して行うテストが結合テストです。

 他機能との関連、とか視点は、その結果であったり、結合テストを行うときの標準化の基準です。

 この基準の決め方は、プロジェクトによって様々ですが、結合テストの次のフェーズに対して

 十分な品質を確保できる(手戻りとならない)テストをしておくことが重要です。

#2のコメントに、「"男性","女性" の2値をテストする場合が単体テストで、結合テストでは、いづれかで良いのか?」という質問がありましたが、単体テストや結合テストを、ホワイトボックスやブラックボックスなど、どのテスト手法で行うかは規定されません。また、本来、単体テストでテストされた項目をを再度結合テストで行う必要はありません。

ただし、単体テストは、モジュールの内部仕様が問題ないかを確認することが目的ですから、

ホワイトボックステストが効率的に実施可能であると言えます。

通常モジュールは階層構造になっていて、外部入出力(画面、印刷物、ファイル授受など)の部分は階層構造の最上位部分です。結合テストでは、必ずこの最上位部分でのテストを行うことになりますが、この場合には外部仕様を満たすことが必要ですから、結果的にブラックボックステストが効率的な場合が多いと言えます。



http://e-words.jp/w/E58D98E4BD93E38386E382B9E38388.html

id:like_aoihana

ご確認に対してご回答頂きありがとうございます。


>厳密に言うと、2つ以上のモジュールを結合して行うテストが結合テストです。

>他機能との関連、とか視点は、その結果であったり、結合テストを行うときの標準化の基準です。

>単体テストや結合テストを、ホワイトボックスやブラックボックスなど、どのテスト手法で行うかは規定されません。また、本来、単体テストでテストされた項目をを再度結合テストで行う必要はありません。

ありがとうございます。

つまり、現場では実際に単体テストをしたものをそれと酷似したケースを結合テストで叩いたケースというのは、

本来の概念とは違った、特別に現場で設けられたルールによって、単体テストと結合テストをほぼ同じ内容で行っていたのですね。


時に、ふと思ったのですが、

今のところのブラックボックステストでは

「想定内、想定外のケース」をテスト必要する必要があるという認識です。


単体テスト:ホワイトボックステスト(想定内の条件を検証)

結合テスト:ブラックボックステスト(想定内、想定外の条件を検証)

と検証方法がなっていた場合、

単体テストでホワイトボックステストをした後のブラックボックステストでは、

想定内の範囲の検証は不要になる、という認識で良いのでしょうか?

2008/03/22 21:40:18
id:watch00 No.7

watch00回答回数112ベストアンサー獲得回数02008/03/18 19:05:50

ポイント40pt

プログラム仕様書から作成するもの→単体テスト

機能仕様書から作成するもの→結合テスト

基本設計書から作成するもの→XXテスト

ユーザが作成するもの->業務テスト

単体テストの前に、机上確認(机上テスト)とかやる場合もあります。

結合テストのあとにXXテストとかいうのをやることもあります。

XXは会社によって名前が違うので、XXとしました。

ウォーターフォールモデルで開発してると仮定した場合です。


http://q.hatena.ne.jp/answer

id:like_aoihana

ご回答ありがとうございます。


「単体テスト」と「結合テスト」の分け方として、

プログラム仕様書からと、機能仕様書と分けてみるととても分かり易かったです。


>ユーザが作成するもの->業務テスト

こちら知りませんでした。

業務テストはユーザーが実際に作成したものなのですね(驚)


因みにこちらは、

設計者の意図とは違う視点をもった、設計要求者の視点を入れて検証を行うことで、

バグを発見するためのテスト、という認識で良ろしいでしょうか?

2008/03/22 21:45:27
  • id:like_aoihana
    色々と為になったことが多かったため、高いポイントを付けたいと思いもあって、
    ご確認として再度ご質問を残しているままなのですが少し早めに終了とさせて頂きました。

    ご確認としてのご質問については、
    もしよろしければご回答くださると幸いです。

    色々な視野として為になるご回答を沢山下さり、ありがとうございました。


  • id:BAZZ
    先のご質問への回答です。

    >>厳密に言うと、2つ以上のモジュールを結合して行うテストが結合テストです。
    >>他機能との関連、とか視点は、その結果であったり、結合テストを行うときの標準化
    >>の基準です。
    >>単体テストや結合テストを、ホワイトボックスやブラックボックスなど、
    >>どのテスト手法で行うかは規定されません。
    >>また、本来、単体テストでテストされた項目をを再度結合テストで行う
    >>必要はありません。

    >ありがとうございます。
    >つまり、現場では実際に単体テストをしたものをそれと酷似したケースを
    >結合テストで叩いたケースというのは、
    >本来の概念とは違った、特別に現場で設けられたルールによって、
    >単体テストと結合テストをほぼ同じ内容で行っていたのですね。

    どうも、うまく伝え切れていないと感じています。
    概念的に言えば、各テストというのは、そのフェーズを示しています。
    いづれのテストも目的は品質を向上させたいということになります。
    単体テストは、単体の品質をチェックする。
    結合テストは、単体を複数結合したときの品質をチェックする。
    ことが目的であり、その目的を達成することができるものであれば、
    どんなテストでも「本来の概念」と違ってはいません。
    その現場でのテストがもし、単体テストで行ったテストとまったく同じであるなら、
    意味は無いと思いますが、きっとなんらかの複数のモジュールを結合したり、
    テスト環境を変えていたり(例えば入力値をプログラム内変数で与えていたものを、
    画面から読み込ませたり)しているのであれば、目的に沿っていると思います。

    >時に、ふと思ったのですが、
    >今のところのブラックボックステストでは
    >「想定内、想定外のケース」をテスト必要する必要があるという認識です。

    想定内 想定外とは、どのような状況でしょうか?
    ここでは、以下のように考えることにします。
      性別を入力値として取りうる場合で、
      想定内:「男性」、「女性」
      想定外:「中性」、入力値なし、その他のテキスト、その他のバイナリ、
          システムの電源障害の発生、ファイルの読み込みエラー

    >単体テスト:ホワイトボックステスト(想定内の条件を検証)
    >結合テスト:ブラックボックステスト(想定内、想定外の条件を検証)
    >と検証方法がなっていた場合、
    >単体テストでホワイトボックステストをした後のブラックボックステストでは、
    >想定内の範囲の検証は不要になる、という認識で良いのでしょうか?

    この認識は違います。

    今一度確認ですが、単体テストは、単体モジュールのテストであり、
    結合テストは、複数のモジュールが結合したもののテストです。
    つまり結合レベルであり、テストケースの作成方法ではありません。
    たとえば、単体テストとして、想定内も、想定外の条件(例:中性)も
    テストしておくべきです。
    これは、ホワイトボックステストの範囲であることが理解できると思います。
    結合モジュールでのテストを行うときには、複数モジュールを結合した状態で、
    正常ケースとして入力値の「男性」「女性」
    を含めて、先に示した、想定内、想定外の全てのケースを実行すべきです。
    もし、テストすべきモジュールが、全体でひとつしかないなら結合テストは不要です。

  • id:like_aoihana
    ご回答ありがとうございます。
    ご返信が遅くなり大変申し訳ありません。


    >時に、ふと思ったのですが、
    >今のところのブラックボックステストでは
    >「想定内、想定外のケース」をテスト必要する必要があるという認識です。

    > 想定内 想定外とは、どのような状況でしょうか?
    > ここでは、以下のように考えることにします。
      性別を入力値として取りうる場合で、
      想定内:「男性」、「女性」
      想定外:「中性」、入力値なし、その他のテキスト、その他のバイナリ、
          システムの電源障害の発生、ファイルの読み込みエラー

    こちらなのですが、
    想定外としては「中性」というのではなく、
    値として「1:男性」「2:女性」「3:(無し)」という場合を
    想定としていました。

    「中性」、「入力値なし」は実際にテストしたこともあるので分かりますし、
    「ファイルの読み込みエラー」も想像が付くのですが、
    「その他のテキスト」、「その他のバイナリ」、「システムの電源障害の発生」というのは
    どういったものなのでしょうか?


    >たとえば、単体テストとして、想定内も、想定外の条件(例:中性)も
    >テストしておくべきです。
    >これは、ホワイトボックステストの範囲であることが理解できると思います。
    こちら“ホワイトボックステストの範囲”というのは、
    「男性」「女性」の検証を含んでいるからということでしょうか?
    それでこの2値についてはホワイトボックスでの検証と呼べて、
    他の「中性」に関してはブラックボックステストになる、
    ということでしょうか?



    【まとめ】
    上手く纏められているかはわからないのですが・・・

    単体テストは、単体の品質をチェックするものである。
    内部処理のプログラム処理であるモジュールに対しては、
    ありうるケースを全て確認する必要がある。
    (「男性」「女性」という2値があった場合、
    他の値を確認する必要がある。)

    結合テストでは、
    結合テストは、単体を複数結合したときの品質をチェックするものである。
    モジュールを結合した上で、
    「中性」、入力値なし、その他のテキスト、その他のバイナリ、
    システムの電源障害の発生、ファイルの読み込みエラーなどの、
    想定外な値について確認を行う必要がある。



    >単体テストは、単体の品質をチェックする。
    >結合テストは、単体を複数結合したときの品質をチェックする。
    >ことが目的であり、その目的を達成することができるものであれば、
    >どんなテストでも「本来の概念」と違ってはいません。
    >その現場でのテストがもし、単体テストで行ったテストとまったく同じであるなら、
    >意味は無いと思いますが、きっとなんらかの複数のモジュールを結合したり、
    >テスト環境を変えていたり(例えば入力値をプログラム内変数で与えていたものを、
    >画面から読み込ませたり)しているのであれば、目的に沿っていると思います。
    すみません。
    何だかとんでもない誤解をしていたようです(汗)

    ある現場で私の視点として単体テストと結合テストが同じように見えていただけで、
    実際に何か意図があったのかもしれないです。

    テストとしては
    本来なら物理データ(テキストファイルから取得)するものを、
    「擬似的に作成したデータを使用してテストを行う。」ということをしていました。

    単体テストでは擬似のデータをJavaで取得して、
    結合テストでは「実際に使用する物理データ」から値を取得する、
    というケースです。

    こういった違いがあれば、
    単体テストと同じような動きをしていても、
    実際にはデータの取得先などが違うために、結合テストである、
    と言えるということですよね。
  • id:BAZZ
    正しく理解されています。
    ありがとうございました。

    なお、「3:(なし)」や その他のビットデータやテキストや数値などは、プログラムロジックからそういうケースが想定できると思いましたので、それはホワイトボックステストで実施すべきと言えます。「男性」「女性」をふくんでいるから、ホワイトボックステストと言う意味ではありません。ホワイトボックステストを実施すると決めた場合に、テストケースを網羅した結果、「男性」「女性」「なし」の全ての境界値をテストケースを実施すべきであると言うことです。テストケースの設定の方法論は他にもいくつかありますが、いづれも、品質を高めるためにテストケースを網羅することが目的です。

    他の上位プログラムから引数で呼ばれるようにして、結合してテストする場合には、その上位プログラムからは、男性・女性 の値しか渡せないようなロジックになっているかもしれません。その場合にあえて、「3:(なし)」などのケースをやろうと考える必要はありません。また、電源障害というのはコンピュータの電源がプログラム実行中に切れるとか、回線が抜けるとかの状況下で、問題なく復旧できるかということをテストするものです。こういったテストはシステム・テストとして実施します。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません