エンティティを整理する
今日はちょっと中級者向けの話かもしれません。
ここでいうエンティティとは、データの塊を指します。
例えば、ECサイトの売り物をイメージしてみましょう。
食品を売っているとします。食品には、品名、数量、
1セットの数量または重さ、単価、また、品質保持日数、
アレルギー表示、重さ、大きさ、要冷蔵か、などなど、
多数の項目が1個の商品に紐づいていますね。
これを、「商品エンティティ」とします。
＜商品エンティティ＞
また、そのあとのデータと組み合わせたい場合、
さらに多くのオプション（水準）が付与されます。
たとえば、天気やお客様の年齢、廃棄率を知りたい、
という要求があるとして、その場合、商品エンティティに
廃棄数量を入れる必要がありますし、お客様エンティティ、
販売環境エンティティが必要になるかもしれません。
エンティティのライフサイクル
また、エンティティにはそれぞれライフサイクルがあります。
これも、テストで考慮する大事な要素です。商品なら、入荷に始まり、
出荷あるいは廃棄にいたるまでのイベントです。
このライフサイクルに関しては、エンティティとは別にモデリングをするなどして洗い出し、
エンティティの前提条件として、組み合わせたものを使います。
数が多くなる時は、抽象化を行って、数を減らすこともあります。
これらを、因子と水準、という言い方もできます。
商品という因子に対して、品名、単価、数量などの水準、ととらえることもできます。
また、商品ライフサイクルという因子に対して、入荷日、出荷日、廃棄日、などを水準、
とすることもできます。このときに、実際の取り扱いに沿ったものにする必要があるため、
ライフサイクルの洗い出しには注意が必要になるでしょう。
これは、状態遷移図で書くことが多いです。
エンティティをまとめることで、抽象化を行い、仕様を整理し、
出荷済みの商品に売上日が入るなどのコンフリクトを洗い出し、
条件を整理して、組合せテストを作るなどして活用します。
また、こうしたエンティティを整理したものは使い回しができることが多く、
カバレッジを調整しやすいポイントになります。また、データベースのスキーマについて
だけではなく、ライフサイクルなど、実際の動作・仕様が、因子と条件になることも
ポイントの一つです。
エンティティを整理するには
- マインドマップ
- 伝統のスプレッドシート
- トレーサビリティマトリクス
などのツールがが使えます
これらの説明は、後日に譲ります。
整理したエンティティで、組合せテスト！
組み合わせるアイテムは、以下のものなどがあります。
- CRUD ＋ 3
- タイミング・時系列
- テスト環境（クロスブラウザ、ドメイン、他）
- アカウント種別
- エンティティ同士の組み合わせ
- 操作の組み合わせ
などなど
組合せテストの話を詳しく知りたい方は、
- All Pair法
- 直交表
などを調べてください。有名なものなので、たくさん見つかるでしょう。
（ 説明してしまうと、これだけで1ページでは足りないので )