ソフトウェアテストシンポジウム 2013
JaSST’13: Japan Symposium on Software Testing 2013

見通しのよいテストの段階的詳細化の手法－テストの網羅性確保の提案－
吉岡 克浩†

水野 昇幸‡

西 康晴††††三菱電機株式会社 設計システム技術センター 〒661-8661 兵庫県尼崎市塚口本町 8-1-1‡三菱電機株式会社 通信機製作所 〒661-8661 兵庫県尼崎市塚口本町 8-1-1†††電気通信大学 情報理工学研究科 〒182-8585 東京都調布市調布ヶ丘 1-5-1
E-mail:†Yoshioka.Katsuhiro@ab.MitsubishiElectric.co.jp ‡Mizuno.Noriyuki@ah.MitsubishiElectric.co.jp

あらまし 段階的にテストを詳細化する「テスト開発プロセス」を構築した。テストの網羅性向上のためにマトリクス形式を導入したが、テストケースのばらつきや成果物が巨大化し作業性が悪化する課題があった。そこで、モデル化したテスト対象とテスト目的の組合せでテストアーキテクチャを決定し、組合せ毎にテストを詳細化する手法を作成した。手法の適用により、テスト密度向上と作業効率化を両立し、テストケースのばらつきを抑制した。
キーワード テストアーキテクチャ、テスト対象、テスト目的、テスト観点、マトリクス、デシジョンテーブル

Test Design by Stepwise Refinement－Approach to Test Coverage Improvement－
Katsuhiro Yoshioka†

Noriyuki Mizuno‡

Yasuharu Nishi††††Design Engineering Center, Mitsubishi Electric, Ltd., ‡Communication Network Center, Mitsubishi Electric, Ltd.,†††Department of Informatics,University of Electro-Communications
E-mail:†Yoshioka.Katsuhiro@ab.MitsubishiElectric.co.jp ‡Mizuno.Noriyuki@ah.MitsubishiElectric.co.jp

Abstract We were established to refine the contents of the test in a stepwise manner "Test Development Process."
By applying this process, the test design work can be done by dividing the unit of test context, we have improved thedeterioration of working with the large test matrix for the conventional process. And we have improved both efficiency of test
design and test density.
Keyword Test Architecture, Test Item, Test Context, Test Viewpoint, Test Matrix, Decision Table

1. は じ め に
情報家電、自動車、産業機器などの工業製品のほとんどは機能や性能の多くを、機器に組み込まれたソフ
トウェアで実現している。市場競争の激化に伴う製品

スト手順、期待値を記述したものであり以下のような課題があった。
(1)テ ス ト ケ ー ス の 作 成 基 準 、網 羅 基 準 が な く 、テ ス
トケースの粒度、記載レベルのばらつきがでる。

の高機能化により、組込みソフトウェアはより大規模(2)テ ス ト ケ ー ス の 羅 列 か ら は 全 体 像 が 見 え ず 、何 をで複雑なものとなってきている。一方で、製品投入間網羅できているか分からないため、レビューで漏れを隔の短縮により、開発期間は短縮してきている。

検出できない。

このような状況で弊社は、納期遅延、コスト超過によるプロジェクト崩れを抑制しつつ市場に高品質な製(3) テ ス ト ケ ー ス の 数 が 多 く 限 ら れ た 時 間 で レ ビ ューしきれない。

品を提供するために、設計段階で品質作り込みを行う
活動とテストの改善を推進してきた。

これらの課題に対し、テスト手順書作成の前に、機能 (行 )ｘ テ ス ト 観 点 ( 列 )の マ ト リ ク ス で テ ス ト ケ ー ス

1.1. 従 来 のテスト設 計 手 法 の課 題の洗い出し、抜け・漏れのチェックを行う、ゆもつよ

従来のシステムテスト設計は、仕様書から直接テス

メ ソ ッ ド [1]を 参 考 に し た 手 法 を 導 入 し た（ 第 ２ 世 代 ）。

ト手順書を作成し、レビューでテストケースの妥当性

マトリクス手法の導入により、大きなテスト観点の抜を 確 認 す る 作 業 で あ っ た（ 第 １ 世 代 ）。テ ス ト 手 順 書 は 、け・漏れを抑制することはできたが、新たな課題も見

階層化（主に大中小）したテスト対象機能に対し、テつかった。本論文ではそれらの課題を明らかにし、課題への対策（第３世代）について記述する。

