こんにちは、はまたくです。
前回の「同値分割法」を使ってみたに続いて、今回は「境界値分析」についてのお話をします。

JSTQB FLを勉強したけど実際にテスト技法を使用したことが無い方や、現在JSTQBの勉強を進めている方々の参考になれば幸いです。

境界値分析の定義

JSTQB FLのシラバスでは境界値分析は以下のように定義されています。

境界値分析(BVA)は同値分割法の拡張であるが、パーティションが数値または順序付け可能な値で構成される場合だけ使用できる。パーティションの最小値および最大値(または最初の値と最後の値)が、境界値である。

JSTQB FLシラバス
Foundation Level シラバス 日本語版 Version 2018V3.1.J03 (p.57)

要は、パーティション(同値クラス)の端を境界値として、その値をテストしようってことですね。

そして、この境界値分析は、
「20歳未満は割引対象」「20歳以上は割引無し」など、境界があるものには適用することが出来て、
「種類(食品)の商品を購入するとポイント付与」「種類(飲料)の商品を購入するとポイントが付与されない」のように、同値分割は出来るが境界が無いものをテストする場合には適用できません。
(当然のことではありますが…)

なぜ境界値に着目するのか

ではなぜ境界値に着目するのでしょうか。
例えば「1以上100未満の整数n」を入力値として受け入れるシステムがあったとします。

不等号で表すなら
「1≦n<100」となりますが、

これをコードに記述する際に、
「未満」「以上」「○○から」「○○まで」「○○より」などの日本語を捉え違えて設定してしまったり、単純な記述ミスにより、
「1<n<100」や「1≦n≦100」と、誤った内容で実装されることがあります。

そうすると、本来受け入れるはずの「1」を受け入れなかったり、本来受け入れないはずの「100」が受け入れたりするバグが混入されるわけです。
この不等号の設定ミスを取りこぼさないようにテストしよう、が境界値を見る主な目的になります。

境界値の取り方

具体的にどのように仕様書から境界値を設定していくか、ですが、
境界値分析の境界値の取り方は「2値」で取る方法と、「3値」で取る方法があります。
2値の境界値は「隣接する同値クラスの端の値2つ」で取ります。

例えば、
20未満の整数」を受け付けるシステムならば、
同値クラスが「19以下の整数」クラスと「20以上の整数」クラスに分けられ、
「19」と「20」が境界値となります。

20以下の整数」を受け付けるシステム、であった場合、
同値クラスが「20以下の整数」クラスと「21以上の整数」クラスに分けられるため、
境界値は「20」「21」となります。

同じ数値「20」が仕様書に記載されていても「未満」なのか「以下」なのかによって同値クラスの端の値が変わるため、仕様をよく理解して境界値を設定する必要がありますね。
2値の境界値分析では、仕様と異なる不等号や等号付き不等号でシステムが実装されていないか(例えば「20<n」が「「20>n」や「20≦n」と設定されていないか」がテストできます。

次に、3値の境界値の取り方ですが、「境界上の値」と「その前後の2値」が境界値になります。

例えば、
20未満の整数」を受け付けるシステムならば、
境界上の値「20」と、その前後「19」と「21」が境界値となります。

20以下の整数」を受け付けるシステム、であった場合も、
境界上の値「20」と、その前後「19」と「21」が境界値となります。

2値のときと異なり、「以下」「未満」の言葉にとらわれずに、仕様書に記載されている境界値とその前後の値をとればいいのでわかりやすいですね。

3値の境界値分析では、2値の境界値分析と同様に仕様と異なる不等号や等号付き不等号でシステムが実装されていないか(例えば「20<n」が「「20>n」や「20≦n」と設定されていないか」の他に、
不等号の代わりに等号が設定されてしまっている場合(「20=n」)の設定ミスも検出することが出来ます。

2値と3値どちらを使うか

では、どちらの境界値の取り方をどの場面で使えばよいか自分なりに考えてみました。
※あくまで僕個人の考えなので参考までに

まず2値と3値のそれぞれのメリットを整理すると

2値
・3値と比較してテストケース数が少ない
・ 不等号や等号付き不等号の設定ミスを検出できる

3値
・ 境界値の取り方がシンプルでわかりやすい
・不等号や等号付き不等号の設定ミス+等号の設定ミスも検出できる

があげられます。
なので、使い分けの基準として考え付いたのは以下の3つです。

1)テストレベルの違い
2)仕様の複雑さ
3)不具合の影響度合い

1つ目のテストレベルの違いですが、
単体テストで仕様通りにコードが記述されているか細かく見よう、ということであれば、等号の設定ミスまでカバー出来る3値で確認したほうがよく、
反対に単体テストや結合テストまでで3値の境界値に対するテストが出来ているのであればシステムテストや受け入れテストでは、2値で見れば十分なのでは?と思います。
また、その他のテストケースで別の代表値のテストが出来ているケースもあり、そういった場合は等号の設定ミスの確認も担保出来るため、3値で確認する必要性は少ないです。

2つ目の仕様の複雑さは、境界値の取り方にミスが発生するリスクがある場合です。
例えば、開発者本人がテストする場合に、日本語の解釈違い(「未満」「以上」「○○から」など)が開発の時点で発生していたとして、テストにおいても同一の解釈違いを起こすケースがあります。そのため、3値で設定しておいたほうがテストの抜け漏れを防げます。
また、同値クラスの数が多く、且つ仕様が複雑な場合など、テストにおける設定ミスが発生しないように3値で設定するのも有効なのかな?と考えました。
(2値だと境界値の設定を間違えるかもしれない、というケースだと3値でテストケースを作成しても期待結果を誤って設定するリスクはありますが…)

3つ目は不具合の影響度合いです。
例えば、金融系や医療機器などのシステムにおいて、テスト対象箇所に不具合があった際にリスクが高い場合はテスト強度の強い3値を使います。
反対に、テスト対象箇所に不具合があってもリスクが小さい場合はテスト強度の弱い2値でも問題ない、といった判断となります。

以上3点のように、
不具合が発生する可能性や不具合の影響度合いに応じて2値と3値を使い分けることが大切です。

まとめ

境界値分析は基本的なテスト技法であり、考え方自体はそう難しくないかもしれません。しかし、実際にこの技法を取り扱う際には「未満」「以上」などの日本語の意味や、等号不等号の何をテストしたいのかなど、仕様に対する理解と整理が求められます(特に2値の場合)。正しく扱えるようになれば、使用頻度も高く、且つ効果的なテスト技法となりますので、境界値の設定ミスに注意して積極的にテストに取り入れていきましょう。

SHARE

  • facebook
  • twitter

SQRIPTER

AGEST Engineers

AGEST

記事一覧

AGESTのエンジニアが情報発信してます!

株式会社AGEST

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST