第231回: 「ソフトウェアテストしようぜ」44 CEGTest(14.制約MASK前編)
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「制約REQ」がテーマでした。
制約REQは、「順序を指定する」制約でした。
制約REQを「Require」や「ならば」から理解して使おうとすると行き詰ります。(経験談)
上に書いたとおり、先にこちらの条件が整っている必要がある、すなわち、「事前条件を指定する」ときに使うことをお勧めします。
さて、今回は、5つの制約である、「ONE」、「EXCL」、「INCL」、「REQ」、「MASK」のうちのラスボスである「MASK」の前編について書きます。(覚えることが多いので分けることにしました)
制約MASKは、「マスク先のノードを無いものとする」制約です。
≡ 制約MASKとは
これまでと同様に、まずはドリル本に載せたものを示します。
例として以下のダイアログが載っています。
上図は、スケジュールの日時設定画面と考えてください。タイトルに「高尾山ハイキング」とあり、日時は、2010年8月3日10時から同日の17時となっています。
つまり、【終日】ハイキングということです。
であれば、ということで、[終日]のチェックボックスをチェックしてみます。ダイアログは、こんなふうに変わりました。
ところで、「高尾山」とは東京にある低い山のことです。休日の朝になって、「天気がいいから、ちょっとハイキングでもするかー」と急に思いついたときにちょうど良い場所です。登山靴などは要りませんが、水筒はあった方が良いかもしれないという程度の山歩きです。
とはいえ、ブラタモリの高尾山回をチェックしてから行くと大人でも楽しめますし、帰りに温泉に入ったり、レストランで美味しいものを食べたり、丸一日楽しめます。“高尾山トリックアート美術館”はお勧めしません。
元気が余っている方は、気持ちの良いハイキングコースが続くので、「陣馬山(じんばさん)855m」まで足をのばすのもお勧めです。
閑話休題。ふたつのダイアログを並べて再掲します。
二つのダイアログを見比べると、[終日]をチェックしたことで、「10:00」と「17:00」の入力エリアが消えていることがわかります。
このように「ある条件をT(True: 真)にすると、別の条件が無くなってしまうこと」を表すのが制約MASKです。
「無くなった」わけではなく、「隠れた」だけですので、例えば、「10:00を入力後、[終日]のチェックを入れてから外した時に10:00が、残っているかどうかのテスト」が必要です。この場合の期待結果は一般には残っていて欲しいですが、別の人が続けて使うようなアプリケーションのときには消えるほうがよいです。
ここで、やっかいなことに、「MASK先の条件が無くなる」ということと、「MASK先の条件が0(F: False=偽)となる」の違いは微妙です。
マイヤーズが誤ったのもしかたないかなーと思いますが、結果が大きく異なりますので、きちんと、「無くなる」と覚えましょう。
それでは、上記ダイアログの[終日]チェックの原因結果グラフとベン図とベン図に対応した表をドリル本から引用します。
、、、としよう思ったら、ドリル本(青も赤も)に書いてありませんでした!!
ひどいやつ(著者=自分)だ。お詫びして、ここに書くことにします。
すみませんでした。
なんか、ちょっと思い出してきたのだけれど、12年前の青ドリルを書いていた時に、この原因結果グラフとベン図と真理値表を載せてもなーって思ったような気がします。
次回までに原因結果グラフとデシジョンテーブルを見比べて、「M」とか「I」ってなんだろう?と考えると理解できると思います。
よって、詳しい解説は次回にします。
≡ おわりに
今回は、「制約MASK」がどのようなものかについての概要でした。
「制約MASK」には方向があり、結果aから結果bに向けた線が引かれていたら「結果aがTになると結果bは無くなる」です。
次回も、「MASK」の続きを書く予定です。MASKされた結果無くなった条件について、デシジョンテーブルはどうなるのか、など、核心に迫っていきます。
前回の終わりに書いたとおり、「MASK」は、知っているだけでよい(使わなくてよい)のですが知っておくべきことは多いのです。