＜第2世代＞マトリクス手法の導入

課題作成基準が無く、テストケースがばらつく。レビューで漏れ検出が困難。限られた時間内でのレビューが難しい。
2章記載の課題が発生

第3世代の手法：

見通しの良いテストの段階的詳細化へ

大中小項目整理
テスト項目…
大項目 中項目
小項目 …
タイマ タイマ操作 設定
リセット

テスト対象
（機能等）

テスト設計手法＜第1世代＞
大中小の階層でテスト項目を整理する

3.2. テスト対 象 とテスト目 的 によるテスト全 体 の分 割
(1)テ ス ト 対 象
テストの全体を考えるには、テストの対象と非対象

マトリクス手法を明確にする必要があった。マトリクス手法で扱ってテストで確認する性質
XX XX XX…

いた「機能」もその１つであるが、実際にシステムテス ト で 扱 っ て い た 対 象 は 、「 ユ ー ス ケ ー ス 」「 実 運 用 シ
ナ リ オ 」「 シ ス テ ム 全 体 」と い っ た 粒 度 の 大 き な も の も
あ る 。 こ れ ら テ ス ト 対 象 の 例 を 表 2に 示 す 。 シ ス テ ム

図 1

テスト設計手法の変遷

テストで扱うテスト対象は、インプット資料に記載があ る も の が ベ ー ス で あ り 、 客 先 RFP、 シ ス テ ム 要 求 仕

2. マ ト リ ク ス 手 法 （ 第 ２ 世 代 ） 導 入 後 の 課 題様書からは、ユースケースや実運用シナリオに似た粒

2.1. 巨 大 なマトリクスになり作 業 性 が悪 い

度の情報が抽出でき、機能仕様書からは機能を抽出であ る 工 事 に 適 用 し た 結 果 で は 、階 層 化 し た 機 能：200

きることが多い。しかし、インプット資料の質・量は

行 ｘ テ ス ト 観 点：15 列 の 巨 大 マ ト リ ク ス と な っ た 。そ客先、プロジェクトごとに一様ではなくテスト設計時の結果、全体を俯瞰することが困難となりレビューやにすべてが開示されていないケースもある。そのため作業分担がし辛い状況となった。

テスト対象として必要であれば上位仕様書作成者に提示を求めたり、テスト設計者自らユースケース一覧や

2.2. テスト観 点 の定 義 が不 十 分運用を想定したシナリオを作成する。テスト対象は、初期に導入したマトリクスでは標準のテスト観点

プロジェクトによって要不要や重み付けを判断するだとその説明文書を定義して展開したが、ドメイン共通

けでなく、新しい項目を追加するといったテーラリン

で使用する狙いとしたためテスト観点の抽象度が高く、グを可能としている。

作業担当者により解釈が異なる場合があり、抽出結果

表 2 テスト対象の例にばらつきが出た。また、記載の詳細度が個人任せで

テスト対象
1
機能

概要
S/W要求仕様書の機能

2

ユースケース

3

実運用シナリオ

4

システム全体S/W要求仕様書のユースケース（複数機能の連携）
運用で想定されるまとまった作業（複数機能、ユースケースの連携）システム全体としての動作

マトリクスは仕様書からテストのポイントを抽出

5

利用シーン

する作業に使用し、テストケース作成のインプットと6

データなる資料であるが、テストケースに落とすまでに組合7あったため、詳細に記載してテスト手順書と内容が重複したり、逆に一部のキーワードのみの記載で中身が良く分からない資料になってしまうケースがあった。

2.3. マトリクス作 成 後 の作 業 が不 明 確

せやテスト準備手順を追加する方法は個人任せであっ網羅的な条件で検証したい特定の状
況
データ保守、システム移行時の対象

プロトコル
シーケンス、信号（シーケンス、信号）
8
状態
状態定義、状態遷移

たため、テストケースの記載内容、粒度が一定でなかった。
(2)テ ス ト 目 的

3. 課 題 に 対 す る 対 策
3.1. 課 題 の対 策 方 針
これら３つの課題に対し以下の対策方針を立てて解決に取り組んだ。

表 1

テスト目的は、テストで保証すべき性質の分類であり、本手法ではテスト観点の上位に位置するテストの「 狙 い 」 を 示 す も の で あ る 。 表 3に テ ス ト 目 的 の 例 を示す。手法の確立においてはテスト目的の漏れ＝手法
によるテスト漏れに繋がるため、テスト目的の議論に

