テスト設計パターン(仮)を考える会 仕様スニペット001

上記について考えてみます。

与えられた仕様スニペットは次の通りです。
例としても挙げられている通り、Aを部署、Bを社員として考えていきます。

1. 2種類のエンティティAとBには親子関係があり、Aが親、Bが子となります。
2. 親Aの数は、全体で0個以上64個以下です。この範囲で追加・削除ができます。
3. 子Bの数は、全体で0個以上128個以下です。この範囲で追加・削除ができます。
4. 親Aは、0個以上16個以下の子Bを持つことができます。
5. 子Bは、必ず1個の親Aを持ちます。
6. 子Bは、いつでも削除することができます。
7. 関連づく子Bが1つ以上存在する限り、親Aを削除することはできません。

分析クラス図を作る

〜以上とか〜以下というキーワードが出てきた時点で、境界値分析を適用することを頭に浮かべます。
ただ、データベースっぽいなと思ったのと、関係を明らかにするために、まずは分析クラス図を作っていきます。

部署と社員の関係

1. 2種類のエンティティAとBには親子関係があり、Aが親、Bが子となります。  

4. 親Aは、0個以上16個以下の子Bを持つことができます。  
5. 子Bは、必ず1個の親Aを持ちます。

上記の仕様から部署と社員の関係を表していきます。
部署と社員が多対多の関係であれば、部署と社員を関係づけるテーブルが必要になりそうですが、
今回は、社員は1つの部署にしか所属が出来ないので、以下のようなクラス図になるはずです。

部署・社員の数

上記だと親Aの数、子Bの数を表現することができないため、仮想のクラス「会社」を作って社員数と部署数を表現します。

2. 親Aの数は、全体で0個以上64個以下です。この範囲で追加・削除ができます。
3. 子Bの数は、全体で0個以上128個以下です。この範囲で追加・削除ができます。

制約

与えられた仕様の中に制約に関する記述がありました。

6. 子Bは、いつでも削除することができます。
7. 関連づく子Bが1つ以上存在する限り、親Aを削除することはできません。

部署と社員の関係 でも示した通り、社員は必ず1つの部署に所属しなければならないので、
部署に社員が関連づいている場合は、「削除」することができません。これは書いてある通りですね。
「追加」については考慮しなくてよいのでしょうか？

仕様には明示されていませんが、部署・社員の数 で示した通り、部署は0であることがあり得るので、
部署が0のとき、社員が追加できないことを確認する必要があることに気づきます。

こうして、分析クラス図を作ると、どの境界をテストしたいのかが明確になるような気がしますよね？

不足しているコンテキストの追加

「部署」と「社員」という例が提示されており、それらを「追加」「削除」できるということから、
社員検索データベースのようなシステムを想定してみます。

  • 社員(名)を検索すると、所属部署を表示できる
  • 部署(名)を検索すると、その部署に所属している社員を一覧表示できる
  • 社員を追加、削除できる
  • 部署を追加、削除できる

これをもとに各クラスの属性と操作を考えてみます。

テストケースを作る

上記をもとにテストケースを作っていきます。

部署に所属する社員を取得

  • 部署に所属する社員が取得できる
    • 部署に所属できる社員の上限(16)、下限(0)
    • 部署(社員)が存在しない(0)

部署を追加

  • 部署を追加できる
    • 部署が存在しない(0)
    • 部署数の上限(追加後に上限の64)
  • 部署の追加に失敗
    • 部署数の上限+1(追加後に65)
    • 部署(名)を指定しない

コンテキスト次第では、上記に加えて、部署の文字列長や、文字種なども確認したいです。

部署を削除

  • 部署を削除できる
    • 部署に所属する社員が存在しない(0)
  • 部署の削除に失敗
    • 部署に所属する社員が存在(1以上)
    • 部署を指定しない
    • 指定した部署が存在しない

所属部署を取得

  • 所属部署が取得できる
    • 社員が存在(1以上)
    • 社員(部署)が存在しない(0)

社員を追加

  • 社員を追加できる
    • 社員数の上限(追加後に上限の128)
    • 部署に関連する社員数の上限(16番目を登録)
    • 部署に関連する社員が存在しない(0)
  • 社員の追加に失敗
    • 部署が存在しない(0)
    • 部署に関連する社員数の上限+1(17番目を登録)
    • 社員総数の上限+1(129番目を登録)
    • 社員を指定しない
    • 部署を指定しない

コンテキスト次第では、上記に加えて、社員の文字列長や、文字種なども確認したいです。

社員を削除

  • 社員を削除できる
    • 社員が存在(1以上)
  • 社員の削除に失敗
    • 社員を指定しない
    • 指定した社員が存在しない

その他、このシステムに複数人が同時でアクセスできるというコンテキストが追加された場合は、
CRUD(Create、Read、Update、Delete)を考慮したテストをしたいと思いました。例えば、以下のようなものです。

  • Aさんが削除中にBさんが取得
  • AさんとBさんが同時に同じデータを削除
  • Aさんが部署を削除中にBさんがその部署に社員を追加する