Use CASEを利用したソフトウェアフォールトに対する SS-FTAの提案
平山雅之 *1,2 ，岸本卓也 *3 ，水野修 *2 ，菊野亨 *2
研究開発センター*1 (株)東芝

システム技術ラボラトリ

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

あらまし*2 大阪大学

大学院基礎工学研究科*3 (株)東芝

家電機器社

情報数理系専攻

研究開発部

ソフトウェアシステムへの依存度が高まるにつれ，高い水準の信頼性がそれらのソフトウェアに求められるようになってきている．ソフトウェアの信頼性は主にテストの繰り返しによって確保されるので，そこで利用されたテスト項目によって保証される信頼性のレベルは大きく異なってくる．このため信頼性の観点から最適なテスト項目を求めることがソフトウェア開発現場におけるテストフェーズでの重要な課題の一つとなっている．本論文ではテスト項目の作成のための新しい方法を提案する．提案法ではまずテスト対象となるソフトウェアの振舞いをユースケースで記述する．次にそのデビエーション分析を行い，ソフトウェアのフォールト木を作成する．このフォールト木を利用してテスト項目の集合を作成する．
提案法と従来法で作成されたテスト項目を比較評価した結果，従来のテスト項目に対する重複や抜けを提案法では効率的に検出・指摘できることを確認した．

キーワード

ユースケース，テストケース設計，FTA

Generating Test Items by Applying Software Fault Tree Analysis
Masayuki Hirayama*1,2, Takuya Kishimoto*3
Osamu Mizuno*2, Tohru Kikuno*2*1 R&DCenterSystemEngineeringLab.,TOSHIBACorporation*2 DepartmentofInformaticsandMathematicalScience,GraduateSchoolofEngineeringScience,OsakaUniversity*3 R&DGroup.HomeApplianceCompany. TOSHIBACorporation
Abstract

Recently software systems are extensively used in our social life and then high reliability is required to be attained in such

software systems. Generally, software testing is a key approach toward high reliability and thus the resultant reliability deeply depends
on the quality and quantity of test items used in software testing.
In this paper, we propose a new method for generating test items. The proposed method consists of the following steps: (1) Describe
software behavior using Use-case notation, (2) Apply deviation analysis to the description, (3) Construct software fault tree using
analysis result, and (4) Generate test items based on software fault tree. As a result of experimental evaluation, it is shown that theproposed method can detect both the overlapping and the lack of test items obtained by conventional method.
Keywords Use CASE, Test Case Design, Fault Tree Analysis

1１

まえがき

を考えた場合，その不具合によるフィールドへの影響が大き

近年，ソフトウェアシステムへの依存度が急速に高まり，いものと小さいものがある．これは対象ソフトウェアが実現

これに伴いより高い信頼性がソフトウェアに求められるようする”機能”間にも重要なものと，付帯的なものなど様々な重になっている．ソフトウェアの信頼性は一連の開発作業の中要度が設定できることを意味している．現状のソフトウェアのテストフェーズでの作業によって確保される．このためよのテストを考えた場合，こうした機能の重要度や発生不具合り高い信頼性レベルを保証しようとする場合，対象とするソの影響度，あるいは不具合の混入率などを体系的にとらえてフトウェアに関してどのような項目についてテストを行うかテストケースを作成することはほとんどない．このため本来が重要な課題になる．ソフトウェアに対するテスト項目を定は不具合が余り混入していない箇所を，又は製品ソフトウェめる作業は，”テストケース設計”として認識される．このテアにとってさして重要でない箇所を一所懸命にテストするとストケース設計に関してソフトウェアの信頼性を考慮した手いった的外れなテストが行われる場合も少なくない．

法は必ずしも十分に整備されているとは言い難い．

(2) 網羅率に偏重したテスト[3]ソフトウェアのテスト項目は，一般的にそのソフトウェア従来のソフトウェアテストでは，対象とするソフトウェアで実現が求められている機能仕様や動作仕様などをもとに作の論理的動作や機能を極力網羅することが至上命題として与成される．従来の研究の多くはフォーマルな形式で表現されえられ，網羅率をあげる方式が重視されてきた．しかし，近たソフトウェア仕様をもとに網羅的なテストケースを生成し年のソフトウェア規模の増大に伴い，ソフトウェアが実現すていた[1]．これらの方法は制約条件が厳しく必ずしもあらゆる全ての動作を網羅してテストケースを作成することは難しるタイプのソフトウェアに当てはまるものではなかった．

