ソフトウェアの系統的な機能テスト法に関する研究

(1)

九州大学学術情報リポジトリ

Kyushu University Institutional Repository

ソフトウェアの系統的な機能テスト法に関する研究

古川, 善吾

https://doi.org/10.11501/3059399

出版情報：Kyushu University, 1991, 博士（工学）, 論文博士

(2)

第4章

システムの適用と評価

AGENTの適用と評価について述べる。まず、AGENTを実際のソフトウェアテストに適用した例について述べる。次に、実際のソフトウェアテストにAGENT を適用した結果についてまとめる。

4.1

システムの適用例

4.1.1

会話端末制御プログラムのテスト

対象システムは、「会話端末制御プログラム」である。会話端末制御プログラムの概要を図4.1に示す。会話端末制御プログラムは、ノレープパスに接続した制御用計算機上で動作する。ルーフ.パスに接続された会話端末入出力装置を介した利用者との応答を制御する。

会話端末制御プログラムは制御用計算機上で動作し、画面制御と文字変換の機能を有している。このプログラムの規模は、 Fortran K似たプログラム言語PCL で1.2K行あれ機能仕穣書と設計仕様書が23ページある。

会話端末制御プログラムのテストは、AGENT 法と従来法とを比較するために、2つの方法を並行して実施した。ととで、従来法とは、従来行われてきた検査法のととである。まず、機能仕様書や設計仕様書を読んで文書の内容を検査する。次に、検査すべき条件を検査項目(テストケース)として抽出する。さらに、

抽出したテストケースを満足するテストデータを作成した後に、テストを実施す

(3)

文字変換

画面制御

会話端末入出力装置

プログラミン支援

応用プログラム

ノレーフノぐス

コンノ〈イラ

エディタ

プロセス入出力装置

図4.1:会話端末制御プログラムの概要

(4)

る。 2つの方法で以下の点について比較を行った。

テストケース数テストケースの数は、テストデータの作成時間やテストの実施時問に影響する。入力データが正常なときのプログラムの動作を確認する正常処理のテストケースと、入力データが誤ったときのプログラムの動作を確認する異常処理のテストケースとに分けて個数を調べた。

テスト時間仕様書を読み始めてから計算機上でのテストが終了するまでの時間を比較する。テスト時聞が短いほど開発費用は少なくてすむ。さらに、文書を読んで内容を調べる文書検査時間と、テストケースの作成時間、テスト実施時間とを分けて調べた。

テスト実施時の被覆率会話端末制御プログラムにテストデータを与えて実行したときのプログラムの分岐の被覆率である。 AGENT法は、プログラム独立なテストである。機能的には充分なテストができても、プログラムの作り方によってテストで実行されない部分が残る。AGENTで作成したテストケースを満足するテストデータで実行されない部分をテストするために、追加のテストケースとテストデータが必要になる。

摘出不良プログラムをテストしたときに発見した不良が多いほど被テストプログラムに残存する誤りが少なくなり、被テストプログラムの信頼性が向上する。

作業担当者の経験年数は、AGENT法の担当者が検査経験1年て\従来法の担当者が検査経験5年である。

比較結果を表4.1に示す。従来法と比較したAGENT法の特徴的な点は、以下の通りである。

- テストケースの数が従来法に比較して減少している。しかも、正常処理のテストケースは半分に以下に減少する一方で異常処理のテストケースは増加している。

- テストケース作成に従来法の2倍近い時間がかかっている。

(5)

-摘出不良数が従来法に比較して増加している。特に、文書不良の摘出においてAGENT法が優れている。

4.1.2

ファームウェアのテストプログラム作成

スーパーコンピュータの論理をテストするために使用するテストプログラム作成にAGENTシステムを適用した。 ζの適用例はAGENTシステム開発の初期に行ったものである。そのために、テストケース作成にAGENT-Iを用いた。機能仕様を最初から原因結果グラフで記述するととが困難であったために決定表を記述した後で原因結果グラフに変換した。

ノ、ードウェアの開発において論理シミュレーションを用いたハードウェアのテストは早くから行われている

[

CHA71

]

。論理回路に基づいて「テスト」を作成するものである。 AGENTの開発においても原因結果グラフからテストケースを作成するアルゴリズムは論理回路の「テスト」作成アノレゴリズムを参考にした。

AGENTの適用例としてととで述べるのは、ファームウェアで実現された命令の機能仕様に基づいたテストプログラムの作成である。テスト対象は、ファームウェアで実現されたハードウェアであるので、ソフトウェアの場合と同様に、機能仕様に基づいたテストのためのテストケース作成をAGENTで行うととができた。

ノ、ードウェアのテストプログラムは、製品

(

^{ハードウェア}

)

の開発と並行して、

機能仕様や利用方法に基づいて検査部門で開発される。テストプログラムは、ノ、ードウェアを動作させるテストデータとしての役割だけでなく、実行結果が正しいか否かの判定まで自動的に行うものである。テストプログラムは、製品を検査するときのテストのためだけでなく、論理シミュレーションの最終段階で行われる装置シミュレーションや製品の保守、製品の機能拡張、のときにも利用される。

ノ、ードウェアのテストを行うので命令を明示的に記述できるようにテストプログラムは、アセンプラで記述される。

ハードウェアのアーキテクチャが大きく変化することは少ないために、テストプログラムは、多くの場合既存のものを改造して使用するととが多い。しかしながら、スーパーコンピュータのベクトノレ処理機構はまったく新しいものでテスト

(6)

表4.1: AGENT法と従来法のテスト内容の比較

従来法 AGENT法

テストケース数

35 26

正常処理

26 11

異常処理

9 15

テスト時間

45.0 (h) 44.0 (h)

文書検査時間

8.5 (h) 8.0 (h)

テストケース作成時間

9.5 (h) 17.5 (h) テスト実施時間 27.0 (h) 18..5 (h)

被覆率(Cl被覆率)

^{78.1 %} ^{82.2 %}

摘出不良数

8 17

文書不良

2 9

プログラム不良

6 8

(7)

プログラムを新規に開発する必要があった。ベクトノレ処理機構によって新たK作成された83 命令がテスト対象の機能である。機能仕段は、命令の動作を説明した製品仕様書に記述されたものである。製品仕様書はA4サイズで265ページある。機能仕様は、次に例を示すように文章で記述されている。

R1で指定される SRiの内容が VERの内容と等しいときには、

R2で指定されるV11Rjの内容にて、第0要素から連続するOの個数を計数し、その値(正またはOの32ピット固定小数点データ)とSRi の内容の上 32ピットを符号付き固定小数点データとして加算し、結果を再びSRの上32ピットに格納する。 SRiの内容とVERの内容が等しくないとき、何も行われない。

テストプログラムの開発状況を表4.2に示す。計画の欄は、従来の経験に基づいた予測である。AGENT 法の欄は、AGENTシステムを用いて作成したテストケースに基づいてテストプログラムを開発した時の結果である。また、その他の欄は、従来の経験に基づいて予測できる利用方法や機能仕様に出てとない内部

仕様(論理回路)から作成したテストケースに基づいたものである。

論理シミュレーションの最後の段階で行われる装置シミュレーション時にテス

