blogJCUnitの開発日誌(ログ)です。"その時点での"JCUnit作者の理解や考え、開発状況を日本語で書きます。この広告は、90日以上更新していないブログに表示しています。パラメタ不正や禁則に違反する入力を組み合わせ試験に用いると、組み合わせ網羅率の低下につながる。」というのは、特にHAYST法関連の書籍や研究でよく見かける主張だ。ここでいう禁則処理とは、句読点や記号を行頭に置かないために行末にぶら下げる処理のことではない。ある機能への入力として禁じられた値や値の組み合わせのことだ。印刷機能だったら「プリンタ機種Aでは、両面印刷はサポートされていない」だとか計算機だったら「12ケタ以上の入力は許されていない」だとかだ。なんだか妙な話にも聞こえる。ソフトウェアの機能というものは、入力チェックも含んだものではないのか?間違った入力に対して「そんな入力はダメだ!」というのもそのソフトウェアの機能の一部ではないのか?だとしたら、HAYST法関連の書籍が言うとおりに、「許容されない」値やその組み合わせをテストから取り除いてしまったら、「入力チェックが正しく行われる」というソフトウェアの重要な特性が全くテストされないことになってしまう。組み合わせテストを行う際の暗黙の了解として、「正常な出力を期待するべき組み合わせが正しく動作することを確認するのが目的」と考えるべきだろう。正常な出力を期待するべき組み合わせ自体がおびただしい数にのぼる。正常な出力を確認できる様々な組み合わせを慎重に選ぶ。これがPairwiseやHAYST法のアプローチ。ところが、パラメタ異常は一個か二個のパラメタが不正な値を取ることで、本来テストしたい機能本体の論理が全く実行されなくなってしまう。そのテストケースは異常ではない(=テストしたい、そのために慎重に選ばれた)パラメタ値も含んでいる。した異常ではない、せっかくペア網羅率が上がるように選んだパラメタ値が無駄になってしまうのだ。して異常な一個か二個のパラメタのためにペア網羅率が低下してしまうのだ。正確に言うなら、ソフトウェア全体としてみれば、ペア網羅率は低下していない。「本来テストしたいソフトウェア機能本体」に着目するとそれはぐっと低下している。「禁則違反となるような値や値の組み合わせは可能な限り取り除いてから、組み合わせテストを生成・設計しましょう」というノウハウにたどり着くわけだ。これは「入力チェックが正しく行われる」「必要に応じてエラーを返す」という処理は別立てで考えるべきだということでもある。JCUnitではどうしようか?「禁則違反」を回避するような、テストケース集合を生成する方法を何かしら作る必要がある。単独のパラメタが禁則違反になる場合なら、そもそもドメインから取り除いておけばよい。2値の組み合わせが禁則を犯す場合には、その組み合わせは予め網羅済みとしておけば良さそうな気がする。(このへん、以前紹介したPairwise生成アルゴリズムの内部に関わるので詳細は省略)3値以上の組み合わせが禁則を犯す場合にはどうするべきか?レアケースとしてその場合は「已むを得ない」としてもいいような気がするが悩ましいところだ。08:55いわゆる禁則処理。jcun...2016-04-10(第四回)JCUnitで2次方程式を解くプログラムをテストする。本ブログでご案内しているように、javacのバグによりJ...2016-03-14(第三回)JCUnitで2次方程式を解くプログラムをテストする。2017でJCUnitの発表をすることになりました。joinedプログラミングはてなブログをはじめよう!dakusuiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。