課題の対策方針

課題
対策方針
対策
1 巨大なマトリクスになり マトリクスを見通しのよいサ 3.2項
作業性が悪いイズに分割するに記載
2 テスト観点の定義が不 テスト観点を具体化する
3.3項
十分
に記載
3 マトリクス作成後の作業 マトリクスからテストケース 3.4項が不明確に落とす作業を具体化する に記載

時間をかけた。テスト目的に挙げた項目はマトリクス手法で用いていた項目をベースに、不具合事例からシ
ステムテストで検出すべき不具合を「狙う」テスト目
的を追加していった。

表 3 テスト目的の定義
テスト目的
カテゴリ
品質特性

テスト目的
1

論理性

る選択肢を「水準」と呼ぶ。因子と水準の考え方はHAYST 法 [2]を 参 考 に し た 。

狙う不具合
仕様不適合の動作。仕様通りの結果にならない。条件通りに動作が変化しない。条件の裏（else）で不正な動作をする。

2 ユーザビリティ 仕様不適合のユーザビリティ。使いにくいUI。ユーザ操作時のレスポンスが悪い。表示の一貫性がない。

(1)フ レ ー ム ご と の マ ト リ ク ス 定 義
従来のマトリクス手法ではテスト条件およびチェ

3

性能

仕様不適合の性能。速度性能未達。リソースの枯渇。

ックポイントの抽出結果を１つ巨大マトリクスに記載

4

保守性

仕様不適合の保守性。解析しにくいログ。膨大な量のログ。短時間で消えるログ。更新しにくいマスタ。更新時間がかかる。装置交換が困難。

していた。本手法では、作業者の分担やレビューをし5

信頼性

オーバースペックな条件で発生する不具合。

6

移行

仕様不適合のデータ移行性。旧バージョン・別環境からのデータ移行が困難。データの追加・変更・削除が困難。

7

組合せ

仕様上影響がないはずの機能・データ・状態の組合せによる不具合。（直交表、HAYST法の適用範囲）

8

環境

H/W、対向装置、気温、地域性など環境・構成を変更して発生する不具合。仕様不適合のもの（環境の違いに実装で対応しているもの）。仕様上影響がないはずのもの。

表 5 フレーム毎のマトリクステンプレート

非ロバスト

9

通常負荷

通常負荷での動作不具合。速度性能未達。

NO

ロバスト性

10

意地悪

意地悪操作による動作不具合。ボタン連打、同時押し、同時
実行、回線切断などによる想定外の不具合。

1.1

11

設計最大負荷での動作不具合。負荷に耐えられず動作が中断。想定以上の性能劣化。

12

設計最大
負荷
過負荷

13

連続運転

連続運転での動作不具合。想定以上のメモリ使用、リソース使用。性能劣化。

依存性やすくするために、フレームごとにマトリクステンプ
レ ー ト を 分 割 し て 定 義 し た 。 表 5は フ レ ー ム ご と の マ

過負荷での動作不具合。リソース枯渇によるクラッシュ。無応答。フェールセーフ機能の動作不具合。

(3)テ ス ト 対 象 と テ ス ト 目 的 の 組 合 せトリクステンプレートの対応イメージである。

テスト
対象

テスト目的

機能

論理性
L
性能
1.2
F
P
論理性
2.1 ユースL
ケース
ユーザビリティ
2.2
UC
U
2.3
保守性
MA

各フレーム単位でテンプレートを用意

ID

環境
E
設計最大
負荷 ML

…

F-L-E

…

UC-L

機能×論理性×環境
テンプレート：F-L-E

UC-U

…

F-P-ML

…

機能×性能
×負荷
テンプレート：F-P-ML

UC-MA

テスト対象にテスト目的を組合せることでどのテスト対象で何の性質を保証するテストをする、という(2)テ ス ト 観 点 マ ト リ ク ス

テストの構成を示す。本手法ではこの組合せ表を「テマトリクステンプレートは、行見出しに具体化したスト設計サマリ表」と呼び、その構成要素である１つ

テスト対象、列見出しにテスト目的を具体化したテス

１ つ の 組 合 せ を 「 フ レ ー ム 」 と 呼 ぶ 。 表 4は テ ス ト 設ト条件、チェックポイントを持つ。本手法ではこのマ計サマリ表の例である。この表は組合せを「○」の有ト リ ク ス を テ ス ト 観 点 マ ト リ ク ス と 呼 ぶ 。 表 6は テ ス

