ちょ・す cho-su [動サ五]意味：触れる。さわる。操作する。

参考情報

ちょしてみよう！
テストスイートモデリング～技法と観点を活用しやすくするカタマリー～
下浅 大輔（テクノラボ）

情野 吉紀（JaSST Hokkaido 実行委員会）
水野 昇幸（JaSST Hokkaido 実行委員会）
Powered by IBURI

参考情報メニュー• テスト開発におけるモデリング• テストケースの粒度• テストカタマリーとは• テストカタマリー表記法• キガカリー＆ブンルイー• テスト方針• カタマリー例• 参考リンク

テスト開発におけるモデリングモデリングとはある事象の抽象化されたコンセプトモデル・グラフィカルモデル・あるいは数理モデルを作るプロセスである。
科学の様々な分野において、各々特化した科学的モデリングのための科学的方法、技術、理論が蓄積されている。
科学的モデリングによって事象を構成する様々な要素が単純化され、容易に読み取れるようになる。

ウィキペディアより

モデリング言語
ADL

システムアーキテクチャの記述や表現のためのアーキテクチャ
記述言語

UML

ソフトウエア・システムのための統一モデリング言語

他テストでも使われているモデリング• クラシフィケーションツリー
• フローチャート• 状態遷移• 数式化他

テストスイートモデル
テストケースが持つ情報構造をモデルで表したものを「テストスイートモデル」と本ワークショップ内では呼びます。
今回のワークショップ内では、クラス図に似た表現でモデルを描きます。

カテゴリ/ID
項目名
概要
1、アラーム1-1 アラーム登録・表示
1-1-1 アラーム追加・個別編集、アラーム、スヌーズ
1-1-1_001 アラーム時間設定の確 アラームの時間を設定する
認テストケースXX
テストケースXX
テストケースXX…

1-1-1_002 サウンド設定の確認

サウンド設定をする

実施方法（案）

合否判定基準ケース/設定<<pattern>>
Alert~ Alert in the background : Compatibility~ Unfavorable Stress : Performance efficiency

備考

1．アラーム登録画面を開く
2．設定した時間でアラーム登録がされている
00:00
自動化対象
2．アラーム時間を設定する（時間設定はケース/設定 ことを確認する
07:00
に記載）
12:00
3．「保存」を押す
23:59
1．アラーム登録画面を開く
3．設定したサウンド設定でアラーム登録がさ デフォルト着 自動化対象
2．サウンド設定画面を開く
れていることを確認する
信音を3件確
3．サウンド設定をする※ライブラリ曲に関しては、1-1-9で確認
認概要
実施方法（案）
合否判定基準
4．「保存」を押す

カテゴリ/ID
項目名
ケース/設定備考
1、アラーム1-1-1_003 スヌーズ設定の確認
スヌーズ設定をする
1．アラーム登録画面を開く
3．設定したスヌーズ設定でアラーム登録がさON
自動化対象
1-1 アラーム登録・表示
2．スヌーズのON/OFF設定をする
れていることを確認する
OFF
1-1-1 アラーム追加・個別編集、アラーム、スヌーズ
3．「保存」を押す
1-1-1_001
アラーム時間設定の確 アラームの時間を設定する
1．アラーム登録画面を開く
2．設定した時間でアラーム登録がされている
00:00
自動化対象
1-1-1_004 設定キャンセルの場合
操作中にキャンセルを実施して登録されないこと
1．アラーム登録画面を開く
2．キャンセルが行われ、登録が行われない
任意に福栖パ 自動化対象
認
2．アラーム時間を設定する（時間設定はケース/設定
ことを確認する ターンの実施
07:00
を確認する
2．アラーム時間を設定する
ことを確認するに記載）
12:00
3．「キャンセル」を押すを推奨
3．「保存」を押す
23:59
サウンド設定をする
1．アラーム登録画面を開く
3．設定したサウンド設定でアラーム登録がさデフォルト着 自動化対象
1．アラーム登録画面を開く
3．設定した曜日の繰り返し設定でアラーム登
1-1-2_001_曜 自動化対象
2．サウンド設定画面を開く
信音を3件確
2．繰り返し設定画面を開く
録がされていることを確認する れていることを確認する
日設定表にま3．サウンド設定をする※ライブラリ曲に関しては、1-1-9で確認
認
3．曜日繰り返し設定をする
とめる
4．「保存」を押す
4．「保存」を押す
1-1-1_003 スヌーズ設定の確認
スヌーズ設定をする
1．アラーム登録画面を開く
3．設定したスヌーズ設定でアラーム登録がさON
自動化対象
1-1-3 アラーム追加・個別編集、ラベル
2．スヌーズのON/OFF設定をする
れていることを確認する
OFF
1-1-3_001 ラベル設定の確認
ラベル名称の設定をする
1．アラーム登録画面を開く
3．設定したラベル設定でアラーム登録がされ1-1-3_001_ラ 自動化対象
3．「保存」を押す
2．ラベル設定画面を開くていることを確認する
ベル設定表に1-1-1_004 設定キャンセルの場合 操作中にキャンセルを実施して登録されないこと
1．アラーム登録画面を開く
2．キャンセルが行われ、登録が行われない
任意に福栖パ 自動化対象
3．ラベル設定をする
まとめる
を確認する
2．アラーム時間を設定する
ことを確認する
ターンの実施4．「保存」を押す
3．「キャンセル」を押すを推奨
1-1-4 アラーム編集
1-1-2 アラーム追加・個別編集、曜日繰り返し設定
1-1-4_001 編集選択での表示
選択したアラームが編集画面に移行できることを 1．アラーム一覧画面を開く
2．アラーム編集対象の編集画面が表示され設定の登録は
1-1-2_001
曜日繰り返し設定の確 曜日繰り返しの設定をする
1．アラーム登録画面を開く
3．設定した曜日の繰り返し設定でアラーム登
確認する
2．編集ボタンを押し、アラーム編集対象を選択する
ることを確認1-1-1～1-1-3 1-1-2_001_曜 自動化対象
認
2．繰り返し設定画面を開く
録がされていることを確認するで実施可能
日設定表にま3．曜日繰り返し設定をする
とめる
1-1-5 アラーム削除
4．「保存」を押す
1-1-5_001 アラーム一覧の編集選 アラーム一覧の編集ボタンを押した際に削除で 1．アラーム一覧画面を開く
2．アラーム削除対象が削除されることを確認
自動化対象
択からの削除 1-1-3 アラーム追加・個別編集、ラベル
きることを確認する
2．編集ボタンを押し、アラーム編集対象「－」を押して
1-1-3_001 ラベル設定の確認
ラベル名称の設定をする
1．アラーム登録画面を開く
3．設定したラベル設定でアラーム登録がされ 1-1-3_001_ラ 自動化対象削除を選択する
2．ラベル設定画面を開くていることを確認する
ベル設定表に
1-1-5_002 編集画面からの削除
アラーム編集画面から削除できること
1．アラーム一覧画面を開く
3．アラーム削除対象が削除されることを確認
自動化対象
3．ラベル設定をする
まとめる
2．編集ボタンを押し、アラーム編集対象を選択する
3．編集画面で削除ボタンを押す4．「保存」を押す
1-1-4
アラーム編集
1-1-6 データ登録最大数確認
1-1-4_001
編集選択での表示
選択したアラームが編集画面に移行できることを
1．アラーム一覧画面を開く
2．アラーム編集対象の編集画面が表示され設定の登録は
1-1-6_001 データ登録数最大数確
アラームデータの登録数の最大数を確認する＜アラーム登録＞
3．アラーム登録数が登録されていることを確
1-1-6_001_ 自動化対象
確認する
2．編集ボタンを押し、アラーム編集対象を選択する
ることを確認 データ登録最1-1-1～1-1-3
認
1．アラーム登録画面を開く
認する
で実施可能
2．「保存」を押してアラーム登録をする
大数表にまと
1-1-5 アラーム削除
3、＜アラーム登録＞を繰り返す
める
1-1-5_001 アラーム一覧の編集選 アラーム一覧の編集ボタンを押した際に削除で 1．アラーム一覧画面を開く
2．アラーム削除対象が削除されることを確認
自動化対象
1-1-7 操作応答確認
択からの削除きることを確認する1-1-6_001の手順を実施
2．編集ボタンを押し、アラーム編集対象「－」を押して
1-1-7_001 操作応答時間の確認 操作に対する応答時間を確認する
登録時のレスポンスが遅くなるようなケース 1-1-6_001と削除を選択するがないこと同じ
1-1-5_002 編集画面からの削除
アラーム編集画面から削除できること
1．アラーム一覧画面を開く
3．アラーム削除対象が削除されることを確認
自動化対象
1-1-8 Siriからの操作
2．編集ボタンを押し、アラーム編集対象を選択する
1-1-8_001 Siriによるアラーム追加 Siri経由でアラームを追加できることを確認する 1．Siriを呼び出す
2．設定した時間でアラーム登録がされている
3．編集画面で削除ボタンを押す
2．時間指定でアラームを追加する
ことを確認する
1-1-6 データ登録最大数確認
1-1-8_002 Siriによるアラーム削除
Siri経由でアラームを削除の一覧を出せることを 1．Siriを呼び出す
2．削除対象のアラーム一覧を表示することを
1-1-6_001
データ登録数最大数確 アラームデータの登録数の最大数を確認する＜アラーム登録＞
3．アラーム登録数が登録されていることを確 1-1-6_001_ 自動化対象
一覧呼び出し確認する
2．アラーム削除を呼び出す
確認する
認
1．アラーム登録画面を開く
認する
データ登録最1-1-8_003 Siriによるアラーム削除 Siri経由でアラームを削除の一覧をからラベルで1．Siriを呼び出す
3．指定したラベルのアラーム削除がされてい2．「保存」を押してアラーム登録をする
大数表にまとラベルで削除アラームを削除できることを確認する
2．アラーム削除を呼び出す
ることを確認する
める
3．ラベルで削除対象を指摘する3、＜アラーム登録＞を繰り返す
1-1-7 操作応答確認
1-1-8_004 Siriによるアラーム削除
Siri経由でアラームを削除の一覧をから登録時 1．Siriを呼び出す
3．指定した時間のアラーム削除がされている
1-1-7_001
操作応答時間の確認 操作に対する応答時間を確認する
1-1-6_001の手順を実施
登録時のレスポンスが遅くなるようなケース 1-1-6_001と時間で削除
間でアラームを削除できることを確認する
2．アラーム削除を呼び出す
ことを確認するがないこと同じ
3．時間で削除対象を指摘する
1-1-9 ライブラリ曲データ選択 1-1-8 Siriからの操作
1-1-8_001
Siriによるアラーム追加 Siri経由でアラームを追加できることを確認する
1．Siriを呼び出す
2．設定した時間でアラーム登録がされている
1-1-9_001 着信音/通知音ストアか
着信音/通知音ストアから購入した曲をアラーム
1．アラーム登録画面を開く
4．設定したサウンドの設定でアラーム登録が自動化対象
2．時間指定でアラームを追加する
ことを確認するら登録として登録できることを確認する
2．サウンド設定画面を開くされていることを確認する
1-1-8_002 Siriによるアラーム削除 Siri経由でアラームを削除の一覧を出せることを
1．Siriを呼び出す
2．削除対象のアラーム一覧を表示することを
3．着信音/通知音ストアからダウンロードして設定を一覧呼び出し確認する
2．アラーム削除を呼び出す
確認する
する
1-1-8_003 Siriによるアラーム削除 Siri経由でアラームを削除の一覧をからラベルで1．Siriを呼び出す
3．指定したラベルのアラーム削除がされてい4．「保存」を押す
ラベルで削除アラームを削除できることを確認する
2．アラーム削除を呼び出す
ることを確認する
1-1-9_002 ライブラリ登録された曲 保存されている曲ライブラリから曲をアラームとし
1．アラーム登録画面を開く
4．設定したサウンドの設定でアラーム登録が自動化対象
3．ラベルで削除対象を指摘するから選択て登録できることを確認する
2．サウンド設定画面を開くされていることを確認する
1-1-8_004 Siriによるアラーム削除 Siri経由でアラームを削除の一覧をから登録時
1．Siriを呼び出す
3．指定した時間のアラーム削除がされている
3．ライブラリから曲を選択して設定をする
時間で削除
間でアラームを削除できることを確認する
2．アラーム削除を呼び出す
ことを確認する
4．「保存」を押す
3．時間で削除対象を指摘する
1-1-9 ライブラリ曲データ選択
1-1-9_001 着信音/通知音ストアか 着信音/通知音ストアから購入した曲をアラーム 1．アラーム登録画面を開く
4．設定したサウンドの設定でアラーム登録が
自動化対象
ら登録
として登録できることを確認する
2．サウンド設定画面を開くされていることを確認する
3．着信音/通知音ストアからダウンロードして設定をする
4．「保存」を押す
1-1-9_002 ライブラリ登録された曲 保存されている曲ライブラリから曲をアラームとし 1．アラーム登録画面を開く
4．設定したサウンドの設定でアラーム登録が
自動化対象
から選択
て登録できることを確認する
2．サウンド設定画面を開くされていることを確認する
3．ライブラリから曲を選択して設定をする
4．「保存」を押す

