機能モジュールに対する優先度に基づいた
選択的ソフトウェアテスト手法の提案
平山雅之 *1*2 ，山本徹也 *1 ，岡安二郎 *1
水野修 *2 ，菊野亨 *2
*1

(株)東芝

研究開発センター

システム技術ラボラトリ

phone : 044-549-2403
e-mail: masayuki.hirayama@toshiba.co.jp
*2

大阪大学

大学院基礎工学研究科

情報数理系専攻

あらまし 近年のソフトウェアシステムの応用範囲の拡大に伴い，ソフトウェアの開発規模も飛躍的に増大する傾向にある．
それと同時に，短い期間での製品開発が求められるようになっている．このような状況の下で，限られた時間内で効率的にソフトウェアテストを行う手法が必要とされている．本報告では，テスト対象となる機能に対して優先度の評価を行い，その評価結果に基づいてテスト仕様書の作成とテスト計画の作成をする「選択的テスト手法」を提案する．優先度の評価においては，構造の複雑さ，不具合の致命度などのプロダクト特性とレビュー充実度，開発者のスキルなどのプロセス特性を考慮している．テスト仕様書では優先度が高いほどチェックすべき具体的な項目を指示している．また，テスト計画では優先度が高い程，スキルを持った開発者が早めに実施するようにしている．
また，実際のソフトウェアテスト現場への適用実験を行った．その結果，提案する選択的テスト手法を用いたグループでは従来のテスト手法を用いたグループよりも多くの致命度の高い不具合を検出できることを確認した．
キーワード

ソフトウェアテスト，選択的テスト手法，テスト仕様書の設計，ソフトウェアメトリクス，優先度

A New Selective Software Testing Method Based on Priorities
Assigned to Functional Modules
Masayuki Hirayama *1*2 , Tetsuya Yamamoto *1 , Jiro Okayasu *1
Osamu Mizuno*2, Tohru Kikuno*2*2*1 R&D Center System Engineering Lab., TOSHIBA Corporation
Department of Informatics and Mathematical Science, Graduate School of Engineering Science, Osaka University

Abstract As software systems have been introduced to many advanced applications, the size of software systems
increases so much. Simultaneously, the lifetime of software systems becomes very small and thus their development isrequired to accomplish within relatively short period. In this paper, we propose a new selective software testing method thataims to attain the requirement of short period development. The proposed method consists of 3 steps: Assign priorities tofunctional modules (Step 1), Derive a test specification (Step 2), and Construct a test plan (Step 3) according to thepriorities. In Step 1, for development of functional modules, we select both product and process properties to calculate
priorities. Then, in Step 2, we generate detailed test items for each module according to its priority. Finally, in Step 3, wemanage test resources including time and developer’s skill to attain the requirement. As a result of experimental application,
we can show superiority of the proposed testing method to the conventional testing method.
Keywords Software testing, Selective software testing method, Testing priority, Design of testing specification, Software
metrics, Priority

11. はじめにテスト手法をここでは選択的テスト手法と呼ぶ．
我々は，ソフトウェアが提供する機能に関して，様々

ソフトウェア利用の拡大に伴い，開発されるソフトウ

な観点からテストの優先度付けを行い，それを利用してェアの規模も飛躍的に大きくなる傾向にある．
この結果，効率的にテストをする手法の研究を進めている．本報告

実装後のソフトウェアのテストに関しても，確認すべきでは，この優先度に基づいて，ソフトウェア機能を選択

機能や操作，あるいは動作が多岐にわたってきている[1]．

的にテストする手法の概要を提案する．また，実際の開そしてそのことが，テスト工数の増大を招いている[8]．

発プロジェクトへの適用事例をもとに，提案法の効果にしかし，一方でソフトウェア開発に充当できる開発期

ついて考察する．

間は限られており，現実には，テストの積み残しなどを引き起こす恐れさえ少なくない．
こうした傾向は製品組込みを前提とするマイコンソフ

2. 選択的テスト手法
2.1 概要トウェアで特に顕著である．例えば，近年の IT ブームを提案する選択的テスト手法は「機能の優先度決定」「テ

背景とした情報通信機器では，ソフトウェアが複雑化のスト仕様書の作成」「テスト計画の作成」の 3 つのフェ一途をたどっており，そのテスト作業は困難を極めていーズから構成される．図 1 にその概要を示す．