無で表示する単純な表であり全体を容易に俯瞰するこ

ト対象：機能、テスト目的：論理性・環境、のテストとができる。テスト設計サマリ表で示す内容は、テス

観点マトリクスの例である。

トの専門家でなくとも短時間の説明で理解可能である。
そ の た め 、 シ ス テ ム 設 計 者 、 S/W 設 計 者 な ど 関 係 者 を交えてテストの範囲を議論して合意するツールとして

表 6 機能 x 論理性 x 環境のテスト観点マト
リ ク ス の 例 （ テ ン プ レ ー ト ： F-L-E）

適している。
列見出し：テスト条件、チェックポイント

表 4 テスト設計サマリ表の例
品質特性

テスト目的
テスト対象
1
2
3
4

機能
ユースケース
実運用シナリオ
・・・

論理性

ユーザ
ビリティ

○

性能

テスト観点
番号

保守性

F-L-E-01 給湯機能

○

○

○

○フレーム

○

○

機能

○

テスト条件
論理

環境
入力/参照
値

環境

・・・・

○

○

○

テスト対象

○

ポットシリーズ（ポット 優先度
A、ポットB）

入力/参照状態

チェックポイント論理
入力イベン 中間値、中
結果値
ト
間状態

振る舞い 事後状態

ロック状態(ロック、解除)
給湯(実施/#1 給湯不水量（空、適量、満水超え）
表示コード 非実施)
元の状態で蓋センサ状態（ON、OFF） 給湯ボタン 可能状態
（L1、L2、 エラーコードあること。
(L1、L2、押下*1 温度制御状態（保温、沸L3、L4） 表示(L1、L3、L4)
騰、アイドル）
L2、L3、L4)
エラー状態

F-L-E-02 タイマセット機能○

F-L-E-03 タイマリセット機能
F-L-E-04 タイマアラーム機能

セ ル の 中 身：テ ス ト 条 件 、チ ェ ッ ク
ポイントの因子と水準

F-L-E-05 沸騰機能

3.3. テスト観 点 の具 体 化 と因 子 の抽 出
テスト構成が決定したら、次は具体的にインプット

F-L-E-06 カルキ抜き機能
F-L-E-07 保温機能

仕様書から入力値、イベントなどの「テスト条件」と振る舞い、判定基準などの「チェックポイント」を抽出する。また、テスト条件、チェックポイントになり得 る 仕 様 書 に 記 載 さ れ た 項 目 を「 因 子 」、因 子 の 取 り 得

F-L-E-08 モード設定機能

ポットシリーズ（ポットA、
ポットB）
ポットシリーズ（ポットA）
外気温（低
温 高温）

なし
水温

保温状態

なし

なし

なし

なし

設定モード(高温、節約、ミル
ク)

なし

なし

水温(高温、
節約、ミルク)

行見出し：具体化したテスト対象

保温ランプ点灯
保温状態
沸騰ランプ消灯なしなし

図 2テ ス ト 条 件 、 チ ェ ッ ク ポ イ ン ト の 詳 細 化 の 例

テスト対象
テンプレート（表2）
テスト対象
1

機能

テスト目的
テンプレート（表3）
テスト目的
カ テゴリ
品質特性

概要
S/W要求仕様書の機能

テスト目的
1

論理性

フレーム毎マトリクス
テンプレート（表5）…

狙う不具合
仕様不適合の動作。仕様通りの結果にならない。条件通りに動作が変化しない。条件の裏（else）で不正な動作をする。

…

2 ユーザビリティ 仕様不適合のユーザビリティ。使いにくいUI。ユーザ操作時のレスポンス

機能×論理性×環境
テンプレート：F-L-Eが悪い。表示の一貫性がない。

2

ユースケース

3

実運用シナリオ

4

システム全体S/W要求仕様書のユースケース（複数機能の連携）運用で想定されるまとまった作業（複数機能、ユースケースの連携）システム全体としての動作

5

利用シーン

網羅的な条件で検証したい特定の状況

6

データ

3

性能

仕様不適合の性能。速度性能未達。リソースの枯渇。

4

保守性

仕様不適合の保守性。解析しにくいログ。膨大な量のログ。短時間で消えるログ。更新しにくいマスタ。更新時間がかかる。装置交換が困
難。

5

信頼性

オーバースペックな条件で発生する不具合。

6

移行