1-1-2 アラーム追加・個別編集、曜日繰り返し設定
1-1-1_002
サウンド設定の確認
1-1-2_001 曜日繰り返し設定の確
曜日繰り返しの設定をする
認<<pattern>>
Resister/Edit/Delete Data
~ Number of data : Performance efficiency~ Operation Response : Performance efficiency<<Resister/Edit/Delete Data>><<Alert>>Alarm+ Confirm each function : Functional suitability~ Number of data : Performance efficiency~ Operation Response : Performance efficiency~ Alert in the background : Performance efficiency~ Unfavorable Stress : Performance efficiency+ Cooperate with other Apps : Compatibility

Register/Display Alarm+ Confirm each function : Functional suitability~ Number of data : Performance efficiency~ Operation Response : Performance efficiency+ Cooperate with other Apps : Compatibility+ Register Alarm() : Confirm each function+ Edit Alarm() : Confirm each function+ Delete Alarm() : Confirm each function+ Check max registration data() : Operation Responce+ Operate from Siri() : Cooperate with other Apps

Notify Alarm+ Confirm each function : Functional suitability~ Alert in the background : Compatibility~ Unfavorable Stress : Performance efficiency+ Confirm Alerm() : Confirm each function+ Confirm Snooze() : Confirm each function+ Check with other Apps() : Alert in the background+ Check with Stress() : Unfavorable Stressテストスイートモデル「テストスイートモデル」はテストケースが持つ情報の構造をモデルで表現したものです。※独自の用語です。
「テストスイートアーキテクチャ」という、テストシステムアーキテクチャ」と対となる概念として、以下の論文にて紹介されております。
＜テストスイートアーキテクチャについて記載している論文＞
Y.Nishi, “Combinatorial Test Architecture Design Using Viewpoint diagram”,
Workshop on Metrics and Standards for Software Testing (MaSST)
Y.Nishi, “Design principles in Test Suite Architecture,”International Workshop on Software Test Architecture (InSTA 2015)
上記テストスイートアーキテクチャを参考に、テストスイートモデルという独自の概念・名前を使用しております。

テストにおけるモデリングアプローチUTP

UML Testing Profile※Unit Test Patternではありません。

NGT/VSTeP

NGT: Notation for Generic Testing
VSTeP: Viewpoint-based Software Test Engineering
Process※電気通信大学にしさんが提案。テスト設計手法がVSTePで、その手法内で使用している記法がNGTとなります。

テストケースの粒度レベルテストケース
高位レベルテストケース（high level test case）
具体的な（実行レベルの）入力値や予測結果を使わないテストケース。論理演算子は使用するが、値のインスタンスは未定義や使用不可であるといった状態にある。

論理的テストケース（logical test case）
high level test caseを参照のこと。

抽象的テストケース（abstract test case）
high level test caseを参照のこと。

低位レベルテストケース（low level test case）
入力データと期待結果が具体的（実装レベル）なテストケース。高位レベルのテストケースからの論理演
算子は、論理演算子に相当する実際の値に置き換えられる。

具体的テストケース（concrete test case）
low level test caseを参照のこと。

「JSTQB 用語集」より

具体的テストケースと論理的テストケース
具体的テストケース
テスト担当者がテストケース（すべてのデータ要件を含む）を実行し結果を検証するために必要な特定の情報と手順のすべてを提供する。

論理的テストケース（ロジカルテストケース）
テスト対象とすべきものに関するガイドラインを提供し、テスト実行時に実データや手続きさえも変更することを可能にする。

「JSTQB TAシラバス」より

テストケースの粒度：仮に４つの段階を紹介
比較的抽象的なテストケース粒度では…？

抽象化

レベル１：処理だけを特定したテストケース（例）購入計算処理のロジック/入出力を確認する

？

購入計算
処理

？

レベル２：入出力のパラメータ項目まで表現したテストケース（例）購入種別と入場時間から計算結果を確認する
購入種別
入場時間

購入計算
処理
参考：レベル３
テストケース

計算結果
入場時間

購入種別（通常料金）

通常料金
10:00:0017:59:59

おとな

1000
円

こども

500
円

夜間料金
18:00:0019:59:59

購入不可時間00:00:0009:59:59
購入不可時間20:00:0023:59:59

購入種別（夜間料金）

おとな

購入
不可

こども

1300
円
800
円

具体化

テストケースの粒度：仮に４つの段階を紹介
より詳細なテストケースでは…
レベル３：同値クラスを用いて組合せ論理条件（ルール）まで表現したテストケース（例）購入種別：おとな、入場時間：通常料金時間 で結果1000円
入場時間

購入種別（通常料金）

通常料金
10:00:0017:59:59

おとな

1000
円

こども

500
円

夜間料金
18:00:0019:59:59

購入不可時間00:00:0009:59:59
購入不可時間20:00:0023:59:59

購入種別（夜間料金）

