どんな単体テストをしますか？ - for文のホワイトボックステスト

今日は少し早めに帰宅した。

==

年月日を指定して、元旦までの日数を計算する関数の単体テスト設計です。

が、ホワイトボックステストが随分長引いている。だって。for文ってどうやって設計するんだろう。意外にわからない。わからないけど、for文のカウンタを固定してひとまず原因結果グラフを作ってみることにした。

作ったところで、頭が回らなくなってきた。36番、いらないなあ。10番→40番、12番→39番も、そのままだ。教派も寝る。また明日考えようっと。

どんな単体テストをしますか？その５

家から確認作業、夜は長いぞ。

==

どんな単体テストをしますか？その４の原因結果グラフを修正。

この分岐はいたってシンプルなので、こう眺めてみると原因結果グラフを明記しなくても、デシジョンテーブルに落とし込むことはできそだな。少し余裕が出たときにサンプルの関数全体をホワイトボックステストで設計するのと、グレーボックステストで設計するのをやるかな。グレーボックステストは今までのまとめっぽいけど。

==

例のMC/DCについて。まだ読み中。

引用：NASA/TM-2001210-876, A Practical Tutorial on Modified Condition/Decision Coverage

MC/DCというカバレッジ基準は図にあるように比較的高レベルなカバレッジ基準といえる。他の資料には、高信頼性を求めるシステム、リアルタイム性が求められる組込み系ソフトウェアなどで使われるらしく、この引用元も米国の航空・宇宙関連システムにおける資料のようだ。ただし、「ここの条件が独立して結果に影響を及ぼす」ことを示すためのカバレッジという点では、原因結果グラフでの網羅を意識した設計が、とても似ていると感じた。（n個のAND条件では、n+1回の条件、など）

もう少し読み込んでみようっと。

どんな単体テストをしますか？その４

「どんな単体テストをしますか？その３」の続き。

関連記事はこちら。コメント欄にも目を通すと理解が進むかも。

どんな単体テストをしますか？

どんな単体テストをしますか？その２

どんな単体テストをしますか？その３

ホワイトボックステストの視点で、daycount関数（年月日を指定して、元旦からの日数をカウントする関数）を単体テスト設計してみるのだが、テスト設計は「なるべく少ないコストで」という意識ですすめるほうがいい。ということで、今回は原因結果グラフから導いたデシジョンテーブルで、テストケースを洗い出してみる。全部やるのは後にして、まずは最初の、

この部分。この分岐に関して、原因結果グラフを作成すると、こんな感じ。

これをデシジョンテーブルに落とし込むのだが、まずは３つの中間ノードについてデシジョンテーブルを作成する。３つともEXC制約を考慮して、こんな感じ。

そして、全体のデシジョンテーブルはこんな感じで。

この３つのデシジョンテーブルを結合すると、テストケース数は７つ。

作ってみて、ブラックボックステストの視点でテストケースを洗い出したときも原因結果グラフを使っているので、似ている。違う点は、コーディングの構成を知っているので、「0」や「-1」などの特異値については考慮されない点だ。

さて、この調子で関数全体のテストケースを作る。が、それはまた今度。MC/DCについても今度調べて記事にするか。

どんな単体テストをしますか？その３

アバウトミーをはじめました。

==

さて、単体テストをブラックボックステスト、ホワイトボックステスト、などの視点で考えてみようとしているわけですが、前回の「ホワイトボックステストの視点」では「ステートメントカバレッジ」を基準にしたため、テストパターンが限られてしまった。

では、今回は「マルチコンディションカバレッジ」を基準にしてみようかな。

うーむ。。。いきなり6つも条件が。めんどくさい。2の6乗＝64通りってことになるけど。一番最初のブラックボックステストの観点でこの部分は10通りだったしな。これは、怠けてもいいのだろうか。

[本]ヒューマンエラーを防ぐ知恵

ソフトウェアテストというか、品質向上ということで、ヒューマンエラーについての本。

ここでは、ヒューマンエラーとは何か、とか、ヒューマンエラーは認知の間違い、判断の間違い、動作の間違い、といったカテゴライズをするのが目的ではない。正しい答えを見出したとしても、ヒューマンエラーによる事故、損害はなくならない。そういった科学的・学術的なことを覚えるよりもより具体的・身近な例をあげている。

当然ながら、ヒューマンエラーのより深い考察を元に対策をとる必要がある場合もある。ただ、昨今のヒューマンエラーというのは単純な要因だけで説明がつくものではない。チェルノブイリ原子力発電所の事故も、「原子炉運転員の教育が不十分であった」「特殊な運転を行ったために事態を予測できなかった」「低出力では不安定な炉で低出力運転を続けた」「実験が予定通りに行われなかったにも関わらず強行した」「実験の為に安全装置をバイパスした」といった複雑な要因が絡み合ったため発生したとも言われている。