仕様不適合のデータ移行性。旧バージョン・別環境からのデータ移行が困難。データの追加・変更・削除が困難。

7

組合せ

仕様上影響がないはずの機能・データ・状態の組合せによる不具合。
（直交表、HAYST法の適用範囲）

8

環境

H/W、対向装置、気温、地域性など環境・構成を変更して発生する不具合。仕様不適合のもの（環境の違いに実装で対応しているもの）。仕様上影響がないはずのもの。

非ロバスト

9

通常負荷

通常負荷での動作不具合。速度性能未達。

ロバスト性

10

意地悪

意地悪操作による動作不具合。ボタン連打、同時押し、同時実行、回線切断などによる想定外の不具合。

11

設計最大
負荷
過負荷

設計最大負荷での動作不具合。負荷に耐えられず動作が中断。想定以上の性能劣化。

12
13

連続運転

連続運転での動作不具合。想定以上のメモリ使用、リソース使用。性
能劣化。

依存性

7
8

データ保守、システム移行時の対象

プロトコル
シーケンス、信号（シーケンス、信号）
状態
状態定義、状態遷移

テンプレート毎のテスト条件、
チェックポイントはツリー形式で検討（図 2）

…
…

機能×性能
×負荷
テンプレート：F-P-ML

過負荷での動作不具合。リソース枯渇によるクラッシュ。無応答。
フェールセーフ機能の動作不具合。

テンプレートの作成（SEPGが担当・検討実施）

・・・①テンプレートを参考に、テスト設計サマリ表を作成
テスト目

品質特性

的
論理性
1
2
3

開発にあわせて担当者が対象をカスタマイズ可能

図 3

4

機能
ユースケース
実運用シナリオ
・・・

ユーザ
ビリティ

○
○
○
○

性能

保守性

・・・・

○
○

○

③テンプレートを選択・活用してテスト観点
マトリクス作成○②実施するテスト○○
を定義、合意する○○○

テスト設計サマリ表（表4）

テスト 観点番号機能

F-L-E-01

給湯機能

F-L-E-02

タイマセット機能

F-L-E-03

タイマリセット機能

F-L-E-04

タイマアラーム機能

F-L-E-05

沸騰機能

F-L-E-06

カルキ抜き機能F-L-E-07

保温機能

F-L-E-08

担当者が
詳細化した
対象を記載

テスト対象

モード設定機能テスト 条件論理

環境
環境

ポットシリーズ（ポットA、
ポットB）

入力/参照
値

入力/参照状態

優先度

ロック状態(ロック、解除)
水量（空、適量、満水超え）
蓋センサ状態（ON、OFF）*1 温度制御状態（保温、沸騰、アイドル）
エラー状態

チェックポイント論理
入力イベン 中間値、中
ト
間状態

結果値

振る舞い

#1 給湯不可能状態(L1、L2、
L3、L4)

表示コード（L1、L2、
L3、L4）

給湯(実施/
非実施)
元の状態でエラーコードあること。
表示(L1、
L2、L3、L4)

給湯ボタン押下

事後状態④各テスト観点マトリクスに従って因子を抽出する
ポットシリーズ（ポットA、ポッ
トB）
ポットシリーズ（ポットA）
外気温（低
温 高温）

なし
水温

保温状態

なし

なし

なし

保温ランプ点灯
沸騰ランプ消灯

保温状態なし

設定モード(高温、節約、ミルク)

なし

なし

水温(高温、
節約、ミルク)なし

なし

テスト観点マトリクス（表6）

現場担当者の作業

テスト範囲の決定～テストマトリクス作成の流れ（テンプレートと実作業の関係）

テスト観点マトリクスのテスト条件、チェックポイ
ントの定義は、テスト目的ごとに狙う不具合を検出すっていることを確認する。
また、テスト観点マトリクスは因子の抽出に特化し、るために何を入力（テスト条件）として、何を確認す

因子の組合せは次の作業で行う。これには、抽出作業

る（チェックポイント）かを作業者に分かりやすく示と組合せ作業で頭の切り替えによる作業効率の低下をす 必 要 が あ る 。そ こ で 、NGT/VSTeP[3]に お け る テ ス ト

防ぎ、組合せで数が増える前なので類似パターンの抽観点抽出方法を参考に、論理性テスト、性能テスト、

出・レビューを容易化する狙いがある。

ユーザビリティテストといったテスト目的ごとにテス
ト条件とチェックポイントを有識者で洗い出してマイテスト観点マトリクス作成までの作業におけるテンプレートと実際の関係を図 3 に記載する。