くなりつつある．また仮にこうしたテストケースの全てを作本研究では自然言語で記述されたソフトウェア仕様を対象成できたとしても，限られたテスト期間内にこれらの膨大なに，デビエーション分析技術や FTA(Fault Tree Analysis)のソテストケースの全てをテストすることは実質上も不可能に近フトウェアへの適用を試みる．具体的にはこれらの技術を融い．網羅率に依存したテストでは最悪の場合，システムの信合した新しいソフトウェアテストケース設計方法論の整備を頼性にとって最も重要であるテスト項目が作成されなかった目指している．

り，時間切れでテストされなかったり，という深刻な事態を

本報告ではこのテストケース設計方法論のうちで特にソフ引き起こしかねない．

トウェア FTA の実施方法に焦点をあてた提案をする．提案
する方法では自然言語で記述されたソフトウェア仕様書にも(3) 不具合経験の体系的な利用とづき，信頼性の観点からソフトウェアの代表的な動きを通常の製品ソフトウェア開発では過去に類似した開発を踏UML(Unified Modeling Language)[2]で提案されているユースまえたものが多い．この場合，過去の類似開発で発生した不ケース記述を拡張した記法で表現する．次にこのユースケー具合を参考にして，テストケースの作成などを行う必要があス記述に対してデビエーション分析の技術を適用して異常動る．しかし実際の開発現場ではこうした過去の不具合を体系作の要因分析を行う．この要因分析に基づいてソフトウェア的に分析し，次回以降のテストケースに反映するための手法に対するフォールト木を作成する方式を提案する．最後に，が整備されていない．そのため必ずしも十分にこうした過去ソフトウェアフォールト木の分析を行ってソフトウェアのテの不具合の経験がテストケースに反映されていない．なお不スト項目を導く．本報告では，実際の冷蔵庫制御ソフトウェ具合の分析手法として FTA(Fault Tree Analysis)が代表的な手アの一部を題材に用いて，上記の方法論を検討した結果を示法として知られている．これまで FTA は主にハードウェアすとともに，ソフトウェアフォールト木から導き出されたソの故障分析に利用されてきており，FTA をソフトウェアに適

フトウェアのテスト項目の評価結果についても紹介する．

用するためには分析手順などの見直しと整備が必要となる．
(4) テストケース作成作業

2. 従来のソフトウェアテストの問題点
従来のソフトウェアテストに関しては次に示すような問題

ソフトウェアのテストケースは，一般にソフトウェア動作仕様をもとに作成される．通常，自然言語で記述されたソフが考えられる．

トウェア動作仕様をテストケース作成担当者が理解し，テス(1) 不具合の存在確率の違いトケースを逐次的に生成する．そのためこの作業には多大なソフトウェアの不具合は一般に対象ソフトウェアの各部分労力を要する．さらに，これらのテストケース作成の作業をにおいて均一には存在しない．即ち，ソフトウェアの部分に行う担当者のスキルによって，作成されるテストケースの質よって不具合が混入しやすいところと，しにくいところがあにばらつきが生ずるといった問題がある．また，こうして作る．例えば，新人の作成した部分や新規開発した部分には不成されたテストケースについては抜けや重複が発生すること具合が混入しやすく，ベテランが作成したり過去のソフトウも少なくない．

ェアを流用した部分には不具合が少ない．また個々の不具合

2

3. テストケース設計手法の概要

Step-3 :デビエーション分析

ここでは 2 節で述べた課題の解決を目標としたテストケース設計手法について紹介する．

3.1

ユースケース記述で明確にされたソフトウェアの基本動作に対し，異常な状況下での動作をデビエーションとして抽出全体の流れする．更に，これらの基本動作から逸脱して異常をきたす動提案するソフトウェアテストケース設計手法(S-TEMRA:作も抽出する．デビエーションは安全性工学[4]の領域で利用

Selective Testing Method based on Reliability Analysis) の全体のされている概念で，”逸脱”を意味する．ここではデビエーシ

流れを図 1 に示す．S-TEMRA は図 1 に示すように全体で５ョン抽出の手法として N. Leveson らが提唱している「ガイドつのステップから構成される．

