論 文プログラム差分を用いたデバグ支援手法 DMET
松下誠†

寺口 正義††

井上 克郎†

Program-Delta Oriented Debugging Supporting Method DMET
Makoto MATSUSHITA † , Masayoshi TERAGUTI†† , and Katsuro INOUE †あらまし 正常に機能することが事前にわかっているリビジョンと，欠陥が含まれるリビジョンとの差分に着目して自動的にテストを行うことで，欠陥の原因を特定する研究が行われている．しかし，テストの度にソース
プログラムからソフトウェアを作成する必要があるため，非常に多くのテスト時間が必要となっていた．また，テスト作業にのみ重点が置かれており，デバグ作業まで考慮されておらず，実用的とはいえなかった．
そこで本研究では，従来よりもテスト実行時間を減らし，テストからデバグまでの一連の流れを支援することで実際のソフトウェア保守に利用可能なデバグ手法 DMET の提案を行う．また，本手法の有効性を確認するため，
DMET を用いた開発支援環境 DSUS の実装を行い，比較実験を行った．その結果，DMET を用いることにより，デバグ時間全体を短縮できることがわかった．
キーワード リビジョン管理，差分，デバグ

一般的に，これらのソフトウェア保守活動の中では，

1. ま え が き

修正保守のための活動が一番多いと考えられがちで

ソフトウェアの保守とは，本稼働中のソフトウェア

ある．しかし，1980 年代初めに Lientz と Swanson にの運用の継続を可能にするため，あるいはそれらを改よって行われた調査によると，修正保守は保守作業の善するための工程である [3]．ソフトウェアにかかる全20%にすぎず，完全化保守が 55%を占めることが報告されている [11]．

費用のうち保守の占める割合は約 80%にものぼり [4]，ソフトウェアに携わる人が費やす総時間の約 65%が，保守やそれに関連する作業に費やされている [2]．

これらの保守活動においては，既存のソフトウェア
に対する多くの変更が発生する．しかし，ソフトウェ

ソフトウェア保守の本質を理解するために，Swanson

アに変更を加える際にエラーを発生させてしまう確率

はソフトウェア保守が必要となる要因を 3 つの基本的は 50%から 80%の間であることが Hetzel の研究で示な種類に分類している [15]．

されている [7]．従って，保守活動の 75%を占める修•••ソフトウェア中のエラーに起因する欠陥

正保守，完全化保守において，ソフトウェアに変更を

ソフトウェアを取り巻く環境の変化加えた場合に，変更された部分の機能だけではなく変ユーザや保守担当者の要求更されていない部分の機能に関しても動作確認が必要

さらに，Swanson はこれらの基本的な要因に対応して実行される保守活動を次のように定義している．

•
•
•
†

開発の際に起きるこれらの動作確認のために，回帰テ

修正保守 : エラーの識別，修正

スト [6], [10], [13] が広く用いられている．また，開発

適応保守 : 環境の変化に応じた修正されるソフトウェアはリビジョン管理システム [1], [16]完全化保守 : 性能の改善，機能の変更や追加等のソフトウェア管理システムを用いて管理されていることが多い．この 2 点に着目して，ソフトウェア管大阪大学大学院情報科学研究科，大阪府
Graduate School of Engineering Science, Osaka University, 1-3 Machikaneyama-

理システムによって管理されているソフトウェアを対象として，完全化保守を支援する研究がこれまで行わ

cho, Toyonaka, Osaka 560 JAPAN
††

となる．

IBM 東京基礎研究所，神奈川県Tokyo Research Laboratory, IBM Japan, Ltd., 1623-14 Shimotsuruma, Yamato,

れてきている [12], [17]．しかし，テストを実行する際に利用するテストツール [9] の設定を，状況に応じてKanagawa, 242-8502 JAPAN

電子情報通信学会論文誌 X

Vol. Jxx–X No. xx pp. 1–8 xxxx 年 xx 月

1

電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xx

手作業で行う必要がある．また，テスト後に行うデバ

正を正しく認識し，組織化し，管理する作業であり，グ作業に対する支援も十分とはいえない．

様々な管理手法のモデルが提案されている．さらに，

そこで本研究では，機能の変更や拡張を目的としたそのモデルに基づくリビジョン管理システムが実装さ完全化保守作業を対象とする．このような保守作業でれている [1], [16]．通常プロダクトの改訂は複数回行

