ソフトウェアテストのいろは（実体験編） - あるある

午前と午後で公園を散歩。もう春ですなー。

==

ソフトウェアテストのいろはが「ノウハウ」編と「あるある」編になっていました。あるあるネタは、経験の違いや業界の違い、担当の違いなどによって感じ方が違うかもしれませんが、思わず「あるある」といいたくなるようなものが多いですね。「またか」はもうききたくなーい！

ソフトウェアテストのいろは

確定申告すませた。けっこう人が多かったなあ。

==

4月に入社する新テストエンジニアや、これからバリバリ勉強する初心者にむけたソフトウェアテストの「いろは」が、まとめられています。

ソフトウェアテストのいろはかるた by HAYST法

キーワードがわからなかったら、それについて調べていく、なんて勉強の進め方もできそうだ。僕がソフトウェアテストを勉強し始めたころだと、半分もキーワードがわからなかったな。8時間の集中力、自分にはあるのだろうか。。。

コードカバレッジのまとめ

単体テストレベルでは、「コードカバレッジ」を意識しながら（基準にしながら）テスト設計やテストケース作成を行う機会が多い。でも、この「コードカバレッジ」って用語がばらばらであったり、どのカバレッジ基準がどういうことを確認するものなのか、どういう不具合を見つけられるのか、見つけられないのか、といったことが自分の中でしっかりまとまっていなかったので、いろいろ調べてまとめようと思います。

2008/03/12更新
　　サンプルプログラムで解説を追加
　　サンプルプログラムは、以前例題として作成したテニスのスコアボードについて
　　[例題]テニスのスコアボード

ステートメントカバレッジ

命令網羅。テスト対象となるプログラム中のステートメント（命令文）をどれくらい実施したかどうかをあらわす基準。すべてのステートメントを最低1回実施した場合に、ステートメントカバレッジ100%という。もっとも基本的なカバレッジ基準であるが、もっとも強度の弱い基準といってもよい。プログラムをフローグラフ（処理ブロック、判定、合流の3種類で表現したグラフ）に変換した場合、すべてのノードを通過することと同値であるので、ノードカバレッジとも呼ばれる。

• 強みポイント

すべてのステートメントが到達可能だということがテスト実施によって証明される。つまり、実装したが到達不可能なコードを見つけることができる。「最低限」ではあるが、もっとも低コストで網羅が可能な基準といえる。
• 弱みポイント

テスト対象となるプログラム構造について検証するという目的では、あまり効果がない。分岐の妥当性（分岐条件が正しいかどうか、分岐がすべて網羅されているか等）について保証するためにはより強度の高い基準が必要となる。
• 100%カバレッジのテストケース例




1. リセットボタンを押す


2. 電源ボタンを押す


3. ゲームポイントではない状態で、ポイントボタンを押す


4. ゲームポイントだが、セットポイントではない状態で、ポイントボタンを押す


5. セットポイントだが、マッチポイントではない状態で、ポイントボタンを押す

ブランチカバレッジ

分岐網羅。テスト対象となるプログラム中のブランチ（分岐）をどれくらい実施したかどうかをあらわす基準。ブランチとはフローグラフでは、2方向以上のリンクを持つノードを意味し、すべてのブランチにおいて、すべての方向を最低1回実施した場合に、ブランチカバレッジ100%という。フローグラフに変換した場合、すべての判定ノードの決定結果をすべて通過することと同値であるので、デシジョンカバレッジとも呼ばれる。

• 強みポイント

自明であるが、ステートメントカバレッジよりも強度の強い基準である。また、実装された分岐ノードでの判定が正しいかどうかをテスト実施によって確認できる。つまり、分岐での条件間違いを検出することができる。
• 弱みポイント

テスト対象となるプログラムや実装言語によっては、分岐条件が論理和（OR）/論理積（AND）であったり、分岐ノードですべての条件について判定しない場合がある。フローチャートをフローグラフに変換することである意味、検出可能なバグが隠蔽されてしまう可能性がある。
• 100%カバレッジのテストケース例