ワード」[5]を利用する．

Step-1: ソフトウェアシステムの動作仕様の理解

Step-4: システム＆ソフトウェア故障分析(SS-FTA)

Step-2: ソフトウェア動作のユースケース記述

デビエーション分析の結果を利用し，ソフトウェアに対す

Step-3: デビエーション分析

るフォールト木 (SS-FTA : System and Software FTA) を作成

Step-4: システム＆ソフトウェア故障分析(SS-FTA)

する．SS-FTA では Step-2, 3 での分析結果に含まれる用語をStep-5: テスト項目の抽出利用して，対象ソフトウェアにとって望ましくない事象が起

3.2 各ステップでの処理きるケースをソフトウェアの内部処理と関連付けて分析する．

Step-1: ソフトウェアシステムの動作仕様の理解

ソフトウェアフォールト木のルート(最上位)事象としては当

ここではテスト対象となるソフトウェアシステムがどのよ

該ソフトウェアにとっての望ましくない事象を選ぶ．実際にうな構成で，どのような動作を行うかについて概要理解を図

は過去の類似開発において発生した不具合の中からフィールる．そのための道具として，ソフトウェアの機能構成を可視ドへの影響度などを考慮して決定する．

化するソフトウェアブロック図，および，ソフトウェアが影

Step-5: テスト項目の抽出

響を及ぼしたり受けたりする周辺のハードウェアに関するブ

SS-FTA の結果を利用して，ソフトウェアフォールト木のロック図を利用する．ソフトウェアブロック図に関しては一リーフに記載された要因を抽出し，この要因をチェックする

般的なデータフロー図などで代用しても構わない．

テスト項目を作成する．こうすることによって，対象ソフト

Step-2: ソフトウェア動作のユースケース記述

ウェアにとって望ましくない事象を引き起こす全ての要因に対象ソフトウェアが実現する機能の代表的な動作や信頼性対するテストが可能となる．

上重要となる動作をユースケース記述を利用して明確にする．

S-TEMRA は上記に示した 5 つの段階を経て最終的にソフ

ユースケース記述はオブジェクト指向開発方法論 UML [2]のト ウ ェ ア 信 頼 性 を 考 慮 し た テスト項目を生成する．なお

中で提案されたソフトウェア動作の記述表現形式の一つであStep-2, 3, 4 の分析が担当者の技量に依存することを少なくする．ここではこのユースケース記述の表現形として，後述するために，分析過程で利用した用語を統一し，用語辞書の形る拡張アクティビティチャートを利用する．

で管理することも合わせて採用する．

製品
仕様書

用語整理
Step-1システム動作機能 理解＆分析

HW/SW ブロック図
ユースケース記述・フリーフォーム・拡張アクティビティチャート

Step-2
ユースケース分析
Step-3
デビエーション分析
Step-4システム＆ソフトウェア故障分析

ソフトウェア
テスト項目

Step-5
テスト項目抽出

図１

ソフトウェア
フォールト木全体の流れ

3

４． テストケース設計手法

図 3(a)は冷蔵庫制御ソフトウェアの基本動作を拡張アクテ

ここでは冷蔵庫制御用ソフトウェアを例に，ユースケースィビティチャートで表記したものである．基本アクティビテ

記述，用語整理，デビエーション分析，ソフトウェアフォー

ィ「自動給水, 実施（する）」「製氷，実施（する）」など

ルト木作成の各段階について詳細に説明する．

が順次実行されることが分かる．また，図 3(b)はこの「自動4.1

ユースケースの分析

給水，実施（する）」をさらに詳細に展開記述したものであ冷蔵庫制御用ソフトウェアの製氷機動作に関するユースケ

る．ここでは「給水タイマ, X 秒 SET する」「給水モータ，ース記述を図 2, 3 に示す．ユースケース記述では，図 2 のよ正回転する」などの下位のアクティビティを利用して順次詳うな自然言語によるフリーフォームのユースケース記述を作細化を進めている．

成した後に，図 3 に示す拡張アクティビティチャートを利用<給水動作||失敗>

自動給水実施して記述する．

<給水検知動作||失敗>(a) フリーフォームによるユースケース記述

給水検知実施フリーフォームによるユースケース記述では唯一の記述制[給水動作||正常終了]