おとな

購入
不可

こども

1300
円
800
円

レベル４：実際の値まで具体化したテストケース（例）
CFDとDTで関係性を図示入力条件
1 購入種別1 おとな
2 こども
2 入場時間
1 購入不可時間
00:00:00-09:59:59
2 通常料金時間
10:00:00-17:59:59
3 夜間料金時間
18:00:00-19:59:59
4 購入不可時間
20:00:00-23:59:59
期待結果
1 購入不可2 1300円
3 1000円
4 800円5 500円

#1 #2 #3 #4 #5 #6--○ ○ - - - ○ ○

○

-

-

-

-

-

-

-

○

-

○

-

-

-

-

○

-

○

-

○

-

-

-

-

#1 #2 #3 #4 #5 #6○ ○ - - - - - - ○ - - - ○ - - - - - - - ○- - - - ○ -（例）購入種別：おとな、入場時間：10:00:00 で結果1000円
・#3-1 購入種別：おとな、入場時間：10:00:00 で結果1000円
・#3-1 購入種別：おとな、入場時間：15:00:00 で結果1000円
・#4-1 購入種別：おとな、入場時間：19:00:00 で結果1300円
…

具体的な
値を設定

テストケースの粒度：仮に４つの段階を紹介
全体を示すとこの通りになります。
抽象化

レベル１：処理だけを特定したテストケース（例）購入計算処理を確認する

？

購入計算
処理

？

レベル２：入出力のパラメータ項目まで表現したテストケース（例）購入種別と時間から計算結果を確認する
購入種別
入場時間

購入計算
処理

計算結果

具体化

レベル３：同値クラスを用いて組合せ論理条件（ルール）まで表現したテストケース（例）購入種別：おとな、入場時間：通常料金時間 で結果1000円
入場時間

購入種別（通常料金）

通常料金
10:00:0017:59:59

おとな

1000
円

こども

500
円

夜間料金
18:00:0019:59:59

購入不可時間00:00:0009:59:59
購入不可時間20:00:0023:59:59

購入種別（夜間料金）

おとな

購入
不可

こども

1300
円
800
円

（例）
CFDで関係性を図示してデシジョンテーブルで表現することができる

レベル４：実際の値まで具体化したテストケース（例）購入種別：おとな、入場時間：10:00:00
・#3-1 購入種別：おとな、入場時間：10:00:00
・#3-1 購入種別：おとな、入場時間：15:00:00
・#4-1 購入種別：おとな、入場時間：19:00:00…

入力条件
1 購入種別1 おとな
2 こども
2 入場時間
1 購入不可時間
00:00:00-09:59:59
2 通常料金時間
10:00:00-17:59:59
3 夜間料金時間
18:00:00-19:59:59
4 購入不可時間
20:00:00-23:59:59
期待結果
1 購入不可2 1300円
3 1000円
4 800円5 500円

#1 #2 #3 #4 #5 #6--○ ○ - - - ○ ○

○

-

-

-

-

-

-

○

-

○

-

-

-

-

○

-

○

-

○

-

-

-

-

#1 #2 #3 #4 #5 #6○ ○ - - - - - ○ - - - ○ - - - - - - - ○- - - - ○ -で結果1000円
で結果1000円
で結果1000円
で結果1300円

-

具体的な
値を設定

各レベルの例
レベル１：購入計算処理のロジック/
入出力を確認する
レベル２：購入種別と時間から計算結果を確認する
レベル３：購入種別：おとな、入場時間：通常料金時間で結果1000円
レベル４：購入種別：おとな、入場時間：10:00:00
で結果1000円

テストケースの粒度と呼び名＠ISTQB
ISTQB/JSTQBでの呼び名を整理したものです。
？

購入計算
処理

※用語集ではハイレベル=ロジカルですが、AL TAの説明を考慮？

レベル２：入出力のパラメータ項目まで表現したテストケース（例）購入種別と時間から計算結果を確認する
購入種別
入場時間

購入計算
処理

ハイレベル
テストケースは
こちら

計算結果

具体化

レベル３：同値クラスを用いて組合せ論理条件（ルール）まで表現したテストケース（例）購入種別：おとな、入場時間：通常料金時間 で結果1000円
入場時間

購入種別（通常料金）

通常料金
10:00:0017:59:59

おとな

1000
円

こども

500
円

夜間料金
18:00:0019:59:59

購入不可時間00:00:0009:59:59
購入不可時間20:00:0023:59:59

購入種別（夜間料金）

おとな

購入
不可

ロジカルテストケースは
こちら

抽象化

レベル１：処理だけを特定したテストケース（例）購入計算処理を確認する

こども

1300
円
800
円

（例）
CFDで関係性を図示してデシジョンテーブルで表現することができる

レベル４：実際の値まで具体化したテストケース（例）購入種別：おとな、入場時間：10:00:00
・#3-1 購入種別：おとな、入場時間：10:00:00
・#3-1 購入種別：おとな、入場時間：15:00:00
・#4-1 購入種別：おとな、入場時間：19:00:00…

入力条件
1 購入種別1 おとな
2 こども
2 入場時間
1 購入不可時間
00:00:00-09:59:59
2 通常料金時間
10:00:00-17:59:59
3 夜間料金時間
18:00:00-19:59:59
4 購入不可時間
20:00:00-23:59:59
期待結果
1 購入不可2 1300円
3 1000円
4 800円5 500円

論理的
テストケース

#1 #2 #3 #4 #5 #6--○ ○ - - - ○ ○

○

-

-

-

-

-

-

-

○

-

○

-

-

-

-

○

-

○

-

○

-

-

-

-

高位レベル
テストケース

#1 #2 #3 #4 #5 #6○ ○ - - - - - ○ - - - ○ - - - - - - - ○- - - - ○ -で結果1000円
で結果1000円
で結果1000円
で結果1300円

具体的な
値を設定

低位レベル
テストケース

具体的
テストケーステストカタマリーとは※注：本資料に出てくる以下の用語は独自に定義したものです
テストカタマリー/カタマリー
キガカリー、ブンルイー

テストカタマリーの概要
テストカタマリーとは• STUDIO IBURIという謎の団体が打ち上げた記法• テストカタマリー：テストケースの集合体（塊）を表現したもの• テスト観点とテストカテゴリ、抽象的なテストケースを
クラス図を利用して表現する記法特徴• UTPとVSTePの中間くらいのモデリング• テストケースの概要の整理がメイン• UMLモデリングツールが使えればそれでお手軽に描ける

テストカタマリーのアイデア
テストカタマリーのアイデアの原型

テストを行うべき
なんとなくの領域

テストカタマリーのアイデア
テストカタマリーのアイデアの原型
テストスコープテストカタマリーのアイデア
テストカタマリーのアイデアの原型
分割されたテストスコープ

テストカタマリーのアイデア
優先順位を決定する
テストカタマリーのアイデアの原型
分割されたテストスコープ

High priority
Low priority

テストカタマリーのアイデア
テストカタマリーのアイデアの原型
分割されたテストスコープ

分割した
テストスコープの一部

テストの詳細設計
・Test Case１
・Test Case２…

テストカタマリーの概要
一連のテストケースを持つ
分割されたテストスコープを「テストカタマリー」と定義。
詳細

テストスコープの一部=テストカタマリー塊・テストケース１
・テストケース２…
テストケーステストカタマリー表記法

テストカタマリー表記法：エンティティ表現
クラス図の記法を利用したテストカタマリー図の記法について概要を紹介する。
<<ステレオタイプ>>

フィールド

クラス図

カタマリー

クラス名

クラス名を記述する。
継承もとの親クラスの情報を追加で表記することもある。
ステレオタイプを記述することで、クラスを種類ごとに分類したり、目印をつける。

カタマリー名を記述する。
ステレオタイプを使うことでカタマリーをパターンで分類することが出来る。

クラスが持っている情報群を表している。
型の指定と可視性を設定できる。

カタマリーが確認したい品質特性や気がかり、テスト
ケースの目的等（キガカリーと呼ぶ）を記載する。

可視性 名前 : 型 = 初期値 { 制約条件 }可視性 具体的なキガカリー：キガカリーの分類

クラスができることが書かれている。
型の指定と可視性を設定できる。

カタマリーが持つ抽象的なテストケースがを記載する。
対応したいロジカルテストケース（抽象的なテスト
ケース）に対し、確認したいキガカリーを割り当てる。
網羅基準ともなるテスト方針をあわせて定義可能。

可視性 名前 ( 引数の名前 : 引数の型 ) : 戻り値の型

可視性 ロジカルテストケース (テスト方針) : キガカリー

クラス名

属性リスト
操作リスト

属性リスト

操作リスト

テストカタマリー表記法：可視性の表記
クラス図のとの違い
記号

可視性の種別

クラス図

カタマリー

+

public

どこからでも利用可能

そのカタマリー固有のモノ#

Protected

当該クラス内とサブクラスから利用
可能

（未使用）

-

private当該クラス内からのみ利用可能

下位のカタマリーを踏襲したモノ~

package