る．

選択的テスト手法では，まずソフトウェアシステムが提ソフトウェアのテストは，一般に単体テスト，結合テ供する機能にテスト優先度を付与する．そして，重要な

スト，
システムテストの 3 つに分けられる[5]．
この中で，機能ほど詳細にテストし，逆に優先度の低い機能についソフトウェアシステムが提供する機能が当初のシステムては軽めにテストをする．また，同時にこれらのテスト仕様に合致しているかどうかを判定するのがシステムテの実行順序も制御する．つまり，許されたシステムテスストである．近年のソフトウェアシステムが提供する機

ト期間を有効に使い，より短い期間で最大の信頼性を得能は膨大になっており，システムテストでテストすべきることを目指す．

機能も増加の一途をたどっている[8]．
ここでシステムテストに関する現状の課題は以下のよ

1) 機能の優先度決定

評価視点別メトリクス決定

重み付け戦略決定

うに整理できる．

優先度付き
機能リスト

(1) 機能が多岐にわたっており，テスト項目の全てを予め抽出することが難しい．
(2) 正常系の機能についてはシステム仕様書などを利用してテスト項目を抽出できる．しかし，異常系については仕様書に記述されないので，テスト項目とし2) テスト仕様書
の作成

優先度
大

小
中

アクティビティ図
逸脱解析
網羅

アクティビティ図網羅

ユースケース記述
テスト仕様書ての抽出が難しい．
(3) システムが実現する機能について，どこまでテスト

3) テスト計画の作成

テストリソース配分

すべきかの見極めが難しい．

テスト実施順序決定

テスト計画書(4) 限られた開発期間の中では，抽出された全てのテス
ト項目をテストするのが難しい．

図1

選択的テスト手法の概要

こうした状況の下で「限られた開発期間内で，ソフトウェアのより高い信頼性を如何に保証していくか」とい

2.2 機能の優先度決定

う命題については多くの研究がなされてきている[2, 3, 6,

ソフトウェアシステムが提供する各機能に対して，ユ9]．従来のソフトウェアシステムテストでは，機能やコースケースの情報などを分析して，テストに関する優先ードレベルで，網羅率を向上させる技術に主眼が置かれ度付けを行う．このとき，テスト優先度評価の視点およ

てきた．
しかし，
巨大化したシステムの開発においては，びメトリクスを利用する．この優先度の値を付加した機

ほとんど無限に近いテスト項目が必要となる[8]．又，こ能のリストを作成する．

れらを実際にテストするには同様に無限の時間が必要と2.3 テスト仕様書の作成なってしまう．このため，従来の網羅率偏重の考え方は成立しえない．
この場合に有望な方法として，「多くのテスト項目の優先度評価された個々の機能に対して具体的なテスト
項目を設計していく．そのときテスト優先度に応じて，必要なテスト項目の質や量を変化させる．

中から，実際に不具合を検出する率の高いテスト項目を優先度の高い機能については，必要に応じて，ユース

選りすぐって，効率良くテストする」あるいは「フィーケース記述を利用した正常ケースからの逸脱(デビエー

ルドでの影響がより深刻な不具合を確実に除去する」とション)解析なども行う[4, 10]．こうして詳細なテスト項

いったことが考えられる．こうした考えに基づいてテス目を抽出する．一方，優先度の低い機能については，ソト項目の選別を行う手法が述べられている[7]．こうした

フトウェア仕様書に記載された一通りの動作について確1

認するのにとどめる．この結果はテスト仕様書として整理される．

一方，不具合の発現についてはユーザがどのような場
面でどう利用するか，あるいはその利用頻度がどの程度なのかなどが大きく影響する．不具合の影響については，

2.4 テスト計画の作成
実際に利用できるテスト期間やリソースなどを考慮し発生した不具合がユーザにどのような影響を及ぼすかといった点を特に考慮する必要がある．

て，生成されたテスト項目の実行順序やテスト担当者の機能に対する優先度付けでは，不具合の混入，発現，割当を行う．限られたテスト期間内により高い信頼性を影響の各基本動作を念頭において，評価範囲として「S1:保証するためには，重要な不具合ほど早期に検出するこ