約として，機能動作の前提条件，サブ機能名，機能動作の詳

製氷実施

細記述という枠組みを設けている．例えば，製氷動作では「製氷皿に水，氷が入っていない」という前提条件のもとで，[製氷動作||開始]

大きな動作の流れとして「給水動作」「製氷動作」「離氷動

製氷検知実施作」「製氷装置水平戻し動作」が順次実行されることが分か[製氷検知||正常終了]-- 氷有るときる．また，「給水動作」では<給水, X 秒実施>などの個別動離氷実施

作が[給水タイマ, X 秒設定], [給水モータ, 正回転]などの操作によって順次行われ，一つの動作として完結していく．

[製氷装置水平位置出し||正常終了]<離氷動作||失敗>[離氷動作||正常終了]

製氷装置水平位置戻し実施

機能動作 ：製氷機能
継続動作のなかで（前回サイクルにおいて離氷動作完了後）
製氷皿に水、氷が入っていない状態で前提条件

サブ機能[製氷装置水平位置戻し||失敗]

機能動作の詳細（振舞い）
振舞い-11 製氷皿
振舞い-12 給水後給水動作(a) 全体記述[給水タイマ,X１秒設定] [給水モータ,正回転][給水タイマ.X２秒設定] [給水モータ,逆回転]

振舞い-21 給水完了後 [製氷動作,開始する]
振舞い-22[皿温度 -T以下] [製氷動作,完了] [離氷動作開始]

製氷動作

離氷動作

製氷装置水平戻し動作

自動給水||実施する

振舞い-31
振舞い-32
振舞い-33[製氷皿,Z2度回転] [貯氷検知動作、開始][貯氷室,満杯でない] [離氷動作,継続][製氷皿,正回転Z2度]

振舞い-41[皿タイマ,X3 秒設定] [製氷皿水平戻し動作,開始] [皿回転モータ、停止][製氷皿水平位置出し動作,開始]

図2

Activityの詳細化<給水タイマ||設定失敗>

給水タイマ
Xsec SETする[給水タイマ||正常設定]

ユースケース記述（フリーフォーム）

給水モータ
正回転する

(b) 拡張アクティビティチャートによるユースケース記述

給水モータ
停止する

[給水モータ||回転正常] &[給水タイマ||終了]

次に，フリーフォームのユースケース記述を参考に拡張ア[給水モータ||停止]

給水タイマ
X sec SETする[給水モータ||回転異常]

クティビティチャートを作成する．

＜給水モータ||停止失敗><給水タイマ||設定失敗>[給水タイマ||正常設定]

アクティビティチャートは UML でその記述様式が定められているが，S-TEMRA では信頼性要求分析のしやすさなど(b) 詳細記述を考慮して以下の拡張を加えた．
・個々のアクティビティは，例えば「自動給水を実施する」

図3

ユースケース記述 (拡張アクティビティチャート)というように「XX を YY(する)」という形式で整える．
・アクティビティのトリガーについてはソフトウェアの制御対象オブジェクトとそれがとり得る状態に着目し，[給水モータ|回転正常]などのように記述する．

4.2

用語の共通化

ソフトウェア故障分析では分析担当者が異なった場合に分析の粒度が異なる可能性がある．このため SS-FTA ではソフ・拡張アクティビティチャートではソフトウェアの基本動作

トウェアのユースケース分析，デビエーション分析，フォー(アクティビティ)の流れを矢印→で記述し，これに対して，ルト木作成の各段階で利用される用語に制約を設け，共通化個々のアクティビティに関する異常動作を矢印を図る．こうすることによって分析担当者による粒度の違いで記述する．こうすることによって，ソフトウェア異常動作をを最小限に押さえている．

明示する．

4用語は[オブジェクト||とり得る状態]という基本的な枠組み仕様に対する異常を導き出すためのキーワードである．

で整理する．用語の共通化を進めるため，まず，オブジェク

図 4 はガイドワードの一例を示したものである．これ以外のトの洗い出しをおこない，次いでこれらのオブジェクト毎のガイドワードについても次に示すようなソフトウェアの動作とり得る状態の洗い出しを行う．

