テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

同値分割について教えてもらった話、其の二

同値分割について教えてもらった話、其の一 - テストする人。

 

の、其の二です。

 

Togetterはコチラから

同値分割について - Togetterまとめ

 

 

2つの系統

 

 前回書いたエントリ

ブラックボックス人問題はブラックボックステストみたい - テストする人。

でイメージが湧いた。

1.は、中身の処理が見えている状態。その場合、その処理から必要となる入力値を判断する(ブラックボックス人の箱の中身を開けている状態)

2.は、ブラックボックス人の最初の状態。この動画の場合、どの方向に置いても、必ず同じ向きに出てくる。

 出力:同じ向きに出ること

 入力:どの向きに置いても

ということから、入力値を判断する

きっと、この動画の場合「横向きにセットする場合、正しく出力できない」ということが1であれば分かるけど、2の場合分からない。

 

郵便番号を例に考えてみる

 

有効同値:郵便番号の集合{811-1211}

無効同値:郵便番号でない集合{ abab }

↓これは同値分割で求めてる?!

実際にテストするとき:{ abab , aaa-bbbb, あああえ, <B><, 000-0000, ....}

実際のテストデータを考える時の頭・・・

「郵便番号・・・7桁だな。ハイフンいるのかいらないのか?」

「入力フォームが3桁、7桁で分かれてるなら、全部数字しか入らないよな」

「入力フォームが1つしかないなら、数字とハイフンで構成されるな」

「桁数のチェックしている?」「数値以外?」「HTMLのタグ入れたら?」「SQL文入れたら?」

こういうことを考えているときには、「郵便番号でない」よりもっと掘り下げてテストケースを考えているはず。。。これが同値分割のズームインということになるのか!?

 

剰余計算を例に考える

 

3で割った余りを考える

出力値:余り 0, 1 , 2

入力値:0になる入力{3, 6, 9...} 、1になる入力、2になる入力

 

X÷3の処理から考える

入力値:有効同値クラス{0,1,2,3 ...}

 

出力から考えた場合と、処理に注目して考えた場合出力するテストデータの数が異なることが分かる。

私の場合、出力と入力から処理を想定して、テストデータを考えることが多いけど(すべての仕様が書いてある仕様書がない、細かい仕様までプログラマーに確認する時間がない)

テストデータが増えてきた場合は、その処理を確認して、省略できるテストはないか考える。というやり方をしています。

それなら、仕様を最初から聞けよ!って思いますが、詳細まで毎度聞くより、3ケースくらいならテストして確認した方が早いのです。。

また、仕様書に書いてあっても、その通りに実装されていなかったり、コードレビューの時間が取れてなかったりするので。。