ン ド マ ッ プ で 整 理 し 、 枝 の 関 係 は 何 か （ has-a／ is-a）、

テ ン プ レ ー ト は SEPG に よ り 事 前 に 作 成 及 び 準 備 さ

漏れはないかをチェックした。マトリクスの段階で、れた状況で、担当者はテンプレートを活用しテーラリ

因子をテスト条件、チェックポイントに分類すること

ング検討を行いながら、テスト観点マトリクスを作成

で、テストケース作成のインプットとして両方がそろする。

3.4. テスト観 点 マトリクス作 成 後 の作 業

4. テ ス ト 開 発 プ ロ セ ス の 構 築(1)テ ス ト ケ ー ス の 作 成

マトリクスを抽出とした一連のテスト作業を現場

テスト観点マトリクスでテスト条件とチェックポに適用するために、テスト開発プロセスとしてガイド

イントの因子を抽出した後は、因子毎に同値分割表を

ラ イ ン 化 し た 。 図 4に テ ス ト 開 発 プ ロ セ ス の 全 体 像 を用いて具体的な入力値と期待値を決定する。次に、原示す。ガイドラインに則って作業を実施することで、因結果グラフ、デシジョンテーブル等を用いて入力値

テスト対象・テスト目的の組合せからテストケースまと 期 待 値 の 組 合 せ を 作 成 し 、テ ス ト ケ ー ス と す る 。表 7

で定型作業で段階的にテストを詳細化することができはデシジョンテーブルの作成例である。テスト観点マる。またテスト設計サマリ表が示す全体像から段階的

トリクスの１行のデータが１つのデシジョンテーブルに成果物をレビューすることにより、ポイントが絞れに対応する。

効率的に漏れ・誤りを検出できる。

表 7 デシジョンテーブルの作成例
入力条件
1. ロック状態
1 ロック
2 解除
2．水量
1 適量(水位センサ1～4がONの状態)
2 空
3 満水（満水センサがONの状態）
3．蓋センサ1 ON(閉じる状態)
2 OFF(開く状態)
4. 状態
1 保温状態
2 沸騰状態
3 アイドル状態
期待結果
1. 振る舞い
1 給湯実施2 給湯非実施
2. エラーコード表示
1 L1（ロック中）
2 L2(給湯不可水量)
3 L3(蓋空き)
4 L4（給湯不可状態）
5 なし

5. 実 施 結 果

#1

#2

#3

#4

#5

#6

#7

本 論 文 執 筆 時 点（ '12/9 月 ）に お い て 、2 件 の 通 信 S/W

○
-

○

○

○

○

○

○

に本手法を適用した。適用工事 2 件はテスト実装を終

○
-

○
-

○

○
-

○
-

○
-

○
-

○
-

○
-

○
-

○

○
-

○
-

○
-

○
#1

○
#2

○
#3

○
#4

○
#5

○
#6

○
#7

○

○

○

○

○

○

○
-

○
-

○
-

○
-

○
-

○
-

○
-

○

(2)テ ス ト 手 順 の 作 成
テストケースにテスト実施における準備作業などえたところで、テスト実施はこれからであるため今回はテスト成果物について、組織標準との比較を行い良好 な 結 果 を 得 た （ 表 9）。

表 9 手法適用効果（組織標準比）
工事１ 工事２(1)テスト密度（テストケース数/開発量KL）(2)テスト成果物作成時間（作業時間/開発量KL）(3)テストケース１件あたりの作成時間(4)テストケース１件あたりのレビュー時間

平均

252%

150%

201%

92%

79%

86%

37%

53%

45%

36%

85%

60%

の テ ス ト 手 順 を 追 加 し テ ス ト 手 順 書 に ま と め る（ 表 8）。
このとき、同じ入力条件や事後条件に着目しテスト手(1)テ ス ト 密 度 （ テ ス ト ケ ー ス 数 /開 発 量 KL）

順の集約を図る。

テ ス ト 密 度 は 2 工 事 平 均 で 組 織 標 準 比 で 201%と なり増加した。

表 8 テスト手順書の作成例
テスト項目
番号

テ ス ト 成 果 物 作 成 時 間 は 組 織 標 準 比 86%と な り 短 縮
テスト項目

共通手順-01 共通手順

開始状態

テスト手順