1. リセットボタンを押す


2. 電源ボタンを押す


3. ゲームポイントではない状態で、ポイントボタンを押す


4. ゲームポイントだが、セットポイントではない状態で、ポイントボタンを押す


5. セットポイントだが、マッチポイントではない状態で、ポイントボタンを押す


6. マッチポイントの状態で、ポイントボタンを押す

コンディションカバレッジ

条件網羅。テスト対象となるプログラム中のブランチが論理和（OR）/論理積（AND）を含む場合、各々条件をどれくらい実施したかどうかをあらわす基準。フローグラフでは無視されてしまう各ブランチでの判定条件を分解して、すべての判定条件を最低1回実施した場合に、コンディションカバレッジ100%という。

• 強みポイント

自明であるが、ブランチカバレッジよりも強度の強い基準である。また、フローグラフでは省略されてしまう、各ブランチでの詳細条件にも着目してテスト設計されるため、ブランチカバレッジでは検出不可能な、より細かい条件間違いを検出することができる。たとえば、論理演算子の順序や記述ミスなどが検出できたり、エラー処理の分岐が足りないなどのバグも検出できる。
• 弱みポイント

各ブランチを構成する条件たち（因子たち）が非独立の場合に、単一の条件のみ（単因子のみ）に着目しているため、検出できない複合的なバグを見落とす可能性が残る。
• 100%カバレッジのテストケース例

今回のサンプルプログラムの場合、分岐B、分岐Cの条件が非常に複雑である。


P1：　第1セット～第4セットである（＝最終セットではない）

P2：　第1ゲーム～第12ゲームである

P3：　今回のポイントが4ポイント目以上である

P4：　今回のポイントが7ポイント目以上である

P5：　今回のポイントで2ポイント差

P6：　今回のゲーム勝利で6ゲーム目以上である

P7：　今回のゲーム勝利で2ゲーム差

P8：　今回のセット勝利で3セット目

分岐Bが真　⇔　P1 && (P2 && P3 && P5 || !P2 && P4 && P5) || !P1 && P3 && P5　が真

分岐Cが真　⇔　P1 && (P2 && P6 || !P2) || !P1 && P6 && P7

分岐Dが真　⇔　P8


すべての単独条件の真偽を網羅するためには、、、（作成中）

マルチコンディションカバレッジ

複数条件網羅。テスト対象となるプログラム中について、各ブランチの各々条件の組み合わせをどのくらい実施したかどうかをあらわす基準。すべての判定条件の組み合わせを最低1回実施した場合に、マルチコンディションカバレッジ100%という。

• 強みポイント

自明であるが、コンディションカバレッジよりも強度の強い基準である。また、各ブランチについていえば、すべての可能な条件を網羅しているため、コンディションカバレッジ基準で検出できなかったバグを検出する可能性がある。
• 弱みポイント

ステートメントカバレッジ、ブランチカバレッジ、コンディションカバレッジに比べて、テストケースが掛け算・指数関数的に膨大化しやすく、現実的ではない場合がある。コンディションカバレッジ基準では検出不可能なバグが見つかる可能性もあるが、本来はテスト対象の見直し・リファクタリングも考慮すべきである。
• 100%カバレッジのテストケース例

作成中

MC/DC

変更条件・分岐網羅、あるいは、モディファイドコンディション/デシジョンカバレッジ。テスト対象となるプログラム中において、各ブランチの各々条件が、分岐方向（結果）に影響を与えるような判定条件（原因）をどのくらい実施したかどうかをあらわす基準。すべての分岐方向を通過するような判定条件の組み合わせを最低1回実施した場合に、MC/DC100%という。また、原因結果グラフやデシジョンテーブルなどを利用したテスト設計は、このカバレッジ基準と同等といえる。

