ホワイトボックステスト

質問

「パス」を網羅することがのホワイトボックステスト
やり方だと思うのですが、どうして"「パス」を網羅すること"が
"論理構造の正しさを確認すること"と同じになるのでしょうか。

回答No.4

choconamacream

>仕様に乗っ取っているかどうかをテストするのは、ブラックボックス
>テストになるのかな。

これは正解です。

>「論理構造が正しい」という言葉自体は、
>　　・実行時エラーにならない。
>　　・無駄なコードがない。
>と置き換えて考えても問題ないでしょうか。
>
>ホワイトボックステストでは、プログラムが仕様に乗っ取って
>いるかどうかをみるテストではないと。上記のことを確認するための
>テストであると。

こっちの方はちょっと微妙ですね。

「論理構造が正しい」という言葉を、「実行時エラーにならない」と置き換えて考えても問題はないと思います。ただ、「無駄なコードがない」という言葉には置き換えれないと思います。

一般に、「見た目は全く同じ動作をしているけれども、無駄なコードをなくして将来的に機能拡張し易いコードに変更していく作業のこと」をリファクタリングといいます。

（A）論理構造は正しく（実行時エラーはなく）、仕様通りの動作をしているけれども、無駄なコードがあるプログラム
（B）論理構造は正しく（実行時エラーはなく）、仕様通りの動作をしているのに加えて、無駄なコードがなく拡張性に優れたプログラム

手短にいえば、リファクタリングとは、（A）から（B）に修正することですね。

ホワイトボックステストともまた、「仕様に乗っ取っているのかどうかをみるテスト」でもあります。この辺りがややこしい所でもありますね。以下がブラックボックステストとホワイトボックステストの違いです。

ブラックボックステスト[機能テスト]→プログラム内の個々の処理は考慮せず、入力と出力の流れが仕様通りの動作となっているかを確認するためのテスト。
ホワイトボックステスト[構造テスト]→プログラムの一つ一つの処理の流れが、仕様通りの動作となっているかを確認するためのテスト。

実際の開発現場においては、余程の小規模でもない限り大半がチーム開発となります。そうなると、やはり個々のプログラマさんによっては無駄なコードがあったりなかったりと、ソフトウェアの品質にもバラツキが出てきたりします。
そのような中で、とりあえずブラックボックステストにおいては、お客様の要求している機能を満たしているのかどうかを見るわけです。（お客様も又、個々のソースプログラムが具体的にどのようになっているのかは知り得ないですよね。）
はたまた、ホワイトボックステストにおいては、個々のプログラマによっていろいろと実装の違いや無駄なコードの有り無しがあるでしょうけど、ソースプログラムの処理１つ１つが、仕様を満たしているのかどうかをチェックするわけです。

仕様で決められているものの一つに、「パラメータ」がありますよね。ブラックボックスにおいては、あるパラメータを入力した時に、また別の期待されたパラメータが返ってきたら、それでテストとしてはOKなわけです。同じく、ホワイトボックスにおいては、仕様によって定められたパラメータを入力した時に、内部でそのパラメータが期待している通りに処理されているかをチェックするわけです。

つまるところ、"「パス」を網羅すること"と"論理構造の正しさを確認すること"の二つも、如何様にも読み取れそうです。「論理構造の正しさ」というのが、あるシステム内での仕様に限定されるものであれば、用はそのためのテストにおいて、「パス」の網羅率を上げていき、デバッグもきちんとこなしていって仕様通りの動作となっていることが確認できれば、その時点で上記の２つは同じとなります。（よく実務レベルでも、論理構造的におかしいのではないか？と開発者さんが声を上げても、設計者さんが「これが仕様です。」と言えば、それがまかり通ってしまうものです。→結果的に、「論理構造が正しい」ということになる！！）

ただ、この「論理構造の正しさ」というのが、一般的なソフトウェアやコンピュータシステム全般の品質や信頼性などに係わってくるものであると仮定したのならば、#1さんのおっしゃる通りとなります。

回答No.3

choconamacream

他の回答者さんと同じく、"論理構造の正しさを確認すること"という表現は、少し分かりづらいように思われます。（何かしらの洋書を、そのまま訳したものなんでしょうかねえ？）

ただ私が察するに、この文章を書かれた方は、用するに「背理法」のような考え方を述べたかったのだと思います。もちろん、以下のような手法を用いれば様々なテストケースを実施することができますが、そこから言えることというのは、単に言語仕様として正しい動作をしている、ということぐらいです。

・ステートメント・カバレッジ[命令網羅]
・ブランチ・カバレッジ、デシジョン・カバレッジ[判定条件網羅]
・条件カバレッジ[条件網羅]

ただ、考えられうるあらゆるテストケースやテストスイート[テストセット]を実施した上で、それでも何ら「論理構造が正しくないこと」が確認できなかったのならば、そもそも「論理構造は正しくないことはない」、つまり、「論理構造は正しい」という結論が導き出せると思います。（とにかく、最初の段階では論理構造が正しいのか、それとも正しくないのかどうかについて分からないので、とりあえず、「論理構造は正しくない」と仮定して、実に様々なテストケースを実施し、網羅率をどんどんあげていこう。そして、もしその仮定が正しかったならば、一つぐらいはバグが見付かるはずだ、という考えですね。それにもかかわらず、バグが一つもなかったのならば、実際には最初の仮定とは反対で、「論理構造は正しい」のではないか、ということです。）

参考URL：

http://www.jstqb.jp/syllabus.html

お礼

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

「論理構造が正しい」という言葉自体は、
　　・実行時エラーにならない。
　　・無駄なコードがない。
と置き換えて考えても問題ないでしょうか。

ホワイトボックステストでは、プログラムが仕様に乗っ取って
いるかどうかをみるテストではないと。上記のことを確認するための
テストであると。
仕様に乗っ取っているかどうかをテストするのは、ブラックボックス
テストになるのかな。

回答No.2

dsuekichi

> ”「 パス」を網羅すること"が
> "論理構造の正しさを確認すること"
にはならないと思いますが、

逆の
> ”「 パス」を網羅『できない』こと"で
> "論理構造に『間違いがある』事を見つけること"
は、ありえますね。

「絶対実行できないパス」があるということは、
分岐条件の設定を間違えているか、そもそも必要ない分岐かどちらかでしょうから・・・

お礼

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

おっしゃることは基本的にNo.1さんと
同じことでしょうか。

回答No.1

notnot

"「パス」を網羅すること"と"論理構造の正しさを確認すること"とは同じではないですね。

"「パス」を網羅すること" は単に未テストのコードがないということを示すだけです。そんなことで、論理構造の正しさが示せるなら、世の中正しいプログラムだらけです。

お礼

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

>"「パス」を網羅すること" は単に未テストのコードがないということを示すだけです。
私もそう思いました。