1)ポットに水を適量注ぐ
2)コンセントを挿す
3)蓋を閉める
4)沸騰するまで待つ
5)カルキ抜き完了まで待つ
6)温度が安定(保温温度±2℃)するまで待つF-L-E-01-#1 給湯ボタン ロック状態給湯 保温状態 1)共通手順-01を実施する-01
非実施
ロック解除 2)ロックボタンを押してロック状態にする
3)給湯ボタンを押す
F-L-E-01-#2-01(2)テ ス ト 成 果 物 作 成 時 間 （ 作 業 時 間 /開 発 量 KL）

保温状態にす 水なし
る
コンセント
抜け
蓋空き

水量空状態給 保温状態 1)共通手順-01を実施する
湯非実施
ロック解除 2)水量を空にする
3)給湯ボタンを押す

テスト規格

備考

6)保温状態であることした。
(3)テ ス ト ケ ー ス １ 件 あ た り の 作 成 時 間
テ ス ト ケ ー ス 作 成 時 間 は 組 織 標 準 比 45%と な り 大 き
く短縮した。

2)ロック状態であること
3)給湯非実施
エラーコード表示L13)給湯非実施
水量の変化はデエラーコード表示L2 バッガで状態変化させる必要あり
もしくは、ポットの蓋を空けずに水量を減らす治具が必要(4)テ ス ト ケ ー ス １ 件 あ た り の レ ビ ュ ー 時 間
テ ス ト ケ ー ス レ ビ ュ ー 時 間 は 組 織 標 準 比 60%と な り
短縮した。

…
…

テスト目的
ユーザ

テスト対象

論理性 ビリティ 性能 環境
機能
UC
…

○
○
…

○

…

機能×性能
×負荷

○

…

…

「テスト設計サマリ表」による
テスト対象、テスト目的の組合せと全体の分割検討

選択

…

…

○

○

機能×論理性×環境

ユースケース×
ユーザビリティ

入力条件
テスト対象
番号 機能
F-L給湯
E-01
…

フレーム毎
テスト観点マトリクスの選択

因子X
（水準）

…

…

テスト観点マトリクスによる因子の抽出（例）機能×論理性×環境マトリクス#1 #2 …
○ - ○
- ○ -

手順

期待結果

- - ○ 追加
○ ○ #1 #2 …

1 給湯
1 給湯実施2 急騰非実施○ - - ○ ○テスト
ケース
（手 順 書 ）因子組合せを検討し、デシジョン
テーブル作成、手順書へ展開

テスト詳 細 設 計

テスト実 装テスト開発プロセス全体像
表 11 プ ロ セ ス 単 位 の ヒ ア リ ン グ 結 果(5)テ ス ト ケ ー ス の 質抽出したテストケースの質を評価するために、同一の 機 能 に 、以 前 の 設 計 手 法 と 今 回 の 設 計 手 法 を 適 用 し 、
結果を比較して論理的な組合せの抜け・重複の確認を行った。

表 10 以 前 の 設 計 手 法 と 今 回 の 手 法 の 比 較

機能１

因子A
（水準）

テスト方 式 設 計

図 4

ケースA：テスト数（以前の設計手法）
10⇒評価：7件の抜け

チェックポイント
結果値 …

…

テスト分 析

テスト
対象

1 蓋センサ1 センサON
2 センサOFF
組合せ2 給湯ボタン押下時間
検討 1 100ms未満
2 100ms以上

テスト条件
環境 …

ケースB：テスト数（今回の設計手法）
16⇒評価：1件の抜け2
5⇒評価：2件の抜け ⇒評価：1件冗長あり
20
18⇒評価：3件の抜け機能３⇒評価：抜け無し
1件冗長あ
り
32
39
合計
⇒評価：12件の抜け ⇒評価：1件の抜け
機能２

ケ ー ス A が 以 前 の 設 計 手 法 を 用 い た 結 果 、ケ ー ス B
が今回の設計手法を用いた結果である。
ケ ー ス A に お い て 、組 合 せ に よ る 抜 け が 発 生 し て い

対象プロセス/担当者ヒアリング結果
テスト分析
全体の俯瞰性が良い。
関係者で合意を取りながら作業が出来た。
大きな範囲で、テストを行う対象の抜けを見つけることが出来た。
早期に目標とする品質を考えることが出来た。