当該クラス内と、同一パッケージのクラスから利用可能

上位のカタマリーから具現化したモノテストカタマリー表記法：関連の表記
クラス図のとの違い
関係

線形

クラス図

カタマリー

関連
（association）

オブジェクト間の関連(あるいは関係)を表す。

（未使用）

集約
（aggregation）「部分ー全体」の関係を表す。ひし形の方が全体を表わす。

カタマリー同士の関連線をつないでいる。機能の関連や実施手順の使用に対して関連するものを表す。

コンポジション
（composition）「部分ー全体」の関係を表す。ひし形の方が全体を表わす。部分が泡ラスオブジェクトが複数の全体を表すオブジェクトに共有されることがない。

（未使用）

依存
（dependency）

クラスのインスタンス間に利用関係がある事を表す。 （未使用）
矢印の元側のクラスが利用者、先側のクラスが機
能提供者。

汎化
（generalization）

継承関係を表す。異なるクラス間に類似性の性まとめた抽象クラスからの関連を表す。

パターンの継承を表す。

実現（realization）

クラスが実現するうえで必要な共通操作のみを定義したインターフェースクラスとの関連を表す。

（未使用）

UMLクラス図と共通箇所
テストカタマリーはUMLツール（astah*やEnterprise Architect）のクラス図を使用してテストスイートモデルを表現できるように検討しております。
ただし、UML直接の表現とは異なる部分があります。
UMLと共通の部分：
クラス間の関連（集約、汎化など）をそのまま使用できるようにしています。
テストケースのグループ単位の関連性を表現しやすくしております。
<<データ登録・編集・削除>>
アラーム+ 各機能確認 : 機能適合性~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性+ バックグラウンド通知 : 互換性+ 想定以上の負荷 : 性能効率性+ リソース連携 : 互換性->相互運用性<<pattern>>

データ登録・編集・削除~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性

集約（has-a）の例

汎化（is-a）の例

アラーム登録・表示+ 各機能確認 : 機能適合性~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性+ リソース連携 : 互換性->相互運用性+ アラーム登録(結果網羅) : ふるまい
+ アラーム編集(結果網羅) : ふるまい
+ アラーム削除(結果網羅) : ふるまい
+ データ登録最大確認(性能評価) : 登録データ数+ 操作応答確認(性能評価) : 操作レスポンス+ Siriからの操作(結果網羅) : リソース連携

アラーム通知+ 各機能確認 : 機能適合性+ バックグラウンド通知 : 互換性+ 負荷時バックグラウンド動作 : 性能効率性<<データ登録・編集・削除>>
世界時計+ アラーム動作確認(結果網羅) : ふるまい
+ スヌーズ処理確認(結果網羅) : ふるまい
+ 他アプリ動作時(通常動作) : バックグラウンド通知+ 負荷時確認(性能評価) : 負荷時バックグラウンド動作+ 各機能確認 : 機能適合性~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性<<データ登録・編集・削除>>
アラーム+ 各機能確認 : 機能適合性~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性+ バックグラウンド通知 : 互換性+ 想定以上の負荷 : 性能効率性+ リソース連携 : 互換性->相互運用性

テストカタマリー（UMLクラス図と共通箇所）
テストカタマリーはUMLツール（astah*やEnterprise Architect）のクラス図を使用してテストスイートモデルを表現できるように検討しております。
ただし、UML直接の表現とは異なる部分があります。
１．UMLと共通の部分：
クラス間の関連（集約、汎化など）をそのまま使用できるようにしています。
テストケースのグループ単位の関連性を表現しやすくしております。
<<データ登録・編集・削除>>
アラーム+ 各機能確認 : 機能適合性~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性+ バックグラウンド通知 : 互換性+ 想定以上の負荷 : 性能効率性+ リソース連携 : 互換性->相互運用性<<pattern>>

データ登録・編集・削除~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性

集約（has-a）の例

汎化（is-a）の例

アラーム登録・表示+ 各機能確認 : 機能適合性~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性+ リソース連携 : 互換性->相互運用性+ アラーム登録(結果網羅) : ふるまい
+ アラーム編集(結果網羅) : ふるまい
+ アラーム削除(結果網羅) : ふるまい
+ データ登録最大確認(性能評価) : 登録データ数+ 操作応答確認(性能評価) : 操作レスポンス+ Siriからの操作(結果網羅) : リソース連携

アラーム通知+ 各機能確認 : 機能適合性+ バックグラウンド通知 : 互換性+ 負荷時バックグラウンド動作 : 性能効率性<<データ登録・編集・削除>>
世界時計+ アラーム動作確認(結果網羅) : ふるまい
+ スヌーズ処理確認(結果網羅) : ふるまい
+ 他アプリ動作時(通常動作) : バックグラウンド通知+ 負荷時確認(性能評価) : 負荷時バックグラウンド動作+ 各機能確認 : 機能適合性~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性<<データ登録・編集・削除>>
アラーム+ 各機能確認 : 機能適合性~ 登録データ数 : 性能効率性~ 操作レスポンス : 性能効率性+ バックグラウンド通知 : 互換性+ 想定以上の負荷 : 性能効率性+ リソース連携 : 互換性->相互運用性

テストカタマリーの構造• テストカタマリーは複数のキガカリーを持つ• ロジカルテストケースは１つのキガカリーと対応<<ステレオタイプ>>

カタマリー名+ キガカリー1: キガカリーの分類- キガカリー2: キガカリーの分類~ キガカリー3: キガカリーの分類+ ロジカルテストケース1(テスト方針) : キガカリー1- ロジカルテストケース2(テスト方針) : キガカリー2~ ロジカルテストケース3(テスト方針) : キガカリー3

キガカリー
ロジカルテストケース（⁼抽象的なテストケース）with キガカリー
おさらい：カタマリーで確認したい品質特性や気がかり、
テストケースの目的等をキガカリーと呼ぶ

テストカタマリーの一例
・「テストカタマリー」では1つの箱の中に10、20ものテストケースを持たせたものを表現可能
アラーム登録・表示+ 各機能確認 : 機能適合性+ 登録データ数 : 性能効率性+ 操作レスポンス : 性能効率性+ リソース連携 : 互換性->相互運用性+ アラーム追加・個別編集、アラーム・スヌーズ() : 各機能確認+ アラーム追加・個別編集、曜日繰り返し設定() : 各機能確認+ アラーム追加・個別編集、ラベル() : 各機能確認+ アラーム編集() : 各機能確認+ アラーム削除() : 各機能確認+ データ登録最大数確認() : 登録データ数+ 操作応答確認() : 操作レスポンス+ Siriからの操作() : リソース連携+ ライブラリ曲データ選択() : リソース連携

例：テストケース17件＋パラメータ組合せに対応

カテゴリ/ID
項目名
概要
1、アラーム1-1 アラーム登録・表示
1-1-1 アラーム追加・個別編集、アラーム、スヌーズ
1-1-1_001 アラーム時間設定の確 アラームの時間を設定する
認実施方法（案）

合否判定基準ケース/設定備考