状況を念頭において用意する．
・周辺ソフトウェアの故障(a) オブジェクトの洗い出し”オブジェクト”としては制御用ソフトウェアの制御対象となりうる次のようなものを考える．
ファンクション・オブジェクト
ソフトウェアが提供，実現する機能そのもの．例えば，「製氷動作」「離氷動作」などを指す．

・周辺ハードウェアの故障
・ソフトウェア環境の異常(OS，ミドルウェア，ライブラリなどの誤動作や不具合)
・周辺外部環境の異常
デビエーション

Use CASE
記述

ハードウェアデバイス・オブジェクト
ソフトウェアが制御する対象としての実態（物）がある
もの．例えば，「コンプレッサー」「給水モータ」などがこれに当たる．なお，内部制御で利用されるソフトウ

Guide Word
(操作が) 欠落する, 早すぎる, 遅すぎる, 速すぎる, 違う
順序が逆, 繰り返される, 同時に発生する(想定より) 多すぎる,少なすぎるェアタイマなども例外的にこのカテゴリのオブジェクト

図4として扱う．
データ・オブジェクト
ソフトウェアが扱ったり必要とする主に外部のデータ．
例えば，「外気温」「庫内温度」など．
ファームウェア・オブジェクト
制御ソフトウェアの実装上の都合で必要とされる内部の変数やフラグなど．
(b) オブジェクトのとり得る状態の抽出
次に，抽出された個々のオブジェクトのとり得る状態の洗い出しを行う．例えば，ファンクション・オブジェクトの1 つである[給水動作]の場合，とり得る状態として<開始する/正常終了する/失敗する>といった３つの状態を抽出できる．

ガイドワード

例えば，冷蔵庫製氷機能を考えた場合には，ソフトウェアの異常動作を引き起こす要因として次のものが考えられる．
製氷機能の周辺にあたる冷凍サイクル制御におけるコンプレッサー制御ソフトウェアの異常やコンプレッサー自身のハードウェア異常，あるいは利用しているリアルタイム OS のバグや，製氷機外部の周辺温度の異常高温などである．
これらの要因の抽出にはガイドワードを利用する．先に作成したユースケース記述(テスト対象ソフトウェアの主たる動作)に対して，ソフトウェアの動作を順に机上トレースしながら，このガイドワードを適用して正常動作状態からの逸脱(デビエーション)を抽出していく．

これらのオブジェクトやそのとり得る状態の抽出は，ユースケース分析，デビエーション分析，フォールト木作成の各

自動給水 実施する<早すぎる＞ 自動給水実施 タイミングが早すぎる
が多すぎる<多すぎる＞ 給水量（時間）が少なすぎる＜少なすぎる＞給水量（時間）段階で追加，修正を繰り返しながら行い，最終的には分析担
当者間で共通に利用できる用語辞書の形で整備していく．

4.3

デビエーション分析<給水動作||失敗>

自動給水実施デビエーション分析ではソフトウェアの基本動作から逸脱したことによる異常動作の分析を主として行う．分析に当たっては特に外部とのインタフェース，ユーザ操作の２つの視

給水検知
実施

[給水動作||正常終了]点に着目する．
外部とのインタフェースでは入出力データに関する値，デー

給水検知 実施する<早すぎる＞ 給水検知実施 タイミングが早すぎる＜遅すぎる＞ 給水検知実施 タイミングが遅すぎる
設定温度が違う<違う＞
給水検知<給水検知動作||失敗>

製氷
実施[製氷動作||失敗]

タ入出力タイミングなどがシステムの異常動作につながる要[製氷動作||開始]

因と考えられる．一方，ユーザ操作はソフトウェアにとっては最終的には入力データの誤りとなるので，ユーザ操作ミスなどについて体系的に分析することは異常動作を考える上で製氷検知
実施[製氷検知||失敗][製氷検知||正常終了]-- 氷有るとき有効である．
これら 2 つの視点に注目し，ソフトウェアに対する異常動作を導き出すことを目的として「ガイドワード」[4]を利用する．

図5

デビエーション分析「ガイドワード」は図 4 に示すような，システムの正常動作5図 3 に示したユースケース記述(拡張アクティビティチャー

例えば，冷蔵庫制御ソフトウェアに関する製氷機能に関してト)に対して，このガイドワードを当てはめてデビエーショ

