境界値分析とは？流れやおさえておきたいポイントをわかりやすく解説

コンピュータの黎明期から、不具合は境界値で発生しやすいといわれてきました。これは現在に至っても同じで、限られた時間と予算のなかで効率よくテストを実施するには、境界値分析を実施するのが有効です。テストのパターンに漏れや抜けがない、網羅性を保証する必要があるソフトウェアテストでは、特に、境界値を意識したテストケースを設計して不具合がないかを確認するテストを実施する必要があるでしょう。

本記事では、境界値分析の概要と同値クラス分析の解説、境界値テストの流れについて解説します。

境界値分析とは、仕様条件の境界となる値とその隣の値に対してテストする技法のことです。境界値とは、ある範囲の最小値または最大値などの同値分割した領域の端にあたる値です。

具体的には「未満」や「以下」などが該当し、こういった境界部分は、間違いを引き起こしやすく、不具合が潜んでいる可能性が高いとされます。境界値を狙ってテストすることで、仕様の認識ミスや実装ミスによる不具合を検出できます。

境界値分析ができることとして、仕様書に書かれている大小比較に対するコーディングのミスを発見することができます。例えば仕様書上に「○○未満」と書かれているにも関わらず「＜＝」でコーディングされている場合、不具合が埋め込まれてしまいシステムが正常な数値で動作しなくなります。

コーディングだけでなく、仕様書を記述する段階での認識ミスで、境界値の表現を書き間違える場合もあります。境界値分析を実施することで、このような書き間違いや認識のミスによる問題を明確にできるのです。後述する同値クラステストでは、システムの代表的な動作を確認することができますが、比較条件のコーディングミスを見つけられることは稀です。不具合が頻繁に発生する境界値を明確にすることで、比較条件に着目した少ないテストケースで、確実に条件比較の確認ができます。不具合を効率よく発見するためにも、ぜひ境界値分析を実施したいところです。

なお、境界値分析は、連続する数値に対して大小判断する場合に有効です。特定の数字を示す「毎月15日」のような条件は境界値分析の対象にはなりません。

同値クラス分割とは、出力が同等になると想定される入力値のグループ（同値クラスや同値パーティション）を識別し、各グループに対するテストケースを作成する技法のことです。システムが正常に作動する値を「有効同値クラス」、エラーを検知する値を「無効同値クラス」といい、それぞれのクラスの代表値を用いてシステムが正常に作動するかをテストします。

例えば、画面上から日付（年月日）を入力するシステムのうち「月」の値を入力する場合について考えてみましょう。この場合、月の入力値の同値クラスは以下の3つが抽出分類できます。

・無効同値クラス：0以下の整数
・有効同値クラス：1から12までの整数
・無効同値クラス：13以上の整数

上記のように同値クラスに分割したあとで、各同値クラスの代表的な値をテストで使う値として選択するのが同値クラステストです。

同値クラスを意識せずに、適当な個数の値を選んだテストでは、すべての結果を確認することができません。各同値クラスから少なくとも1個の代表値を選ぶことで、最低限の結果を網羅したテストをすることができます。境界値は確認しませんが、最低限の網羅はできるので、工数を限定したテスト、例えばリグレッションテストなどで採用されます。

リグレッションテストについてはこちらもご覧ください。
＞＞リグレッションテスト（回帰テスト）とは？目的や自動化のメリットを解説のページへ

境界値テストの手順は、大きく以下の3つにわかれます。

1．境界を見つける
2．境界値を決める
3．テストする値を決める

それぞれの手順について詳しく見ていきましょう。

まずは同値クラス分割で、動作の変わり目となる仕様条件の境界を見つけます。このとき、次のような曖昧で誤解を生じさせやすい表現は、ひと目でわかるように数直線などを用いて表現しましょう。

・～より大きい
・～より小さい
・～と同等
・～以上
・～以下
・～未満

数直線で表す場合は、下図のように具体的にどんな値をテストすべきか正確に把握する必要があります。

この段階で最も重要なのは、境界を見つけることです。「～」の数値が条件に含まれるか否かを可視化することで、仕様書上では曖昧になっている部分をわかりやすくすることができます。これを同値パーティションといいます。

次に境界値を決めます。境界と隣り合う条件や値を境界値とするため、境界値は有効同値クラスの最小値と最大値になります。

上記の数直線であれば2と50です。ただし、これをそのまま境界値としてテストケースに採用してはいけません。