は，作業対象となる機能以外の部分も影響を受けて，われ，各改訂毎に作成されるプロダクトをリビジョン

テストで欠陥が検出されることがある．本稿では，こと呼ぶ．

のような欠陥の除去を効率よく行うために，回帰テス
トを用いたデバグ手法 DMET の提案を行う．
本手法では，まずプロダクトのリビジョンを順に取また，(3) を行うにあたり，ソフトウェアに変更を加えた後で，ソフトウェアが仕様通りの性能で動作するかどうかをテストするための一手法として回帰テスト

り出し，テストツールを利用して自動的にテストを行がある [6], [10], [13]．回帰テストは実際のソフトウェ

う．テストの結果，欠陥を出力するリビジョンと正常

ア保守において活用されており，修正が正しく行われに出力するリビジョンを発見した場合，このリビジョているかを検査する際に役立てられている．

ン間で行われた修正にエラーがあるとする．次に，こ2. 2 既存手法の問題点の修正内容 (以下，単に差分と呼ぶ) が現在のリビジョ

リビジョン管理システムを用いて開発されたソフトンにおいてどの部分に相当するかを調べる．この結果

ウェアの保守段階では，仕様通りの性能で動作するリを利用して，利用者はデバグを行い，欠陥の修正を行

ビジョン (以下，基準リビジョンと呼ぶ) が存在していう．欠陥を訂正した後，その変更を古いリビジョンにる．従来のソフトウェア保守では，上述した保守作業も反映することで，以降のテストに役立てる．
また，DMET の有効性を検証することを目的として，DMET を用いたデバグ支援システム DSUS の試の (2)，(3) において，基準リビジョンのプログラムを変更し，回帰テストを用いてソフトウェアの動作を確認している．

作を行い，DSUS を用いた比較実験を行った．この結テストで欠陥が発見されれば，その欠陥の原因とな

果，DMET はテストからデバグまでの一連の流れを支るエラーを取り除く (デバグを行う) ために，保守作業

援することができ，実際の保守においてデバグ作業時の (1)，(2) を繰り返し行う．しかし，変更していない

間を短縮できることがわかった．

機能に欠陥が見つかった場合，その原因となるエラー

2. ソフトウェア保守を発見することは一般的に困難である．
そこで，基準リビジョンから現在のリビジョンに至2. 1 保 守 作 業るまでの間に行われた修正を用いて自動的にテスト保守活動においてソフトウェアに変更を加えるためを行うことで，欠陥の原因となるエラーを特定するたに行われる作業は，基本的に次の 3 つに分類することめの研究が行われている [12], [17]．しかし，テストをができる．

行う度に，基準リビジョンに変更を加えてコンパイル（ 1 ） ソフトウェアおよびなされるべき変更の理解を行い，テストを適用するソフトウェアを作成するた（ 2 ） ソフトウェアの変更

め，テストに多大な時間が必要となる．また，欠陥を（ 3 ） 変更後のソフトウェアの動作確認

発見する度に，その欠陥に応じてテストケースを逐一

このうち，(1) が正しく行われれば，発見された欠陥作成する必要があるため，テストに利用しているテスの原因を究明するために役立つ．逆に，ソフトウェア

トツール [9] に関する教育や訓練も必要となる．さらに対する理解が乏しければ，欠陥の原因究明および訂には，欠陥の原因を特定するテスト作業にのみ重点が正に大幅な時間がかかる．そこでソフトウェアの理解

おかれており，その後のデバグ作業までは考慮されて性および保守性を向上させるための一手法としてソフいないため，実際の保守作業にそのままでは適用でき

トウェア構成管理やリビジョン管理を行う方法がある．

ないといった問題がある．

ソフトウェア構成管理とはソフトウェア開発，保守過程で作成される，さまざまなプロダクトの識別や

3. デバグ手法 DMET

制御，状態の把握等を解決する作業を指す [5]．また，

本節では，我々の提案する，リビジョン管理システム

リビジョン管理とは開発チームが作成したプロダクトが保持しているプログラムの差分情報を用いた，回帰(ソースプログラムや付随する文書) に対する様々な修テストを利用するデバグ手法 DMET について述べる．

2

論文／プログラム差分を用いたデバグ支援手法 DMET

3. 1 概要