1．アラーム登録画面を開く
2．設定した時間でアラーム登録がされている
00:00
自動化対象
2．アラーム時間を設定する（時間設定はケース/設定 ことを確認する
07:00
に記載）
12:00
3．「保存」を押す
23:59
1-1-1_002 サウンド設定の確認
サウンド設定をする
1．アラーム登録画面を開く
3．設定したサウンド設定でアラーム登録がさ デフォルト着 自動化対象
2．サウンド設定画面を開く
れていることを確認する
信音を3件確
3．サウンド設定をする※ライブラリ曲に関しては、1-1-9で確認
認
4．「保存」を押す
1-1-1_003 スヌーズ設定の確認
スヌーズ設定をする
1．アラーム登録画面を開く
3．設定したスヌーズ設定でアラーム登録がさON
自動化対象
2．スヌーズのON/OFF設定をする
れていることを確認する
OFF
3．「保存」を押す
1-1-1_004 設定キャンセルの場合 操作中にキャンセルを実施して登録されないこと 1．アラーム登録画面を開く
2．キャンセルが行われ、登録が行われない 任意に福栖パ 自動化対象を確認する
2．アラーム時間を設定する
ことを確認する
ターンの実施3．「キャンセル」を押すを推奨
1-1-2 アラーム追加・個別編集、曜日繰り返し設定
1-1-2_001 曜日繰り返し設定の確 曜日繰り返しの設定をする
1．アラーム登録画面を開く
3．設定した曜日の繰り返し設定でアラーム登 1-1-2_001_曜 自動化対象
認
2．繰り返し設定画面を開く
録がされていることを確認する
日設定表にま3．曜日繰り返し設定をする
とめる
4．「保存」を押す
1-1-3 アラーム追加・個別編集、ラベル
1-1-3_001 ラベル設定の確認
ラベル名称の設定をする
1．アラーム登録画面を開く
3．設定したラベル設定でアラーム登録がされ 1-1-3_001_ラ 自動化対象
2．ラベル設定画面を開くていることを確認する
ベル設定表に
3．ラベル設定をする
まとめる
4．「保存」を押す
1-1-4 アラーム編集
1-1-4_001 編集選択での表示
選択したアラームが編集画面に移行できることを 1．アラーム一覧画面を開く
2．アラーム編集対象の編集画面が表示され設定の登録は確認する
2．編集ボタンを押し、アラーム編集対象を選択する ることを確認
1-1-1～1-1-3
で実施可能
1-1-5 アラーム削除
1-1-5_001 アラーム一覧の編集選 アラーム一覧の編集ボタンを押した際に削除で 1．アラーム一覧画面を開く
2．アラーム削除対象が削除されることを確認
自動化対象
択からの削除きることを確認する
2．編集ボタンを押し、アラーム編集対象「－」を押して削除を選択する
1-1-5_002 編集画面からの削除
アラーム編集画面から削除できること
1．アラーム一覧画面を開く
3．アラーム削除対象が削除されることを確認
自動化対象
2．編集ボタンを押し、アラーム編集対象を選択する
3．編集画面で削除ボタンを押す
1-1-6 データ登録最大数確認
1-1-6_001 データ登録数最大数確 アラームデータの登録数の最大数を確認する＜アラーム登録＞
3．アラーム登録数が登録されていることを確 1-1-6_001_ 自動化対象
認
1．アラーム登録画面を開く
認する
データ登録最2．「保存」を押してアラーム登録をする
大数表にまと3、＜アラーム登録＞を繰り返す
める
1-1-7 操作応答確認
1-1-7_001 操作応答時間の確認 操作に対する応答時間を確認する
1-1-6_001の手順を実施
登録時のレスポンスが遅くなるようなケース 1-1-6_001とがないこと同じ
1-1-8 Siriからの操作
1-1-8_001 Siriによるアラーム追加 Siri経由でアラームを追加できることを確認する 1．Siriを呼び出す
2．設定した時間でアラーム登録がされている
2．時間指定でアラームを追加する
ことを確認する
1-1-8_002 Siriによるアラーム削除 Siri経由でアラームを削除の一覧を出せることを 1．Siriを呼び出す
2．削除対象のアラーム一覧を表示することを一覧呼び出し確認する
2．アラーム削除を呼び出す
確認する
1-1-8_003 Siriによるアラーム削除 Siri経由でアラームを削除の一覧をからラベルで 1．Siriを呼び出す
3．指定したラベルのアラーム削除がされていラベルで削除アラームを削除できることを確認する
2．アラーム削除を呼び出す
ることを確認する
3．ラベルで削除対象を指摘する
1-1-8_004 Siriによるアラーム削除 Siri経由でアラームを削除の一覧をから登録時 1．Siriを呼び出す
3．指定した時間のアラーム削除がされている
時間で削除
間でアラームを削除できることを確認する
2．アラーム削除を呼び出す
ことを確認する
3．時間で削除対象を指摘する
1-1-9 ライブラリ曲データ選択
1-1-9_001 着信音/通知音ストアか 着信音/通知音ストアから購入した曲をアラーム 1．アラーム登録画面を開く
4．設定したサウンドの設定でアラーム登録が
自動化対象
ら登録
として登録できることを確認する
2．サウンド設定画面を開くされていることを確認する
3．着信音/通知音ストアからダウンロードして設定をする
4．「保存」を押す
1-1-9_002 ライブラリ登録された曲 保存されている曲ライブラリから曲をアラームとし 1．アラーム登録画面を開く
4．設定したサウンドの設定でアラーム登録が
自動化対象
から選択
て登録できることを確認する
2．サウンド設定画面を開くされていることを確認する
3．ライブラリから曲を選択して設定をする
4．「保存」を押す

カタマリーの表現方法の例
カタマリーには、パターン化した抽象的なカタマリーとパターンを具現化した具象的なカタマリーがある。さらに具象化したカタマリー
を細分化することができる。
制約有機能~ 機能適合 : 機能適合性~ 性能効率 : 性能効率性~ 信頼性 : 信頼性<<カタマリーパターン>>
カタマリー名<<制約有機能>>
映像再生+ キガカリー1: キガカリーの分類- キガカリー2: キガカリーの分類~ キガカリー3: キガカリーの分類~ 機能適合 : 機能適合性~ 性能効率 : 性能効率性- 使用性 : 使用性- 単機能を操作する(結果網羅) : 機能適合性- 単機能を操作する(機能有効条件) :: 機能適合性：+ ロジカルテストケース1(テスト方針) : キガカリー1- ロジカルテストケース2(テスト方針) : キガカリー2~ ロジカルテストケース3(テスト方針) : キガカリー3

テロップ表示~ 機能適合 : 機能適合性+ 使用性 : 使用性+ 単機能を操作する(結果網羅) : 機能適合性+ 単機能を操作する(機能有効条件) : 機能適合性+ 歌詞を表示する(見やすさ) : 使用性

映像再生~ 機能適合 : 機能適合性+ 使用性 : 使用性+ 単機能を操作する(結果網羅) : 機能適合性+ テーマ映像を再生する(ランダム表示) : 使用性キガカリー＆ブンルイー※キガカリー、ブンルイーは独自用語ですキガカリーについて※キガカリーは独自用語です• テストケースの持つ目的（意図）を明示する。
• テストの範囲を決めるため、抜けの確認に役立つ。
• 知識の蓄積やパターン化もできる。
• 「テスト観点（の、とある抽象度範囲）」 もしくは「テストカテゴリ」と同等と考えてよい。
※実例<<ステレオタイプ>>

カタマリー名+ キガカリー1: キガカリーの分類- キガカリー2: キガカリーの分類~ キガカリー3: キガカリーの分類+ ロジカルテストケース1(テスト方針) : キガカリー1- ロジカルテストケース2(テスト方針) : キガカリー2~ ロジカルテストケース3(テスト方針) : キガカリー3

アラーム登録・表示+ 各機能確認 : 機能適合性+ 登録データ数 : 性能効率性+ 操作レスポンス : 性能効率性+ リソース連携 : 互換性->相互運用性+ アラーム追加・個別編集、アラーム・スヌーズ() : 各機能確認+ アラーム追加・個別編集、曜日繰り返し設定() : 各機能確認+ アラーム追加・個別編集、ラベル() : 各機能確認+ アラーム編集() : 各機能確認+ アラーム削除() : 各機能確認+ データ登録最大数確認() : 登録データ数+ 操作応答確認() : 操作レスポンス+ Siriからの操作() : リソース連携+ ライブラリ曲データ選択() : リソース連携

キガカリーの概念について• テストケース/テストケースのグループは目的（意図）を持つ。
• 目的のないテストケースは意味がない。

• テスト技法で導出されたテストケースも目的を持っている。

• 同値クラス：結果に影響する入力値を確認する。
• 境界値：不具合に繋がりやすい同値設定の境界部分を確認する。
• DT/ドメイン分析：関係のある複数パラメータ組合せを確認する。

• 目的を実現するテストケースを明確にしたい。

※某テスト観点では、テストケースに割り当てる方法は明示していない。

• テストカタマリーではテストケースのグループが１つの目的に対応するように表現する。
※これはある意味仮説的、複数の目的に対応する場合もあるかもしれない。

別の言葉で表してみる
キガカリーを別の言葉で表すと、次のようなものとなりそう。
• 保証すべきもののキーワード• 確認したいもの• テストの関心ごと• テストケースの目的/意図• 気がかり事項/リスク≒ テスト観点上のとある抽象レベル≒ テストカテゴリ

テスト観点の範囲に対する概念MAP
抽象…

品質特性など・機能適合性・性能効率性etc

動作環境

ﾌﾟﾗｯﾄﾌｫｰﾑ

OS

ﾈｯﾄﾜｰｸﾊｰﾄﾞｳｪｱ

…

三角形

ﾃﾞｰﾀ操作

成立

正三角形

直線

二等辺△

不成立

不等辺△

音声操作

テスト観点
（テストカテゴリ）
キガカリー
ブンルイー

具体

・・・

具体的な
パラメータ
同値クラス
単位の項目

他手法との関連
ゆもつよメソッド
機能名

機能小分類

検索
再生

テストカテゴリ
データ操作

音声操作

キュー

1件

1件

データ送り

2件

-

1件再生

1件

5件

…

データ送り × データ操作
１件再生 × データ操作
１件再生 × 音声操作

・・・

キガカリーに相当

VSTeP / NGT ※テスト観点に基づくテスト開発方法論VSTePの概要 より引用
抽象

…

動作環境

ﾌﾟﾗｯﾄﾌｫｰﾑ

OS

ﾈｯﾄﾜｰｸﾊｰﾄﾞｳｪｱ

※どのテストケースでテスト観点をカバーしているか関連付けたい⇒対応する観点が「キガカリー」相当

…

三角形

具体

・・・

テストケース
テストケース
テストケース
成立

正三角形

直線

二等辺△

不成立

不等辺△

・・・

他手法との関連※把握・理解している内容で説明
機能名 機能小分類
検索
キュー・ゆもつよメソッド：
データ送り
テストケースはいずれかの再生
1件再生
テストカテゴリに属する。
・・・
テストカテゴリが、そのテストケースの目的（意図）を示す。

