6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ソフトウェアテストの小ネタのカレンダー | Advent Calendar 2023 - Qiitaの2日目の記事です。

こんにちは、
テスト技法の一つである境界値分析を勉強していると、OnポイントとOffポイントという言葉が出てきます。難しくてよくわからないと感じたことが皆さん少なからずあるのではないでしょうか。私もそうでした。
特に新しいトピックではないですが、今日は、私なりにOnポイントとOffポイントという言葉を解釈して境界値分析について解説しようと思います。

Onポイント

Onポイントは、どこでもいいのですが、仕様書に書いている値や着目しようとしている境界値のことです。
例1:「15以上」と仕様に書いてあった場合は、15がOnポイントです。
例2:「16未満」と仕様に書いてあった場合は、16がOnポイントです。

Offポイント

Offポイントは、Onポイントに隣接する別の同値パーティションの境界値です。
Offポイントは、Onポイントに従って決まります。同値パーティションは領域と言い換えても問題ないと思います。
先程の「15以上」の例ですと、Offポイントは、14になります。(整数しか存在しないと仮定しています)。
図にするとこのような形になります。
image.png

Inポイント

OffポイントとOnポイントが決まると、Inポイントという言葉が出てきます。
Inポイントは、OnポイントまたはOffポイントではない、同値パーティションの中の値です。
つまり、13や16などの数字です(他の数字でもいいです)。

ここまでのまとめ

ここまでの話をまとめると次のようになります。

  • Onポイント: 仕様書に書いてある境界値(着目しようとしている境界値)
  • Offポイント: Onポイントに隣接する別の同値パーティションの境界値
  • Inポイント: OnポイントまたはOffポイントではない、同値パーティション中の値

よくある勘違い

ここで、次の勘違いをよくしてしまいがちだと思っています。

  • Onポイントならば有効同値パーティションに属する。
    Onポイントと有効同値パーティションか無効同値パーティションかは、関連しない概念です。Onポイントであっても無効同値パーティションになりますし、有効同値パーティションにもなりえます。
  • Offポイントならば無効同値パーティションに属する。
    こちらもOnポイントと同様です。Offポイントと有効同値パーティションか無効同値パーティションかは関連しない概念です。Offポイントであっても有効同値パーティションになりえるし、無効同値パーティションにもなりえます。

境界値分析でのテストケースの作り方

テストケースの作り方は他にも色々あると思いますが、よくいわれている2種類のやり方について紹介します。

Beizerの方法

境界値のOnポイントとOffポイントをテストケースとする方法です。
OnポイントごとにOffポイントは何か選ばなければいけないので、テストケースの選択ミスが起きやすいです。

「>=」を「>」や「<=」や「<」に書き間違えたり、
「<=」を「<」や「>=」や「>」に書き間違えたケースを見つけることができます。

== などを見つけたい場合は、Inポイントをテストケースに含める必要があります。
GIHOZだと、こちらの方法に基づいて、テストケースを生成していますね。

Jorgensenの方法

Onポイントの前後を加えた3つのポイントをテストケースとする方法です。
Offポイントは何か選ばなくても、Onポイントの前後を選べばよいので、テストケースの選択ミスが起きにくいです。

Beizerの方法で見つけることができる問題に加えて、「==」にしていた間違いを見つけることができるようになります。

テストケース数がBeizerの方法に比べて多くなります。一つのOnポイントごとにテストケースは、3つ必要になります。

どちらを使うべきか?

こちらの記事によると、

どちらを使うか? ですが、私は、開発者本人が行うコンポーネントテストでは3値が良いと思っています(コーディングとテストで同じ間違えを犯すことを救うため)。
第三者がテストする際には仕様をきちんと読み直し2値で実施するのが良いと思っています。

ということだそうです。

つまり、開発者本人が行うテストでは3値(Jorgensenの方法)でやるほうが良く、なぜならば、コーディングする際とテストする際にどちらともに、同じ間違いをしてしまいバグが見つからない可能性があるからだそうです。
QAなどの第三者がテストする際は、仕様をきちんと読み直し、2値(Bezierの方法)で実施するのが良いそうです。

最後に

この記事が理解の助けになれば幸いです。何か間違いがあればご指摘ください。

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?