品質

日本システム開発株式会社から品質に関するコラムをお届けします。

品質向上サービスを提供し続けて十数年の弊社から、品質を高めるための様々な情報を発信します。

日本システム開発の技術、
覗いてみませんか。

品質コラム第5回「「詳細設計書を見る人」にとっての「良い詳細設計」CASE1(引数)」

2014.11.11

前回は「詳細設計書｣はフォーマットではなくどういう情報を載せているかが重要で、詳細設計書を見る人(コーディング者とテスト実施者)が質問をするようではダメだということになりました。

今回は「詳細設計書を見る人」にとっての「良い詳細設計」を具体的に検討しました。

「詳細設計書を見る人」でも特に単体テスト実施者の側から検討しています。

今日のサンプル

一般的に良くありがちな詳細設計書(関数仕様)のサンプルとして以下を題材にしました。

サンプル詳細設計書(関数仕様)
書式		unsigned char chk_date(unsigned short year, unsigned char month, unsigned char day)
仕様説明		引数に指定された年月日の範囲チェックを行い、正当かどうかをチェックする。
引数		unsigned short year [入力]
	意味	チェックしたい年
		unsigned char month [入力]
	意味	チェックしたい月
		unsigned char day [入力]
	意味	チェックしたい日
戻り値	正常	TRUE(1) ：年月日が正当
戻り値	異常	FALSE(0)：年月日が不当
備考		–

上記情報だけでは品質の良い単体テスト設計は出来ません。

なぜ出来ないかを順を追って検討していきます。

今回は『引数』に着目します。

品質が良いと言うためにはどれだけやればいいか

引数に着目した場合、入力される値のどれだけをテストしたら品質がいいといえるでしょうか。

テストを実施する目的は2種類あります。

品質を証明するため
バグを発見するため

この2つが目的であれば、値に絶対漏れが無く大丈夫だといえるのは「全部の値」をテストすることです。

例えば、unsigned short 型の変数であれば0 ～ 65535 全てをテストしたら品質は良く、バグを発見できる確率も高いと言えます。

しかし、開発効率を考えれば「全部の値」をテストすることは適切ではありません。

かといって減らしすぎてもバグが発見されず、証明パターンも減ってしまいます。

バグを潜在させず、かつ、いかにテストデータを間引くかがテーマになります。

そのため一般的にはある観点でサンプリングを行い、テストケースを減らしていきます。

サンプリングの例

サンプリングの観点の例として「境界値分析」と「同値分割」を挙げます。

境界値分析と同値分割とは・・・

同値分割
起こりうるすべての事象をいくつかのグループに分け、各グループから代表値を選ぶ。
※このグループを同値クラスと呼ぶ。同じ出力結果が得られる入力値の集合。
境界値分析
同値クラスの境界値付近を入力値として選ぶ。
※一般的に、欠陥は境界値付近に潜在することが多いため、重要。
※本掲載では、同値分割・境界値分析は9点設定を基本とする。

以降のサンプリング観点は「境界値分析」と「同値分割」を使用していきます。

どんなテストが出来るか

chk_dateの引数「year」に着目してテストデータをサンプリングします。

引数		unsigned short year [入力]
引数	意味	チェックしたい年

本関数仕様からは｢unsigned short｣の範囲は全て許容されるように見えます。

欠陥がある可能性の高い「境界」をテストすべきですが、引数「year」の仕様には何も基準の指定がありません。

そのため、キャストなどの可能性から危険と考えられる箇所「他の型との境界値」を設定したら良いという意見が出ました。

0と1は重複しているため省くと、サンプリングされた値は「0, 1, 126, 127, 128, 254, 255, 256, 32766, 32767, 32768, 65534, 35535」の13個になります。

本当にこの13個の値でよいのでしょうか。

数字の指定がないと品質の良いテスト設計できない

サンプリングした13個の値を検証していきましょう。

型がunsigned shortとなった理由は下記2点が考えられます。

unsigned shortの範囲(0～65535)全てを使用する可能性がある
unsigned charの最大値(255)を超える可能性がある

1つ目が理由の場合、可能性がある以上テストすべきです。

しかし2つ目が理由の場合、可能性がある値以外の余分なテストを行うことになります。

現在2011年であるため、一般的に考えると65535まで必要はありません。

2100くらいまで使用できればいいのではないでしょうか。

詳細設計者はそのまま自分がコーディングを行うため、記載する必要ないと考えました。

年が１～2100年の場合処理を行う。

これは上記の2つ目の理由だとわかります。

＜サンプリングデータの抽出範囲＞

同値分割の観点で「範囲外」となる同一グループから5つも値をサンプリングしていることになります。

余分なテストをしています。

＜サンプリングデータの質＞

欠陥がある可能性の高い「境界」をテストすべきですが、1～2100の範囲の境界値である「0, 1, 2, 2099, 2100, 2101」のうち「2, 2099, 2100, 2101」は前出のサンプリング値に含まれていません。

本来の仕様でテストできないうえに、余分なテストが多いことになります。

詳細設計書は関数の仕様を決める仕様書です。

「コーディングの結果この値で判定することになった」ではなく「詳細設計書を見た結果この判定は正しい」と判断できる明確な記載が必要です。

そうすることで、的確なサンプリングができるようになります。

数字を指定するとテストケースが減る

引数の「許容範囲」が指定されていれば、それをもとにした境界値分析と同値分割を行えます。

コーディング者も許容範囲を使用して引数チェックを行えばよくなります。

引数yearは1～2100を使用する

「0, 1, 2, 1000, 2099, 2100, 2101, 3000」の8個になります。

許容範囲が明確になっていない場合と比べてサンプリング値は少なく、かつ意味のあるものになっています。

情報を追加してみると

上記の情報を追加してみると次の詳細設計になりました。

サンプル詳細設計書(関数仕様)　～情報追加後～
書式		unsigned char chk_date(unsigned short year, unsigned char month, unsigned char day)
仕様説明		引数に指定された年月日の範囲チェックを行い、正当かどうかをチェックする。
引数		unsigned short year [入力]
	意味	チェックしたい年
	許容範囲	1～2100
		unsigned char month [入力]
	意味	チェックしたい月
	許容範囲	1～12
		unsigned char day [入力]
	意味	チェックしたい日
	許容範囲	1～31
戻り値	正常	TRUE(1) ：年月日が正当
戻り値	異常	FALSE(0)：年月日が不当
備考		–

コーディング者としても引数チェックが明確になります。

今日の結論

単体テストでテスト項目を作成するために「詳細設計書」を考えると情報が足りないことがある
詳細設計書の関数設計では次の情報が必要
引数の許容範囲
単体テストが出来る情報があれば、コーディング者にとっても十分な情報がある

次回は同じサンプル詳細設計書で『呼び出し関数』について検討をしていきます。

品質コラム 第5回「「詳細設計書を見る人」にとっての「良い詳細設計」CASE1(引数)」