どしろうと製作所：WebLog

記事のまとめはこちら。


今回も長めです。

■全体像はある程度決まりましたが…

前回まででテスト要求の全体像がある程度決まった状態としましょう。
このテスト要求の全体像の段階では、個々のテストに関する詳細まで明確ではありません。実際にテストを行うためには、具体的なテストケースをつくることができる程度に詳細化する必要があります。

個々のテスト要求をテストケース作成が可能になる程度に詳細化する方法を「テストカタマリー」の記法を用いて紹介します。

全体像の1つのテストカタマリーを取り出して詳細化を行う、というのが本作業の概要となります。



■各テスト要求を分割する（DFDからの例）

既に参照モデルとしてDFDが作成されている場合には、DFDの階層構造とテストの階層構造をあわせて表現することも可能です。
図で示すと次のようになります。


カラオケシステムにおける「予約をする」は、DFDで詳細を示すと以下のようになります。


この内容に対して、テストカタマリーの記法を用いてテストの構造を表現してみましょう。
「予約をする」は、DFDから次の処理を持っていることがわかります。
・予約系操作をする
・予約登録をする/楽曲履歴登録をする
・予約確認表示をする
・予約表示をする
・ランキングを決める

上記の分割を活用してテストカタマリーも分割してみましょう。
テストカタマリーは以前紹介したように「has-a」関係で階層構造を持たせることができますので、テストカタマリーの詳細構造を分割して示すことが出来るようになります。
この分割したテストカタマリーは「サブテストカタマリー」とでも呼ぶことにします。


このように、テスト要求の全体像で示されるテストカタマリーをそれぞれ詳細構造で分割整理することができます。


■各テスト要求を分割する（DFD以外）

DFD以外の場合においても、テストカタマリーを分割してテストの構造を示すことが可能です。
カラオケシステムにおいてカラオケシステムとデータサーバ等が存在するセンターとの通信を行う「センター間インタフェース」を対象として詳細化した例を紹介してみます。


インタフェースをテストする場合に大きく「メッセージ」のテストと「シーケンス」のサブテストカタマリーに分けて確認することができます。
さらに、シーケンスには送信応答型やデータ送信型といった種類、メッセージにもいくつか種類を考えることはできるのですが、カラオケシステムのテストベースには詳細の記述はありませんでしたので省略しております。
ですが、通信に必要なテストはある程度分割して考えることができるのではないでしょうか。

このようにテストを階層的に表現して、テストケースに近づけることが可能です。


■ハイレベルテストケースの説明

has-a関係を用いて分割したテストカタマリーにおいて、ハイレベルテストケースを導出していきます。
ハイレベルテストケースは、テストカタマリーの記法では下部（クラス図のメソッドを記述する部分）に記述を行います。


ここで「ハイレベルテストケース」は抽象度の幅が大きい議論の発生する用語なのですが、この記事では次のサイズを想定しています。
・デシジョンテーブル1つに対応するサイズ
・表でパラメータ一覧を表現できるサイズ
・品質要素の1つを割り当てて確認するサイズ

「予約をする」におけるハイレベルテストケースの例を紹介してみます。
・曲Noで予約登録をする（機能適合性->ふるまい）
・予約をキューから削除する（機能適合性->ふるまい）
・データが多い場合のランキング登録（性能効率性->ボリューム）
・予約同時入力（信頼性->同時入力・処理）

以上の表現で今回ターゲットと使用としているハイレベルテストケースの大きさの感覚を掴んで頂ければ幸いです。
ハイレベルテストケースは、次回紹介するテスト詳細設計で具体化を行います。


■品質要素（仮）を考えつつハイレベルテストケースを導出する

ここで、これらのハイレベルテストケースは前回紹介したような「これをテストしないといけない！」という品質要素（仮）を確認するものであるべきです。

「予約をする」に対して割り当てられた品質要素（仮）をテストカタマリー記法にて示すと以下のようになります。

※こちらでは、品質要素は詳細化しておりません。

これらを各サブカタマリーを含めた何処かで確認する必要があります。
ここで、テストが検討出来ていることを分かりやすくするため、1つマトリクスを用意して確認することにします。

マトリクス（テストカテゴリ検討マトリクスと呼んでいます）は、それぞれの品質要素（仮）をサブテストカタマリーの何処かでテストが行われていることを確認しながら、具体的なハイレベルテストケースを考える作業を行うためのものです。
「予約をする」に対するマトリクスは以下のような内容となります。


このマトリクスの作り方としては以下の手順となります。
1．行見出しにサブカタマリーを割り当て、列見出しに品質要素（仮）を割り当てる


2．必要に応じて品質要素（仮）を階層的に詳細化した表現を行う

　品質要素の表現が「粗い」場合にはより詳細化した表現を割り当てます。
　なお、この詳細化した表現は他のテストでも使う可能性が有りますので、「ブンルイー」の図に追加すると良いでしょう。

3．関連性のある交点部分に色を付けて明確化する、不要な部分はグレイアウト/削除する

　すべてのマトリクスを埋める必要がないことが多いです。また、結果として「確認不要」であったと判断される品質要素（仮）も存在しますので、実際に適用する内容を明らかにしていきます。

4．関連性のある交点部分にて、ハイレベルテストケースを記述する
　交点部分に対して、必要なハイレベルテストケースを記述していきます。
　今回は、最後にハイレベルテストケース記述をしております。しかし、実際の手順としては、ハイレベルテストケースを考えながら、不足が無いかをマトリクスで確認するという手順で進めることも可能です。

この段階で、ブンルイーやサブカタマリーの分類が同時に見直される場合もあります。
本手順にて同時に行っている作業は次の図のようになります。（ちょっと忙しい感じですが…）


検討した複数の結果を行ったり来たりしながら、必要なハイレベルテストケースを出していきます。その活動で同時に「ブンルイー」がフィードバックによりアップデートも行われます。


■必要に応じて詳細の参照モデルを作成する

テストの詳細を検討する際に、詳細情報を含む何らかの設計情報があれば良いですが、情報が存在しない場合もあります。このような場合には設計担当者にインタビューしながら具体的内容を確認しながらテストを検討することも多いです。
ここでテストに向けて設計を明確化した部分につきましては、参照モデルとして残しておくことを推奨します。

例えば「予約をする」においては、予約キューの構造やふるまいや不明確な部分がありましたので、参照モデルを作成してテストの検討に繋げております。



■テストカタマリー詳細図を完成させる

検討した結果を各サブテストカタマリーへ展開を行い、テストカタマリー詳細図を完成させます。マトリクスの行単位（サブテストカタマリー単位）でテストカタマリーへ展開します。


この結果が「予約をする」という1つのテストカタマリーに対するテスト構造を示している図となります。



これでテストすべき内容がハイレベルテストケースまで表現されるようになりました。
次回は、こちらのハイレベルテストケースを具体的なテストケースにまで落とし込む「テスト詳細設計」を行います。