単体テスト仕様書を作成したいが、どんなテストを実施すればいいのかが難しく分かりません。

Question

以下のmain.cshの単体テスト仕様書を作成したいです。

#!/bin/csh -f

set list = (str1 str2)
set status = 0

foreach str ($list)
  sub1.csh $str
  if ($? != 0) then
  	echo "sub1失敗"
  	set status = 1
  endif

  # sub2.cshのみ環境変数${USER}を引数としており、
  # 異常終了によるメッセージは出力しない
  sub2.csh ${USER}

  sub3.csh $str
  if ($? != 0) then
  	echo "sub3失敗"
  	set status = 1
  endif
end

sub4.csh $str
if ($? != 0) then
  echo "sub4失敗"
  set status = 1
endif

if (status == 0) then
  exit 0
else
  exit 1
endif

※sub1～4は単体テスト完了済みです。

現在、単体テストのテスト内容としては以下を考えています。
(1)sub1が異常終了する場合
・「sub1失敗」のメッセージが出力されること。
・mainの終了ステータスが1であること・
(2)sub3が異常終了する場合
・「sub3失敗」のメッセージが出力されること。
・mainの終了ステータスが1であること。
(3)sub4が異常終する場合
・「sub4失敗」のメッセージが出力されること。
・mainの終了ステータスが1であること。
(4)sub1,3,4がすべて正常終了する場合
・「sub1失敗」のメッセージが出力されないこと。
・「sub3失敗」のメッセージが出力されないこと。
・「sub4失敗」のメッセージが出力されないこと。
・mainの終了ステータスが0であること。

他にテストするケースとしてはsub1,sub2,sub3,sub4がそれぞれ正常終了、異常終了する全ての組み合わせのテストは必要でしょうか？
(例：sub1→正常終了 sub2→異常終了 sub3→異常終了 sub4→異常終了 等)
また、他にテストするべきケースはありますか？
よろしければ、理由も含めて教えていただきたいです。

単体テスト仕様書を書くのがどうも苦手で、どんなテストを実施すればいいのか、またそのテストを実施する理由はどうしてかを考えるのが難しいです。

Answer 1

このプログラムを作る際の仕様書があるはずですよね。
仕様書の通りに動くことが必要なのでプログラムからはテスト仕様書は作れません。

プログラムが書いてあるとおりに動作するかというのはコンパイラーのテストをしているに過ぎません。

Comments

[退会済みユーザー]

基本設計書も詳細設計書などの仕様書もありません。
ツール作成→単体テスト実施→詳細設計書作成という手順で行うよう依頼されています。
また、このツールは私以外の人が作成したものであり、私が単体テスト実施の依頼をされています。

[maiko0318]

順序がおかしいです。
作らなければならないものっていうのは客のニーズに答えるものであり、
設計→仕様書→プログラミング→テストという順です。
～という手順で、とお願いされたら「はい」ではなくて「それはおかしいです」というべきものです。

(1)sub1が異常終了する場合
・「sub1失敗」のメッセージが出力されること。
それでいいのですか？という答えは客が持っています。

Answer 2

単体テストでは、バグを出し切りたいので、思いつくテストは全部やったほうが良いです。

ただ、お仕事だと、いろいろな考え方やルールややり方が合ったりしますので、基本的には同じ職場の先輩、上司に相談したほうが良いと思います。やりすぎて、時間がかかりすぎるというは、それはそれで問題なので。

パッと見ですが、入力値に対するチェックがないので、そのへんでバグがあるかもなぁ、って感じがします。
与えた入力によって動作が変わることを想定していろんな値を与えるテストをすると良いかもしれません。

• 文字列に空白文字を含んだ場合にバグらないかテストします。
• 数値であれば、数値に対しては、負数・整数、整数・小数点、極端に大きい数値、などを与えます。
• リストが含まれる場合は、空のリストになる場合のテストもしたいですね。

Answer 3

工程ごとにドキュメントがあるのが正しいあり方だと思いますが、現実的にはそうでないケースもありますね。
基本的にはすべてを網羅して期待値を記入した上でテスト実施前に依頼元に確認してからテストを実施という流れになるかと思います。

私が某F社の方に教わったやり方は要因分析表を使うもので要因分析表示体がテスト設計になるというものでした。

要因分析表とはエクセルを使って横軸に入力要因を並べて縦軸に要因の入力パターンを列挙します。テストパターンは入力パターンの組み合わせとなるので横軸の最終列に期待値と結果を記入できるようにしておきます。入力パターンは仕様書があるなら仕様書から、なければ境界値付近、代表値などで取っていきます。
関数からの戻り値も入力要因だった気がしますが詳しいことは忘れました。

cshのスクリプトは読めないので表は適当です。。。

| パターン \ 要因| str1 | str2 | sub1の戻り値($?) | sub3の戻り値($?) | sub4の戻り値($?) | 期待値 | 結果 |
|:--|:--:|--:|--:|--:|
| 1 | NULL | NULL | 0 | 0 | 0 | | |
| 2 | 非NULL(長さ1) | NULL | 0 | 0 | 0 | | |
| 3 | 非NULL(長さ10) | NULL | 0 | 0 | 0 | |
| 4 | 非NULL(...) | NULL | 0 | 0 | 0 | | |
| 5 | 非NULL(...) | NULL | 0 | 0 | 0 | | |

正直無駄の多い方法だとは思いますが、エビデンスとしてきちんと残せますし、テスト設計者とテスト実施者を分けることが出来ますし、プログラムの把握にはつながると思います。

Comments

[退会済みユーザー]

ご回答ありがとうございます。
要因分析表作ってみます。