DMET (Debugging METhod) は、基準リビジョンでは全機能が正常に働いており，保守作業の際に機能に欠陥を作りこんだ場合のデバグ作業を効率良く行うことする．コンパイル済みファイルをリビジョンとして登録する際には，付随情報として当該ファイルとソー
スプログラムのリビジョンの関連も記録する．

•

基準リビジョンが存在するとを支援するための手法である．DMET はテスト手

本手法はソフトウェアの保守作業を対象としている．

法、表示手法、反映手法という 3 つの手法を繰り返し

このため，保守作業が開始される時点でのソフトウェ

適用することにより，欠陥の除去を行う．

アを基準リビジョンとすることにより，修正前の全機テスト手法では，テストツールを利用して自動的にテストを行い，欠陥の原因を含むリビジョン間を特定能が必ず動作することが保証されているリビジョンが必ず存在することとする．

する．DMET では回帰テストを用いることにより，各•リビジョンが欠陥を含んでいるかを確認する．回帰テ

本手法では，テストツールを用いてテストデータのストにおいて欠陥が発見された場合には，その欠陥が入力に対して出力が正しい物であるかを判定している

どのリビジョンによって作りこまれたかを確認するたため，出力が行われるソフトウェアを対象とする．こめのテスト (以降「局所化テスト」と呼ぶ) を行う．

こで出力とは，例えば端末への文字列の出力等，一般

表示手法では，テスト手法で特定された実行可能プ

入力に対して何らかの出力を行う

的に目に見える結果として出されるものを仮定する．

ログラムのリビジョン間の差分を，ソースプログラム•の最新リビジョン上で表示する．一般的にソースプロ

一般的に，ソフトウェア保守活動においては規模のグラムの修正作業は最新リビジョン上で行われるため，大きな仕様変更等は行われないため，本手法では，入特定されたリビジョンから最新リビジョンまでに行わ

力パラメータ自体が増減するなどといった，ソフトウェ

れた変更を，本手法では自動的に求める．

アに対する入力が変更されることは想定しない．また，入力や利用環境等は変更されない反映手法では，テスト手法で特定されたリビジョン

同様の理由から，ハードウェアや動作環境といった，までリビジョンを遡りながら，最新リビジョン上で修ソフトウェアの利用環境についても変更は行われない

正作業時に行った変更を反映する．本論文では以降，ことを本手法は前提とする．

最新リビジョン上での修正変更を反映する必要がある

このようなソフトウェア開発環境においては，開発

テストで欠陥を生じたリビジョンをまとめて反映必須

者は小さな作業単位でその結果をリビジョン管理シス

リビジョンと呼ぶことにする．反映必須リビジョンにテムに登録することが一般的である．一人の開発者が対して修正内容を適用することで，それ以降のテスト

小規模の開発を行っている場合，リビジョン登録を行作業を効率良く続けることができる．

うたびに回帰テストを実行することも可能であろう

以下，本手法が前提とするソフトウェア開発環境にが，一般的には複数の開発者が協調しながらそれぞれついて述べた後，テスト手法，表示手法，および反映の作業を行っており，また一人の作業者も同時に複数手法の具体的手順について説明する．

の作業を並行して行うことも珍しくはない．また，あ3. 2 DMET を適用する際の前提環境

るまとまった作業の途中経過を記録するために，修正

ソフトウェア保守において我々の考えるデバグ手法が不完全なものをリビジョンとして登録することも良を利用する際に，ソフトウェアおよびその開発と保守，く行われる．このような状況においては，開発者がリ

ソフトウェア保守担当者に必要となる前提条件についビジョン登録を行う毎に回帰テストを実行しても意味て述べる．ある程度成熟したオープンソースソフトがないため，ある程度まとまった作業が終了した時点

ウェアの開発事例など，この種の前提は広く普及してで，修正が正しく行われたかを回帰テストなどによっいる．よって我々は，これらの前提条件が近年のソフて確認することとなる．

トウェア開発環境で問題とはならないと考えている．

•

3. 3 テスト手法

リビジョン管理システムを用いた開発を行う

テスト手法では，ソフトウェアに対して何らかの変開発中の作業履歴を比較的詳細な単位で把握する

更を行う度に，用意されたテストを全て実行する回帰

ために，リビジョン管理システムを用いた開発作業を

テストを自動的に行う．

前提とする．リビジョン管理の対象としては，ソフト