境界値が識別できたら、つづいてテストする値を決めます。テストする値の候補となるのは、以下の3つの値です。

（i）境界値
（ii）最小の境界値の1つ下
（iii）最大の境界値の1つ上

上記の数直線でいえば、1・2および50・51の組み合わせです。これらをテストケースに採用して境界値分析を実施します。

なお、「<」と「<=」の書き間違いをチェックする場合は上記の2つずつの組み合わせで十分ですが、「=」と書き間違えた場合はこれだけでは検出できません。この心配がある場合は、3つずつの組み合わせ、この場合では1・2・3と49・50・51をテストするようにします。また、特にリスクが高い部分に関しては境界値のほかに中間値、上記の例では25をテストケースに加えることも考えましょう。

実数の場合は、一つ上、一つ下の値を厳密に書けません。境界値分析自体は有効なので、数値範囲を考えて0.01など適切な上下の間隔を決めることになります。

境界値テストをするうえでおさえておきたいポイントが3つあります。

・表現
・複製や転記
・網羅性

これらを意識しておかなければ、コーディング時に誤解や入力ミスが発生してしまう可能性があります。トラブルを避けるためにも上記の3点は特に注意をしましょう。

境界を表す仕様の記述方法は、「～より大きい」、「～と同等」、「未満」などさまざまなものがあります。この境界をあらわす表現方法を注意深く定義しないと、意味の誤解が発生してしまうかもしれません。

仕様書の作成者と実際にコーディングを実施する人物は同じとは限らないでしょう。そうなると、同じ表現でも捉え方が変わってしまい、間違ったコードを記述してしまう可能性があるのです。

有効な対策としては、数直線などで表現の意味を可視化することです。文章ではなく図や数直線で伝えることで、誤解やコードの記述ミスを防げるようになるでしょう。

複製や転記にも注意が必要です。初級の開発者は実際に動いているソースコードをコピーしたがる傾向がありますが、このときにコンパイルエラーを解消するために変数などを修正することに気を取られて、条件や境界値の違いを見落としがちです。その結果、開発仕様書に記載されていた条件とは異なる条件をコーディングしてしまい、レビューでも見過ごされることがあります。

このような不具合は境界値テストでも見つけられますが、複数人でレビューして重点的にチェックするといいでしょう。不具合を取るだけでなく、開発者の育成にもつなげられます。経験を積んだ開発者はソースコードの複製や転記を避け、仕様書を見ながらソースコードを書きますが、そういう習慣をつけるのもいいでしょう。

網羅性も注意すべきポイントですが、少しわかりにくいかもしれないため、例を用いて説明します。例えば、「パスワードの文字数は5文字以上、16文字以下」という仕様において、その文字数をチェックするプログラムを以下のようにコーディングしたとします。

このようにコーディングされていれば、以下の同値クラス分割とプログラム内部構造は一致します。

・有効同値クラス：5文字以上、16文字以下
・無効同値クラス：0文字以上、4文字以下
・無効同値クラス：17文字以上

いい換えれば、境界値分析で代表値を選んでテストすれば、テストの網羅性は確保できるのです。

しかし、極端な例として以下のようにコーディングされていたとします。

このようなコーディングでは内部に同値クラスがいくつも存在するため、文字数が取りうるケースを全件テストしなければならなくなります。このような記述をしてしまうと、仕様書から読み取れる内容で同値クラス分割・境界値分析を行ってテストをしたとしても不十分ということになり、境界値テストをするうえで注意しなければならなくなります。

網羅性は確かに重要ではありますが、テストにかかる費用や労力を考えた記述をしなければなりません。コーディングはできる限り簡潔に記述するようにし、テストケースを増やさないようにしましょう。

境界値分析は、仕様書上の曖昧な表現を明確にし、コーディングの際に不具合が発生しないようにするための重要な分析です。数直線や図で示すなど、やや手間がかかる部分がありますが、品質の高いシステムを提供するためには欠かせない分析でもあります。本記事で紹介した手順や注意すべきポイントを意識して、境界値分析を実施してみてください。

自社に境界値分析の経験則がない、第三者に依頼したいという場合は、SHIFTまでご相談ください。SHIFTはソフトウェアテストに強みをもっており、数多くの不具合を発見してきました。境界値分析の経験が少なく実施できない、経験はあるが正しいかどうか自信がないとお困りの方は、ぜひ一度SHIFTまでお問い合わせください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

よくある質問はこちら
＞＞ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座