アドベントカレンダー２４日目 第３章 面で逃さない（１）
こんにちは。リリカルです。前回の続きでWACATEの予習です。
WACATE2016 夏 満員御礼！と 予習内容について - WACATEブログ
第３章 面で逃さない
第３章では、ソフトウェアの入力がロジックを網羅しているかテストする方法について述べられています。
まずはじめに紹介されているのが、ドメイン分析テストです。
ドメイン分析テスト
ドメイン分析テストとは、関係性のある複数の変数を同時にテストする方法です。
onポイント、offポイントなどの言葉が出てきますが、詳しくは拙作ではありますが私が作成したドメイン分析テストの解説スライドをご覧ください。一応、若干ですが勉強会当時のスライドに手を入れています。
p.14あたりから、ONポイント、OFFポイントの説明が始まっています。
ONポイント、OFFポイントが境界値分析で出てくるわけですが、この変数が複数あったりするとこのドメイン分析テストの出番となります。
同時に複数の確認を行えないため、まず着目する変数に関してはONとOFFの値を変化させ、他の値は全部INにしておけば、一つの変数ごとに検証できるようになります。
あとはBinderさんのドメイン分析テストマトリクスという便利なものがありますから、そこに機械的に値を当てはめていけば良いことになります。ドメイン分析テストは境界値分析・同値分割の応用であり、特に数式で表される関係の複数の変数のテストをするときに使うことができます。
デシジョンテーブル
こちらもお馴染みの技法です。これは、主に論理式で結ばれた複数の条件をテストするのに使います。例えば以下のような感じです。
これは変数の値が２つしかないので、組み合わせの数も４つで済んでいるのですが、これが３つとか４つとかどんどん増えていくと全数はテストしきれなくなってきます。
そこで考えるのがデシジョンテーブルの圧縮です。
上の例で言えば、そもそも「カケホーダイライト」が適用されていなければ通話料が0円になることはありません。（という設定です。）ですので、本来ならば#3と#4のテストケースは両方実施する必要はなく、片方のみをテストすれば十分といえます。こう言ったように、期待結果が等しいテストケースをまとめて記述することで、デシジョンテーブルを圧縮していきます。ただしこれはあくまで処理順を考慮しなくても良い場合の話で、もし「条件１を見た後に条件２の判定を行う」という実装になっていた場合はこのような圧縮をすることはできなくなります。この処理順に関しては、しっかりと設計チームから情報を提供してもらう必要があります。
次回予告
次回は第３章、「面で逃さない」の続きです。
次回っていうか、WACATEまであと二日なのですがね…
でも最後までやろうと思います。
