データベースカバレッジを考えたデータ作成

とりあえず、データベースカバレッジを考えたデータ作成を考えてみます。
まず、大きくわけて3つのカバレッジを考えます。

「単一テーブルの条件カバレッジ」というのは、ひとつのテーブルの列の値について、数パターン考えられるときに、それぞれの列の条件を組み合わせるカバレッジです。例えば「受注」テーブルで「受注日」「出荷済」「入金済」という列があったとき、「受注日」について今月、先月、去年、今月末、今月頭、先月末という6パターンの値を考え、「出荷済」「入金済」に関してはそれぞれ「済」と「未だ」という2パターンを考えるとき、6×2×2パターンすべての組み合わせのデータを用意するという考え方です。
このカバレッジの場合は、テストデータを作成するためのツールもたくさんあるし、自作するのも難しくないので、比較的簡単に満たすことができます。


問題は、関連テーブルを考慮したカバレッジです。
「関連テーブルの行数カバレッジ」は、例えば「受注」テーブルと「受注明細」テーブルがあったときに、「受注明細」がない「受注」データ、「受注明細」が1件だけある「受注」データ、「受注明細」が複数ある「受注」データ、のように、関連データの行数の組み合わせを考慮するカバレッジです。
「関連テーブルの条件カバレッジ」は、前の例の「受注明細」テーブルに「取消」列があるとき、「取消」された「明細」を含む「受注」データ、「取消」されてない「明細」だけを含む「受注」データ、のように、関連データの条件の組み合わせを考慮するカバレッジです。
この場合は、ここで例に挙げた「代表」「明細」関連よりも、「データ」「マスタ」関連での考慮が大切になるかもしれません。つまり、取り消された「商品」の「受注明細」、取り消されてない「商品」の「受注明細」のようなデータの組み合わせです。


もちろん、これらのカバレッジは組み合わせて考えることになります。ただし、ここで、すべての組み合わせとまではいかなくても多くの組み合わせを準備しようとすると、簡単に手におえない数の組み合わせになってしまいます。そこで、いかに効率のよいデータの組み合わせ方を考えるかということが、データベースカバレッジという考え方の重要な部分になります。
基本的には

  • 機能ごとにわけて考えること
  • 条件に優先順位をつけること
  • 関連テーブルの行数カバレッジでは、優先度の非常に高い条件だけ考慮すること
  • 関連テーブルの条件カバレッジは、とりあえずまとめてしまうこと

が有効な気がしました。
少し考え込んでしまうと、組み合わせの深みに簡単にはまってしまうので、レアケースのひとつのバグを見つけるよりもメジャーケースを確実に動かすということを頭に置きながら簡単な組み合わせを広く用意したほうがよさそうです。


このカバレッジの中に「単一テーブルの行数カバレッジ」を含めなかったのは、単一のデータベースで網羅できないからです。
「受注」テーブルにデータがない状態と「受注」テーブルにデータが一件ある状態と「受注」テーブルにデータが複数ある状態は共存できないからです。データの条件は共存できますが、テーブルやデータベースの条件は共存できません。
そういった意味では、「データベースカバレッジ」ではなく「データカバレッジ」というほうがいいのですが、組み込み系で「データカバレッジ」という言葉が使われているので、ここでは「データベースカバレッジ」と呼んでみました。