同値分割再考－その1－ もどうぞ♪
ブラックボックスの場合は、基本的には機能仕様書からモデル化し、同値分割を行います。
しかし同値分割したはいいものの、本当にその同値分割でいいのかと不安になることがあります。
なぜ不安になるのでしょうか？
それは同値分割の"根拠"が足りないからだと考えます。
自分が考えた限り、同値分割の"根拠"は以下の２つに集約されると思っています。
①ソースコード(設計書)を見る
②既にテスト済みである
これがポイントの2つ目になります。
同値分割のポイント②『同値と見なした根拠を考える』
【同値分割の根拠①】
まずは"①ソースコード(設計書)を見る"について考えてみます。
自分達がテストするのは、仕様書ではありません。仕様書から設計という工程を経て、コーディングされたコードなんです！
すると自分が作成した同値分割のモデルがコードと本当に合致しているのかが気になりますよね？
もし、コードを見ることができないのであれば仕方ないと思いますが、コードが見れる場合は絶対に見て、モデルが合っているか確認したほうがいいと思います。
これはホワイトボックスとブラックボックスの間ということでグレーボックスと呼ばれています。
参考）Androidテスト技法 P37 グレーボックスで設計する
例えば以下の仕様があったとします。
仕様：毎月20日までは割引率10%、21日以降は割引率15%とする。
この場合普通に考えると【コード1】になっていると推測して、同値分割するはずです。
でも、コードが【コード2】になっている場合はどうでしょうか？
【コード1】
if (day >= 1 && day <=20)
{
discontRate = 10;
}
else if (day >= 21 && day <= 31)
{
discontRate = 15;
}
else
{
// error処理
}
【コード2】
if (day == 1)
{
discontRate = 10;
}
else if (day == 2)
{
discontRate = 10;
}
else if (day == 3)
{
discontRate = 10;
}
：
else if (day == 31)
{
discontRate = 15;
}
else
{
// error処理
}
最初に考えたモデルは意味のないことが分かります。
1日～20日は同じ処理を通っている訳ではないですよね？？
【コード2】の場合は15日だけバグがでることも十分あります。
この場合は1,2,3,･･･というのを別の同値クラスにする必要があります。
モデルの同値分割が足りないことを自分は同値分割の"ザンネンモデル"と呼んでいます
もう1つ逆のパターンもあります。
それがモデルの同値分割が多くなるパターンである"ヤリスギモデル"になります。
例えば、以下の仕様が書いてあったらどうでしょうか？
仕様：IPアドレスの4つの数値の入力チェックを行います。最初の数値1は1～255、その他の数値は0～255のときに有効なIPアドレスとする。
どんなコードを想像して、どういう風に同値分割しますか？
自分の場合は入力値を以下のように同値分割をします。一番上が有効同値でそれ以外は無効同値ですね。
・入力が正常な数値のパターン(1～255)
・入力の数値が間違っているパターン（0, 256, など ）
・入力に文字列が入るパターン（a, b など）
・入力に記号が入るパターン（*, [ など）
※1つ目の入力についてのみ記述していますが、他の入力に関しても同様に考えることができます。
さて、ちょっとコードを覗いてみたところ、【コード3】のようになっていたとします。（C#のコード）
【コード3】
IPAddress ipAddress;
if (IPAddress.TryParse(ipText, out ipAddress))
{
return ipAddress;
}
※ipTextには[数値1.数値2.数値3.数値4]のテキストが入るとします
この例は.NET F/WのIPAddressクラスライブラリを使っているので、自分で面倒な判定のコードは書いていないですね。全てライブラリに任せています。
このときは、ここで細かいテストを書くのは無駄の極みですよね。これは先ほど言いましたが"ヤリスギモデル"と勝手に呼んでます。
仕様書からテストケースを作るとこういうことが起きることがあります。だからコードを見ることができる場合は、絶対に見たほうがいいんです！！そもそも同値分割の目的がテストケースを少なくするためなのに、無駄なことをやることはありません＞＜
【同値分割の根拠②】
続いて"②既にテスト済みである"について考えてみます。
例えば同値分割再考－その1－で取り上げたエクセルのフォントの例を取り上げます。
まず最初に以下のテストを実施したとします。
目的:設定したフォントサイズが反映されるか？
軸:入力タイプと小数
直接入力小数点なしクラス[1,2,3･･･409]
直接入力小数点ありクラス[1.5,2.5,3.5･･･409.5]
ドロップダウンクラス [6,8,9･･･72]
その後で次のような目的のテストをするときはどうするでしょうか？
目的:フォントサイズとBoldとItalicとUnderlineが同時に反映されるか？
この場合はフォントサイズが（単機能として）反映されるか関しては既にテスト済みであるため、有効同値クラスを3つから1つへまとめます。
入力フォントサイズクラス[1,1.5,2,2.5･･･409,409.5]
これは、"設定したフォントサイズが反映されるか？"がテスト済みであるため"まとめること"ができるのです。
このテスト済みの結果を考慮に入れて"まとめること"をズームアウトと言います。
逆に細かくみていくことを、ズームインと言います。
このことを意識していないとテストの目的にあっていない細かい同値分割を用いてしまい、無駄なテストケースが山のようにできてしまいます。
同値分割のズームイン/ズームアウトについてはこちらのエントリーも参考にしてください。
http://ameblo.jp/sendai-test/entry-11566522843.html
【まとめ】
同値分割を再考してみました。
だれでも知っている技法くらい有名になっていると思いますが、自分が納得するまでは結構時間がかかりました。
再度になりますが同値分割をさらに使えるようにするポイントは2つだと思っています。
同値分割のポイント①『常にテストの目的と軸を意識する』
同値分割のポイント②『同値と見なした根拠を考える』
根拠①ソースコード(設計書)を見る
根拠②既にテスト済みである
間違い、ツッコミ等あれば@nemorineまで連絡お願いしまーす。(*´∀｀)ﾉ