テストカテゴリ
データ操作

音声操作

1件

1件

2件

-

1件

5件

・VSTeP：テストケースの目的（意図）をモデリングしている。
ただし、テストケースに割り当てる方法を明示はしていない。
抽象

…

動作環境

ﾌﾟﾗｯﾄﾌｫｰﾑ

OS

ﾈｯﾄﾜｰｸﾊｰﾄﾞｳｪｱ

…

三角形

具体

・・・
成立

正三角形

直線

二等辺△

不成立

不等辺△

・・・

…

ブンルイー
キガカリーは蓄積することで役立つ情報となります。
整理して全体を示したものを「ブンルイー」と呼ぶ。 ※独自用語です
わざと、意地悪人による要因安全性テスト

無意識
検討方法（メモ）
HW故障

機能テスト
HWの異常、故障による要因

ノイズ、環境構造テスト/ユーザ提供の状態確認
温度上がりすぎのケース

機器性能評価/スペック評価

安全性テスト（機器及びユーザ）
温度が上がらないエラー

ユーザビリティテスト

機能テストを意味する（テストレベルのFunction Testと分けている）

参考：テストタイプ一覧

水が無い、少ない場合の沸騰ボタン押下取説・シナリオテスト

Facility Testing

沸騰中に蓋を開けた場合の加熱停止

連続テスト

状態×ボタンを押しっぱなしにした場合の振る舞い確認（All Pair）
蓋状態が獲得できない時の起動時処理確認

機能、状態、環境組合せ（無側の確認）

仕様->タイマ×機能テスト

タイミング、状態信頼性テスト

ボリュームテスト

Volume Testing

ストレステストStress Testing

仕様->給湯×機能テスト
給湯する

仕様->温度制御×機能テスト
詳細分割（メモ）98℃

仕様->ロック/解除×機能テスト

90℃
保温する

仕様->保温モード×機能テスト

適切さ

60℃

メイン機能、サブ/サポート機能、デバイス機能の3層で検討

モード切替

ボタン押下時の有則組合せ
沸騰させる

ユーザビリティテスト

給湯ロックを解除する

操作

カルキ抜き
ふるまいが目的に適合していること

温度制御

高温

相互運用性

時間を計る

各モード保温タイマ使用を止める

セキュリティテスト

セキュリティ

温度を見る

ふるまい

機能適合性

節約

同時入力・処理

途中取消

信頼性

処理中異常

ミルク

メイン機能

水位を確認する

Security Testing

Ver.170125

沸騰

機能性

給湯ロックを行う

Usability Testing

アイドル

正確性

カルキ抜きを行う- 結果網羅状態遷移×構造テストで確認

状態網羅

ボタン押下時の有則組合せ
給湯する

ユーザビリティテスト
水が満水を知る

性能/パフォーマンステスト
ストレージテスト

Storage Testing

フォールトレランス

操作のしやすさ

互換性/コンパチビリティテスト

Myersのシステムテストカテゴリ

ボタン入力の論理判定条件網羅

復元力

評価基準

保温モード
機能テスト

サブ機能

主観評価、アンケート

理解のしやすさ

満足度
方法
想定ユーザテスト

テスコン'13
テストタイプベース

使用性

沸騰機能

温度判定のロジック確認、パターンによる妥当性検証

容量

学習のしやすさ
操作パネル：入力

機器性能評価/スペック評価

タイマ機能
節電タイマ機能

各テストフレーム（システム/ユーザ）

条件網羅

沸騰ボタン

条件網羅

便利機能

復旧処理

利用時有効性

Serviceability Testing

分析のしやすさ

条件網羅

想定シーン

条件網羅

性能効率性

ブザー

条件網羅

ボリューム

給湯

- 性能評価保温時間
沸騰、保温の繰り返し

連続操作

保温性能

テストのしやすさ

セキュリティ

温度推移

機器性能評価/スペック評価

タイマも使用する

範囲

メモリ

温度制御

確認項目

製品

性能効率性

サーミスタ水温検出
精度

CPU

メモ

モード遷移時間

狙いどころ

使用環境
外部環境

インストールのしやすさ

静的分析（外部構成）
機能、状態、環境組合せ（無側の確認）

操作

異常系

沸騰ボタン

ストレス

チャタリング想定
状態網羅（遷移表ベース、2スイッチ）

移植性

アクティブノイズ汎用観点（追加予定）

保温ボタン
チャタリング想定

共存力

静的分析（内部構成）

競合

チャタリング想定
状態遷移

ワンプレートスタイルで分析

構造テスト

置換製

シナリオベース
メモ

水位メータ
温度制御

状態網羅（遷移表ベース、2スイッチ）

動的分析

タイマボタン※ゆもつよメソッドより

ノイズのタイミングへの影響

信頼性、異常系
ガイドワード仕様適合

参考：HAZOP

詳細

安全性

ロジック

シナリオテスト

シナリオ（シーン）

セキュリティテスト

状態遷移

ロバストネステスト
状態遷移

抜けやすい観点

信頼性

映像処理重ね

回復性テスト

ユーザビリティテスト

ユーザにとっての使用性

ロードテスト

仕様/機能

効率性

ストレステスト

物理特性

拡張性テスト

シナリオ（シーン）

テスコン'12@東京

殺虫剤のパラドックス「バグゼロ」の落とし穴

H/W

水質

構成テスト

入力値異常

不定値入力

機器組合せ
- 2因子網羅- 因子網羅コンテンツ処理重ね

ファイル異常
並行処理

ガイドP

カバレッジ
量産における品質安定性

負荷時仕様- 異常時処理確認

構造

状態

構造テスト

要求

競合

ユースケース

長期使用可能な耐久性
環境
シナリオ（シーン）

開発プロセス改善の指標となる（改善、予防）
高温層を用いた加速確認
ロジック
ポットのシステム

機能組合せ

機能組合せ

因子組合せ

制御時タイミング
ジャンプタイミング

異常値

タイミング

フェールソフト
異常操作

連続

パステスト

最大処理時の負荷- 2因子網羅タイミング- 正常動作確認
キューデータへの同時処理- 正常動作確認タイミング変化

外観検査

一般的なテストの必要性- 正常動作確認- 性能評価処理重ね

振る舞い

両立性テスト特性/精度

欠陥やバグを検出する(検出)要件を満たすことを保証する（保障）

不具合確認

負荷時性能

データ互換性テスト
移植性異常値

分かりやすさ

保守性

負荷時使用

テストは条件次第- 正常動作確認

欠陥検出戦略/ガイドP（っぽい）ワード

要求
H/W

要求

テストの原則- 通信費評価

処理重ね

シナリオ（シーン）仕様適合（当たり前品質）

テストタイプ一覧

初期テスト

不具合確認

仕様/機能

使用性
水温変化の規定

完全なテストは不可能

通信費

レスポンス

信頼性テスト

起動、アップデート

仕様書出図後の仕様変更、ユーザ固有の環境、MWとのIF

テストは欠陥があることしか示せない

歌いやすさ

信頼性や性能効率性の一部だが、ドメインで特に気にする部分を明示

H/W性能

競合

データ互換

音声処理重ね

環境（電圧、温度、振動・衝撃）

機能組合せテスト

ロジック

想定外、数値、起動、終了、割り込み、タイミング

コンテンツ互換

競合表に従った状態、ボタン組合せパターン

機能テスト
機能性

リリース後の品質リスクを見積もる（リスク）

見やすさ- 学習性 : int

意地悪チャタリング想定
競合表

欠陥の偏在

使用性

瞬間的な負荷

エラーの割込みパターン想定

割込み操作、タイミング

CPU量
メモリ量
ディスク

互換性

タイミング変化

沸騰行為

タイミング、状態信頼性テスト

使用性状態網羅（遷移表ベース、2スイッチ）
状態網羅（遷移表ベース、2スイッチ）
状態網羅（遷移表ベース、2スイッチ）

時系列での検討

アクティブノイズ

信頼性

状態網羅（遷移表ベース、2スイッチ）
解除ボタン

割込み

メモリがあふれた時、ハード的なエラー

周辺機器

状態網羅（遷移表ベース、2スイッチ）

ノイズ無し、増加、減少、他に、一部、逆、異なる、早い、遅い、前、後

互換性- 正常動作確認

ワンプレートスタイルで分析

外側、例外、間、対象、類推

リカバリ

HWリソース

保温制御精度順応性

システム、構成ベース

そ、れ、あ、た、る

ﾘﾄﾗｲ（成功）、再接続（成功）、 規制、再送、未接続でHHH、 未契約でGGG、契約外、無応答

大きなデータ（ファイル等）を扱う

吐水量の確認

給湯量

連続テスト

水を補充しながら連続操作

Procedure Testing- 分かりやすさ- 使いやすさ

機能適合性

給湯口

安定性

連続稼動

ポンプ
デバイス：出力

保守性

家庭環境
夜沸騰して朝まで保温

移植性

条件網羅

サーミスタ

コンビニ環境Documentation Testing

保守性

