普段の業務では
要件定義段階：ユースケース記述とユースケース図作成
分析・設計段階：詳細外部仕様書兼テスト仕様書としてのテストケースと設計モデルとしての
各種UMLダイアグラム(クラス図、シーケンス図、アクティビティ図、
ステートマシン図など)を作成
といった流れを取っています。
この時に課題となっているのがテスト対象モジュールに対するテストケースが持つべき
条件網羅性を如何に高めるか？ということです。せっかくアクティビティ図やステート
マシン図を描いて処理の分岐などを明確にしておいても、それとは別の流れでユースケ
ースからテストケースを導出する方法だと、どうしても抜けがでてきてしまいます。
リスト記法を用いて例外シナリオを明記したり、マトリックス記法を用いて期待される
IN/OUTの組を境界値も含めて洗い出したりと工夫はしていますが、どうしてもテストの
パスから漏れる処理が出てきてしまいます。
そこで、こんなことができたらいいなぁというのを考えてみました。
1. テストケースにはIN/OUTの組と共に、各テストシナリオをどの設計モデル
において実施するかのポインタを記載しておく
2. テストケースを元にして(必要に応じて設計モデルと比較して、各IN/OUTの組
が設計モデル上のどのロジック分岐を通過するかを確認しつつ)全ての分岐が
網羅できるようにIN/OUTの組を適宜追加・修正する
3. 各設計モデルからコードスケルトンを生成する際に各アクティビティの処理
を通過したことを示すログ出力処理を自動挿入できるようにしておく
4. 3.のログ出力で起り得る全てのログ出力シーケンスを設計モデルを元にして
洗い出して保存しておく
(これは机上になってしまいますが、「実行可能なモデル」が一般的になれば、
近い将来には自動生成も可能なはずです。現時点でも製品によってはある程度
できますね)
5. テスト実施の際には2.で作成したIN/OUTの組を順次適用して期待された値が
得られることを確認すると共に、生成されるログ出力シーケンスを確認する。
全てのIN/OUTの組でのテストを終わった段階で4.にて洗い出したログ出力シ
ーケンスが全て登場していれば漏れはないが、出てきていないログ出力シー
ケンスがあれば、作成したIN/OUTの組では全てのロジック分岐が網羅できて
いないことになる。その場合には2.に戻って不足しているIN/OUTの組を追加
して再度3.以降を実施する。逆に4.で洗い出したログ出力シーケンスに存在
しないものを再現するIN/OUTの組が存在した場合には4.での洗い出しに漏れ
があることになるので、4.に戻って以降を再度実施する。
ツールによっては既にこうしたことを実現できているものもあるかと思いますが
高価なツールを気楽に使える身分でもないので(笑)このようなことを実現できる
仕組みを何とか作れないかなぁとか思っています。2.と4.のそれぞれの段階で人
手によるミスや見落としの可能性がありますが、2.と4.を別々の開発者に担当さ
せることで従来よりは抜けを少なく抑えられるのではないかと考えています。2.
はブラックボックス的アプローチ、4.はホワイトボックス的アプローチと言える
かと思います。この両社をうまく組み合わせることで条件網羅性を上げようとい
う試みだといえるかと思います。白と黒を交互に織り交ぜて用いるということで
「ゼブラボックスアプローチ」とでも呼びましょうか(^_^)
