境界値テストを行う場合には有効桁数に注意する

境界値テストについては、以前の記事にてデシジョンテーブルと共に紹介しました。
しかし、以前の記事では紹介しきれていないことがあるので、別に記事を書いて紹介しようと思います。


表題の通りなのですが、有効桁数については、コーディング時にも気を付ける必要がありますし、境界値テストを行う際にも気を付ける必要があります。
有効桁数を見誤ると、境界値付近の値が与えられた場合に意図せぬ挙動を示すことがあります。

例えば、株価に応じて処理を変える必要がある場面において、以下のような条件指定をしたとします。

そして、1つ目のif文と2つ目のif文の境界値を見るために、株価が99円・100円・101円・102円のテストケースを用意したとします。

これは一見正しそうに見えるのですが、有効桁数が見落とされており、バグを引き起こすコーディングであり、バグを発見できないテストケースです。
実は株価は1円単位とは限らず、0.1円単位のこともあります。
もし、ここで100.1円という株価が与えられた場合、1つ目のif文も2つ目のif文もすり抜けてしまい、意図せぬ分岐に進んでしまいます。
そして、テストケースでは100円より大きく101円より小さい値が設定されていないので、このバグを見つけ出すことができません。

正しくは、以下のようにコーディングするべきです。

そして、1つ目のif文と2つ目のif文の境界値を見るテストケースとしては、最小桁数での境界を見ることができるように、株価が99.9円・100.0円・100.1円のテストケースを用意するべきです。


いかがでしたでしょうか。

今回紹介した例は、私が本当に目にしたことがあるバグです。
金融案件のように数字を扱う案件では発生しがちなバグだと思うので、有効桁数に気を付ける必要があるということを心に留めておきましょう。

ゴンペルツ曲線(信頼度成長曲線)とは

ゴンペルツ曲線(信頼度成長曲線)とは、テストで発見されるバグ数をグラフにしたものです。
横軸に時間、縦軸に累積バグ数をとる場合、下記のようなグラフになります。

テストを開始した直後は、テスト手順が確立していないため、バグはなかなか見つかりません。
テスト手順が確立した後は、時間が経つにつれて順調にバグが見つかります。
テストが終盤に近づくと、残っているテストケースはテスト困難なレアケースになるので、再びバグを見つけにくくなります。

具体的にいくつのバグが出るかは、プロジェクトの特性によって変化します。
現場毎に、プロジェクトの規模と発見されるバグ数の統計を取り、その統計を元にいくつのバグが出るのかを具体的な数値に落とし込みます。

もし、バグが大量に見つかる(aのケース)ようであれば、テスト開始時点の品質が悪い疑いがあります。
この場合、品質管理者は、バグの原因を確認し、前工程で見つけるべきバグが大量に見つかっていないかどうかを見る必要があります。
前工程で見つけるべきバグが大量に発見された場合は、バグの対応でテストの進捗が悪くなることを防ぐために、もう一度前工程に戻って品質強化を行う必要があります。

また、発見されるバグが少ない(bのケース)ようであれば、テストケースの作り込みが甘い疑いがあります。
この場合、品質管理者は、テストに使われているテストケースを確認し、テストの目的に照らし合わせてテストケースの網羅性が十分かを見る必要があります。
テストケースの網羅性が不十分な場合は、現在のテスト工程で見つけるべきバグが見つからないことにより次工程やリリース後に悪影響を及ぼすのを防ぐため、テストケースの修正を指示する必要があります。

品質管理者には成果物の一つ一つを細かく見る程の時間はないため、上記のような数値管理を行い、プロジェクトの状況を把握しようとします。
(人間の体に例えると、健康診断で数値を出し、疑わしい数値が出た場合に医師が検査を行う、という例えになります)
そのため、作業者としては、正直に数値を出すことで、品質管理者が適切に管理を行えるようにする必要があります。


あけましておめでとうございます!

昨年、何のためにバグ数を報告する必要があるのかと問われたので、今回の記事を執筆しました。
作業者目線では報告はうんざりするかもしれませんが、プロジェクトを円滑に進めるためだということを知っていれば、頑張って報告する気になれると思います。

実は昨年は適当に報告してしまっていた…という方、新年は是非報告も頑張ってみましょう!

現新比較の方法

情報処理技術者試験では出題されないのですが、IT技術者として当然知っておくべきテスト手法として「現新比較」というものがあります。
これは、システムを改修した際に思わぬ箇所に影響が出ていないことを確認する(無影響確認)ための手法であり、改修前の出力と改修後の出力を比較し、改修の影響を受けるべき箇所以外は差異がないことを確認する、というものです。

この手法は単体テストからリリース後の確認まで工程を問わず使用される手法です。
例えば、プログラムを製造する場面で、「販売情報管理システムの取引ファイル出力プログラムについて、ポイント払いのレコード(ポイント払いされた場合)にポイントの有効期限を更新するように改修する。それ以外の箇所は変更しない。」という改修を行った場合、単体テストでは「ポイント払いのレコードはポイントの有効期限以外は現新で差異が無いこと」「ポイント払い以外のレコードは現新で差異が無いこと」を検証するべきです。

直すべきところだけ直したつもりなのに、知らず知らずの内に他の箇所にも影響していたというのは意外とよくあります。
現新比較を行わないと、本来見つかるはずのバグが見つからず、後でバグが見つかることになってしまいます。
システム開発に慣れ始めた頃が危ないです。「この改修で他に影響するわけないだろう」と思わず、現新比較はしっかり行うようにして下さい。

現新比較の具体的な方法としては、以下のようなものがあります。

1.ファイル・テーブル・電文のレコード等、出力が文字列の場合

・WindowsのfcコマンドやLinuxのdiffコマンド