は，一般ユーザが認識する望ましくない不具合事象としてンを抽出したものを図 5 に示す．例えば，アクティビティ「氷ができない」という不具合事象が考えられる．これを引[自動給水を実施する]に対しては，<早すぎる>というガイドき起こす不具合事象として，「水が製氷装置にたまらない」ワードの適用により，『自動給水実施早す「製氷中に水こぼし」などが考えられる．ここで「水が製氷ぎる』というデビエーションが導かれる．同様に，<多すぎ装置にたまらない」という事象を考えると，その原因としてる>というガイドワードの適用により『給水量(時間)タイミングが多「製氷装置が正常にセットされない」「給水自体が失敗しすぎる』を，<少なすぎる>というガイドワードの適用によりがた」が考えられる．このうち，「製氷装置が正常にセットさ『給水量(時間)がれない」については，「製氷装置のセット/リセットを検知で少なすぎる』をそれぞれ導くことができる．

きない」場合と「製氷装置水平位置戻し動作不正」場合の 2つに分けられる．後者は先のユースケースで記述した「製氷4.4 ソフトウェアフォールト木の作成装置水平位置戻し動作」に対応していることが分かる．更に抽出されたソフトウェアデビエーションとソフトウェアフ

この「製氷装置水平位置戻し動作が不正」というのは，先のォールトの因果関係をつけることによりソフトウェアフォーデビエーション要求分析の結果を参考に，「製氷機が水平状ルト木を作成する．ソフトウェアフォールト木は最上位のル態を行き過ぎる」「製氷機が水平状態に達しない」「製氷機ート事象に当該ソフトウェアにとっての不具合事象をとり，の回転が止まらない」「製氷機が回転しない」などの原因にこの事象が発生するケースについてソフトウェアデビエーシ分けて考えることができる．

ョンとの対応付けをとりながら逐次展開していく．
不具合事象の展開は「機能不具合の展開」と「ソフトウェア不具合への展開」の 2 つのステップに分けて行う．

(2) ソフトウェア不具合への展開「ソフトウェア不具合への展開」フェーズではソフトウェ
ア機能の不正をさらにソフトウェア実装上の不正のレベルに(1) 機能不具合の展開フェーズまで詳細にブレークダウンする．

通常，ソフトウェアフォールト木のルート事象はシステム

例えば，先の「製氷機水平戻し動作が不正」という事象に（ソフトウェア製品）が提供するサービスの観察可能な不具関しては「製氷機が水平状態を行き過ぎる/達しない」「製氷合事象を取り上げる．「機能不具合の展開フェーズ」では，機回転が止まらない/回転しない」などの機能的な不正がソフ取り上げた不具合事象とこれを引き起こすソフトウェアの機トウェアとしてどのような誤りをした場合に発生するかを分能上の不具合を対応させる作業をおこなう．実際には，ユー析していく．ここで「製氷機が水平状態を行き過ぎる/達しなスケース記述で示したソフトウェアの機能動作の流れをトレい」という事象が発生するのは，製氷機の水平状態を監視しースして，ルート事象の不具合の原因となりうる機能動作のているセンサー信号に関連し，不具合事象を抽出し，細分化していく．

Step-4SS-FTA

氷ができないFatal Trouble
製氷中に水こぼし水が製氷装置にたまらない

機能不具合