テスト方式設計
レビュー観点がシンプル。
抽出すべき項目が分かりやすく比較的単純で作業に集中できる。
因子を抜き出すまでが目標となるため、作業の終了判断基準が明確だった。
フレーム単位で担当者を分担することが出来た。結果として、マネジメントがやりやすかった。
全体が見えやすいことから抽象化するポイントを発見しやす
く、テスト実装～実施時の作業効率化につながった。

テスト詳細設計、テスト実装
入出力のレビュー、組合せのレビューに分割して考えることが出来たため、レビューがやりやすい。
全てのデシジョンテーブルをレビュー出来た。
事前に因子を抜き出していたことにより、CFDによる組合せ
検討がやりやすかった。

また、担当者に手法に対するヒアリングを行った結果においても、手法の狙いに適合する結果が得られて
い る こ と を 確 認 出 来 た （ 表 11）。

るという状況が確認できた。
上記のように、今回の設計手法を用いることで論理的な検討が改善できることが判断できる。

6. 考 察次に 2 項に挙げた課題に対する対策結果を記載する。
（課題１）巨大なマトリクスになり作業性が悪い
マトリクスをフレーム毎に分割したため、最も大きい マ ト リ ク ス の 列 数 で 従 来 の も の よ り 半 減（ 15⇒ 8）した。ヒアリングでは、全体の見通しがよくなり因子の抽出作業が実施しやすくなったという結果が出ており、定量データではテスト成果物作成時間の低減に表れているものと思われる。

（課題２）テスト観点の定義が不十分
テスト目的毎に抽出すべき項目を細分化し、マトリクスの列見出しに定義した。ヒアリングでは、抽出すべき因子が分かりやすく作業しやすいという結果が出ており、定量データのテスト成果物作成時間の低減と因子の網羅度向上によるテスト密度向上に表れている。
表 10 の 比 較 結 果 か ら テ ス ト 設 計 漏 れ が 低 減 し た こ とも確認できた。また、レビューにおいてもポイントが明確になりレビューがしやくなったという意見があり、レビュー効率向上に繋がったと思われる。
（課題３）マトリクス作成後の作業が不明確
マトリクスに記載する内容を因子の列挙（テスト方式設計）とし、以降の因子組合せ作業（テスト詳細設計 ）、テ ス ト 手 順 を 足 し て テ ス ト 手 順 書 を 作 成 す る 作 業（テスト実装）を定義した。これにより、各成果物はガイドラインで定めた手法で一貫性を持って作成され、テストケースにおける粒度のばらつきは見られなかった。成果物作成効率化の面では、テスト方式設計において因子が具体的な入力値を含まない粒度であるため、類似パターンの流用が多く行え貢献が大きかった。また、方式設計の類似パターンはテスト詳細設計も流用でき、更に効率化できた。レビュー効率化の面では、
従来はテスト手順書で因子、因子組合せ、テスト手順のすべてをレビューしていたのに対し、段階的に詳細化する成果物毎にポイントを絞ってレビューすることができレビュー効率が向上したことが、ヒアリング・
定量データの両方で確認できた。また、従来テストケース全件のレビューが実施できていない工事もあった
が 、 今 回 の 2 工 事 は い ず れ も 100%レ ビ ュ ー を 実 施 できた。

7. 今 後 の 取 り 組 み(1)テ ス ト 実 施 結 果 の フ ィ ー ド バ ッ ク
テスト開発プロセスの適用は 1 順目の途中であり、テスト実施結果の不具合情報を分析し手法へのフィードバックを行う。
(2)テ ス ト の 網 羅 度 の 定 義
テスト設計結果の中身の良否を判断するために、何らかの基準に対する網羅度などの定義が必要である。
(3)テ ス ト 実 装 ～ 実 施 に お け る 効 率 化 の 実 施
今回のプロセス上では改善対象外となっている、テスト実装からテスト実施フェーズに対して効率的な方法を検討、実践する。
(4)展 開 拡 大手法の検討メンバを中心に主要工事での展開拡大を進めていく。

文献[1] 湯 本 剛 ，“ テ ス ト の 上 流 設 計 ”，ソ フ ト ウ ェ ア テ ス
ト PRESS Vol.10, pp.1-25, Sep.2010．
[2] 秋 山 浩 一 ，ソ フ ト ウ ェ ア テ ス ト 技 法 ド リ ル ，日 科
技 連 出 版 社 ,2010．
[3] 西 康 晴 ， JaSST’ 09 東 京 テ ス ト 観 点 に 着 目 し た テ
ス ト 開 発 プ ロ セ ス (VSTeP)の 概 要