プロダクト特性」「S2: プロセス特性」の 2 つに分けてとが求められる．

考える．(図 2 参照)

このためテスト作業計画の作成では，テスト優先度を

範囲 S

視点 V

S1: プロダクト特性

V1: システム視点

メトリクス TM

考慮しつつ，一方でテストのしやすさなども加味した実行順序の決定を行う．また優先度の高い機能についてはスキルの高いテスト担当者を割り当てるといったことについても考慮する．これらはテスト計画書としてまとめ

V2: ユーザ視点

TM21: ユーザ利用頻度
TM22: 利用シナリオの複雑さ
TM23: 不具合致命度

V3: 開発者視点

TM31: 構造面からテスト
すべき度合いV4: 開発者スキル

TM41: スキル
TM42: 類似開発の経験

V5: 開発プロセス

TM51: レビュー充実度
TM52: 設計仕様の十分性
TM53: 単体テストの十分性

られ，実際のテスト作業への入力となる．

3. テスト優先度決定手法

S2: プロセス特性

3.1 概要ソフトウェア中に不具合が存在する確率は均一ではな

TM11: 機能構造の規模(LOC)
TM12: 複雑さ(CL)TM13: 新規性
TM14: 流用率

い．また，各不具合がソフトウェアシステムやユーザに与える影響も全てが同じではない．ここでは，「影響の大きい不具合がより多く存在する箇所を重点的にテスト

図 2 優先度評価の視点とメトリクス

する」ことでテストの効率を向上させることを目指す．
本手法ではこうしたテストを実現するため，複数の視点から評価を行い，テスト優先度を決定する．

(a) プロダクト特性
プロダクト特性はいわゆるソフトウェアプロダクトに

テスト優先度導出は次に示す 4 つのステップによって関する評価のためのメトリクスを含む．これはソフトウ実現される．

ェアとして実現される機能毎に決定される．

Step-1: テスト対象の機能の抽出

V1: システム視点

ソフトウェアの仕様書をもとに，テスト対象となる機

特に不具合の混入に関する評価として注目する必要が能をリストアップする．

ある．ソフトウェアの規模や複雑さ，あるいはソフトウ

Step-2: 評価視点の決定

ェアを構成する各部分の新規性や流用度合いなどを含む．

抽出した機能に対し，どのような視点からテスト優先
度付けを行うか，その視点を決定する．
Step-3: 評価メトリクスの重み付け

V2: ユーザ視点
ユーザ視点は不具合の発現と影響に深い関係をもっている．提供される機能を利用する立場から評価するもの

上記の視点毎に評価メトリクスを決定する．またそれで，ユーザの利用シナリオ(操作)の複雑さ，利用頻度，

ぞれの評価メトリクスをどの程度重視するのか(重み付

またその機能で発生した不具合の致命度などを考慮する．

け)についても決定する．
Step-4: 機能の優先度付け抽出した機能に対して，決定した重み付きメトリクスに基づいてテスト優先度を決定する．

例えば，携帯電話ソフトウェアを考えると，若年層とそれ以外の年齢層では全く異なった機能を重視する．
V3: 開発者視点
通常，開発者は担当した機能の構造や機能間の関連などを熟知している．また過去の不具合事例なども考慮し3.2 優先度付けのための評価視点
ソフトウェアの不具合に関する基本動作としては，不て，テストしておくべき機能についても良く知っている．
このように開発者から見てどの機能に重点を置いたテス具合の混入，発現，影響の 3 つが存在する．機能の優先トをすべきかを考慮するのが開発者視点である．

度付けでもこれらを考慮する必要がある．

(b) プロセス特性

不具合の混入に対しては，開発したソフトウェア自身

プロセス特性は不具合の混入に大きな影響を持つと考の機能規模や複雑さなどが大きく影響する．また同時にえられる．このためプロセス特性では，ソフトウェアでソフトウェア設計，実装段階での開発プロセスや開発者

実現する個々の機能の開発について，のスキルの影響も少なくない．

・どのようなスキルをもった開発担当者が開発したか2

・どのようなプロセスで開発を進めたかのメトリクスを重視するかを決定する必要がある．こうといった点を評価する．

した戦略はメトリクスに重み付けを行うことで実現する．

V4: 開発者スキルの視点