完全一致する場合等、ごく簡単な場合に。

・WinMerge等の差異比較用のソフトウェア

1レコードの内の一部が異なっている場合がある等、少し複雑な場合に。

・Excelやjava等で作成した独自ツール

複雑なデータ加工が必要な場合に。
改行コード付与や一部項目除外等で済むなら、Linuxのfoldコマンドやcutコマンド等を組み合わせるだけでも十分です。

2.Windowsで生成した帳票・ハガキ等、出力がPDFファイルの場合

・2つのPDFファイルを開き、画面を切り替えて目視

アナログですが、簡単な比較なら結局これが一番早いです。

・AdobeAcrobatやDiffPDF等のPDF比較用のソフトウェア

大量のPDFファイルを機械的に比較する必要があるなら必要です。

3.Web画面のキャプチャ等、出力が画像の場合

・2つの画像を異なるファイルの同じ個所に張り付け、画面を切り替えて目視

アナログですが、簡単な比較なら結局これが一番早いです。

・ImageMagick等の画像比較用のソフトウェア

ソフトウェアを導入することで、流行りの自動化も可能になります。

4.プリンターで出力した帳票やハガキ等、出力が紙媒体の場合

・出力された紙を重ねて透かして目視

アナログですが、これしか手段がない気がします。


いかがでしたでしょうか。

現新比較について研修という形で座学で教わることは少ないと思いますが、実務では重要になります。
まだ実務で現新比較をあまり行ったことがないのであれば、こういったことを実務では行っているということを知っておいた方がスムーズに仕事に取り掛かれると思います。

次回からも役に立つ情報を提供していきたいと思います!

デシジョンテーブルを使用したテストケース設定

条件分岐が複雑な場合、テストケースの設定に漏れが発生して、テストでバグを洗い出しきれなくなることがあります。
そのような場合は、デシジョンテーブルを書いてテストケースを明示的に洗い出すのが有効になります。

デシジョンテーブルの書き方について、例を挙げて説明していきます。
今回も、在庫管理システムの在庫発注処理の例を使用します。
発注するべき条件(在庫切れ、若しくは人気上昇)を満たしている時に、発注関数を呼び出し、発注量や発注日等を計算するという仕様を想定します。
また、最後の発注日から3日以上経過しないと新たに発注できない、という仕様を想定します。
フローチャートは以下の通りです。

この例の場合、以下のようにデシジョンテーブルを書くと、これらの条件からテストケースを洗い出すことができます。
「入力」欄に条件の組み合わせを、「出力」欄に各々の条件の組み合わせの結果を書きます。

発注経過日のように境界値分析が必要になる箇所は、「境界値以下(代表値2)」「境界値と同じ(3)」「境界値を超える(代表値4)」の3パターンを洗い出した方が良いです。
分岐を網羅するだけであれば「境界値以下」「境界値と同じ」の2パターンのみで十分なのですが、コーディングの誤り(IF文の「≧」を「=」としてしまう誤り)で境界値と同じ場合のみ条件が真になるという実装になってしまっていることがあるため、上記3パターンでテストを行うのが無難です。
(本当にこのような誤りを見たことがあります)

また、今回は12パターンのテストケースを洗い出していますが、テストケースが多すぎてテストする時間が取れない場合は、デシジョンテーブルを見ながら不要なテストパターンを抽出するのが有効となります。
今回の例で言うと、発注経過日が3日未満の場合については、在庫切れフラグや人気上昇フラグが発注有無に関与しないことを確認できれば良いので、テストケース2やテストケース3は削っても問題ないでしょう。発注経過日が3日を超える場合についても、前述のようなコーディング誤りがないことを確認できれば良いので、テストケース10やテストケース11は削っても問題ないと思います。

ホワイトボックステストのテストケース設定

ホワイトボックステストのテストケース設定の方法は、単体テストのテストケースを考えることになった新人に良く教えています。
十分に網羅性のあるテストケースを作らないと、後の工程にバグを残し、プロジェクトの進捗に影響を及ぼすことにもなりかねません。
(単体テストで見つけるべきバグが結合テストで頻発してしまい、結合テストの項目を消化できない、ということはプロジェクトはよくあることです)

今回は、普段新人に教えていることを記事化します。

ホワイトボックステストのテストケースの設定方法としては、以下のものがあります。

命令網羅全ての命令を1回以上実行
判定条件網羅(分岐網羅)全ての経路を1回以上通過
条件網羅判定条件中の全ての条件について真/偽それぞれ実行
判定条件/条件網羅判定条件網羅+条件網羅
複数条件網羅判定条件中の条件の全ての組み合わせを網羅

以下は、在庫管理システムの在庫発注処理の例です。
発注するべき条件(在庫切れ、若しくは人気上昇)を満たしている時に、発注関数を呼び出し、発注量や発注日等を計算するという仕様を想定します。

適切なテストケースを設定するためには、単に処理を通ったかどうかだけでなく、業務仕様通りの出力がされているかを確認できるテストケースを設定する必要があります。
大規模なシステムではカバレージツールをテストケースの網羅性を客観的に判断するために使用すると思うのですが、大抵のカバレージツールでは、C0カバレージ(命令網羅)とC1カバレージ(判定条件網羅)しか計測できません。
上記の例で言うと、「人気上昇した時に正常に発注量や発注日等を計算できるか」という観点でテストできませんし、関数の中の計算式によっては「在庫切れと人気上昇が同時発生した時にも正常に計算できるか」という観点でのテストも必要になるかもしれません。
このように、例えカバレージが100%だとしてもそれだけでは十分なテストを行えていると言うことはできず、業務仕様を確認できるかどうかという視点で条件網羅や複数条件網羅のテストケースが必要になることもあります。