トプログラムを実行したときに発見した不良の割合を表 4.3 K示す。ただし、表 4.2に示したテストプログラムの他にランダムに組み合わせた命令列15 KSをテストプログラムとして使用した。そのために、表4.3 のその他(AGENT法以外で作成)の欄のために使用したテストプログラムは27 KSである。

従来、機能仕様書からテストケースを作成するためには、経験を必要としてしていた。また、ハードウェアのテストプログラムは、既存のテストプログラムを拡張して使用するととが多い。しかも、アセンプラで記述されているためにテストプログラムの作成を経験者が担当する必要があった。新人は、経験者の指導の下にテストプログラムの作成に参加していた。とのペクトノレ処理機構は、新規の開発であるので、テストプログラムを新規に開発する必要があった。また、AGENT

法は、機能仕様を原因結果グラフで記述すればテストケースを作成できる。以上

(8)

のととから、テストケースとテストプログラムの作成を主に新人が担当した。経験者は、機能仕儀の解釈の指導や、原因結果グラフおよびテストケースのチェッ

ク、経験を必要とする利用法に基づくテストケースの作成を担当した。表4.4 I'C、

経験者と新人の貢献度 (開発工数)について、従来法(推定)とAGENT法それぞれの割合を示す。表4.2 I'C示したように、実際の開発工数 (44)は計画(4.5)と差

がない。そのために、とのテストでは、新人の貢献度が約2倍向上したととがわかる。

4.2 システムの評価

4.l.1節や4.l.2節の例やその他の適用例からAGENT法の特徴として以下のととがいえる。

l. テストケースの充実。

テストケース数は、従来法に比較して増加したり、減少したりする。とれは、

従来法が個人の経験や勘に依存しているために一定の品質が保証されたものとはなっていないためと考えられる。 AGENTシステムによって作成したテストケースの特徴は次の通りである。

- プログラムの異常処理のテストケースが増加する0

・プログラムの正常処理のテストケースは減少する。

入手で作成する場合は、まず、正常動作を確認するためのテストケースを作成し、その後で時間に余裕があれば入力誤りなどの異常事態に対するプログラムの動作を確認するためのテストケースを作成する。そのために、正常動作については過剰なテストケースを作成するが、異常動作に対してはテストケースが少なくなる。また、人間の思考傾向として異常処理よりも正常処理の方が理解しやすいために、テストケースとして抽出するときも正常処理の方をより詳しく検討するためと考えられる。 AGENTシステムは、プログ

(9)

表4.2:テストプログラム開発状況

計画実際

AGENT法その他合計テストプログラムの大きさ(1<S) 42

開発工数(人月) 45

37 35

12 49

9

₄₄

表4.3:ベクトル処理機繕の不良発見割合

テストケース数の割合(%)

テストプログラムの大きさ(1<S) 発見不良の割合(%)

AGENT法その他

79 21

37 (59 %) 27 (41 %)

85 15

表4.4:経験者と新人の貢献度

テストケース作成テストプログラム作成全体

従来法 AGENT法

経験者

37

新人経験者新人経験者新人

0

63

vhυ ハ汐にυ 1i

45 81

66 34

23 77

(10)

ラムの正常処理や異常処理の区別を行なわずにテストケースを作成するので上K述べたような特徴が出てくる。

2. テストケース作成時間の増加。

従来のテスト作業におけるテストケースの作成は、ソフトウェアの機能仕様書や設計仕様書を読んで、検査担当者が必要と判断した条件をテストケースとして抽出する。一方、 AGENTを用いたテストの場合は次の手順で行なう。

( ^a ) 機能仕様を機能図式で記述する。

(b)

AGENTプログラムによって機能図式からテストケースを自動的に作成する。

従来法に比較すると、機能図式を記述するための時間が必要で、テストケース作成により多くの時聞がかかる。しかも、機能図式は、状態遷移と論理関係を用いた形式的な記法である。そのために、機能仕様があいまいであると機能図式を作成できない。特に、機能図式を作成するのが検査担当者である場合には、プログラムの機能仕様を十分に理解していないことが多い。また、

修正ゃあいまいさの除去は開発部門の責任であるために、誤りがあった場合にその修正に時間がかかり、ますます時聞がかかる。しかしながら、形式的な記法で記述する過程で機能仕様の誤りを発見する機会が増加し、ソフトウェアの信頼性向上には効果がある。