条件網羅

第n水位センサ

ナビゲーション

通信速度

条件網羅

デバイス：入力

変更のしやすさ

長時間使用

レスポンス

条件網羅
条件網羅

水位メータ

満水センサ

テストシナリオ

繰り返しで使用される環境を活用

機器対応
規格・プロトコル対応

割込み処理

条件網羅

温度/モード表示窓

構造テスト/ユーザ提供の状態確認

タイマ
状態網羅

利用状況網羅性

条件網羅

保温ランプ

蓋センサ

ロックOFF時
ロックON時利用時効率性

条件網羅

操作パネル：出力
デバイス機能資源の活用度

音声、ブザー通知- 正常復旧確認

条件網羅

沸騰ランプ

時間挙動

表示

LED表示

条件網羅

タイマ残り時間表示枠

効率性

液晶表示

エラー、異常、NG、例外、XX失敗、ﾘﾄﾗｲｵｰﾊﾞｰ、 ﾀｲﾑｱｳﾄ、不正、Reject、
状態不一致、障害、 同期はずれ、 想定外／未知- 信頼性評価- 正常動作確認- 結果網羅操作レスポンス

条件網羅

ロックランプ

カルキ抜き

手続きテスト

解除ボタン

給湯ボタン

魅力

品質特性（ISO9126）
安全機能

ドキュメンテーションテスト

状態遷移

条件網羅

タイマボタン

各テストフレーム（ソフトウェア/機器）

保温設定ボタン

エラー検知

サービスアビリティテスト

リスク回避性ヒータへの制御出力の妥当性確認

吐水量
ロック機能

Recovery Testing

水位判定の論理組合せ条件網羅

温度判定

操作のしやすさ

基本機能

Reliability Testing

エラー発生条件の条件網羅

水位判定

ヒータ制御

保温機能

Installability Testing

リカバリーテスト

エラー判定

操作学習

Compatibility/conversion Testing

信頼性テスト

利用時

状態遷移×構造テストで確認

状態網羅

操作認識

分かりやすさエキスパートレビュー

インストーラビリティテスト

満足性

状態遷移×構造テストで確認

状態網羅

企業イメージへの配慮

Configuration Testing

機能排他

ボタン入力の論理判定条件網羅
ロック/解除

ユーザと環境に合せる

設定/コンフィグレーションテスト

給湯停止

状態遷移×構造テストで確認

状態網羅

タイマ

信頼性

理解のしやすさ

状態遷移×構造テストで確認

状態網羅

温度異常を知る
見つけやすさ、見易さ

品質特性

ふるまいが目的に適合していること

給湯

成熟度

水位センサ異常を知る

Performance Testing

不正利用

セキュリティ

水が空になったことを知る

機器組合せ

通信費

フェールソフト
登録キュー超過入力

負荷時のタイミング

縮退運転

片肺運転

作り方には決まりはない＜品質特性ベース＞
機能適合性

状態遷移

ふるまい

互換性

- 結果網羅- 正常動作確認

ふるまい

周辺機器

機能性

データ互換

状態遷移

機能排他

レスポンス
性能効率性
- 性能評価
ボリューム

HWリソースコンテンツ互換

途中取消
信頼性- 信頼性評価- 正常動作確認

同時入力・処理動作環境- 信頼性評価- 正常動作確認

処理中異常

復旧処理
- 正常復旧確認

同時入力・処理

プラットフォーム確認

ネットワーク確認

ナビゲーション

- 結果網羅- 分かりやすさ- 使いやすさ

途中取消

実行性能

OS種類

ハードウェア種類

処理中異常

表示くずれ有無

レスポンス

ボリューム

通信速度

操作レスポンス

復旧処理- 正常復旧確認

参考データ- 学習性 : int

信頼性＜VSTeP形式＞ ※ボトムアップに構築になるかも
機能

見やすさ

ユーザビリティ- 結果網羅機能排他- 結果網羅ストレス＜FURPS+ベース＞

保守性/サポート性

制約

テスト方針（ポリシー）

よく出てくるテスト方針• 結果網羅• 機能有効条件• 見やすさ• タイミング• 性能評価上記のような「網羅すべき、確認すべき基準」を記載します。

カタマリー例

テストカタマリー推奨のテスト粒度
テストカタマリーは「ロジカルテストケース」※特にレベル1～2
相当の抽象度のテストケースを持つことを推奨します。
ロジカルTC-A：名前※同値分割でグループ

テストケース
テストケース
テストケース
ロジカルTC-B：名前※DTでグループ

テストケース
テストケース
テストケース
ロジカルTC-C：名前※性能XX確認でグループ参加申込みチケット+ロジカルテストケースA+ロジカルテストケースB+ロジカルテストケースC…

※各ロジカルテストケースはデシジョンテーブル1～2つくらい相当
さらなる詳細化は後のプロセスで実施
目的が異なると分けることを推奨テストカタマリーの概要
アラーム登録+各機能 : 機能特性
~登録数 : 性能効率性…
+アラーム登録 : 各機能+アラーム解除 : 各機能~最大登録数検証 : 登録数…

詳細

iOS時計アプリ
アラーム登録テストスコープの一部=テストカタマリー塊・テストケース１
・テストケース２…
テストケーステストカタマリーの概要
アラーム登録+各機能 : 機能特性
~登録数 : 性能効率性…
+アラーム登録 : 各機能+アラーム解除 : 各機能~最大登録数検証 : 登録数…

ロジカルテストケース＝抽象的なテストケース
詳細

テストスコープの一部=テストカタマリー塊・テストケース１
・テストケース２…
テストケーステストカタマリーの概要
各ロジカルテストケースから具体的なテストケースを作成※テスト詳細設計で実施

アラーム登録+各機能 : 機能特性
~登録数 : 性能効率性…
+アラーム登録 : 各機能+アラーム解除 : アラーム解除
各機能~最大登録数検証 : 登録数…

複数の具体的テストケース
編集画面にて登録解除
アラーム画面にて登録解除

未登録のときに登録解除
詳細テストスコープの一部=テストカタマリー塊・テストケース１
・テストケース２…
テストケースカタマリーノウハウ

ロジカルテストケースとテストケース
上位から考える場合には、ロジカルテストケースまで一度考えた後に、テスト詳細設計で具体的テストケースをつくります。
参加申込みチケット
テスト詳細設計+論文採録No入力可否+論文採録No異常入力+チケット種類の数 対 チケット種別+チケット名文字数 対 チケット種別+チケット種類の数 対 価格確認表+チケット名文字数 対 価格確認表+価格確認表操作レスポンス+レスポンシブでのチケット名表示+参加者種別の入力判定・価格反映+参加者種別・チケット種別価格反映

テストケース
チケット種類1個

チケット種類の数

01

テストケース
チケット種類2個

10 11※0と10超過は設定できないテストケース
チケット種類10個

テスト詳細設計
参加者種別
通常参加
論文採録者

論文採録No

通常参加
費用

論文採録
者費用

有効
入力無し
システム登録なし

画面遷移
負荷テストケース仕様書を作る場合
テストケース仕様書を作成する場合や、テスト管理ツールにてテストケースを管理する場合に階層構造はシンプルに対応してます。
参加申込みチケット
各入力説明 No

+論文採録No入力可否+論文採録No異常入力+チケット種類の数 対 チケット種別+チケット名文字数 対 チケット種別+チケット種類の数 対 価格確認表+チケット名文字数 対 価格確認表+価格確認表操作レスポンス+レスポンシブでのチケット名表示+参加者種別の入力判定・価格反映+参加者種別・チケット種別価格反映

ロジカルテストケースのテストケース範囲は赤点線

テスト名

テストカタマリーのもつテストケースは青点線範囲

No
テストケースBusST申し込みシステム
参加申込みチケット
論文採録No入力可否
1 参加者種別->通常参加 選択時に論文採録Noがグレイアウトで入力不可
試験カテゴリ

2 参加者種別->論文採録者 選択時に論文採録Noが入力できること
チケット種類の数 対 チケット種別
チケット種別の選択可能なドロップダウンリスト数（チケット種類の数）が1個の場合、表示されるドロップダウンリストが1つしかないこと
3

4

チケット種別の選択可能なドロップダウンリスト数（チケット種類の数）が2個の場合、表示されるドロップダウンリストが2つあること

5

チケット種別の選択可能なドロップダウンリスト数（チケット種類の数）が10個の場合、表示されるドロップダウンリストが10個あること

チケット名文字数 対 チケット種別
・・・

カタマリーとレベルテストケースの関係

各入力説明 No

テスト名

カタマリー
｜－カタマリー｜－ロジカルテストケース｜－ハイレベルテストケース｜－ローレベルテストケース｜－ローレベルテストケース

試験カテゴリ No
テストケースBusST申し込みシステム
参加申込みチケット
論文採録No入力可否
1 参加者種別->通常参加 選択時に論文採録Noがグレイアウトで入力不可
2 参加者種別->論文採録者 選択時に論文採録Noが入力できること<<ユーザ接点機能>>
予約をする~ 機能適合性 : 機能適合性~ 異常値 : 異常値~ 性能効率 : 性能効率性~ 使用性 : 使用性~ 信頼性 : 信頼性+ タイミング : タイミング+ 機能組合せ : 機能組合せ