テスト対象となるソフトウェアに対して用意された，ウェアのソースプログラム，コンパイル済みファイル

完全化保守を行うために用いるテストの集合を T1 〜
3

電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xx
基準バージョン

最新バージョン

VB ......... Vj ........ Vk ........ VL
局所化テストLcT(i,j,k)

局所化テスト: LclT( i , j , k )Vj : テストバージョン T i : テスト

O j, i : テスト出力

Vk : 欠陥バージョン I i : テスト入力

O k, i (= O L, i ) : 欠陥出力
O B, i : 正常出力

適用

T1 T2 ....... Ti .......Tn

開始

テスト集合

図 1 局所化テスト
Fig. 1 Localization test

j=B

Yes

No

Tn とする．これらのテストは，保守作業が開始される際にあらかじめ用意する．また，あるファイルに対する i 番目のリビジョンを Vi としたとき，基準リビ
ジョンは VB ，最新リビジョンは VL (B <= L) として表すものとする．いま，ある時点のソフトウェアに対してテスト Ti (1 <=i<= n) を適用する場合を考える．まずあらかじめ，各ファイルについて正しく動作することがあらかじめわかっている VB に対して，Ti の入力である Ii を与えた場合の出力結果 OB,i をこのソフト
ウェアの正常出力とする．
テスト手法ではまず，VL に対して全ての Ti (1 <=i<= n) を適用し，その出力 OL,i が OB,i と一致するかを確認する．もし，あるテスト Ti を適用した際に欠終了

VBとVkのバージョン間で欠陥が作り込まれた

Vj : I i =>O j, i

O j, i = O k, i

Yes×

LclT( i , j-1 , j )NoO j, i = O B, i

Yes
○

No
core output?

終了

VjとVkのバージョン間で欠陥が作り込まれた

Yes△

LclT( i , j-1 , k )− No
LclT( i , j-1 , k )図 2 局所化テストアルゴリズム
Fig. 2 Localization test algorithm

陥が発見された場合，局所化テスト LclT (i, L − 1, L)を行う．

る」と判断して終了する．

なお，局所化テスト LclT (i, j, k) とは，Vj (j <= k)（ 5 ） それ以外の Oj,i 自体が得られた場合には，テに対して Ti を適用した結果を判定し，かつ欠陥の原因

ストの実行結果は「−」(新たな欠陥が発見された) とがどのリビジョンとどのリビジョン間に存在している判定する．また，実行結果がソフトウェアの異常終了

かを返すテストである (図 1)．ただし，ここでは Vk にのため得られなかった場合には「△」(結果が得られな対して Ti を用いてテストを行った際，その出力 Ok,iい) であったとする．どちらの場合においても，さらが OL,i と同一であることがわかっている．局所化テに再帰的に LclT (i, j − 1, k) を実行し，その結果を求

スト LclT (i, j, k) のアルゴリズムを図 2 に示す．

める結果とする．

（ 1 ） j が基準リビジョン B と一致しているならば，本手法では，各リビジョンを新しいものから順に線「欠陥は VB と Vk 間に存在する」と判断して終了する．

型探索を行うことにより，欠陥を含む箇所の特定を（ 2 ） Vj に対し，テスト Ti を適用する．具体的に行っている．仮に結果が「○」と「×」しかなく，かは，Ii を Vj に与えて，出力 Oj,i を得る．

つ，○から×への遷移が高々 1 回しか起きない場合に（ 3 ） Oj,i と Ok,i が一致すれば，リビジョン j にはは，二分探索を用いることによりより効率の良い探索

まだ欠陥が存在していることになるため，テストの実が可能である．しかし，前提としてその他の出力が含

行結果は「×」(同一の欠陥が含まれる) と判定する．

まれる場合や，何らかの理由により○から×，あるい

さらに再帰的に LclT (i, j − 1, j) を実行し，その結果はその逆への遷移が複数考えられるため，ここでは二を求める結果とする．

分探索を用いることはできない．

（ 4 ） もし Oj,i と OB,i が一致した場合には，リビ

3. 4 表 示 手 法

ジョン j の時点では欠陥が含まれていなかったことにテスト手法で発見したリビジョン間の差分 (ここでは，なるため，テストの実行結果は「○」(欠陥が含まれリビジョン C とリビジョン E の間とする (C < E <= L))ない) と判定する．また，「欠陥は Vj と Vk 間に存在す
4を最新のリビジョン L で表示するために，まずソフト