機能図式で機能仕様を記述しであればテストケースの作成は従来より少なくなる。また、 AGENTによって{乍成したテストケースは、十分なテストのための最低条件である。基本的なテストは開発部門に任せてその結果の確認だけで済まし、より特殊なテストに専念するととが検査部門としては望ましい。従来のように開発部門でのテストが入手に頼るものでは、検査部門としてテストの十分性を評価できないために開発部門だけに任せるととができな

(11)

かった。 AGENT法を用いたテストでは、機能図式をチェックするζとによってテストケースの品質を確認できるので、テスト品質を評価できる。

3. ソフトウェアテスト品質の向上。

AGENTで作成したテストケースは項番1で述べたように、異常処理については従来より充実し、正常処理についての十分性が保証されているのでテスト品質が向上する。とのととは、テスト実施時のプログラムの被覆率の向上からも言うととができる。

4. ソフトウェアの信頼性向上。

4.1.1節のAGENT法の適用例では、AGENT法の評価のために従来法と平行してAGENT法を適用した。効果の 1っとして摘出不良数が従来法よりも多くソフトウェアの信頼性向上に有効であるととがわかった。

特に、機能仕様の不良摘出に効果があるととがわかる。とれまで、機能仕様の誤りゃあいまいな点の発見は、文書検査として行なわれていた。項番2で述べたように、AGENTでテストケースを作成するためには、入力として機能図式を書かなければならない。そのために、機能仕様があいまいであると機能図式で記述できない。機能仕様を機能図式で記述することによって機能仕様の誤りゃあいまいな点を発見できる。テストケースを作成するために機能仕様を形式的な言語で記述するととによって機能仕様をあいまいに記述していたととがわかる。

状態遷移図は、状態によってプログラム内での記憶を表現する。同じ入力条件に対して異なった出力条件を与えるためには、状態が異なっているととが必要である。ととろが、ソフトウェアの機能仕様は複雑であり、状態遷移だけで表現するととができないか、困難なととがある。例えば、ループを3回繰り返す場合は、ノレープが1回のときと2回、 3 回のときの状態を作成しなければならないので、状態数が多くなり、記述が困難になる。また、状態遷移機械は正規文法の言語だけを受理する。一般のプログラミング言語が属

(12)

している文脈自由文法の言語を表現するためには、少なくともプッシュダウンオートマトンが必要である

[

HON72

]

。また、ソフトウェアの開発現場では、これまでとのような形式的な記述法を取り入れていないために、記述法を習得するために時間が掛かる。

5. テストの系統化およびテストの標準化。

4.1.1節の適用例で、検査経験1年の新人に近い検査担当者が、経験5年のベテラン以上のテスト品質を達成できたととがわかる。とれは、 AGENT 法という系統的なテスト技法を用いたととによって、検査経験が少なくてもテスト品質が高くなったためと考えられる。また、 4.1.2節の適用例では、

新人が経験者と同等以上に検査作業に貢献できることがわかる。

AGENTによって、検査担当者の能力によってまちまちであったソフトウェアの機能テストのためのテストケースの品質を一定にするととができる。とれまでは、未経験者が作成したテストケースではプログラムを十分にはテストできず、検査部門では人手の不足が慢性的であった。 AGENT で作成したテストケースは、プログラムの全ての誤りを発見できるものではないが、

機能図式で機能が十分に記述されていればテストケースの品質を十分なものにするととができる。そのために、新人であっても機能図式を記述するととによって基本的なテストを行なうためのテストケースを作成するととができる。さらに、記述した機能図式を経験ある検査担当者とレピューするととによってテストケースの品質を高めるととができる。

4.3

実際のソフトウェアテストへの適用

AGENTシステムの開発は大きく2つの時期に区分するととができる。最初は、原因結果グラフ技法に基づいたAGENT-Iシステムの開発である。 AGENT

Iの開発は1979年から開始し、最初にプロトタイプを作成してアルゴリズムを確認し、1980年の半ばに完成した。その後も、高速化や出力形式の改善を行なった。 AGENT-I システムは、原因結果グラフで記述した機能仕様からテストケー

(13)

スを作成する。原因結果グラフだけで機能仕様を表現するととが困難であり、適用が広まらなかった。 AGENT-Iの問題点を解決するために1980年の後半から機能仕様の記述法として機能図式を開発した。機能図式による機能仕様の記述は原因結果グラフによる記述の約半分で行なうととができる

[

FUR82c

]

。機能図式で記述した機能仕様からテストケースを作成するAGENT-II を1982年に開発した。

その後、AGENT-IIシステムの適用を日立製作所全体K拡大した

[

NOG84

]

。 AGENTを適用したプログラムの数の推移を表4.5 K示す。ただし、表4.5 には、試験的に適用を試みたプログラムのテストを含んでいる。 AGENTシステムは、ソフトウェアの機能の基本的なテストケースを作成するので、ソフトウェア開発の初期のテストでのテストケース作成に適している。また、設計部門は、ソフトウェアの機能仕様を熟知しているために、機能仕様のもともとの記述形式が状態遷移図や状態遷移行列の場合は、機能図式に変換するととなく、AGENTシステムの入力を作成するととができる。とれらの理由で、検査部門でよりも設計部門で適用する方が効果が大きい。表4.5の「設計」の行は、設計部門のみあるいは検査部門と共同でAGENTをテストに適用したソフトウェアの件数である。

次に表4.6は、1984年と1985年の2年聞に適用したソフトウェアの中で対象プログラムを分類できた場合の種類毎のAGENTの適用件数である。表4.6には、入力形式として原因結果グラフのみを用いたか、機能図式まで利用したか、

の区別を示す。対象ソフトウェアの種類は、以下の通りである。

1. システムは制御プログラムおよびサーピスプログラム、

2. DBはデータペースおよびデータコミュニケーション関連プログラム、

3. 通信は通信応用プログラム、

4. 言語は言語プロセッサ、

5. 応用はアプリケーションプログラムおよび業務プログラム。

最初の試用時の結果とは異なり、原因結果グラフのみの利用が多い。これは、

従来のテストケースが断片的なケースとして取り出していたために、AGENTシ

(14)

ステムの適用時にも機能仕様を断片に細分した後にテストケースを作成したためと考えられる。そのために、機能図式を使って作成したテストケースを従来法と比較したときに、「テストケースの密度が異なる」との意見があった。一方、通信ソフトウェアのみは、機能図式での適用が多い。通信ソフトウェアの機能仕様は、従来から状態遷移図を用いて記述されていた。そのために、 AGENTシステムの適用に当たっても状態遷移図を用いた機能図式に取り組み易かったものと考えられる。

4.4

今後の課題

AGENT法は、ソフトウェアが実現しようとしてる機能から基準の明確なテス

トケースを自動的に作成しているので、テストの系統化の基礎を与える。とのテスト法だけでプログラムのテストは完了するのではなく、テスト実施時のプログラムの被覆率の測定によるテスト十分性の評価や、誤りを発見し易いテストデータの選択など他のテスト法との有機的な結合が必要である。

今後の課題としては、機能設計段階での機能仕様を記述する言語として機能図式を整備するととと、テストケースだけでなく実際のテストデータを作成するとと、テスト実施時の実行結果の確認をテストケースを利用して自動化するとと、

が考えられる。さらに、ソフトウェアテスト法の中で並行処理プログラムのテスト法の開発が現在の急務である。プログラムの動作を列として取り扱うζとは、

プログラムの動作を理解するために効果的である。並行プログラムのテスト法としてプログラム内の並行事象に着目して、その列をテストケースと考えるととが提案されている

[

^TAI86

]

。ただし、並行処理プログラムでは、列の数が指数関数的に増大するためにテストケースの品質を列の数で評価することは適当ではない。

このような並行処理プログラムのテスト法については、テストケースの品質やテストの再現性、並行処理プログラムの実行結果の確認、テスト充分性の評価、という課題が数多くある。

(15)

表4.5: AGENT適用件数の推移

1979年 1980年 1981年 1982年 1983年 1984年 1985年合計

全体設計

2 28 105

10 170 71

206 108

243 155

335 1089 212 556

表4.6:ソフトウェアの種類毎のAGENT適用件数

システム DB 通信言語応用合計

全体原因結果グラフ

機能図式

nku qtU Fひ

っ“

ウ』

FhU にυ 内，J 1i つJV ハO 円i ハU nhv qd

守ti

A吐 A斗A nU

4 3 1

ヴa qO A斗A 1Eム

唱，A ρnU

FO ti 06 ρo qru 只U FO qtυ ヴt nU ウt っ“

つ山

(16)

第5章結論

本章では、本研究の成果と問題点について論じ、最後に本研究の今後の発展性について述べる。

5.1

成果

本論文では、ソフトウェアの開発現場でテストを系統的に行なう方法を提示した。また、実際にソフトウェアのテストを行なう際にソフトウェアの機能仕様から自動的にテストケースを作成するプログラム(AGENT) を開発し、ソフトウェアテストの品質向上を実現した。 AGENTは、機能図式と呼ぶ形式的な記法で記述した機能仕様から、テスト能力の明確なテストケースを作成する。 AGENTで作成したテストケースは、プログラムをテストするための基本的なテストケースである。そのテストケースを用いたテストの実施で測定したプログラムの被覆率から不足しているテストケースや経験的に誤り発見に効果のあるテストケースを追加してテストするととによって、ソフトウェアの信頼性をより高めるととができる。機能図式は、状態遷移(状態遷移図) と論理関係(原因結果グラフあるいは決定表)を用いて機能仕様を記述する。機能図式からAGENTで作成したテストケースは、論理関係の入出力条件を確認し、状態遷移の遷移を少なくとも1回実行する。

開発現場でAGENTを利用した結果、以下のような効果があるととがわかった。

(17)

- テストの品質向上

ソフトウェアをテストするために作成するテストケースが充実し、テスト作業でテストの充分性が向上する。

- ソフトウェアの信頼性向上

AGENTでテストケースを作成するには、機能図式と呼ぶ形式的な記法で機能仕様を記述する。形式的な記法を用いるので機能仕様の誤りゃあいまいな点を発見するととができる。さらに、AGENTで作成したテストケースは、従来法に比較してテストケースの品質が向上するので、テストケースから作成したテストデータを用いて被テストプログラムを実行するテストの実施で発見できる誤りが増加し、発見されずに残るプログラムの誤りが減少する。そのために、プログラムの信頼性が向上する。

- ソフトウェアテストの標準化

ソフトウェアテストは、経験を必要とする知的作業であり、これまでは、充分な信頼性を確保するために、経験者が担当していた。AGENT を用いたプログラムのテストは、手順が明確であるので、経験がない新人であっても担当するととができる。しかも、機能図式を記述した時点やテストケースを作成した時点で、それぞれの生成物が形式化されているために、チェックが比較的容易である。そのために、テスト作業の品質を一定に保つととができる。経験者は、AGENT法で対象としていないテスト条件に基づいたテスト作業に専念できるのでさらにソフトウェアの信頼性を向上させるととができる。

5.2 問題点と考察

5.2.1 AGENTシステム

最初にAGENTの問題点について考える。AGENTを利用するためには、機能図式を記述しなければならない。従来のテスト方法では、テスト実施者が機能

(18)

仕様を読んでチェックすべきと判断した項目をテスト条件あるいは確認項目として取り出していた。 AGENTを利用するために機能図式を記述することは従来はなかった作業であり、テストの作業時聞が長くなる。実用化K当たっては、との点が最大の問題となった。との作業時間の増大に対する反論としては以下のととが挙げられる。

・ソフトウェアの信頼性を向上するために必要な作業である。本来、ソフトウェアの開発では、機能仕様を形式的な記法で記述し漏れをなくすととが必要である。それにもかかわらず、とれまで行なっていなかったために信頼性が低かった。

-信頼性の向上に効果がある。実際のソフトウェアテストで誤り発見の向上という効果がある。特に、とれまで自然言語で記述されていた機能仕様を形式的な記法で記述するととによって誤りの発見ができる。そのために、残存ノぐグ数が減少し、デノぐッグ時聞が減少するので、開発作業全体では作業時間の削減になる。

-テスト段階になってから形式的に機能仕様を記述しようとするために時間がかかるのであって、開発の最初の段階から機能仕様を形式的に記述すればテスト時間の増大にはならない。そのととは、機能仕様そのものの信頼性向上となり、開発時間全体の削減となる。

それでも、開発現場では時間の増大はなかなか受け入れらず、 AGENT法の適用を強制するととも必要であった。開発の初期の段階から機能仕様を形式的に記述するととが開発作業全体の短縮になるという観点からは、最大の効果を期待できる。しかしながら、その方法は開発作業全体の見直しが必要でありさらに抵抗が予想される。ソフトウェア工学の研究成果を実用化する過程では、これまでの作業の慣性を打ち破るための苦労が常につきまとう。

ζのような作業時間の増大に対処する1つの試みとして、プログラムから機能図式を作成する試みを行った[FUR87b]。プログラムから機能図式を作成するととの利点は以下の通りである。

(19)

-

機能図式の作成時間を削減できる。プログラムは計算機が理解できる形式であるので、機能図式を計算機で作成するととができる。そのために、機能図式の作成時間を削減できる。

- テストデータを自動的に作成できる可能性がある。入力条件や出力条件をプログラムから抽出するので、条件が形式的に記述されている。形式的K記述された条件を解くととによってテストデータを自動的に作成できる可能性がある。

一方、短所は以下の通りである。

-機能テストの利点を失う。プログラムに基づいてテストケースを作成するので、プログラムに誤りがあるとテストケースの品質が低下する。

-テストケースの数が増加する可能性がある。プログラムから機能図式を作成するので、機能仕様では記述されない細かい条件を抽出してしまう可能性がある。そのために、機能図式が大きくなるのでテストケースの数が増大する可能性がある。

-完全には自動化できない。プログラムの実行可能性を調べる必要がある。しかしながら、計算機によって解決できない場合があるので、入手の介入が必要となる。

ソフトウェアの機能仕様の記述用言語としては、機能図式には以下のような難点がある。そのために、汎用的な機能仕様の記述用言語としては不十分である。

1. 抽象化機能がない。大規模なソフトウェアの機能仕様を記述するには、抽象化機能は必須である

[

NOG89

]

。機能図式では、テスト対象の機能を形式的に表現できることを主眼にしている。そのために、抽象化機能は必要がない。

また、上位の機能仕様として記述した状態遷移図の状態を具体化すると非決定的な機能仕様となるととがある。

(20)

2. 並行処理が記述できない。ソフトウェアの機能仕様を設計する場合、人とのやり取りを入出力として記述する。厳密なモデル化を行なうためには人の行為をモデル化して機能を決定する。とのとき、システムと人は並行した処理を行なっているので、機能仕様の設計には並行処理の記述が必須である。さらに、最近の分散システムの普及にともなって、並行処理の記述はますます必要になってくる。

AGENTの実現では原因結果グラフから部分テストケースを作成する際の処理で多くの高速化のための工夫を行なった。しかしながら、 Rothのdアノレゴリズムは、原因の2n個の組合せをすべて試みるために処理に時間がかかる場合がある。それを避けるために冗長性のない原因結果グラフを計算機で作成することは、可解な問題ではない。ツーノレの実用性を重んじるのであれば、指数関数的な処理時間の増大は受け入れるととはできない。時間の増大を防止するためには、

部分テストケースの厳密性を放棄したアノレゴリズムとするか、入手の介入を認めるかである。

部分テストケースの厳密性を放棄するのでであれば、入出力条件の値の全ての組合せを部分テストケースとする、入力した決定表の入出力条件の値の組合せをそのままテストケースとする、ことが考えられる。前者は、テストケース数の増大となり、テスト実施時間の増大となる。後者は、漏れのないテストケースではなくなってしまう。

もう1つの解決策として、部分テストケースの作成で前方操作や後方操作で矛盾が発生した時点で処理を停止し人が介入する。決定表あるいは原因結果グラフをチェックし、矛盾を生じない論理関係とする。 ζの方法は、利用者が AGENT プログラムの処理を知っており、論理関係の簡単化を容易に行えなければならな

レユ。

どちらの方法にしても、ツールの実用性あるいは技法の厳密性を犠牲にするととになる。

AGENTは、テストケースを{乍成するシステムである。そのために、テストを実施するためには、被テストプログラムの入力データであるテストデータをAGENT

(21)

で作成したテストケースに基づいて作成しなければならない。との手問を省くためには、テストケースの入力条件をテストデータのレベルで記述するととが必要である。テストデータのレベルでテストケースの入力条件を記述することによる問題点として以下のととが挙げられる。

1. 一般に、テストデータは無限個存在する。現実的にテストの実施が可能なテストデータを選択するためには、入力条件を記述する段階でテストデータが現実的に処理可能な個数になるように選択するととが必要である。そのために、テストデータのレベルで記述した入力条件では、被テストプログラムの入力データの定義域を完全に包含するζとができない可能性がある。とのような完全でない入力条件に基づいて作成したテストケースは、被テストプログラムの入力データの定義域を完全に包含するととができない。

2.

作成されたテストケースとテストデータが1対1K対応してるので、全てのテストデータに対して被テストプログラムを実行しなければならない。そのために、テストケースを満足するテストデータを作成する段階で、テストに残された時間で実施できるだけのテストデータを作成する自由度が失われてしまう。また、テストデータの追加や削減のためには、機能図式の記述とテストケースの作成とをやり直す必要がある。

テストを完全に近付けるためには、より多くのテストデータに対してプログラムを実行するととが必要である。しかしながら、開発現場では、無限の時間をテストに掛けるととができない。そのために、上記の方法では、テストケースのレベノレで完全なものを作成し、テストデータ作成の段階で、許された時間内で実施できるテストデータを選択し、効率よくテストを実施するという利点、が失われる。

テストケースの作成とテストデータの作成を分けて、その利点を生かすためには、

作成したテストケースから効率よくテストデータを作成するととが必要になる。

テストデータの作成を自動化して効率化するには、以下のことが必要である。

- テストケースの入出力条件の形式的な記述

(22)

現在の機能図式の入力条件や出力条件の記述は形式化されておらず、単にコメントとして扱っているだけである。テストデータの作成を自動的に行うためには、計算機で処理できるように形式的に記述するととが必要である。しかも、出力条件を形式的に記述することによって、テスト実施時の被テスト

プログラムの実行結果の判定を自動化できる可能性がある。

-新たな条件記述の導入

テストケースの作成とテストデータの作成を分離するのは、それぞれの作業で決定すべき項目が異なるためである。テストデータ作成時の決定事項をテストデータ作成に組み込むために、テストデータ作成の条件としては、テストケースにおける入力条件だけでなく、新たな条件をテストデータ作成に導入するととが必要ある。

また、同じ入力条件を満足するテストデータであっても、誤り発見能力が異なることがある。例えば、「正の整数」という条件を満足するテストデータとして、1，2，3の3個の数字よりも1，10，100という3個の数字の方が誤り発見能力は、一般に、高いと考えられる。テストケースの作成においては考慮しなかった条件を追加するととによって誤り発見能力に差が発生する。誤り発見能力の定式化の試みが行われている

[

HOW8 0， ZEI83

J

_{。さらに、経験}

的に知られている誤り発見確率の高いテストデータに関する知識を知識ペース化し、実用化が進んでいる知識処理技術によって系統的にテストデータを作成する研究の余地がある。

-対話処理の導入

テストケースからテストデータを作成するためには、入力条件を解くととが必要である。しかしながら、不等式の解を自動的に求める問題は可解ではない。とれを解決するためには、入手の介入が必要である。入手の介入を許した場合には、誤り混入の防止とテストデータを再生成する時の作業の繰り返し防止の対策が必要なる。

(23)

AGENTは、現在のととろテストケースを作成するだけのシステムである。テストを効率的に実施するためには、テスト作業全体を通して支援するシステムが必要である。

さらに、テスト実施における作業を効率化するために現在普及が進んでいるテスト・デバッグ支援システムとの統合がある。テスト・デノぐッグ支援システムは、

被テストプログラムの実行と実行結果の確認を支援する。被テストプログラムをテストデータで実行したときの確認は手間と注意力が必要な作業である。被テストプログラムの実行結果の中から、誤りを見つけ出すには、大量の出力データを注意深く調べなければならない。また、実行結果が誤りを示していても、誤りに気が付かずに見逃すととが起とり得る。 AGENTで作成したテストケースは、入力条件の組み合わせに対応する出力条件を記述する。との出力条件を形式的に記述し、テスト・デパッグ支援システムで解釈するととができれば、実行結果の確認を自動的に行うととができる。

5.2.2 ソフトウェアテスト

次に、ソフトウェアテスト法について考察する。ソフトウェアのテストは、信頼性向上の一手法である。テスト以外に信頼性向上の手法としては、正当性証明がある。ソフトウェアの正当性証明は、ソフトウェアの正しさを数学的に証明しようとするものである。そのために、機能仕様を形式化し、プログラムの意味論に基づいて、プログラムが仕様を満足するととを証明する。極論するとソフトウェアのテストは、被テストプログラムを実行したテストデータに対してのみプログラムの正しさを主張できるのに対し、正当性証明は入力条件を満たす全ての入力データに対しプログラムの正当性を数学的に証明する。しかしながら、実用的なプログラムの信頼性向上技法としては、適用可能性および適用に要する費用の点でテスト技法の方が優れている。

これまでは、自然言語で記述された機能仕様を基にテストが実施されてきたので、テストは、形式的な技法とは考えられていなかった。 AGENTで試みたように、形式的に記述した機能仕様に基づいたテストケースの作成や、テストデータ

(24)

の作成の自動化、実行結果の自動判定を行うためには、テストにおいても形式的な手法を用いるととが必要になる。

テストそのものの理論的な取り扱いは、 Goodenough等が始め[G007.5]、そ

の後、理論的な展開や、テスト基準の提案と評価が行われてきた[HO\V78a.， \VEY80，

WHI80， ZEI81， CLA82]o Gourlayは、テストの数学的な枠組みを与え議論の明確化を行った[GOU83]。最近では、プログラムのデータフローに基づくテスト基準に関する検討が盛んである [WEY84， FRA88， CLA89]。プログラムの制御フローに基づいたテスト基準がプログラムの構文的な構造に関するテスト充分性を評価するのに対して、データフローに基づくたテスト基準は変数の意味を考慮、してテスト充分性を評価する。 Howdenのr Functional Testing Jも同様に窓味論に基づくテスト法である[HOW87]o また、個々のテスト法の提案だけでなく、テスト法の特性を取り出して、テスト法の比較を行う研究が行われている[CLA83，

WEY86， FRA88]。

とれまでは、テスト法の提案と評価が中心であったが、今後の動向としては、

提案されたテスト法の中から実際のテスト作業の中に取り入れるべきテスト法の選択が行われるであろう。単にテストケースやテストデムタの作成基準を与えるテスト法だけでは実際のテスト作業を効率化し、テストの品質を向上させて、ソフトウェアの信頼性を向上させるには充分ではない。テスト作業だけでなく、ソフトウェア開発作業全体の中での効率化、信頼性の向上が必要とされる時期である。

ソフトウェアのテストの大きなテーマの1っとして現在注目を集めているのが並行処理プログラムのテスト法である[TAI86， TAI89， TAY86]。計算機の普及によって並行処理システムや分散処理システムが実用化されている。並行処理プログラムの研究では、とれまで、その記述法や実現方法が研究課題となっていた [AND83]。逐次処理プログラムのテスト法は、多くの入力データの中から、効率良く誤りを発見し、ソフトウェアの信頼性を確認するための、テストデータをどのようにして選択するかが1つの課題であった。逐次処理と同様に、テスト法を考え、その効率を検討するととが必要である。

(25)

しかしながら、並列処理プログラムのテストでは、逐次処理プログラムのテストとは異なった以下の点に関する考察が必要である。

1. 逐次処理プログラムでは、プログラムの記述言語が異なっても、ノイマン型の計算機であれば、動作モデノレとして有向グラフがあり、有向グラフの上でテスト法を定義することが1つの方法として考えられた。並行処理プログラムでは、記述言語毎に動作モデノレが異なっているために、それぞれの動作モ

デノレ毎にテスト法を定義するととが必要になる。

2. 並行処理プログラムは、入力データの定義域だけでなく、実行のタイミングがテスト条件の1つになる。逐次処理プログラムに比較すると、より多くの可能性の中からテストデータを効率的に選択するととが必要になる。

3. テストケースの条件としてタイミング情報は欠かせないものである。そのタイミング情報についてのテストケースを作成したとしてもテストケースで指定されたタイミングをテスト実施時に実現するための機構が必要になる。

4. 逐次処理プログラムは、実行系列の再現性が保証されているが、並行処理プログラムでは、実行時のタイミングや環境条件の変化によって実行系列が変化する。そのために、同じ入力データであっても、出力結果が同じになる保証はない。誤りを発見するためだけのテストでは、再現性のなさは問題とならない。しかしながら、誤りが発見されたときその誤りを修正した後での確認のための実行はテスト条件を再現するととが必要である。

5.2.3

ソフトウェア工学

次に、ソフトウェア工学全体との関連性について考察する。ソフトウェア工学は、ソフトウェアの開発を工学的に行うための研究である。ソフトウェアの開発は多くの人手を必要とする「労働集約」型である。そのために人や組織との関係についての考察が必要である。

(26)

- ソフトウェア工学の成果として計算機による支援システムを検討するととが多い。その場合、「計算機は、優れた能力を持った人を越えることはできない」というζとを銘記しておくととが必要である。計算機にできるととは、

ソフトウェア開発作業の平均値を向上させるととだけである。単純作業の繰り返しにおいては、計算機の方が人よりも優れている。しかしながら、ソフトウェアの開発においては、知的な作業が中心であり、そこでは計算機が人間を越えるととはできない。

- ソフトウェアの開発現場では、プログラム開発に追われているために新しい技法の導入には大きな抵抗がある。特に、開発工数の増大を伴うような技法を導入するにはよほどの覚悟が必要である。

先にも論じたが、形式化技法とテスト技法の連携は今後ますます必要になる。

特に、要求定義技法の中の実行可能性を備えた要求定義言語との関係、が深まる。

実行可能性を備えた要求定義言語は、とれまでの、静的な要求定義技法に対して、

操作的な要求定義技法を支援するために考えられたものである

[

NOG89

]

。操作的な要求定義技法は、要求定義言語による静的な記述によって要求定義を行うだけでなく、それぞれの要求定義言語の動作モデノレに従って要求仕機を実行する。要求仕様を実行するζとによって、要求仕様の理解を深め、利用者の要求を的確に把握しようとする技法である。

静的な記述では、全ての条件や状態を記述しなければならない。一方、要求仕様を実行するととができる場合には、動作モデノレで表現されている条件や実行時に実現される状態を陽に記述する必要がない。そのために、要求仕様の記述が容易になるし、理解する場合にも、実行の流れとそれぞれの状態での条件を分離して理解すれば良いので、理解が容易になる。とのととは、 AGENTを利用するために機能図式を記述する場合にも当てはまる。 AGENTでは、テストケースの作成が機能仕様の実行に相当している。機能図式を記述した時点では気付かなかった誤りが、作成されたテストケースのチェックやテストケースからテストデータを作成する時点で発見されることがある。

(27)

実行可能な要求仕様が作成できれば、要求仕様の実行系列がそのまま、プログラムのテストケースとなる。要求仕様の実行系列を作成する段階で、要求仕様の動作モデルの上でテスト充分性を確認すれば、テストケースの充分性を保証できる。さらに、被テストプログラムの実行結果は、要求仕様の実行系列と同じ順序で出現するはずであるので、実行結果の自動確認が可能になる。

5.3

本研究の今後の発展の方向

ζれまで、本研究における問題点と今後の研究課題および研究の方向について述べてきた。ととで、研究としての発展の方向をまとめる。

テストケース作成ツールAGENTは、テストケース作成ツールて・ある。テストケースを自動的に作成する。入手の介在を許さないととを目指したために、実際にはプログラムを実行する複数の条件のどれであっても良い場合でも、その選択の自由を残していない。選択の自由を残すととによってテスト作業の短縮が可能な場合がある。 ζのような、実用化のための調整を続ける必要がある。

テスト支援ツール機能図式の条件の記述を形式化するととによって、単に、テストケースを作成するだけでなく、テストデータの作成や被テストプログラムの実行結果の自動確認が可能になる。

ソフトウェア開発支援ツール機能図式は、ソフトウェアの機能仕様を形式的に記述する1つの手段を与えている。しかしながら、機能仕授の設計言語としては、不十分であれ抽象化や並行処理の記述を可能にするととによってソフトウェアの開発作業の全体を支援するととが可能になる。さらに、実行可能性を備えた要求定義言語とするととによってソフトウェア開発の一層の効率化ができる。

テスト法並行処理システムや分散処理システムの実用化が進んでいる。並行処理プログラムは、逐次処理プログラムに比較すると、動作モデルが確定してい

(28)

ない、タイミングを考虐するという謀題がある。正当性証明の研究が進んでいるとはいえ、実用的なプログラムにおいては信頼性確保のための手段としては、テストを捨てるわけにはゆかない。並行処理プログラムのテストについても逐次処理プログラムと同様のテスト法の研究が必要である。

(29)

あとカミき

最近の計算機の発展には、計算機の研究に携わっている者にとっても驚くべきものがある。本研究に取り掛かった時点では、パッチ処理からTSSへ移行する時期であった。その後、日本語ワードプロセッサが発表され、パーソナルコンピュータが普及し始めた。現在では、パーソナノレコンピュータは名前の通りパーソナルなものになり、さらに、ワークステーションが普及し始めている。ワークステーションは、単独で使用するよりもネットワークによって接続されており、ディスク領域の共有やcpuの効率的な使用が始まろうとしている。

ソフトウェアテストでは、研究そのものにパーソナルコンピュータやワークステーションを利用するととろまでは至っていないが、文書や図表の作成では、計算機の発展を謡歌するするととができた。

ソフトウェアの開発という知的な作業において、人は最大の貢献をしてくれると同時に最大の障害でもあった。単純作業を計算機で行うととによる効果は明らかである。ソフトウェアの開発における知的な作業を計算機で行おうとすると「賢い人間」には、かなわない。そのために、研究と言いながら、「賢い人間」から

見ればひどく幼稚な作業を行えるだけである。

また、実用化においては、人間の慣性力が新しい技術の導入の障害となる。研

究の初期においては技術的に至らない点が適用の障害となることがあった。しかしながら、ある程度のレベルに達しでも新しい技術に対する抵抗感が導入をためらわせる場面が多かった。そのような場合、新人ほど抵抗なく新しい技術を受け入れるととができる。現在ノ〈ーソナノレコンピュータからワークステーション、ミ

ニコンピュータまで広く使用され始めている unlXが開発着手から実用化までに

(30)

10年の歳月を要し、さらに、普及に10 年近い月日を要しているのもうなづけるところである。

本研究の大部分は、日立製作所に入社して退社するまでの9年の内の8年聞に行ったものである。 9年自に大学に戻ったときに、卒業研究で使用したパンチカードの束が廊下の片隅にひっ・そりと積み上げられており時代の流れを感じさせられた。一方、ソフトウェアの開発についてみると、多くの人が大量に生産した仕様書の中で奮闘しながら、打ち合せに明け暮れる開発現場と、計算機に埋もれながらプログラムを作成する大学との環境の格差に驚かされた。ととら辺りでペンを置く

(

キーボードの前から離れると言った方が正確であろう

)

。

(31)

謝辞

本研究を行なうにあたり終始ど指導いただいた九州大学工学部情報工学科牛島和夫教授に深謝いたします。また、本論文についての多くの有益など助言をいただいた、九州大学工学部情報工学科長田正教授、九州大学大型計算機センター研究開発部島崎箕昭教授、九州大学工学部電子工学科二宮保教授に感謝いたします。

目立製作所基礎研究所の野木兼六氏には、 AGENTの開発、適用を推進していただきました。実際のソフトウェアテストへの適用には日立製作所の各工場の検査部員の皆様にど協力いただきました。ととに記して謝意を表します。目立製作所を退職後暖かく受け入れていただき、激励していただいた九州大学情報工学科の先生方に感謝いたします。また、計算機環境の整備や討論に応じて下さった研究室の皆さんに感謝いたします。

199 1年著者

(32)

参考文献

[ABB81]

[AH077]

[ALF85]

[ALL 76]

[AND79]

[AND83]

[ARA82]

[ARA91]

Abbott， R.J.， 1100rhead， D.K. : Softwa.re Requirements a.nd Spec

i五ca.tions: A Survey of Needs a.nd Languages， The Journal of Sys

telus and Software， No.2， pp.297-316， 1981.

Aho， Alfred V .， Ulhna.n， J.D. : Principles of COlnpiler Design，

Addison-Wesley Pub.， 1977.

Alford， M. : SREM a.t the Age of Eight; The Distributed COlUput

ing Design Systenl， COluputer， Vol.18， No.4， pp.36-46， 198.5.

Allen， F .E・， Cocke， J. : A Program Da.ta Flow Analysis Procedure，

Comm. ACM， Vol.19， No.3， pp.137-147， 1976.

Anderson， Robert B.， (有津誠訳) :演習プログラムの証明?近代科学社う1980.

Andrews， G.R・， Schneider， F .B. : Concepts and N otations for Con

current Progranuning， ACM Computing Surveys， Vo1.1.5， N 0.1，

pp.3-43， 1983.

荒木啓二郎: Pascal型プログラムの公理論的検証法K関する研究?

九州大学博士論文う1982.

Ara.ki， K.， Furukawa， Z.， a.nd Cheng， J. : A General Fra.luework for Debugging， IEEE Software， May 1991.

(33)

1ilJ ハ叫U

1llJ

nhu

ハhuo

δ

も

のδTsiAパ同一TlよRZA

A A B

[BAL82]

[BIC79]

[BIR83]

[BOE76]

[BO\N79]

[CHA71]

[CHA85]

有津誠: ソフトウェアプロトタイピング?近代科学社. 1986.

安宅彦三郎:プーノレ代数?共立出版， ^1Ð69.

Baiardi， F.， DeFrancesco， N .D.， Vaglini， G. : Developlnent of ^aDe

buger for a Concurrent Langua.ge， IEEE Tra.ns. Soft. Eng・， Vo1.SE- 12， No.4， pp.547-553， 1986.

Balzer， R.M.うGoldlnan，N .M.， Wile， D.S. : Operational Specifi

cation as the Basis for Ra.pid Prototy ping， ACM SIGSOFT Soft.

Eng. Notes， Vo1.7， No.5， pp.3-16， 1982.

Bicevskis， J.， Borzovs， J.， Stra吋ums， U.， Zarins， A.， M社]er， E.F.

Jr. : SMOTL-A System to Construct Samples for Da.ta Process

ing Program Debugging， IEEEτrans. Soft. Eng.， Vo1.SE-5， No.1，

pp.60-66， 1979.

Bird， D.L.， Munoz， C.U. : Automatic Generation of Ra.ndom Self

checking Test Cases， IBM Systems Journal， Vo1.22， No.3， pp.229- 245， 1983.

Boehm， B.W.， Brown， J.R.， Lipow， 1V1. ^: Quantitative Eva]uation of Software Quality， Proc. of 2nd ICSE， pp.592-605， 1976.

Bowen， J.B.， Fullerton， H. : A Survey of Standa.rds a.nd Proposed Metrics for Software Quality Testing.， Computer， No.8， pp.37-42，

1979.

Chang， H.Y.， Ma.nning， E.， (鵜飼直哉?利谷圭介訳) :ディジタノレ・

システムの故障診断，産業図書， 1971.

Chandrasekharan， M.， Da.sarathy， B.， Kisimoto， Z. ^: Requirelllents

Ba.sed Testing of Real-Tin1e Systems: Modeling for Testa bility，

Con1puter， Vo1.18， No.4， pp.71-80， 198.5.

(34)

[CHE83]

[CH078]

[CHU82J

[CLA 76J

[CLA 78]

[CLA81J

[CLA82J

[CLA83]

[CLA89J

Chen， B.S.， Yeh， R.T. : Fonnal Specifica.tion and Verfication of Distributed Systen1s， IEEE Tra.ns. Soft. Eng.， Vol.SE-9， No.6， pp.710- 722， 1983.

Chow， T.S. : Testing Softwa.re Design 1vfodeled by Finite-St.ate 11a

chine， IEEE Trans. Soft. Eng.， Vol.SE-4， No.3， pp.178-187， 1978.

中所武司:パステストに本質的な分岐に着目した網ら率尺度の提案?

情報処理学会論文誌Vo1.23， No.5， pp.545-552， 1982.

Cla.rke， L.A. : A Systeln to Genera.te Test Da.ta a.nd Symboli

cally Execute Progral1lS， IEEEτÌans. Soft. Eng.， Vol.SE-2， N 0.3，

pp.215-222， 1976.

Clarke， L.A. : Testing: Achievements and Frustra.tions， Proc. of COMPSAC'78， pp.310-314， 1978.

Clarke， L.A.， Richardson， D.J. : Symbolic Evaluat.ion 11ethods-

Implementation and Applications， C011PUT ER PROGRA11 T EST ING， B.Cha.ndra叫<aran， S.Ra.dicchi(eds)， North-Hol1a吋Pl1b.， pp.65- 102， 1981.

Cla.rke， L.A.， Hassell， J.， Richa.rdson， D.J. : A Close Look at Do

main Testing， IEEE Trans. Soft. Eng・， Vol.SE-8， N 0.4， pp.380-390，

1982.

Clarke， L.A.， Richardson， D.J. : T he A pplication of Error-Sensitive Testing Strategies to Debugging， Proc. of T he AC11 SIGSO FT jSIG

PLAN Soft. Eng. Symposium on High-Level Debugging， pp.4.5-52，

1983.

Clarke， L.A.， Podgurski， A.， Richardson， D.J.， Zeil， S.J. : A Forn1al Evalua.tion of Data Flow Path Selection Criteria， IEEEτrans. Soft.

(35)

[

_CRI83

]

[

DAV82

]

[

_DEM80

]

[

DEU84

]

[

DUN81

]

Eng.， Vol.SE-15， No.11， pp.1318-1332， 1989.

Cristofor， E. : A utonlatic Generation of Test Softwa.re， Proc. of Conf. on Soft. Developnlent Tools Technique and Alternatives，

pp.32-37， 1983.

Davis， A.11. : Rapid Prototyping Using Executable Requirenlents Specifications， ACM SIGSOFT Soft. Eng. Notes， Vo1.7， No.5， pp.39- 44， 1982.

De11illo， R.A. : Mutation Analysis as a Tool for Software Qua.lity Assurance， Proc. of COMPSAC'80， pp.390-393， 1980.

Deutsch， M.S.，

(島崎恭一訳) : ソフトウェアテストの技術3企画セ

ンタ-， 1984.

Duncan， A.G.， Hutchison J.S. : Using Attributed Grmnlnars to Test Designs and Implenlenta.tions， Proc. of 5th ICSE， pp.170-178，

1981.

[

DUNN84

]

Dunn， R.H. : Software Defect Relnova.l， McGra.，トHill， Inc・， 1984.

[

_ELM69

]

EhnendorfヲW.R. : Contorolling the Functional Testing of a.n Op

erating Systeln， IEEE Tra.ns. on Systems Science and Cybernetics，

Vol.SSCーム No.4， pp.284-290， 1969.

[

ELM73

]

[

FOS76

]

Elmendorf，羽T.R. : Cause-Effect Graphs in functiona.l Testing， IB11 Technical Report τト00.2487， 1973.

Fosdic， L.D.， Osterweil， L.J. : Data F low Analysis in Software Re

lia.bility， ACM Computing Surveys， Vo1.8， No.3， pp.30.5-330， 1976.

(36)

[FRA88] Fra.nkl， P.G.， Weyuker， E.J. : An Applica.ble Fa.Illl1y of Dat.a F lo\V Testing Criteria， IEEE Tra.ns. Soft. Eng・，Vol.SE-14， No.10， pp.1483- 1498， 1988.

[FUR80a] 古川善吾?野木兼六: 機能テストのためのテストケース作成法につ

いて?情報処理学会第21回全国大会予稿， pp.367-368， 1980.

[FUR80b] 古川善吾?野木兼六3越智毅:機能テストのためのテスト項目作成手

法について1情報処理学会ソフトウェア工学研究会資料16-2， 1980.

[FUR81] 古川善吾?野木兼六?小川茂?越智毅: ソフトウェアテスト項目作成

支援システムAGENT の開発?情報処理学会第22回全国大会予稿?

pp.323-324， 1981.

[FUR82a] 古川善吾，野木兼六?竹内久:ソフトウェアテスト項目作成支援シス

テムAGENTにおけるグラフチェック支援機能の開発?情報処理学会第24回全国大会予稿， pp.357-358， 1982.

[FUR82b] Fur北awa， Z.， Nogi， K.， Takizawa，

H.

: AGENT:A凶oIna tic Gen

eration of Test Ca.ses with Cause-Effect Gra.phs， Proc. of 6th ICSE Poster Session， pp.23-24， 1982.

[FUR82c] 古川善吾3 野木兼六3徳永健司3小森真一: ソフトウェアテスト項目

[FUR83]

作成支援システムAGENT における仕様記述法の拡張7情報処理学会第25回全国大会予稿， pp.437-438， 1982.

古川善吾?車谷博之1野木兼六?徳永健司: ソフトウェアテスト項目作成支援システムAGENT-IIの開発と評価?情報処理学会ソフトウェア工学研究会資料28-8， 1983.

[F.UR84a] 古川善吾?田口浩一:ソフトウェアの複雑性評価の一方式?情報処理

学会第28回全国大会予稿， pp.637-638， 1984.

(37)

[FUR84b] 古川善吾?野木兼六?徳永健司: AGENT:機能テストのためのテスト項目作成の一手法?情報処理学会論文誌， Vol.25， N 0..5， 1コp.736- 744， 1984.

[FUR85a] 古川善吾?西尾高典?野木兼六 :ICASにおけるテスト項目作成支援システム?情報処理学会第30回全国大会予稿， pp.607-608， 1985.

[FUR85b] Furuka.wa， Z.， Nogi， K.， Tokunaga， K. : AGENT: An Advanced Test-case Generation Systen1 for Functional Testing， AFIPS-Conf.

Proc.， Vo1.54， pp.525-535， 1985.

[FUR85c] 古川善吾3西尾高典7野木兼六:要求仕様検証の一方法?情報処理学

[FUR86]

会第31回全国大会予稿， pp.521-522， 1985.

古川善吾3牛島和夫:有向グラフ上の列概念を用いたテスト法について?日本ソフトウェア科学会第3回大会論文集， pp.221-224， 1986.

[FUR87a] 古川善吾?牛島和夫:列概念を用いたテスト支援法について1情報処

理学会ソフトウェア工学研究会資料87-SW-52， No.52， pp.137-144，

1987.

t [FUR87b] Furukawa， Z.， Ushijima， K. : A model for the

t伐e

s

討 t.i訂

lT

時

S

印 upp

or此

[FUR89]

[GEL88]

[GILB77]

method with sequences of a directed gra.ph， Proc. of C01\1PSAC'87，

pp.311-316， 1987.

古川善吾3牛島和夫:並行処理プログラムのテスト法に関する一考察?日本ソフトウェア科学会第6回大会論文集， pp.18.5-188， 1989.

Gelperin， D.， Hetzel， B. : The Growth of Software Testing， Comm.

ACM， Vo1.31， No.6， pp.687-695， 1988.

Gilb， T . : Software Metrics， \i\Tinthrop Publishers， Inc.， 1977.

(38)

[GIR85]

[GLA81]

[GOG82]

[GOG84]

[G0075]

[GOU83]

[HAL 77]

[HEC75]

[HET73]

[HOL 79]

Girgis， M.R・， Woodwa.rd， lv1.R. : An Integra.tecl Systen1 for Prか gra.lTI Testing U sing \九Teak 1/1 utation a.nd Da.ta. Flow Anal.， Proc of 8th ICSE， pp.313-319， 1985.

Glass， R.L・， (菅野文友訳) ^: ソフトウェア信頼性ガイドブック1日科技連出版社， 1981.

Goguen， J・， Mesegure， J. : Rapid Prototyping in the OBJ Exe

cuta.ble Specification La.ngua.geぅACM SIGSOF T Soft. Eng. Notes，

Vo1.7， No.5うpp.75-84， 1982.

Goguen， J. : Pa.ran1eterrized Programming， IEEEτ'rans. Soft.

Eng・， Vol.SE-10， No.5， pp.528-543， 1982.

Goodenough， J.P・， Gerhart， S. : Toward a Theory of Test Data Selection， SIGPLAN NOTICES， Vo1.10， No.6， pp.493-510， 1975.

Gourlay， J .S. : A Mathema.tical Frarnework for the Invest.lgation of Testing， IEEE Trans. Soft. Eng.， Vol.SE-9， No.6， pp.686-709，

1983.

HalsteaムM.H. : Elements of Software Science， Elsevier North

Holla.ndうInc.， 1977.

Hecht， M.S.， Ullman， J .D. : A Simple Algorithm for Global Data 乱ow Analsys Problelus， SIAM Journal Computing， Vo1.4， No.4，

pp.519-532， 1975.

Hetzel， W.C.(ed)， (鳥居宏次訳) ^{:プログラム} ^{・テスト法?近代科学}

社， 1974.

Holthouse， M.A・， Ha.tch， M.J. : Experierice with Automatec1 Test

ing Analysis， IEEE Computer， Vol.12， 1979.

ソフトウェアの系統的な機能テスト法に関する研究

九州大学学術情報リポジトリ

Kyushu University Institutional Repository