【ソフトウェアテスト】同値分割法/境界値分析
公開日: 2025/1/24
入力されるデータによって判定を変えるという機能は、ソフトウェアの機能として広く一般的に使われます。
自己責任で金銭を扱うサービスを利用する際には、18歳以上か未満かで利用の可不可を判定するという年齢確認機能が適用されていることがあります。
ユーザーが任意にパスワードを設定できる機能の場合は、文字数が想定より少ない場合はセキュリティレベルが低いため無効として、文字数が想定より多い場合も仕様想定外として無効とするシステムもあります。
こういった機能を対象に検証を実施する際、入力可能な数値を全て検証対象としてテストを実施しようとすると、非常に多くの工数を割かねばならないため、入力想定範囲の中で同じ処理を返す想定の数値は1つのグループとして扱い、処理の変わる境目に狙いを付けてテストするというのが、「同値分割法」と「境界値分析」です。
1. システム要件の一例
年齢確認ダイアログの動作と処理の要件を定義します。
■ 年齢認証機能の仕様
・入力画面の操作可能なモジュールは、数値を入力する入力フォーム、OKボタン、キャンセルボタンを実装する・数値入力フォームにはキーボードから入力する
・数字以外の文字は入力できない
・入力欄が未入力の場合はOKボタンを非アクティブとする
・整数以外の数字と3桁以上の数字を入力した場合はOKボタンを非アクティブとする
・0から17を入力してOKボタンをクリックすると、別のダイアログで「年齢の条件を満たしていません」と表示させる
・18から99を入力してOKボタンをクリックすると、別のダイアログで「登録情報入力に進みます」と表示させる
2. 同値クラス/同値パーティション
入力値によって同じ動作結果を返すと想定される値をそれぞれ「同値クラス」あるいは「同値パーティション」としてグループに分けます。
有効な入力値・無効な入力値が明確な場合は、有効として処理されるグループを「有効同値パーティション」、無効として処理されるグループを「無効同値パーティション」として分けます。
上記仕様を元に考える場合は、以下のグループに分けられます。
有効な入力値・無効な入力値が明確な場合は、有効として処理されるグループを「有効同値パーティション」、無効として処理されるグループを「無効同値パーティション」として分けます。
上記仕様を元に考える場合は、以下のグループに分けられます。
■無効同値パーティション
・入力値が1~2桁の半角数字以外の数字
■有効同値パーティション
・0~17の数字(年齢の条件を満たしていません)
・18~99の数字(登録情報入力に進みます)
これらのパーティションを元に、テスト実施時の代表値を各グループから任意に一つ抽出して、ローレベルテストケースを作成します。
3. 境界値分析
上記の入力値は分割したパーティション内から任意の数値で仮定しましたが、数値によって動作の変わるシステムの場合、動作が変わる境界付近に不具合が偏在することが多いので、切り替わるポイントに重点をおいてテストケースを作成する際に、境界値分析を使用します。
境界値に不具合が偏在しやすい理由として、仕様定義時に「以下」「以上」「未満」「を超える」と記載した仕様と、実装したコード内の[==][>=][<=][>][<]等の記述とで相違が発生しやすいという点に起因します。
上記システムの仕様は、0以上17以下なら「年齢条件を満たさない」、18以上99以下なら「登録情報入力に進む」、0未満の負数や100以上の3桁なら無効な入力となりますが、これを2値と3値それぞれで境界値を想定すると下記のようになります。
・[0][17]は有効(年齢条件を満たさない)
・[18][99]は有効(登録情報入力に進む)
・[100]~は無効
・[0][1][17]は有効(年齢条件を満たさない)
・[18][19][99]は有効(登録情報入力に進む)
・[100][101]~は無効
2値でテストする場合と3値でテストする場合、それぞれ長所と短所があります。
2値でテストする場合は、3値と比べてより少ないテストケースで分岐条件をカバーできます。
3値でテストする場合は、2値よりもテストの工数はかかりますが、以下のようなコードの仕様相違を検知できます。
正 if(age >= 18)
上記の誤りは[18]でテストした場合は動作不良にならず見逃す可能性がありますが、[19]でテストした場合は想定外の動作になり動作不良を検知できます。
境界値に不具合が偏在しやすい理由として、仕様定義時に「以下」「以上」「未満」「を超える」と記載した仕様と、実装したコード内の[==][>=][<=][>][<]等の記述とで相違が発生しやすいという点に起因します。
・2値か3値か
数値の境界をテスト対象とする場合に、境界付近の値を2つと3つのどちらで取るかを考えます。上記システムの仕様は、0以上17以下なら「年齢条件を満たさない」、18以上99以下なら「登録情報入力に進む」、0未満の負数や100以上の3桁なら無効な入力となりますが、これを2値と3値それぞれで境界値を想定すると下記のようになります。
■2値
・~[-1]は無効・[0][17]は有効(年齢条件を満たさない)
・[18][99]は有効(登録情報入力に進む)
・[100]~は無効
■3値
・~[-1]は無効・[0][1][17]は有効(年齢条件を満たさない)
・[18][19][99]は有効(登録情報入力に進む)
・[100][101]~は無効
2値でテストする場合と3値でテストする場合、それぞれ長所と短所があります。
2値でテストする場合は、3値と比べてより少ないテストケースで分岐条件をカバーできます。
3値でテストする場合は、2値よりもテストの工数はかかりますが、以下のようなコードの仕様相違を検知できます。
・18以上を条件とした仕様想定
誤 if(age == 18)正 if(age >= 18)
上記の誤りは[18]でテストした場合は動作不良にならず見逃す可能性がありますが、[19]でテストした場合は想定外の動作になり動作不良を検知できます。
※補足
[99]でテストした際にも同様に想定外の動作になるので動作不良の検知自体はできますが、18では想定外挙動にならず、19~99の間のどこで想定外挙動になったかが不明であり、上記のようなコード記述の相違を特定するまでには至らないので、2値の場合は検知自体はできるが発生原因の特定が困難、3値の場合は発生原因の特定まで可能なテストといえます。4. テストケースを想定する
以上の点をもとに、今回定義したシステム要件に対するテストケースを作成する場合、以下のパターンが想定されます。
2値を元にしたテストケースは対象項目数が6項目で、各パーティションの動作を2回確認しています。
3値を元にしたテストケースは対象項目数が9項目で、各パーティションの動作を3回確認しています。
2値を元にしたテストケースは対象項目数が6項目で、各パーティションの動作を2回確認しています。
3値を元にしたテストケースは対象項目数が9項目で、各パーティションの動作を3回確認しています。
5. 仕様から想定する境界値とテスト対象
今回定義したシステム仕様は、
・数値入力フォームにはキーボードから入力する
・数字以外の文字は入力できない
・整数以外の数字と3桁以上の数字を入力した場合はOKボタンを非アクティブとする
上記のとおり、入力可能な数値はキーボードから入力できる数字に限られ、整数以外の数値は受け付けない異常系と想定しているので、前述のようなテストケースになりました。
[-1]を入力した際の動作「OKボタン非アクティブ」をもって異常系の確認としていますが、「キーボードから入力する」と「数字以外の文字は入力できない」仕様について、プログラムのコードとして整数型を指定していることが分かっている場合は、[-1]を入力して異常系を確認するケース想定で十分ですが、コードの内容を考慮せずにテストを実施する場合には、入力フォームに小数やひらがななどの文字列を入力した場合の動作確認も必要になります。
また、数字を入力する際、入力欄へキーボードで入力する形式ではなく、ドロップダウンやピッカーなどのインターフェースから選択する場合は、有効な0~99までを選択肢として用意している仕様であれば、そもそもそれ以外の数字や文字列は選択できなくなるので、無効同値の確認は不要になります。
実際に同値分割法や境界値分析を行う場合は、テスト対象システムの仕様定義を考慮すると、より詳細に取捨選択が可能になります。
6. さまざまな境界値
・時間/日付の境界
何日の何時より前は無効で何日の何時より後になったら有効になるというシステムの場合は、時間/日付の形式をどのように定義しているかの考慮が必要です。
「1月1日0時から有効になる」という仕様の際に、分刻みなのか秒刻みなのかによってパーティションの分け方が変わります。
分刻みの場合の境界は「12/31 23:59」まで無効「1/1 0:00」から有効、秒刻みの場合の境界は「12/31 23:59:59」まで無効「1/1 0:00:00」から有効となり、テストケースを作成する際に確認項目が無駄に増えてしまう懸念があるので、どのような実装でどのような仕様想定なのかの認識合わせをしておくべきです。
・入力可能な最大値
今回定義したシステムは3桁以上の数値は全て異常系として扱う想定としましたが、どこまでを上限とするかは特に明示していません。
使用する言語によって整数型の宣言方法も違うので、上限値を明示していなかった場合の最大値は各言語の指定した整数型最大値になりますが、実装したコードを確認できる状況ではない場合は上限値が不明になってしまうため、実装担当者と仕様について認識合わせをしておく必要があります。
年齢入力の際に9桁10桁の数字を入力する状況など、エンドユーザーの操作としては本来あり得ませんが、やろうと思ったらできる操作というのは、意図的にやるか否かは別として、
ケースとしてはあり得るということなので、テストスコープに含めるかどうかは検討が必要です。