読者です 読者をやめる 読者になる 読者になる

mhlyc -presentation

ソフトウェアテスト、品質に関わること、たまに変なことを書いていくブログです。

ソフトウェアテスト技法ドリル 第3章 面で逃さない(1)

ソフトウェアテスト

アドベントカレンダー24日目 第3章 面で逃さない(1)

こんにちは。リリカルです。前回の続きでWACATEの予習です。

WACATE2016 夏 満員御礼!と 予習内容について - WACATEブログ

第3章 面で逃さない

第3章では、ソフトウェアの入力がロジックを網羅しているかテストする方法について述べられています。

まずはじめに紹介されているのが、ドメイン分析テストです。

ドメイン分析テスト

ドメイン分析テストとは、関係性のある複数の変数を同時にテストする方法です。

onポイント、offポイントなどの言葉が出てきますが、詳しくは拙作ではありますが私が作成したドメイン分析テストの解説スライドをご覧ください。一応、若干ですが勉強会当時のスライドに手を入れています。

p.14あたりから、ONポイント、OFFポイントの説明が始まっています。

www.slideshare.net

ONポイント、OFFポイントが境界値分析で出てくるわけですが、この変数が複数あったりするとこのドメイン分析テストの出番となります。

同時に複数の確認を行えないため、まず着目する変数に関してはONとOFFの値を変化させ、他の値は全部INにしておけば、一つの変数ごとに検証できるようになります。

あとはBinderさんのドメイン分析テストマトリクスという便利なものがありますから、そこに機械的に値を当てはめていけば良いことになります。ドメイン分析テストは境界値分析・同値分割の応用であり、特に数式で表される関係の複数の変数のテストをするときに使うことができます。

デシジョンテーブル

こちらもお馴染みの技法です。これは、主に論理式で結ばれた複数の条件をテストするのに使います。例えば以下のような感じです。

f:id:mhlyc:20160616013848j:plain

これは変数の値が2つしかないので、組み合わせの数も4つで済んでいるのですが、これが3つとか4つとかどんどん増えていくと全数はテストしきれなくなってきます。

そこで考えるのがデシジョンテーブルの圧縮です。

上の例で言えば、そもそも「カケホーダイライト」が適用されていなければ通話料が0円になることはありません。(という設定です。)ですので、本来ならば#3と#4のテストケースは両方実施する必要はなく、片方のみをテストすれば十分といえます。こう言ったように、期待結果が等しいテストケースをまとめて記述することで、デシジョンテーブルを圧縮していきます。ただしこれはあくまで処理順を考慮しなくても良い場合の話で、もし「条件1を見た後に条件2の判定を行う」という実装になっていた場合はこのような圧縮をすることはできなくなります。この処理順に関しては、しっかりと設計チームから情報を提供してもらう必要があります。

次回予告

次回は第3章、「面で逃さない」の続きです。

次回っていうか、WACATEまであと二日なのですがね…

でも最後までやろうと思います。