〔準備Ⅱ）
給水自体に失敗する(準備Ⅰ）
製氷装置が正常セットされない

Software Function
Failure
製氷装置セッ/リセットトを検知できない

製氷機水平位置戻し動作不正

製氷機の水平状態を行き過ぎる

製氷機が水平状態に達しない

水平検知信号の誤認
水平検知タイミングの誤り

図6

製氷機が回転しない

製氷機回転が止まらない

ソフトウェア不具合

SoftwareErrors

ソフトウェアフォールト木

6

出を確認』という項目があり，水平検知信号確認によりこの① 水平検知信号を誤認した．

確認をしていた．これに対し，今回の方法では「ソフトウェ② 水平検知のタイミングがおかしい．

ア側での製氷装置水平位置検知のタイミングは適切か」「製などがその要因として考えられる．

氷装置水平位置検知センサーの値は正常値か」といったソフ

実際のソフトウェアでは水平検知のタイミングはソフトウェ

トウェア実装により近いレベルでのテスト項目が作成された．

ア側からのリクエストで指定し，検知信号を受ける形となっ

つまり，ここで作成されたテスト項目はより具体的なものとている．そのため①については信号データの読み間違い（アなっている．

ドレス誤りなど），②については水平検知を指示する箇所の(2) 従来法で発見できなかった不具合の検出誤りなどが原因となる．このようにして，ソフトウェアの機提案法で作成したテスト項目を品質保証段階での製品チェ能動作の不正を引き起こす要因を分析し，ソフトウェア実装

ックで指摘された不具合項目と対比させてみた．その結果，上の不正という最もプリミティブな要因まで展開していって，「製氷装置水平位置検出」に関する不具合に関して，「水平これらをソフトウェアフォールト木の形で整理していく．

位置センサーの検出タイミング誤りに起因する不具合」が品質保証部門の検査で指摘されていることが確認できた．つま4.5 ソフトウェアテスト項目の抽出

り，この不具合は設計部門でのテストにおいては「離氷動作作成したソフトウェアフォールト木を利用してテスト項目終了後の製氷装置水平復帰時の水平位置検出を確認」というの抽出を行う．既に説明したようにフォールト木のリーフにテスト項目では検出できず，後の工程である品質保証部門では，最上位のルート事象に記載された不具合事象を引き起この検査において検出されたものであった．今回の方法で抽出すソフトウェア実装面での不正が記載される．テスト項目とされた新しい 2 つのテスト項目「ソフトウェア側での製氷装してはこのリーフのアイテムを検出可能なものを考える．例

置水平位置検知タイミングは適切か」「製氷装置水平位置検えば，前述の①製氷装置水平位置検知信号に関するテストケ

知センサーの値は正常値か」をデバッグ段階で適用すれば，ースとして「水平検知信号は正常値が設定されているか」とこれらの不具合を開発部門内で事前に検出することが期待さいうテスト項目が作成される．実際のテストではソフトウェれる．

ア実行時に信号データをモニタし，実際の装置動作に合っていることを確認する

6. 評価
ここでは，提案法の実ソフトウェアへの試行実験を通してこのようにして作成したソフトウェアフォールト木をもとに，最上位のルート事象に関するテスト項目を作成すること得られた成果について考察する．

が可能となる．

6.1

効果に関する議論
今回の適用実験の結果，次のような事項を確認した．

5.

適用実験

5.1 対象ソフトウェア(1) ソフトウェア動作の形式的記述
従来の自然言語によるソフトウェア動作仕様記述をもとに前節までに提案したテスト項目設計手法を冷蔵庫制御ソフ

テスト仕様を作成する場合には，ソフトウェアの動作の流トウェアの一部に適用した例について述べる．本実験では製れなどを的確に把握することが難しかった．今回，拡張ア

氷機能の一部に対し提案手法を適用してテスト項目を作成しクティビティチャートを利用したユースケース記述を導入た．この生成されたテスト項目と，従来のチェックアイテムしたことでこれらの課題が解決でき，ソフトウェア動作のを用いて作成されたテスト項目との比較を行う．
今回の試行ではソフトウェアフォールト木のルート事象と流れに沿ったテスト仕様の作成が可能となった．
(2) ガイドワードを利用した信頼性要求分析して「氷ができない」という事象を設定した．そしてこれをユースケース記述に対してソフトウェア信頼性の観点から展開した機能不具合である「製氷装置初期位置設定動作」にのガイドワードを適用することにより，ソフトウェアの基関してさらに詳細に展開したソフトウェアフォールト木を作

本動作に対する異常について抜けなく分析することが可能

成する．このフォールト木に基づいてソフトウェアのテストとなった．

項目の作成を行う．

(3) SS-FTA によるソフトウェアフォールト木の作成

5.2 適用結果

ユースケース記述，ガイドワードなどを利用して段階的にこのソフトウェアに提案法を適用した結果，次の 2 つの効果

ソフトウェアフォールト木を作成するアプローチを採用しを確認することができた．

たことにより，ソフトウェアフォールト木が従来より作り(1) より具体的なテスト項目の作成やすく，かつ均一なものが作成できるようになった．

「製氷装置初期位置設定動作」に関して，従来のテスト項
目では『離氷動作終了後の製氷装置水平復帰時の水平位置検5.2

残された課題点

S-TEMRA では過去の不具合例を参考にしてソフトウェア7フォールト木を作成することで，ソフトウェアのテスト項目いきたい．

を作成し，最終的にはこれらに優先度付けをすることを狙っている．今回の検討により，その基本的な部分であるソフト参考文献

ウェアフォールト木を作成し，テストケースの抽出を行うス[1] 萩原他，”マイコン組込み SW の開発を支援する CASE ツテップについては明確になったと考えている．

ール：TestCASE”,情報処理学会第５７回全国大会,pp. l-248-l-

次の課題として，ソフトウェアフォールト木の最上位にど249 (1998).のような不具合事象を置くかが重要になる．ソフトウェアの[2] M. Fowler and K. Scott: ”UML DISTILLED:

不具合について考えると，不具合の発生頻度およびその不具

Applying the Standard Object Modeling Language” (羽生田栄合が発生した場合に与える影響について考慮することが必要

一,”UML モデリングのエッセンス”) アジソン・ウェスレとなる．例えば，原子力プラントなどの制御では冷却水給水

イ・パブリッシャーズ (1998).

循環制御機能に不具合が発生した場合，その発生頻度自身は[3] Z. Xinjun and Y. Tashiro: “An Approach to Automated

低くても不具合の結果引き起こされる影響は計り知れないも

Program Testing and Debugging”, Proc. of APSEC’99, pp.582-589のとなる．このような不具合の検出に関するテスト項目の優(1999).

先度は高くする必要がある．一方でワープロソフトにおける[4] N.G. Leveson: Safeware: System Safety and Computers,

特定文字の変換ミスなどは発生頻度は比較的高いものの不具

Addison-Wesley (1995).

合の影響という面ではそれほど大きな影響を及ぼすとは考え[5] J.D. Reese et al.: “Software Deviation Analysis”, Proc. ofにくく，テスト項目としての優先度は低くしても差し支えな

ICSE97, pp.250-260 (1997).

いと考えられる[6] T. Fukaya, M. Hirayama and Y. Mihara: “Software

また，2 節でも示したように，不具合の存在確率についてSpecification Verification using FTA”, Proc. of FTCS-24, pp.131-も考慮する必要がある．即ち，より複雑な機能あるいは開発

133 (1994).

者のスキルが不足している箇所などについては，テスト項目[7] K. Tamura, J. Okayasu and M. Hirayama: “A Software Testingの優先度を高くするといったことを検討する必要がある．

Method based on Hazard Analysis and Planning”, Proc. of ISSRE98, pp. 103-110 (1998).

７.

まとめ

本稿ではユースケース記述を利用し，ソフトウェアフォー

[8] T. Tsuchiya et. al.: “Derivation of Safety Requirements for
Safety Analysis of Object-Oriented Design Documents”, Proc. of

ルトに対するフォールト木を作成し，これを利用してテスト

COMPSAC’97, pp.252-255 (1997).

項目の抽出と選択を行うテスト項目設計手法 S-TEMRA につ[9] Y. Kim and C.R. Carlson: “Scenario Based Integration Testing

いて報告した．テスト項目設計手法 S-TEMRA についてはテ

for Object-Oriented Software Development”, Proc of 8th ATS,スト項目設計の全体の流れを提案し，pp.283-288 (1999).

(1) ソフトウェア動作を拡張アクティビティチャートによっ[10] K.-C. Tai and H.K. Su: “Theory of Fault-based Predicateて表現し，これに対してガイドワードを利用した信頼性

Testing for Computer Programs”, IEEE Trans. on SE, Vol.22, no.8,分析を行う手法

pp. 552-562 (1996).

(2) ユースケース記述に対するデビエーション分析結果をもとに，ソフトウェアのフォールト木を作成する手法(3) 上記分析の過程での用語を用語辞書の形で整理していくことで，作成するフォールト木の記述レベルの均一化を実現する手法などを明らかにした．
また，この手法を実際の冷蔵庫ソフトウェアの一部に適用した実験では，この手法によって作成されたテスト項目と従来のテスト項目を比較し，本方式による方が従来方式に比べより実装に近く詳細なテスト項目を作成できることを確認した．
今後の研究課題としては，テスト項目の優先度付けや選択の観点からどのようなソフトウェアフォールトに着目するか，また，テスト重要度や構造面からソフトウェアの構成部分に，どのように優先度を与えていくかといった点の検討を進めて8