例えば，ある機能Kに関して，評価メトリクスTMijのソフトウェア不具合の原因の多くは開発者のスキルな値がXij, その評価メトリクスの重みをWijとする．テスト

どのせいにされる．同じ機能あるいは同じ複雑さを持つ

優先度は次の式で計算される．(ここでWijは重み係数で，ソフトウェアの開発であっても，スキルの低い開発者は0 ≦ Wij ≦ 1.0 の任意の値を設定する．）

不具合を多く作りこみ，そうでない開発者は不具合をほ

テスト優先度(機能K)＝ΣWij ×Xij

とんど作りこまない．

例えば，あるテストでユーザ視点(V2)を重視する戦略

V5: 開発プロセスの視点を採用する場合には，ユーザ視点に関するメトリクスで同じスキルの開発者であっても，適切な開発プロセスをあるユーザ利用頻度(TM21)，不具合致命度(TM23)などの利用したか否かによって不具合を作りこむ度合いは異な重み係数を 1.0 に近い値にすればよい．同時に，開発者ってくる．経験的には開発プロセスが不適切な場合，設視点(V3)などに対する係数を 0.2 程度にすればよい．

計や実装チェックなどが不十分になり，その結果としてまた，評価のためのメトリクス(図 2)は，その一部だけを利用することも可能である．例えば，プロセス特性を不具合を作りこむことが多い．

考慮しない場合には，プロセス特性に関するメトリクスの係数をすべて 0 とすればよい．

3.3 評価メトリクス
テスト優先度付けでは，各機能に上記のそれぞれの視点から見たテスト優先度を定量的に評価する．
このため，

例えば，
ワープロソフトの文書保存機能を考えてみる．
評価メトリクスとして

上記の各視点Vi毎に，これを計測，評価するためのメトTM12：機能構造の複雑さ

リクス(TMij)を用意する．
例えば，システム視点V1に関しては，TM11:機能構造のTM21：ユーザ利用頻度

規模(LOC)，TM12:複雑さ(CL:サイクロマティック数)，

TM23：不具合致命度

TM13:新規性，TM14:流用率などをメトリクスとする．
それぞれのメトリクス(TMij)は 1〜10 の値をとる．この 3 つを考え，それぞれの値をTM12=4，TM21=6，TM23=8の値はテスト対象となる機能間での相対的な評価と考えとする．また重み係数として，W12=0.2，W21=1.0，W23=1.0

る．例えば，システム規模は図 3 に示すように，LOCのを設定する．この文書保存機能に関するテスト優先度は大きさに従って，1 から 10 の間の値をつける．

0.2×4＋1.0×6+1.0×8=14.8 となる．

4. 適用実験
4.1 実験の目的

S1: プロダクト特性

ここでは選択的テスト手法の有効性を評価するために行った実験について紹介する．実験ではソフトウェア開V1: システム視点
TM11: 機能構造の規模

1: かなり小さい発の支援ツール(具体的には単体テスト支援ツール）の実際の開発に提案手法を適用した．

5: 平均的な大きさ

実験では図 4 に示すように，比較のために独立した 2
つのテストチーム A, B を用意し，それぞれに選択的テス

10: かなり大きい

トと従来方式のテストを行わせ，検出される不具合について比較した．ここで従来方式とは与えられるテスト仕様書の順番にテストを実行していくものとする．

図 3 メトリクス評価の例

この実験の目的は，選択的テスト手法では機能に優先度を付け，この優先度に応じてテストの詳細度(入力のバ

3.4 テスト戦略

リエーションなど))を変えることで，重要な不具合が多機能の優先度付けに関しては上記のように様々な視点く検出されること(一方，従来方式のテストでは，選択的を考える必要がある．しかし，例えばエンドユーザが重テスト手法に比べて重要な不具合の検出率が低くなって視する機能と開発担当者がテストした方が良いと考えるいるということ)を確認することである．

機能とは，必ずしも一致しない．またプロセスの視点から見てテストをするとよい機能とも一致するとは限らない．このため一つの視点からの評価ではなく，複数視点からの評価結果を総合的に判断することが必要となる．
実際のテストにおいては，どの視点を重視するか，ど3テスト担当チームA

テスト担当チームB

実験コーディネータ

テスト仕様書の作成

ソフトウェア仕様
従来法による
テスト項目作成

提案法

テスト計画書B (PB)

機能の優先度決定
テスト仕様書の作成
テスト計画の作成

テスト計画書A (PA)
テスト実施

テスト対象ソフトウェア

PAの下でのテスト

PBの下でのテスト検出された不具合(χA)

検出された不具合(χB)

デバッグ
新しい版のソフトウェア

図 4 実験の概要
テスト仕様書 A の中では各機能項目について，優先度を4.2 実験対象のソフトウェア

3 段階(高，中，低)で明記した．このテスト仕様書 A で今回のテストでは単体テストを支援するツールを対象

テストチーム A にテストをするように指示をした．なおとする．本ツールは，テスト対象を選定する機能，テス

テスト仕様書 B はテストチーム B が利用した．

トデータを自動生成する機能，スタブ/ドライバを自動生(3) テストの実施成する機能，などを含む．主な特性を次に示す．

実際のテストでは，テストチーム A，B はそれぞれ独

使用言語：

C 言語

立してテストを実施した．テスト期間は 1 サイクルを 1規模：

30KLOC

週間程度として，これを 3 回くり返した(図 5 参照)．

新規性：

全てが新規開発

各サイクル内で両チームによって検出された不具合は，サイクルの終了時点でまとめて開発担当者にフィードバ

4.3 実験方法

ックされ，修正・デバッグ作業を行った．この作業を終(1) テストチーム

えた時点で，再び次のサイクルのテストに着手する．そ独立した 2 チーム A と B が，それぞれ，選択的テスト
手法，従来方式のテスト手法を利用してテストする．今

こでは前回と同じテスト仕様を用いて，新しい版のソフ
トウェアについてテストを行う．

回の実験ではそれぞれのチームの担当者のソフトウェア
開発経験,スキルなどはほぼ同じレベルにし，能力差はほチームA:
優先度付きテスト項目

チームB:
従来テスト項目

サイクル 1

とんど生じないようにした．
またソフトウェアの設計，実装はテストとは別のグループが担当した．更に，これらのグループとは別に，ソフトウェア仕様の作成者がテスト実験コーディネータとして実験全体の調整を行った．
(2) テスト仕様書作成
まず，ソフトウェアの仕様書に基づいてグループ B の担当者が従来方式の考えでテスト仕様書 B を作成した．
次に，テスト実験コーディネータがテスト仕様書 B につ別チームによるデバッグ (χA ∪ χB について)

チームA:優先度付きテスト項目

チームB:
従来テスト項目

サイクル 2

別チームによるデバッグ (χA ∪ χB について)

チームA:優先度付きテスト項目

チームB:
従来テスト項目

サイクル 3

別チームによるデバッグ (χA ∪ χB について)

いて確認した後，ソフトウェアの機能の優先度付けを行った．続いてこの結果をもとに選択的テストのためのテ

図 5 テスト実施の詳細

スト仕様書 A を作成した．

4

テスト戦略致命度 利用頻度 複雑さ
0.33333 0.33333 0.33333
機能ID 大項目
9 プロジェクトウィンドウ
2 メイン
42 テストケースと結果ウィンドウ
1 メイン
0 起動
34 具体値設定ダイアログ
23 生成パターンウィンドウ
30 具体値設定ダイアログ
31 具体値設定ダイアログ
63 具体値設定ダイアログ
7 プロジェクトウィンドウ
8 プロジェクトウィンドウ45 テストケースと結果ウィンドウ58 テスト実行ダイアログ
28 生成パターンウィンドウ54 テストケースと結果ウィンドウ40 構造体初期化ダイアログ
6 プロジェクトウィンドウ38 構造体初期化ダイアログ
64 構造体初期化ダイアログ
21 コピー先関数選択ダイアログ
48 テストケースと結果ウィンドウ55 テストケースと結果ウィンドウ16 プロジェクトウィンドウ

機能名
中項目
最新の情報に更新
プロジェクトを開く
一通りの表示プロジェクトの新規作成
起動
具体値編集
一通りの表示
ランダム
境界値
表示
ツリーの展開、折り畳みプロジェクトにソースの追加
行選択(一行、複数、全行)
実行
生成パターンの上書き保存
テストケースの上書き保存
更新
一通りの表示編集
表示
他の関数にコピー
値の編集(基本型の時)テストケースの別ファイルへの保存(テストパターン)削除

図６

致命度

システム特性値
利用頻度 複雑さ
8
6
9
8
5
10
6
10
7
10
2
9
10
5
3
6
7
5
6
5
7
5
7
6
7
4
7
6
8
4
5
10
2
7
2
8
4
10
3
7
6
3
9
3
3
8
4
3
7
2
6
6
5
4
6
4
5
6
4
5
6
2
7
5
4
6
6
4
4
6
3
5

Score
7.666667
7.666667
7.666667
7
6
6
6
6
6
6
5.666667
5.666667
5.666667
5.333333
5
5
5
5
5
5
5
5
4.666667
4.666667

テスト対象の機能

4.4 機能の優先度付け
ここでは選択的テスト手法による機能の優先度付けの

5. 実験結果

評価点と評価メトリクスを示す．今回の実験では，特に以降では，1 つのテスト項目で検出された不具合はまプロダクト特性のユーザ視点(V2)に絞って評価を行った．

とめて 1 件と数えることにする．したがって，不具合の実験では各機能の利用頻度(TM21) ,利用シナリオの複雑さ(TM22）および不具合致命度(TM23)を評価メトリクス
として採用した．各機能毎の評価メトリクスの値は，実験コーディネータがその動作仕様から概要・特徴などを考慮して決定した．

件数と不具合を検出したテスト項目数は一致する．
5.1 検出された不具合の数
表 1 (a)〜(c)に各サイクルにおける不具合の検出の状
況を示す．
(1) サイクル-1: 選択的テストと従来方式を合わせるとまたテスト戦略としては各評価メトリクスに均等な重優先度=大として検出された不具合の数は全部で 14 件でみを与えることにした．したがって，各機能のテスト優あった．このうちの約 8 割を選択的テストで検出した．

先度は 0.33×TM21+0.33×TM22+ 0.33×TM23 を利用して従来方式と選択的テストでともに検出されたものは 5 件求めることができる．

である．

4.5 テスト仕様書

従来方式で検出された優先度=大の不具合の数は 3 件で一方，選択的テストでは未検出であるにもかかわらず，
各機能に対して評価点をつけ，優先度順にソートしたあった．
その原因について詳細に調査したところ，本来，機能の一覧を図 6 に示す．優先度が 5 以上のものを優先

優先度=大であるため，テストに関する詳細な指示があ度=大，4 以上で 5 未満のものを優先度=中，4 未満のものを優先度=小とする．優先度別のテスト項目数につい

表 1 検出された不具合の総数ては，優先度=大の項目が 118，優先度=中の項目が 51，
優先度=小の項目が 56 となった．

(a)

χA
χB
χA ∩ χBχA ∪ χB

またチームA向けに用意したテスト仕様書Aの一部を
図 7(a)に示す．同図に示すように，テスト仕様書 A の優先度が高い機能のテスト項目には，どのような点を重視(b)ションなどに関する具体的な指示を与えている．一方，
トで十分であることが明記されている．一方，図 7(b)に示すように，チーム B 向けのテスト仕様書 B にはどの項目にも特別な指示は与えられていない．

サイクル2
χA
χB
χA ∩ χBχA ∪ χB

してテストをするべきか，あるいは，テストのバリエー
優先度の低い機能に対するテスト項目には，軽めのテス

サイクル1

(c)

サイクル3
χA
χB
χA ∩ χBχA ∪ χB

大
11
8
5
14

優先度
中
3
2
2
3

小
5
7
4
8

計
19
17
11
25

大
9
4
0
13

優先度
中
1
2
0
3

小
5
5
3
7

計
15
11
3
23

大
6
0
0
6

優先度
中
0
1
0
1

小
2
1
1
2

計
8
2
1
9

χA: チームAのテスト項目で発見された不具合χB: チームBのテスト項目で発見された不具合5

(a) 選択的テストのテスト仕様書A
項目
番号

試験項目

期待される結果

合否

1

生成パターンウィンドウを起動する[既存開く，新規の両方に対して行う．
具体値設定は全てのタイプ(引数，グローバル，スタブ)について行う](1) 変数名，型，具体値生成方針，具体値，ループ生成方針の各欄が表示される．
(2) テスト対象関数で使用している引数，グローバル変数，スタブ関数の名前がこの順に変数名の欄に一覧表示される．
(3) テスト対象関数から呼び出される関数で使用されるグローバル変数とスタブ変数の名前も変数名の欄に表示される．
優先度=高の項目に対する指示
優先度=高の項目に対する指示
(4) …

2

行を選択してダブルクリックする．
[基本パターンのみでOK]

具体値設定ダイアログが表示される．ただし，1の(7)(8)に該当する場合は，ダイアログは表示しない．

3

行を選択して編集メニューの項目「詳細設定」を選択する．
[基本パターンのみでOK]

2と同じ結果．

優先度=低の項目に対する指示
優先度=低の項目に対する指示(b) 従来法式のテスト仕様書B
項目
番号

試験項目

期待される結果

合否

1

生成パターンウィンドウを起動する(1) 変数名，型，具体値生成方針，具体値，ループ生成方針の各欄が表示される．
(2) テスト対象関数で使用している引数，グローバル変数，スタブ関数の名前がこの順に変数名の欄に一覧表示される．
(3) テスト対象関数から呼び出される関数で使用されるグローバル変数とスタブ変数の名前も変数名の欄に表示される．
(4) …

2

行を選択してダブルクリックする．

具体値設定ダイアログが表示される．ただし，1の(7)(8)に該当する場合は，ダイアログは表示しない．

3

行を選択して編集メニューの項目「詳細設定」を選択する．

2と同じ結果．

図 7 テスト仕様書
たえられるはずであるが，この指示が不明確で結果的に示す．なお，表 2 では重複する不具合は除いている．

は従来方式と変わらなかった．また，優先度=小の不具
表 2 不具合を検出したテスト項目

合は全部で 8 件検出されたが，このうちの 9 割を従来方式で検出している．
(2) サイクル-2: 検出された不具合の総数は 23 件となっており，サイクル-1 とほぼ同数であった．この 23 件の不具合の内訳について分析すると，次の 3 種類に分類で

優先度
大
中
小
合計

総数
26
6
13
45

選択的テストで検出したテスト項目数
22
85%
4
67%
7
54%
33
73%

従来方式で検出したテスト項目数
11
42%
4
67%
12
82%
27
60%

きることが分かった．
a.
b.
c.

サイクル-1 の時点では未実装であった新しい機能

優先度=大の 118 個のテスト項目の内で，選択的テス(ソフトウェア)に関する不具合

トでは 22 項目で不具合を検出した．一方，従来方式ではサイクル-1 での不具合の修正に起因する新たな不11 項目で不具合を検出した．優先度=大で不具合を検出

具合したテスト項目の総数は 26 個なので，このうちの 85%

サイクル-1 での不具合の修正漏れを選択的テストで検出したことになる．一方，従来方式

このうち，b.または c.と見なされる不具合は 6 件であった．

は 42%を検出したにとどまっている．
また，優先度=中の 51 個のテスト項目に関しては，従このサイクル 2 でも優先度=大の不具合 13 件のうち，来方式，選択的テストともにそれぞれが 4 項目で不具合

選択的テストでは約 7 割を検出している．一方，従来方を検出している．なお，不具合を検出したテスト項目の式では 4 割強にとどまっている．

総数は重複を除くと 6 個であった．一方，優先度=小の(3) サイクル-3: 2 回のテストにより不具合の多くが除去

56 個のテスト項目に関しては選択的テストと従来方式された状況で，最終の確認テストとして実施した．こので検出した不具合の総数は 13 個であった．
このうち選択サイクル 3 で検出された不具合の総数は 9 件である．そ的テストでは７個(54%），従来方式では 12 個(92%）でのうち約７割を優先度=大の不具合が占めており，その検出している．

全てを選択的テストで検出している．検出された不具合の半分はサイクル-2 での修正ミスであった．

5.3 所要工数

5.2 不具合を検出したテスト項目

工数に関しては，従来方式と選択的テストの平均時間の今回の実験でテスト作業に要した工数を表 3 に示す．
表 2 に 3 つのサイクルを通しての不具合の検出状況を

6

間には有意な差は見られなかった1．

それに基づいてテスト計画書を作成する．
また，この提案手法を実際のソフトウェアのシステム

表 3 所要工数

サイクル 1サイクル 2サイクル 3

選択的テスト
(時間)
30
25
13.5

テストに適用して実験的評価を行った．実験ではプロダクト特性からの評価を基にした優先度付けを行った．そ

従来方式
(時間)

の結果，重要な機能のテストに十分な工数を投入するこ
33
23
22

とが可能になり，不具合が確実に検出できることを確認した．
今後の課題としては，プロセス特性からの評価を優先
度付けに反映させること，テスト戦略に関しての各メト

6. 評価
6.1 テスト項目に対する具体的な指示の影響
選択的テストでは優先度の高い機能に対するテスト項

リクスに対する重み付けを決めること，などがある．

参考文献

目にはテストに関する具体的な指示をした．こうするこ[1] B. Beizer, Black-box Testing: techniques for functionalとによって，テストの質をコントロールする試みを行っ

testing of software and systems, John Wiley & Sons, 1995.

てきた．先の結果を見ると，優先度=大のテスト項目で[2] D. M. Cohen, S. R. Dalal, J. Parelius and G. C. Patton,

は，選択的テストが従来方式に比べて約 2 倍近くの不具“The combinatorial design approach to automatic test

合を検出していることが確認できた．また優先度=中のgeneration,” IEEE Software, vol.26, no.9, pp.83-88, 1996.

テスト項目については選択的テストでも特に指示を与え[3] P. D. Coward, “A review of software testing,” Informationていない．その結果、不具合検出率の上では優先度＝大and Software Technology, vol.30, no.3, pp.189-198, 1988.

のものほどの大きな差異は見られない．さらに優先度＝[4] M. Hirayama, T. Yamamoto, T. Kishimoto, O. Mizuno,

小のテスト項目については優先度＝大のものとは逆に従and T. Kikuno, “Generating test items for checking illegal

来方式の方が多くの不具合を検出している．

behavior in software testing,” Proc. of 9th Asian Test

このように選択的テストによって，システムの重要な

Symposium (ATS2000), pp.235-240, 2000.

部分の不具合の効率的な検出が可能となる．一方，仕様[5] M. R. Lyu, Handbook of Software Reliability Engineering,

書順にテストしていく従来方式では，システムの重要な

McGraw-Hill, 1995.

機能や部分に対して必ずしも十分なテストが行われると[6] Y. K. Malaiya, “Antirandom testing: Getting the most out

いう保証がなく，結果として不具合の取り残す可能性もof black-box testing,” Proc. 6th International Symposium on

ある．

Software Reliability Engineering, pp.86-95, 1995.
[7] D. M. Marks, Testing Very Big Systems, McGraw-Hill,

6.2 テスト期間の効率的な利用表 1〜表 3 より，選択的テストでは重要な機能に関す

1992.
[8] I. Sommerville, Software Engineering, 4th edition,

るテスト項目に重きをおいた時間の利用がなされており，

Addison-Wesley, 1992.

効率的に不具合を検出していることが分かる．特に，サ[9] W. E. Wong, J. R. Horgan, S. London, and A. P. Mathur,

イクル-3 では従来方式よりも短い時間で優先度の高い不“Effect of test set minimization on fault detection

具合を集中的に検出していることが推測できる．一方，effectiveness,” Proc. of 17th International Conference on

従来方式のテストでは重要度に関係無く均等に工数を割Software Engineering (ICSE’95), pp.41-50, 1995.

くために，テスト効率面では必ずしも最適ではない．

[10] 平山他, “UseCASE を利用したソフトウェアフォー

今回の実験からは，プロダクト特性から優先度をつけテストの詳細度を変えるだけでも，テスト時の不具合のルトに対する SS-FTA の提案”, 電子情報通信学会 SS 研
究会，SS99-53，2000.

検出の状況を大きく変えることが可能であるとの結論が得られた．ここで更にプロセス特性も加味することで，より一層の効率の向上が期待できる．

7. まとめと今後の課題
本報告ではソフトウェアのシステムテストを効率化す
る選択的テスト手法について報告した．選択的テスト手法では機能の特性分析を行い，機能の優先度付けを行い，
1有意水準 5%の統計的仮説検定による．
7

8