• 強みポイント

自明であるが、コンディションカバレッジよりも強度の高い基準である。また、マルチコンディションカバレッジよりも強度でいえば下回るが、より効率的にコードをカバーしているため、遜色のないバグ検出が可能である。
• 弱みポイント

他のカバレッジ基準に比べて、考え方が難しい点、解説資料が少ない点などがある。また、実装自体のリファクタリング、単純な実装などであれば、テスト設計のコストに見合った効果が期待できない場合がある。
• 100%カバレッジのテストケース例

作成中

パスカバレッジ

経路網羅。テスト対象となるプログラム中の考えうるすべての経路をどのくらい実施したかどうかをあらわす基準。すべての経路を最低1回実施した場合に、パスカバレッジ100%という。ただし、現実的には達成不可能の場合が多い。

• 強みポイント

理論上はすべての構造的なバグを検出可能である。
• 弱みポイント

現実的ではない場合が多い。パスカバレッジを達成するために、更なるコンポーネントの細分化が求められる。
• 100%カバレッジのテストケース例

現実的なテストケース数には落とし込めないので割愛。

参考：
Code Coverage Anaysis
Testing and Code Coverage
Part2 ホワイトボックス技法：ITpro
ソフトウェアテストの分類
A Practical Tutorial on Modified Condition/Decision Coverage(PDF)

カバレッジ100%だからといって、well-testedではない

TotT: Understanding Your Coverage Data by Google Testing Blog

So the correct way to do coverage analysis is:

Step1. Make your tests as comprehensive as you can, without coverage in mind. This means writing as many test case as are necessary, not just the minimum set of test cases to achieve maximum coverage.

Step2. Check coverage results from your tests. Find code that's missed in your testing. Also look for unexpected coverage patterns, which usually indicate bugs.

Step3. Add additional test cases to address the missed cases you found in step 2.

Step4. Repeat step 2-3 until it's no longer cost effective. If it is too difficult to test some of the corner cases, you may want to consider refactoring to improve testability.

「僕のソースはコードカバレッジが高いから、十分テストしてるのさ」というのはマチガイ。という話。ここではステートメントカバレッジを例に挙げて、たとえテストが100%カバレッジをしていても、見つけられない欠陥があるということを示している。

で、コードカバレッジ解析の正しい手順はこんな感じ。

1. 可能な限り広範囲にテストケースを作成する

ここでは最小のテストサブセットで最大のカバレッジ（数学的にはcompactか）させようとは思わずに。
2. 自分のテストカバレッジ結果をチェックする

そうすると自分のテストケースから漏れていた、想定外のパターンが見えてくる。
3. 2を元にテストケースを追記する
4. 2～3を効果がでなくなるまで繰り返していく

テスト容易性（testability）に着目してリファクタリングするもよし。

ある技法によってテストケースを作成し、もれてしまったパターンや重要なパターンなどは追記していく。これ常套手段ですな。HAYST法でもやるやる。

テストのさしすせそ

トラブル対応で1週間があっという間に過ぎてしまった。

==

どこかのサイトでソフトウェアテストのあいうえお作文が載ってた記憶が。自分なりに、効率的・効果的なソフトウェアテストのあいうえお作文。サ行で。

サ：サボれ！

シ：自動化すればいいんだっけ？

ス：水準値は肝

セ：センスも必要

ソ：「ソフトウェアテスト」でググれ！

完全テストは無理なので、緩急のつけ方が重要。サボれるところはサボれ。自動化という呪文にだまされるな。メンテナンスは自動じゃないぞ。水準値の取り方で効率と効果がぜんぜん違う。無駄にテストしても品質は上がらないよ。プログラミングと同じでテストもセンスが必要。今はソフトウェアテストのサイトも書籍も充実してる、まずはインターネットを活用して勉強するべし。

なんてね。

2008/03/06追記
テストのはひふへほ
このコラムにインスパイヤされて。