論文／プログラム差分を用いたデバグ支援手法 DMET
VC

VE

...

1
2
3
4
5
6
7
8
9
10
11

VL

...

1
2
3
4
5
6
7
8

1
2
3
4
5
6

本節 で は ，DMET に基 づ く デ バ グ 支 援 シ ステ ム

DSUS を用いた，DMET の評価実験について述べる．

この部分を削除することで欠陥の原因となる可能性がある

図3

4. 評 価 実 験

リビジョン間の差分でコードを削除した場合
Fig. 3 Code deleted between revisions

4. 1 試作システム DSUSDMET に基づくデバグ支援システムの構築にあたり，
我々は以下の点に留意してシステムの作成を行った．

•

プログラミング言語から独立

一般的に，プログラミング言語に依存したシステムをVC

この部分を削除しても欠陥の原因とはならない

図4

VE

...

1
2
3
4
5
6
7

1
2
3
4
5
6
7
8
9
10
11

VL

...

1
2
3
4
5
6
7
8
9
10

リビジョン間の差分でコードを挿入した場合
Fig. 4 Code inserted between revisions

構築することによって，より細かいデバグ支援を行うことが可能になる．しかし，現在のプログラミング開発は多くのプログラミング言語によって行われており，DMET 自身は言語に依存しない手法であることから，
DSUS には特定のプログラミング言語に依存した機能を持たせないようにした．

•

テストとエラー修正の両方を支援

DSUS はテストの自動実行だけでなく，テストによって発見したエラーの修正を行うための環境を提供する．
ウェアとソースプログラムの関連情報を利用して，どこれによって，開発作業を DSUS 内で完結させることのソースプログラムのどのリビジョン間の差分を強調ができる．

表示するか調べる．両リビジョン間で削除された場合，•ツールの自動実行

あるいは挿入された場合に応じて，以下のような表示テストの実行をはじめ，DMET で述べられている各作を行う．

業を順次正しく実行することは，開発者に対してさら削除

現在リビジョンのソースプログラム上に現れず，なる負担を強いることになる可能性がある．DSUS で変更前のソースプログラム自身は強調表示できない

は，DMET の手順やそれに付随するテストを自動的に(図 3 参照)．このため，最新リビジョン上では，削除行うことによって，DMET の導入にかかる負担を減らされたソースコードの場所と内容を示す印によって強すことをめざす．

調表示を行う (図 2VL における点線表示)．
現在リビジョンのソースプログラム上に現れる

DSUS は，DSUSmain ，RCS [16]，DejaGnu [14] と，ユーザに対する GUI から構成される (図 5)．GUI を用部分を強調表示する (図 4 参照)．挿入後にも何らかのいることにより，ソースコードの編集やエラーを含む

変更が行われるが，欠陥の致命的な原因となる部分はと考えられる差分の表示などを行う．

挿入

変更されていないと考えられる．

RCS は，多くの開発環境で用いられている，リビ

3. 5 反 映 手 法

ジョン管理システムである．DSUS は，ユーザが RCS

局所化テストで新たな欠陥が発見された場合，まずに対する操作のインターフェイスとして動作することその欠陥の除去を最新リビジョン L に対して行う (以により，誤った操作や危険な操作を行わないように作下，これをした差分を修正 ∆L と呼ぶ)．次に，局所化られている．また，開発者がソースコードを編集する

テストを続行するために，∆L を過去のリビジョンに際には，定期的にその内容を RCS へ登録することに反映させる．まず，patch プログラム等を用いて，∆L

よって，RCS に登録される差分が小さくなるようにすを過去のリビジョンへ適用し，新たなソフトウェアをる．DejaGnu はオープンソースで開発が進められてい作成すべくコンパイルを行う．もしコンパイルが成功るテスト実行フレームワークであり，DSUS では回帰

すれば，それを新たなテスト対象プログラムとして利テストを実行するために用いられる．

用する．もし ∆L の patch が失敗するか，成功してもコンパイルに失敗した場合には，そのリビジョンは以DSUSmain は DSUS 全体の中核をなす部分である．
GUI の管理，RCS に対する操作，DejaGnu 実行環境

降の回帰テストの対象外とする．