チケット種類の数 対 チケット種別
チケット種別の選択可能なドロップダウンリスト数（チケット種類の数）が1個の場合、表示されるドロップダウンリストが1つしかないこと
3

4

チケット種別の選択可能なドロップダウンリスト数（チケット種類の数）が2個の場合、表示されるドロップダウンリストが2つあること

5

チケット種別の選択可能なドロップダウンリスト数（チケット種類の数）が10個の場合、表示されるドロップダウンリストが10個あること

チケット名文字数 対 チケット種別
・・・

予約系操作をする~ ふるまい : 機能適合性+ 曲Noで予約登録をする(結果網羅) : ふるまい
+ 検索結果から予約登録をする(結果網羅) : ふるまい
+ 予約オプション設定を確認する(結果網羅) : ふるまい

小さいカタマリー
小さいカタマリーを考えるの場合、ツリー状にテストケースを下記のように考えると良いです。
※テストケース出しの段階では下記の形を意識する必要はない。
テスト方針

テストパラメータ

テスト対象
テストパラメータ

分類
テスト方針

テストパラメータ

テスト対象

カタマリー

テストパラメータ
分類

テスト対象
テスト方針
テスト方針
テスト対象

テストパラメータ
テストパラメータカタマリーが大きすぎる場合
１つのカタマリーが大きすぎる場合、分割を推奨。
「has-a（集約）」を用いて分割を明示。

参加申込み登録画面

参加申込みチケット+ 単体パラメータ確認 : 機能適合性+ 有則組合せ確認 : 機能適合性+ 入力値異常 : 異常値+ レスポンス : 性能効率性+ 表示くずれ有無 : 使用性

参加申込みチケット+ 単体パラメータ確認 : 機能適合性+ 有則組合せ確認 : 機能適合性+ 入力値異常 : 異常値+ レスポンス : 性能効率性+ 表示くずれ有無 : 使用性+ 論文採録No入力可否(結果網羅) : 単体パラメータ確認+ 論文採録No異常入力(異常時処理確認) : 入力値異常+ チケット種類の数 対 チケット種別(結果網羅) : 単体パラメータ確認+ チケット名文字数 対 チケット種別(結果網羅) : 単体パラメータ確認+ チケット種類の数 対 価格確認表(結果網羅) : 単体パラメータ確認+ チケット名文字数 対 価格確認表(結果網羅) : 単体パラメータ確認+ 価格確認表操作レスポンス(性能評価) : レスポンス+ レスポンシブでのチケット名表示(表示確認) : 表示くずれ有無+ 参加者種別の入力判定・価格反映(結果網羅) : 単体パラメータ確認+ 参加者種別・チケット種別価格反映(結果網羅) : 有則組合せ確認

他要素

参加申込みチケット：組合せ・品質特性+ 有則組合せ確認 : 機能適合性+ レスポンス : 性能効率性+ 表示くずれ有無 : 使用性+ 価格確認表操作レスポンス(性能評価) : レスポンス+ レスポンシブでのチケット名表示(表示確認) : 表示くずれ有無+ 参加者種別・チケット種別価格反映(結果網羅) : 有則組合せ確認
参加申込みチケット：単体パラメータ+ 単体パラメータ確認 : 機能適合性+ 入力値異常 : 異常値+ 論文採録No入力可否(結果網羅) : 単体パラメータ確認+ 論文採録No異常入力(異常時処理確認) : 入力値異常+ チケット種類の数 対 チケット種別(結果網羅) : 単体パラメータ確認+ チケット名文字数 対 チケット種別(結果網羅) : 単体パラメータ確認+ チケット種類の数 対 価格確認表(結果網羅) : 単体パラメータ確認+ チケット名文字数 対 価格確認表(結果網羅) : 単体パラメータ確認+ 参加者種別の入力判定・価格反映(結果網羅) : 単体パラメータ確認

書き方の一例
ロジカルテストケース「○○を××する」という感じに整理。
「××」が「確認」、「評価」というのが出てきたらそれは方針のことを言っていたり、対象と方針を一緒くたにしている可能性がある。

テスト方針「○○を確認する」「○○を評価する」の「○○」。
「結果網羅を確認する」という場合は、「結果網羅」がテスト方針の箇所に当たる。

記法を用いるにあたって• 全記法を必ず使用する必要はありません。
• クラス図の記法と異なる使用がありますのでご注意を。
※今後の課題、変わるかもしれません。
カタマリー名+ふるまい：機能適合性+異常値：信頼性+レスポンス：性能効率性…

+ロジカルテストケースA： レスポンス+ロジカルテストケースB： ふるまい
+ロジカルテストケースC： 異常値
…

参考情報

用語
テストスイートアーキテクチャ
段階的に設計されたテストケースで構成されるテストスイートの構造。
ソフトウェアの内部に焦点を当てている。

テストシステムアーキテクチャ
シミュレータなどテスト実行環境のシステム構成に焦点を当てている。

用語
テストカタマリー
テストケースの集合体（塊）を表現したもの「カタマリー」と略して呼ぶ場合もある
テストカタマリー記法自体を「テストカタマリー」と呼ぶ場合もある
キガカリー
カタマリーが確認したい品質特性や気がかり、テストケースの目的等
ブンルイー
上記キガカリーを分類し、特定のプロジェクトや組織単位で使う一覧としたもの
ツリー構造やネットワーク構造で整理したもの。ブンルイー図と呼ぶ場合もあるブログ情報• テストケースの表現と粒度
http://blog.amateur-factory.jp/?eid=1444287• テストケースの表現と粒度（マニアック編～ISTQB（JSTQB）の情報から考える）
http://blog.amateur-factory.jp/?eid=1444288

ブログ情報• テストカタマリーの紹介１：カタマリーの概要
http://blog.amateur-factory.jp/?eid=1444271• テストカタマリーの紹介２：カタマリーの例
http://blog.amateur-factory.jp/?eid=1444272• テストカタマリーの紹介３：カタマリーの記法とツール（前編）
http://blog.amateur-factory.jp/?eid=1444273• テストカタマリーの紹介４：カタマリーの記法とツール（後編）
http://blog.amateur-factory.jp/?eid=1444274• テストカタマリーの紹介５：カタマリーパターンの活用
http://blog.amateur-factory.jp/?eid=1444275• テストカタマリーの紹介６：まとめ
http://blog.amateur-factory.jp/?eid=1444276

レポート他• OSC2017 in Hokkaido「もしかして、テストって誰でもできると思っちゃってませんか？ 最新のテストの動向を知りたくないですか？」https://www.slideshare.net/tef-do/tefdo-osc2017-inhokkaido-07152017• テスト設計コンテスト'17 OPENクラス 決勝戦レポート
http://aster.or.jp/business/contest/contest2017.html• 公開用 テストカタマリーワークショップ（説明のみ）
https://www.slideshare.net/NoriyukiMizuno/ss-80257236

参考論文• OMG, “UML Testing Profile (UTP) Version 2.0 - Beta,”
http://www.omg.org/spec/UTP/2.0/, September 2017.
• OMG, “UML Version 2.4.1,” http://www.uml.org/, 2012.
• OMG, “SysML Version 1.5,” http://www.omgsysml.org/,
2017.
• ISO/IEC 25010:2011, “Systems and software engineering− Systems and software Quality Requirements and
Evaluation (SQuaRE)−System and software quality
models,” 2011.

参考論文• Glenford J. Myers, Tom Badgett, Corey Sandler, "The Art of
Software Testing 3rd edition," Wiley, 2011.
• Erich Gamma, Richard Helm, Ralph Johnson and John
Vlissides, “Design Patterns: Elements of Reusable ObjectOriented Software,” Addison-Wesley Professional, 1994
• Y.Nishi, “Design principles in Test Suite Architecture,”International Workshop on Software Test Architecture (InSTA
2015), Graz, Austria, April 2015.
• Y. Nishi, T. Katayama and S. Yoshizawa, “Combinatorial Test
Architecture Design Using Viewpoint diagram,” International
Workshop on Combinatorial Testing (IWCT2013), Luxembourg,
March 2013, CD-ROM.

参考論文• T.Yumoto, T.Matsuodani, and K.Tsuda, ” A Study on theeffectiveness of Test-Categories based test analysis” ,International Workshop on Software Test Architecture(InSTA2016), Chicago, April 2016.
• N.Mizuno, M.Nakakuni and Y.Seino, “Test Conglomeration Proposal for Test Design Notation like Class Diagram,”
International Workshop on Software Test Architecture(InSTA2017), March 2017.
http://ieeexplore.ieee.org/document/7899074/• M.Nakakuni, S.Ban, N.Mizuno, K.Abe, H.Iseri, T.Odan, H.Ando,
K.Iseri, A.Satoh “Proposal for Enhancing UTP2 with Test Aspects,”
International Workshop on Software Test Architecture(InSTA2018), April 2018.