【ソフトウェアテスト】桁数上限を指定された値を入力する場合

こんばんは。
気が付けばこんな時間。

　「そういえば、今日の分書いてなかったなー_(:3｣∠)_」

と思って、いそいそと書き始めました。

今日は、少々具体的過ぎる内容にしたいと思います。というのも、以前書きましたが、ソフトウェアテストに「考える」という作業を、私は要らないと思っているので、その一端を書いてみようかなと思いまして。

テストケースを考えるにあたって、「システム」と「ソフトウェア」を切り離して考えた場合、観点の棲み分けは

　「システム」　　＝システムテスト、総合テスト
　「ソフトウェア」＝単体テスト、結合テスト、適格性テスト

等に大きく分類されることになります。ここでは、あくまでもソフトウェアテスト…具体的には結合テストの観点として１つ例に挙げます。

たとえば、ある値を入力する際、かならず「桁数（byte長、文字数など）」には上限（Twitterなら140文字までとか）がありますが、こうした値を取り扱う場合に、テストパターンを考える時点でﾓﾔﾓﾔと考えているようでは、属人的な発想を許してしまうことになり、品質の安定性を保つことができません。

そもそも、ソフトウェアそのものは突き詰めると０と１の世界だけで成り立つ『デジタル』の世界の存在なので、全てが論理で説明できるようになっています。アナログの世界の考え方をそれに当てはめていると、正解かどうかが証明できません。

さて。

デジタルの世界の住人である『ソフトウェア』だけに限って言えば、そのほぼすべては「同値分割」と「境界値分析」の２つの基本的な概念だけで説明が可能です。

「同値分割」とは、テスト結果が同一になるものをグループ分けし、それぞれのテスト結果になる代表的なテスト条件を選択してテストする手法です。

たとえば上記のように、上限16桁の数値を取り扱う場合は、

　0未満を無効桁数（異常値）
　1～16桁を有効桁数（正常値）
　16桁以上を無効桁数（異常値）

としてグループ化し、そのグループ内の代表１件をテストすれば、同じグループ内となる値はすべて品質が保証される…と言う考え方です。数あるパターンの中から１件だけテストすれば他も保証されるので、最も楽な方法…ともいえるかもしれません。

ですが、プログラマーには比較演算子の過ちが起こりがちです。特に新人から２年目あたりまでの初歩的なミスとしてよく見られるのですが、

if ( valueSize > 17 ) {
　　　…エラー処理
}

といったように、等号が足りずに、"17"桁だった場合の処理が漏れてしまうなんてことが往々にしてよく起こります。そんな時に、テスト実行者の気まぐれで

　「20桁あたりを適当にやっておけば、同値グループはすべて証明される」

と勘違いされると、不良検知の抜け漏れが発生してしまいます。このような『範囲（スコープ）』が特定されているようなケースでは、同値分割では対応しきれません。結果、テストが漏れて、次工程以降で発覚して見直しを要求されたり、あるいは納品後まで気づかず、市場に出てから大問題となってしまうことも度々あります。

そんな時に選択するのが「境界値分析」です。境界値を挟む前後を確認することで、同値分割の精度向上および範囲保証を行うテスト手法です。境界値分析を用いると、テストケースの精度は格段に向上します…と言うか、このケースでは完璧に保証されます。このあたりを整理してみると、次のようになります。

多くの場合、境界値分析を実施することで同値分割を兼ねます（大は小を兼ねる）が、ノンデグレーション確認を行う場合などは、双方において保証することもありえます。

これを図化すると、次のような観点が集約されているということになります。

※ＴＰＯ、仕様、あるいはチェックロジックによっては
　②と③が逆転することもある。
※何故、必須チェックを冒頭で行うのか？
　桁数が０であれば、それでも代用できるのに、
　何故必須チェックが必要なのか？
　→オブジェクト指向言語の場合、Null値に対してはメソッドが機能しない
　　ため、Nullであった時点で処理の流れから除外しないと例外が発生して
　　しまう。

シンプルに考えられるようにするため、今回のタイトルにある条件の場合、且つ単項目に対するテストケースの場合、という限定的なパターンを挙げていますが、このようにソフトウェアの開発においては、その検証において、少なくとも、法則性をしっかり理解しておけば、「考える」「悩む」といった手間は一切必要がありません。すべて機械的に決められるのです。

複数の項目の組み合わせにおいても、それぞれ個々に網羅できていれば、あとはそれを組み合わせるだけです。10パターンと10パターンを組み合わせれば、およそ100パターンになるだけですね。まぁあまり増えすぎると現場から悲鳴が上がるので、10万パターンくらいまでなら…１日もあれば、おそらく500パターン前後にまで絞り込めるのではないでしょうか。

この辺りは最初からマトリクスにしてパターンを構築していれば、けっこう簡単に重複ケースや包含ケースを塗りつぶせて簡単になります。この辺りは、どちらかと言うと肉体労働に近いので、少々慣れがないと、パフォーマンスが向上しないかもしれませんね。