の設定やテストの管理はこの部分で行われる．DSUS
5電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xx
file edit build test window tool
file1.cfile2.cThu Feb 17 2000

project

int main() {scanf("%d", a);if (a == 1) {printf("data is OK\n");} else {printf("data is No\n");}file1.cfile2.cexe
1.1
1.2
file1.c
1.1
1.2

Regression Test
Test No[1]correct output
Test No[2]new bug
Localization Test
With Version[1.3]same bug

表 1 本実験で用いたソフトウェアの開発履歴
Table 1 Development software and its history
ソフトウェア名 リビジョン数 テスト回数
A
28
25
B
91
10

GUI

DSUS
4. 2 実験の概要
DSUSmain

デバグ作業を DMET に従った場合と従来手法で行った場合でかかる時間にどの程度の差が見られるのかを，

RCS

DejaGnu

storages
Versioninformation

Test data
Test results

DSUS を用いて調べ，本手法の実用性を示す．
本実験では，C プログラミングの経験をある程度持つ大学 4 年生および大学院生 10 人を被験者とした．
全体を 2 つのグループ (G1 と G2 ) に分け，グループ
G1 は DSUS を，グループ G2 は，DSUS の機能のうち，DMET に基づくリビジョンの特定機能のみを利用できないようにした DSUS を用いて，デバグ作業を行うこととする．なお，デバグ対象として用いるソフト

図 5 DSUS の構成
Fig. 5 The DSUS structure

ウェアの問題としては，酒屋問題 [8] を用いた．
実験は，ステップ 1 とステップ 2 に分け，ステップ 1
で，ステップ 2 の際に用いるデバグ対象となるソフト
ウェアの開発と収集を行った．収集されたソフトウェアを用いて，本実験でデバグ作業を行った．

4. 3 ステップ 1
酒屋問題のうち「空コンテナマーク」部分以外を正しく実装したソフトウェアを事前に用意しておき，これに対して，空コンテナマークの機能を追加する．なお，当該ソフトウェアは C 言語で記述されており，およそ 500 行程度の規模である．得られたソフトウェアのうち，この拡張により他の機能に対して欠陥を生じるようになった 2 つのソフトウェア (以下，ソフトウェ
図 6 DSUS の GUI 画面
Fig. 6 Screenshot of GUI

ア A, B) をステップ 2 でデバグ対象とするソフトウェ
アとした．表 1 に収集したソフトウェアの一覧とその開発履歴を示す．

の GUI (図 6) は，大きくエディタ用ウィンドウ (画面例えばソフトウェア A は，最初に用意したソフト

左) と状態ウィンドウ (画面右) から構成される．開発

ウェアを初版として合計 28 のリビジョンを持つ．ソ者は，状態ウィンドウから選択することにより，任意

フトウェア A は，DMET によって 25 回の局所化テスのリビジョンのソースコードを取りだして編集するこトが実行され，その結果 DMET が検出したリビジョとができる．また，画面上部のボタンを利用して，テン間の差分に，欠陥が含まれていることがわかった．

ストの実行等を指示することができる．テストの結果，エラーが検出された場合には，エラーが含まれると考4. 4 ステップ 2グループ G1 および G2 に対して，ステップ 1 で得えられるリビジョンを色つきで表示する．

られた 3 つの欠陥を含むソフトウェアを与え，DSUS

DSUS は C 言語によって実装されており，規模は約20000 行である．また，GUI の実装には GTK+ を用を用いてデバグ作業を行ってもらった．デバグの際にいた．

たものを用いてもらい，与えたテストデータに対する

6

利用するテストデータについては，あらかじめ準備し論文／プログラム差分を用いたデバグ支援手法 DMET
表 2 G1 のデバグ時間 (DMET 利用)
Table 2 Debugging time of G1 (with DMET)
被験者 平均 (分)
T1
75
T2
62
T3
65
T4
79
T5
54
G1 全体
67.0
表 3 G2 のデバグ時間 (DMET 非利用)
Table 3 Debugging time of G2 (without DMET)
被験者 平均 (分)
T6
237
T7
107
T8
237
T9
69
T10
165
G2 全体
163.0

れることで初めてテストが失敗する場合や，変更の適用によりコンパイルできないといった矛盾が生じる場
合にはうまく動作しない．

5. 2 Zeller の研究
Zeller は Ness らの問題点である複数のエラーによる欠陥や変更の適用による矛盾にも対応可能な手法を提案している [17]．Zeller の手法では，修正を適用する
場合の順序は考慮せず，修正を集合の一要素として捉える．従って，行われた修正の数が n であれば，考えられる集合の数が 2n となる．Zeller は考えられる集合の中から欠陥が生じる要素数が最小の集合を見つけ出すアルゴリズムを利用する．修正の集合を利用することで，複数のエラーによって引き起こされる欠陥の原因を特定することに成功している．また，変更の適用による矛盾にも対応できるアルゴリズムであり，Nessらの手法では見つけることができなかったエラーも発処理が正しく行えるのを確認できた時点でデバグ終了

見することができる．

とした．デバグを開始してから終了するまでの，各被しかし，アルゴリズムを複雑にすることでバグの原験者が費やした時間の計測を行った．表 2 と 3 が，実因となる差分を特定する精度は上がるが，修正の数

験によって得られた各被験者 (T1〜T10) のデバグ時間

に対して指数的にテストすべき集合の数が増加する．

である (単位は分)．

従って，テストの回数が増加し，テストに多大の時間

4. 5 考察

ソフトウェア A, B のデバグ時間合計に対して，5%がかかる．

5. 3 問 題 点

有意水準による Welch の検定を用いたところ，G1 とNess らと Zeller のどちらの手法も基準リビジョン

G2 には有意な差が見られることが確認できた．本実験により，DMET を用いることによってデバグ時間をのソースプログラムを基本として考えており，テスト

短縮することができることがわかった．

て，コンパイルを行わなければならない．また，どの5. 関 連 研 究
本章では，これまでに行われてきた欠陥の原因となを行うためには毎回そのソースコードに修正を適用しソースプログラムをどのように修正したかを正確に管理した上でコンパイルを行う必要があるため，単純にコンパイルを行うだけでも繁雑な作業となる．

るエラーを特定するための手法に関する研究について

また，欠陥の原因を探るために自分でテストケース

取り上げ，既存の手法が抱える問題点について述べる．

を作成してテストを行う必要があり，各々の手法で利5. 1 Ness と Ngo の研究用しているテストツールの学習や訓練を行わなければ

Ness と Ngo はグレイ研究所において，コンパイラならない．さらには，欠陥の原因を特定するためのテ開発のために regression containment と呼ばれる手法

スト作業にのみ重点がおかれており，デバグ作業までを利用している [12]．Ness らの手法では，まず回帰テは考慮されていないため，実際の保守作業に適用するストを自動的に行う．この回帰テストが失敗した場合，ことは難しい．

基準リビジョンが正しく動作することに着目して，構DMET では，どのソースプログラムをどの時点でコ

成管理から取得した修正を実際の適用順に施しながらンパイルすることになるか，を DMET 自体の枠組でテストを繰り返し行う．テストが失敗した段階でその管理することになり，DSUS のような支援環境を用い時に適用した修正をバグの原因となるエラーとして特ることによって容易にコンパイル作業を行うことが可定する．

能となっている．また，DMET においては最初にテス

しかし，Ness らの手法は特定の状況ではうまく動作

トケースを作成しておき，それを用いたデバグを行う

するが，単一の差分だけではなく複数の差分が適用さため，欠陥に応じてテストケースを自作する必要性が
7電子情報通信学会論文誌 xxxx/xx Vol. Jxx–X No. xx

なく，またテストケース作成自体にかかる時間も軽減

487 Data Processing Organizations,” Addison-Wesley, Reading,MA, pp.151-157, 1980.

される．DMET は欠陥の特定だけではなく，デバグ作業まで含めた作業を対象としているため，実際の保守[12]

Ness, B., and Ngo, V., “Regression containment through sourcecode isolation.”, In Proceedings of the 21st Annual Internatial

作業においても容易に適用することが可能であり，今Computer & Applications Conference (COMPSAC ’97), IEEE

回実験によってそれを示している．

Computer Society Press, pp.616-621, 1997.
[13]

6. ま と めRaither, B. and Osterweil, I., “TRICS : a Testing Tool for C,” Proceedings of the First European Software Engineering Conference,
Strasbourg, France, pp.254-262, 1987.

本 研 究 で は ，保 守 作 業 を 対 象 と し た デ バ グ 手 法

DMET の提案を行った．また，試作システム DSUSを用いた実験を通じ，DMET の有効性を示した．本手

[14]
[15]

Francisco, pp.492-497, October 1976.
[16]

Tichy, W. F., “RCS - A System for Version Control, SoftwarePractice and Experience, Vol.15, No.7, pp.637-654, 1985.

今後の課題としてまず，差分検出アルゴリズムの改良によって，欠陥の含まれる差分の検出をより確実に

Swanson, E., “The Dimensions of Maintenance,” Second International Conference on Software Engineering Proceedings, San法を用いることで，実際の保守においてデバグ作業をより行いやすくなることが期待できる．

Savoye, R., “Test DejaGnu Testing Framework for DejaGnu Version 1.3,” Free Software Foundation, Inc., January, 1996.

[17]

Zeller, A., “Yesterday, my program worked. Today, it does not.
Why?”, Proceedings of the 7th European Software Engineering

行うことがあげられる．また，DMET が検出した差分

Conference and 7th ACM SIGSOFT International Symposium

が比較的大きくなった場合，DMET によって得られた

on the Foundations of Software Engineering (ESEC/FSE ’99),

結果を用いても作業時間の短縮に貢献しないことが考

Toulouse, France, September 1999.

（平成 xx 年 xx 月 xx 日受付）

えられる．このような場合，DSUS があらかじめそれを判断し，単に結果を提示するだけではなく，開発者に注意するための方法などについて検討を行いたい．
文
[1]

献

Babich, W. A., “Software Configuration Management,” AddisonWesley, Reading, Massachusetts, 1986.

[2]

CASE 1988-89, Sentry Market Research, Westborough, MA,
pp.13-14, 1989.

[3]

Carma. M 著, ベスト CASE 研究グループ 訳, “ソフトウェア[4]

開発と保守の戦略,” 共立出版社, 1993.
Cashman, P. M. and Holt, A. W. , “A Communication-Oriented
Approach to Structuring the Software Maintenance Environment,”松下

誠

平 5 阪大・基礎工・情報卒．平 10 同大学
大学院博士後期課程退学．同年同大・基礎工学研究科・助手．平 14 同大・情報科学研
究科・助手．博士 (工学)．ソフトウェア開発環境，ソフトウェア開発プロセス，オー
プンソース開発の研究に従事．

Software Engineering Notes, 5, No.1, pp.4-17, January 1980.
[5]

Conradi, R. and Westfechtel, B., “Version Models for Software

寺口

正義

Configuration Management,” ACM Computing Surveys, Vol.30,
No.2, pp.232-280, 1998.
[6]

Dogsa, T. and Rozman, I., “CAMOTE - Computer Aided Module
Testing and Design Environment,” Proceedings of the Conference
on Software Maintenance - 88, Phoenix, Ariz., pp.404-408, 1988.

[7]平 5 阪大・基礎工・情報卒．平 12 同大
学大学院博士前期課程修了．同年 IBM 基
礎研究所．修士 (工学)．在学時，デバグ支
援環境の研究に従事．

Hetzel, W., “The Complete Guide to Software Testing,” QED Informaion Sciences, Wellsley, Mass., 1984.

[8]

Kudo, H., Sugiyama, Y., Fujii, M. and Torii, K., “Quantifying adesign process based on experiments”. In Proceedings of the 21th
International Conference on System Sciences, Hawaii, pages 285–
292, 1988.

[9]IEEE., “Test Methods for Mesureing Conformance to POSIX,”ANSI/IEEE Standard 1003.3-1991, ISO/IEC Standard 132101994.

[10]

Leung, H. K. N. and White, L., “Insights into Regression Testing,” Proceedings of the Conference on Software Maintenance 89, Miami, Fla., pp.60-69, October 1989.

[11]

Lientz, B. and Swanson, E., “Software Maintenance Management:
A Study of the Maintenance of Computer Application Software in8

井上克郎 （正員）昭 54 阪大・基礎工・情報卒．昭 59 同大
大学院博士課程了．同年同大・基礎工・情報・助手．昭 59〜昭 61 ハワイ大マノア校・情報工学科・助教授．平 1 阪大・基礎工・情報・講師．平 3 同学科・助教授．平 7 同学科・教授．平 14 同大・情報科学研究科・教授．工博．ソフトウェア工学の研究に従事．