テスト項目の挙げ方について、C0,C1について書いた
「テストでのC0、C1、C2に対応した仕様書の書き方」って、学校で教えないよね
https://blog.goo.ne.jp/xmldtp/e/55d32a4a623e92481567a9b477521556
けど、C2はまだだったので、今回書く。これで完結。
まずははじめC2のアカデミック的な話をして、そのあと学校ではやらない「実施不可」の話。
■C2とは
前の話。
C0は、命令網羅で、命令に着目して項目を挙げた
C1は、分岐網羅で、分岐(if,switch)に着目して項目を挙げた
C2は？というと、これら１個１個の対象物（＝命令、分岐）に着目するのではなく、
その組み合わせに着目する。
組み合わせが問題になるのは、C0,C1のテストケース作成（いっぺんにやるから）でも問題になる
ので、
テスト項目とテストケース
https://blog.goo.ne.jp/xmldtp/e/d240a48fd8f3e0584e848c11f0c85a98
を書いた（ので、テストケースについては、そちら参照。そのエントリの「テストケースは、どう作るの？」
の話が今回の話。つまり、テストケースを作る組み合わせの話）けど、
それより主に結合テストで問題。結合テストの場合、
入力画面
サーバーサービス
出力画面
のような組み合わせになる。このとき、入力画面項目だけをみても複数あり、さらに、場合によって動く
サービスも複数あり、順番もあり・・・となってくると、組み合わせが問題になる。
■問題
例えば今、
Aという項目が３種類の値の取り方（同値グループ）｛あ、い、う｝
Bとうう項目が２種類の値の取り方（同値グループ）｛１、２｝
だったとする。
この組み合わせを考える。
ここでC0,C1 １００％を考えると（上記エントリのC0、C1のテストケースなど）、
あ、い、う、１、２すべてを通ればよい
なので、
｛あ、１｝、｛い、２｝、｛う、１｝
の３通りやれば１００％になる（一般に、同値グループ要素数の最大数（Aが３、Bが２→最大はAの３）
行えば、うまく組合せればC0,C1の１００％は作れる。
だけど、上記のやりかたでは、組み合わせを尽くしていない。たとえば上記の例だと
｛あ、２｝
を行っていない。なので、C2 １００％にならない。C2の場合は、組み合わせすべてを
行うことになる。
｛あ、１｝、｛あ、２｝、｛い、１｝、｛い、２｝、｛う、１｝、｛う、２｝
の６通り（３X２）。
■組み合わせ爆発と直交表、ペアワイズ法
今のは、簡単な例だったので、問題ないけど、実際には、項目が５つ、６つ・・・で、
とりうる値も、３つ４つ・・・といろいろなので、全部のケース数を行っていたら、
ものすごい組み合わせ量になる。
入力から出力の組み合わせすべてを行ったら・・・テストが終わらなくなる。
そこで、
最低限２つの組み合わせだけは行う、ペアワイズ法や、
２つの組み合わせは完璧、３つもできるだけの直交表
をつかって、組み合わせケースを出してテストする。
・・・ということまでは、学校で習うし、アカデミックでも行う。
■実施不能のケース
実務上ではこれに加え、実施不可というケースがある。
上記例だと、
あを選んだ人は１と２を選べるが、
いを選んだ人は２だけ
うを選んだ人は１だけ
しか選べないとする。
この場合、入力画面は、そのようにプロテクトしてしまうので、いの１は、入力すらできない。
しかし、サービス側では、将来的に入力画面以外の入力も受け付けるかもしれないので、
プログラム上は、いの１のケースは、エラーとして処理するようにコーディングされているのが普通。
（いの１は来ないからといって、そのまま流してしまう作りには、ふつうしていない）
この場合は、上記いの１のように入力できないものは「実施不可」として、
サーバー側のテストはしないでOKとすることがある。
問題は、この「実施不可」をどこまでとるか？ということ。
今、その可能性がないからといって、行わない場合、
将来、その可能性が出てきて行った場合、問題が発覚してしまうかもしれない。
たとえば、データベースにあるデータは存在しえない（本社が２つ同時にあることはない等）
となっていたのが、ビジネスが変わって存在してしまった場合（本社が２つになった）
・・・そこまでテストしたらキリないよね！と考えれば実施不可になる。
だから実施不可は、組み合わせ列挙とちがって、ケースバイケースの「ときもある」
■実施不可：単体テストでは起こらないわけ、単体テストでも起こるわけ
単体テストの場合、デバッガでどこへでも？行けるので、実際にはとりえない値でも、
テキトーにデバッガで値を設定して、そのモジュールを実行してしまう。
なので、「実施不可にはならない」
が、どうしても作れないテストデータのケースまで、デバッガで無理やり実施するのか？
という問いに「やんなくてよくね？」「そだね～」ということになれば、
「実施不可となる」。
ここで、問題になるのが、
「開発当初、まず起こりえないと思うケースに対して、単体テストをやっていなかったからといって、
そのケースが起こってしまい、それで問題が発覚したとき、単体テストをやっていなかったことを
責められるか？」
ということ。論理上ではやるべきだけど、起こりえないケースをやることが、経済的に理にかなっているのか？
この問題は、「みずほ証券事件」で争われた論点だけど、
裁判所は「後講釈になってはいけない」（事故が起こってから、「やるべきだったでしょ」と責めては
いけない。当時の状況を起案が得なければ）として、組み合わせチェックをしてれば、いいんでないかい
ぐらいの判断になっていると思った。。。けど違ったかな？（必要な人は自己責任で調べてください）
「テストでのC0、C1、C2に対応した仕様書の書き方」って、学校で教えないよね
https://blog.goo.ne.jp/xmldtp/e/55d32a4a623e92481567a9b477521556
けど、C2はまだだったので、今回書く。これで完結。
まずははじめC2のアカデミック的な話をして、そのあと学校ではやらない「実施不可」の話。
■C2とは
前の話。
C0は、命令網羅で、命令に着目して項目を挙げた
C1は、分岐網羅で、分岐(if,switch)に着目して項目を挙げた
C2は？というと、これら１個１個の対象物（＝命令、分岐）に着目するのではなく、
その組み合わせに着目する。
組み合わせが問題になるのは、C0,C1のテストケース作成（いっぺんにやるから）でも問題になる
ので、
テスト項目とテストケース
https://blog.goo.ne.jp/xmldtp/e/d240a48fd8f3e0584e848c11f0c85a98
を書いた（ので、テストケースについては、そちら参照。そのエントリの「テストケースは、どう作るの？」
の話が今回の話。つまり、テストケースを作る組み合わせの話）けど、
それより主に結合テストで問題。結合テストの場合、
入力画面
サーバーサービス
出力画面
のような組み合わせになる。このとき、入力画面項目だけをみても複数あり、さらに、場合によって動く
サービスも複数あり、順番もあり・・・となってくると、組み合わせが問題になる。
■問題
例えば今、
Aという項目が３種類の値の取り方（同値グループ）｛あ、い、う｝
Bとうう項目が２種類の値の取り方（同値グループ）｛１、２｝
だったとする。
この組み合わせを考える。
ここでC0,C1 １００％を考えると（上記エントリのC0、C1のテストケースなど）、
あ、い、う、１、２すべてを通ればよい
なので、
｛あ、１｝、｛い、２｝、｛う、１｝
の３通りやれば１００％になる（一般に、同値グループ要素数の最大数（Aが３、Bが２→最大はAの３）
行えば、うまく組合せればC0,C1の１００％は作れる。
だけど、上記のやりかたでは、組み合わせを尽くしていない。たとえば上記の例だと
｛あ、２｝
を行っていない。なので、C2 １００％にならない。C2の場合は、組み合わせすべてを
行うことになる。
｛あ、１｝、｛あ、２｝、｛い、１｝、｛い、２｝、｛う、１｝、｛う、２｝
の６通り（３X２）。
■組み合わせ爆発と直交表、ペアワイズ法
今のは、簡単な例だったので、問題ないけど、実際には、項目が５つ、６つ・・・で、
とりうる値も、３つ４つ・・・といろいろなので、全部のケース数を行っていたら、
ものすごい組み合わせ量になる。
入力から出力の組み合わせすべてを行ったら・・・テストが終わらなくなる。
そこで、
最低限２つの組み合わせだけは行う、ペアワイズ法や、
２つの組み合わせは完璧、３つもできるだけの直交表
をつかって、組み合わせケースを出してテストする。
・・・ということまでは、学校で習うし、アカデミックでも行う。
■実施不能のケース
実務上ではこれに加え、実施不可というケースがある。
上記例だと、
あを選んだ人は１と２を選べるが、
いを選んだ人は２だけ
うを選んだ人は１だけ
しか選べないとする。
この場合、入力画面は、そのようにプロテクトしてしまうので、いの１は、入力すらできない。
しかし、サービス側では、将来的に入力画面以外の入力も受け付けるかもしれないので、
プログラム上は、いの１のケースは、エラーとして処理するようにコーディングされているのが普通。
（いの１は来ないからといって、そのまま流してしまう作りには、ふつうしていない）
この場合は、上記いの１のように入力できないものは「実施不可」として、
サーバー側のテストはしないでOKとすることがある。
問題は、この「実施不可」をどこまでとるか？ということ。
今、その可能性がないからといって、行わない場合、
将来、その可能性が出てきて行った場合、問題が発覚してしまうかもしれない。
たとえば、データベースにあるデータは存在しえない（本社が２つ同時にあることはない等）
となっていたのが、ビジネスが変わって存在してしまった場合（本社が２つになった）
・・・そこまでテストしたらキリないよね！と考えれば実施不可になる。
だから実施不可は、組み合わせ列挙とちがって、ケースバイケースの「ときもある」
■実施不可：単体テストでは起こらないわけ、単体テストでも起こるわけ
単体テストの場合、デバッガでどこへでも？行けるので、実際にはとりえない値でも、
テキトーにデバッガで値を設定して、そのモジュールを実行してしまう。
なので、「実施不可にはならない」
が、どうしても作れないテストデータのケースまで、デバッガで無理やり実施するのか？
という問いに「やんなくてよくね？」「そだね～」ということになれば、
「実施不可となる」。
ここで、問題になるのが、
「開発当初、まず起こりえないと思うケースに対して、単体テストをやっていなかったからといって、
そのケースが起こってしまい、それで問題が発覚したとき、単体テストをやっていなかったことを
責められるか？」
ということ。論理上ではやるべきだけど、起こりえないケースをやることが、経済的に理にかなっているのか？
この問題は、「みずほ証券事件」で争われた論点だけど、
裁判所は「後講釈になってはいけない」（事故が起こってから、「やるべきだったでしょ」と責めては
いけない。当時の状況を起案が得なければ）として、組み合わせチェックをしてれば、いいんでないかい
ぐらいの判断になっていると思った。。。けど違ったかな？（必要な人は自己責任で調べてください）
アクセス
トータル
ランキング