途中、ヒューマンエラーの防止策の3つの方針が掲げられている。

作業を行いやすくする。ヒューマンエラーの発生頻度を抑制する

人に異常を気づかせる。損害が出る前に事故を回避できるようにする

被害を抑える。小さな事故が大きな事故に発展しないようにする

これって、実はソフトウェアテストでも応用できそうで、

欠陥を見つけやすくする

血管を事前に作りこませないようにする

テスト優先順位を考える

というように換言できるんじゃないかな。他にも「二人作業班策」って、これはペア・プログラミングそのもの。

リスク分析という観点では、「きっかけ演繹法（Event Tree Analysis, ETA）」「事故原因帰納法（Fault Tree Analysis, FTA）」というアプローチがごくごく自然にエンジニアは使っているような気もする。前者が「マウス操作を誤ったら、どんな事故が発生するか」というリスク分析で、後者は「交通事故はどういう原因で発生するのか」という逆方向の分析。

直接的にソフトウェアテストに活かせるわけでもないが、なかなか興味深い本ですね。

どんな単体テストをしますか？番外

番外。

どんな単体テストをしますか？にて、ひと月のパターンとして「1日」「15日」「晦日（28日、29日、30日、あるいは31日）」の3パターンを考慮したが、一般的には「15日」は不要なのだろうか？必要なのだろうか？もしかしたら、最頻出値をパターンとして選ぶのが妥当？

イマイチ基本的な技法を理解していないかも。。。

どんな単体テストをしますか？その２

新年度に入ってから、電車事故が多い気がする。

==

どんな単体テストをしますか？では、ブラックボックステストの観点でテストケース・テスト条件を洗い出してみた。

今度はホワイトボックステストの観点で考えてみよう。

元の記事はこちら（自動で単体テスト、ステートメントカバレッジ、そしてテストケースレビュー）なので、ご参考までに。

• ホワイトボックステストの観点

まずはコード。西暦、月、日を指定することで元旦からの日数を計算する関数。


30：int
31：daycount(
32：　　　　int year,
33：　　　　int month,
34：　　　　int day )
35：{
36：　　　　int　　　　 i = 0;
37：　　　　int　　　　 count = 0;
38：　　　　int　　　　 mday = 0;
39：
40：　　　　if( year < 1900 || year > 2100
41：　　　　|| month <= 0 || month >= 13
42：　　　　|| day <= 0 || day >= 32 ){
43：　　　　　　　　return(-1);
44：　　　　}
45：
46：　　　　count = 0;
47：　　　　for(i = 1; i < month + 1; i++){
48：　　　　　　　　switch(i){
49：　　　　　　　　case 4: case 6: case 9: case 11:
50：　　　　　　　　　　　　mday = 30; break;
51：　　　　　　　　case 1: case 3: case 5: case 7: case 8: case 10: case 12:
52：　　　　　　　　　　　　mday = 31; break;
53：　　　　　　　　case 2:
54：　　　　　　　　　　　　if( (year % 4 == 0) && (year % 100 != 0 || year % 400 == 0) ){
55：　　　　　　　　　　　　　　　　mday = 29;
56：　　　　　　　　　　　　}
57：　　　　　　　　　　　　else{
58：　　　　　　　　　　　　　　　　mday = 28;
59：　　　　　　　　　　　　}
60：　　　　　　　　　　　　break;
61：　　　　　　　　default:
62：　　　　　　　　　　　　return(-1);
63：　　　　　　　　}
64：
65：　　　　　　　　if( i == month ){
66：　　　　　　　　　　　　if( day > mday ){
67：　　　　　　　　　　　　　　　　return(-1);
68：　　　　　　　　　　　　}
69：　　　　　　　　　　　　else{
70：　　　　　　　　　　　　　　　　count += day;
71：　　　　　　　　　　　　}
72：　　　　　　　　}
73：　　　　　　　　else{
74：　　　　　　　　　　　　count += mday;
75：　　　　　　　　}
76：　　　　}
77：
78：　　　　return(count);
79： }

ホワイトボックステストではカバレッジを基準にすることが多い。ステートメントカバレッジ、ブランチカバレッジ、コンディションカバレッジなどなど。組織やプロジェクトチーム内でどのカバレッジレベルを採用するかが決まっている場合はそれに従うのもいい。でも、最低限ステートメントカバレッジは抑えたい。テスト（実施）カバレッジについてはここを参照。（俗称として、「C0」「C1」「C2」などと呼ばれることがある。）とりあえず、ステートメントカバレッジを基準にしてみるか。

まずは、最初の「引数チェック」の箇所。これはif文を分岐として2種類が考えられる。


次に月に関するfor文内の処理。ここで少し複雑だが、switch文やif文で複数のブランチが考えられるが、テスト設計者の主観によっては、全ての月の条件（1月～12月）と、うるう年条件（平年、うるう年、100年後との平年、400年後とのうるう年）も網羅すべきだと考える場合もある。


これらを組み合わせて、全ての命令文・手続きを実行するようなテストケース・テスト条件表を作成すると、こんな感じになるだろうか。


結構、テストケースが少ない。これだけじゃテストしたという自信はないな。ホワイトボックステストってもしかしたら、コード構成によっては威力を発揮できないこともあるのかしら？

どんな単体テストをしますか？

自動で単体テスト、ステートメントカバレッジ、そしてテストケースレビューで、適当な関数を作って、適当な単体テストの条件を作ってみた。この中で「指定日が元旦から何日目かを返答する関数（daycount）」についてもう少しきちんとテストしてみようかと。

==

• ブラックボックステストの観点

ブラックボックステストなので、基本的には「指定日が元旦からの日数」が正しく計算できるか、という仕様からテストケース・テスト条件を洗い出す。でもまずは関数インターフェースを眺めてみる。


int daycount( int year, int month, int day );


引数は、



1. year（西暦）


2. month（月）


3. day（日）



の3つ。西暦はここでは「1900年～2100年」という範囲に限定する、という（かくれ）仕様。月は「1月～12月」、日は「1日～31日」である。これは自明な仕様とでもいうのだろうか。ただし、不明確な仕様として「その月に存在しない日を指定した場合の動作」を確認しなくてはならない。ここでの仕様は「エラー」である。（9月の場合、31日を指定するとエラーとなる、など）

最近の僕の場合、ここで大分類として




1. 引数エラーケース


2. 内部エラーケース


3. 正常ケース



というように考えている。

引数エラーケースは、3引数の引数を原因結果グラフ・デシジョンテーブルで考えることが多い。

西暦のエラー値は、「-1」「0」「1899」「2101」あたりが妥当かな。int型の最小値、最大値は、別にいらないだろう。月のエラー値は、「-1」「0」「13」あたりかな。日のエラー値は「-1」「0」「32」としましょうか。

そして、3つともエラー値ではない場合は、さらに「内部エラーケース」「正常ケース」で考えてみる。

内部エラーケースは、月と日の不整合だろう。大の月（1月、3月、5月、7月、8月、10月、12月）は31日まであるので、引数エラーケース以外での不整合はなさそう。小の月（4月、6月、9月、11月）は30日なので、日が31日の場合に不整合が発生する。2月はややこしいが、西暦がうるう年ではない場合は、29日、30日、31日が不整合となるパターン。うるう年の場合は、30日、31日が不整合となるパターン。

正常ケースは、どうする？（1月、6月、12月）と（1日、15日、晦日）くらいでいいのかな。

まとめてみると、、、




あってるかなあ。

ホワイトボックステストの観点、グレーボックステストの観点は、また今度書きたい。忘れなかったら。

自動で単体テスト、ステートメントカバレッジ、そしてテストケースレビュー

C言語の単体テストの自動化はしてみたものの、テストケースレビューがしづらい。でも、テストプログラムにテストケース（テスト条件）を載せておけば、何かテストレビュー資料になる気がした。

文字化けはめんどくさいからそのまま。

一瞬テストケースレビュー資料になりうると思ったけど、まだまだ人間の読む資料じゃないかも。。。

サンプルソース（文字列の小文字化と、元旦からの日数カウント）

サンプルソースのテストプログラム

[セミナー]テスティングエンジニア体験会

この勉強室も春眠のため、ずいぶんと間が空いてしまった。。。

==

パソナテックさんの体験会という形のテスティングエンジニア向けの説明会。

テスティングエンジニア業務体験型説明会

ソフトウェアもハードウェアも「品質」が問われる時代、開発現場の多くで今、「テスト」の工程が見直され始めています。また、将来的なキャリアとしての価値も注目されはじめています。そこで今回パソナテックでは、システム開発工程や製品出荷前などでのテストと何が違うのか具体的にイメージして頂くために「テスティング業務体験会」を開催します。また、テストのスペシャリスト／エキスパートとして活躍できる機会を提供する場として、業務内容説明会と個別相談会を開催いたします。テスティングエンジニアとして成長できるチャンスです。是非ご参加ください。

タイトル テスティングエンジニア業務体験型説明会
主催 株式会社パソナテック
協力 株式会社OIテクノロジーズ
日時 2007年5月19日（土） 10:00～18:00
会場 パソナテック東京本社（渋谷）セミナールーム
対象 6月以降3ヶ月以内に派遣就業可能で、下記に該当する方
IT関連の何かしらの業務経験がある方（テスト業務未経験可）
ソフトウェアまたはハードウェアのテスト業務経験者
定員 30名（定員になり次第締め切り）
参加費用 無料

内容に興味あり。