40

九州産業大学情報科学会誌 3 巻 1 号（2004 年 9 月）¥¨
§研究室紹介 ¦ソフトウェアのテストについて
廣田 豊彦

Toyohiko HIROTA

九州産業大学 情報科学部 社会情報システム学科
Faculty of Information Science, Kyushu Sangyo University

hirota@is.kyusan-u.ac.jp, http://www.is.kyusan-u.ac.jp/~hirota/

1. ソフトウェア工学

れらの部品もさらにより細かな部品に分解できることが多いでしょう．ソフトウェアの場合でも，そのように分

現在では，ソフトウェアという語を耳にしたことがな割して開発します．設計フェーズにおいて，ソフトウェい人は少ないでしょう．一般の家庭でも PC があり，イアをどのように分割するかを決定します．このとき分割ンターネットに接続されているというのが珍しくない時された部品同士をどのように結合するかをはっきりさせ代です．ソフトウェアはハードウェアと対になる語と考ておくことも重要です．

えられていますが，コンピュータ以前の時代にはハード設計書ができると，それに従って実装，すなわちプロウェアという語しかありませんでした．それは金物を意

グラミングを行います．初心者にはプログラミングはた味していました．コンピュータが登場して，その物理的実いへん困難な作業のように思えますが，ソフトウェア開体がハードウェアと呼ばれるようになり，それと対比す

発全体から見ると，ほんの一部の作業にすぎません．しる形でソフトウェアという新しい語が作られたようです．

かも過去に多くのプログラムが書かれており，それらをソフトウェアが一般化していることと比較すると，ソ有効に利用することで，新たに書かなければならないプ

フトウェア工学（あるいはソフトウェアエンジニアリン

ログラムの量をを減らすことができます．むしろ，そうグ）はあまり知られていないように思われます．ソフト

いった過去の資産を活用できるように，いかにうまく設

ウェア工学とは，ソフトウェアの開発，運用，保守への工計するかが重要になっています．

学的アプローチとそれに関する研究を指しています [1]．

以上，ソフトウェア開発の３つのフェーズについて簡

工学は，単なる技術の集まりではなく，背景となる理論単に紹介しましたが，これらの３つのフェーズが順に実体系や，組織的な教育方法が確立していなければなりま行されるわけではありません．かつては，これらのフェーせん．

ズが順に，後戻りすることなく実行されることが理想とソフトウェアの開発は大きく３つのフェーズに分けてされていました．しかし現在では，そのような理想的な考えることができます．要求分析，設計，そして実装です

開発スタイルは非現実的であることが認識されています．

[2]．ソフトウェアはきわめて多様な能力を持つことがで実際には，これらのフェーズがオーバーラップしたり，３きます．そこで，現実の資源，すなわち開発経費やハーつのフェーズを何度も反復したり，といったやり方でソドウェアの能力に見合う適切なソフトウェアを開発する

フトウェア開発が行われます．

必要があります．そのためには顧客の要求をきちんと整ソフトウェアは多種多様な能力を持つことができます．

理しなければなりません．それが要求分析のフェーズで，その裏返しとして，ソフトウェアには多種多様な欠陥がその結果として要求仕様書が作成されます．顧客が期待ありえます．ここで欠陥とは，ソフトウェアが顧客の期するソフトウェアと，開発者が約束するソフトウェアの待通りに動作しないことを指します．要求仕様書通りに合意が要求仕様書です．

開発したはずなのに，実際にはその通りに動かないとす

要求仕様書に基づいてソフトウェアを開発するわけですが，すぐにプログラムを書き始めるわけにはいきませると，それは欠陥です．実は要求仕様書自体が欠陥を含んでいることも珍しくありません．

ん．一般にソフトウェア開発には多数の技術者が関わり要求仕様書は，顧客と開発者が合意したものであるとます．そこで，それらの人々の間で，開発のための基本方最初に説明しましたが，顧客はソフトウェア開発の専門針を定めておかなければなりません．それが設計のフェー家ではないため，要求仕様書に記述されている内容を十ズで，その結果として設計仕様書が作成されます．実際分に理解できるとはかぎりません．一方，開発者は顧客には，設計は単一のフェーズではなく，開発するソフトのやりたい仕事の内容を熟知しているわけではありませウェア全体の設計から，ある一部分の詳細な設計まで多ん．そのため，顧客が考えていることを的確に要求仕様くのレベルに分割されます．

書に表現することは容易ではありません．

一般に製品は多数の部品からできあがっています．そソフトウェアの欠陥を発見し修正するためのアプロー

41

ソフトウェアのテストについて

要求分析

システムテスト

対応

統合
テスト

設計実装

単体
テスト

クボックステストとホワイトボックステストがあります．
これはソフトウェアのソースコードを参照するかどうかの違いによるものです．ソースコードを参照せずに，ソフトウェアの仕様書（要求仕様書や設計仕様書）だけを参照して，テストを計画し，実行するやり方を，ブラッ

実行順序

図 1 ソフトウェア開発フェーズとテスト

クボックステストと呼びます．中身の見えない箱のことをブラックボックスと呼ぶことから名づけられたものです．一方，ソースコードを参照するテストのやり方をホワイトボックステストと呼びます．ホワイトボックスという語は一般的な言葉ではありませんが，ブラックボッ

チは，大きく分けて二つあります．一つは，開発の途中

クスとは逆の意味ということで名づけられたものです．

で，欠陥の原因が入り込むことがないようにするという本来のテストの目的，すなわち欠陥を発見するというアプローチです．もう一つはできあがった製品をテスト

立場からは，ブラックボックステストだけで十分なはずし，欠陥を発見するというアプローチです．両者はどちです．仕様書通りにソフトウェアが動作するかどうかをらか一方でよいというものではありません．欠陥の原因発見するのがテストの目的だからです．それにもかかわを作らないようにソフトウェアを開発するための方法論

らずホワイトボックステストという考え方があり，実際もいろいろと提案されてきましたが，だれでもできるわにそのようなテストが行われます．それはソフトウェアけではない，どんなソフトウェア開発へも適用できるわのテストの困難さに原因があります．ソフトウェアが仕けではない，といった課題があります．

様書通りに動作するかどうか，完全にテストすることは一方，テストに関しては，ソフトウェアの能力をすべ事実上不可能です．そこで効果的なテストを選択して実てテストすることは事実上不可能であるという根本的な施する必要があります．そのときにソースコードを参照

課題があります．テストをより多く実施することでソフすることで，効果的なテストを選択する，あるいはテストウェアの信頼性を高めることができますが，そのためトの効果を測定することができます．のコストや期間が増大します．いかに効率的かつ効果的

ところで，ブラックボックステストとホワイトボックにテストを行うかは，ソフトウェア工学の重要な課題のステストという分類はあまり適切な分類ではありません．

一つです．

単体テスト，統合テスト，システムテストのうちで，この分類が意味を持つのは単体テストの場合だけです．統合2. ソフトウェアのテスト

テストやシステムテストをソースコードに基づいて実施することは事実上不可能であり，これらのテストは必然

テストと一口に言っても，様々なものがあります．テ

的にすべてブラックボックステストになるからです．まストの分類方法自体，一通りではありません．ソフトウェ

た，ソースコードを参照するといっても，実はいろいろア開発フェーズに対応するテストの分類として，単体テなアプローチがあります．そこで，テストモデルというスト，統合テスト，システムテストがあります．単体テス

考え方を導入します [3]．テストモデルとは，テスト対象

トは，実装の直後に，実装の基本単位毎に行うテストでのソフトウェア（あるいはその一部）を，テストの視点す．統合テストは，設計フェーズでのソフトウェアの分からモデル化したものです．テストモデルを導入するこ

割を逆にたどって，順にソフトウェア部品を組み立てなとで，何をテストしようとするのかを明らかにすること

がらテストを行います．システムテストは，ソフトウェができます．

ア全体をテストするもので，ソフトウェアが要求仕様書通りに動作するかどうかを確認します．

単体テストのためのテストモデルとして，制御フローモデル，データフローモデル，状態遷移モデルなどがあソフトウェア開発フェーズとテストの対応関係を図 1

ります．オブジェクト指向プログラムがテスト対象となに示します．ここで注目すべきことは，開発フェーズのる場合，制御フローモデルとデータフローモデルは一つ

時間的順序とテストの時間的順序が逆になるということのメソッドをテストします．そして状態遷移モデルはクです．要求仕様書に欠陥の原因がある場合，その欠陥がラス全体をテストします．

テストによって発見されるのは，最後のシステムテスト

制御フローモデルは，ソースコードのどの部分がどののときです．そして，そのような欠陥が発見されると，開ような順序で実行されるかをモデル化したものです．制発フェーズの最初である要求分析からやり直すことが必

御フローモデルは，ノードとエッジからなるフローグラ要になります．このような欠陥と比較すると，実装フェーフで表されます．ノードには分岐と合流の２種類があり，ズのプログラミングに起因する欠陥の除去ははるかに容他に開始ノードと終了ノードが一つずつあります．図 2

易なものと言えます．のメソッド numOfSubs の制御フローモデルを図 3 に示

ソフトウェアテストの分類方法の一つとして，ブラッします．制御フローモデルでは，フローグラフ中のすべ

42

九州産業大学情報科学会誌 3 巻 1 号（2004 年 9 月）

開始

13終了

2new
部下数=0

図 3 制御フローモデル

定義(sum)
開始 1計算使用(sum)3 終了
定義(sum)2 計算使用(sum)

図 4 データフローモデルてのエッジをテストする，というのが一般的なテストの規準です．図 3 でその規準を満たすもっとも簡単なテス

delete

add

add

add

部下数
部下数=1>1
remove[部下数=1] remove
図 5 状態遷移モデル

着目すると，エッジ 1 と 2 に定義があり，エッジ 2 と 3に使用があります．そこですべての組み合わせは(a) エッジ 1 の定義とエッジ 2 の使用(b) エッジ 1 の定義とエッジ 3 の使用( c ) エッジ 2 の定義とエッジ 2 の使用(d) エッジ 2 の定義とエッジ 3 の使用

トは，ループを 1 回だけ実行して終了するような経路をの 4 通りになります．これらをすべて実行するためには，実行するものです．

少なくとも次の 3 回のテストを実行します．

制御フローモデルでは，すべてのノードは，開始ノードから終了ノードの経路上に存在しなければなりません．
あたりまえのようですが，現実には孤立したノードが存在することがあります．それは決して実行されることの(1) ループを 1 度も実行しない．
（b）(2) ループを 1 度だけ実行する．
（a，d）(3) ループを 2 度以上実行する．
（c）
制御フローモデルでは，2 だけでよかったのですが，デーないソースコードが存在することを意味しています．プ

タフローモデルを採用すると，1 や 3 もテストする必要

ログラムの修正を繰り返すうちに，以前は使われていたがあります．

コードが使われなくなったというようなことがよくありデータフローモデルでも，テスト実行前に欠陥の原因ます．しかし，ほんとうに不必要なのかどうか，十分にが見つかることがあります．データが定義されていない検討する必要があります．もしもそのコードが実は必要のに使用される，といった場合です．一般にこのようななコードであったとすると，それはソフトウェアの欠陥誤りをデータフロー異常といいます．特に，ある特定のにつながることになります．このように，テスト実行以条件のときだけ発生するデータフロー異常に注意する必前のモデル作成段階で，欠陥の原因が見つかることもあ要があります．

ります．

データフローモデルは単一のメソッドを対象とします

データフローモデルは，制御フローモデルで用いたフが，変数がクラス属性の場合，メソッド間での定義と使ローグラフのエッジに，次の 4 種類の注釈を付加したも用の関係が問題となります．これについては，ここではのです．

立ち入らないことにします [4]．

• データの定義• データの消滅• データの計算使用• データの述語使用

データの定義とは，変数にデータが代入されることを意

状態遷移モデルは，オブジェクトの内部状態に関する状態遷移図です．状態遷移は，メソッドの呼び出しや，内部状態に関する条件の成立によって起こります．外部からのイベントによっても状態遷移が起こりえますが，一般のオブジェクト指向プログラムでは，メソッド呼び出味します．データの消滅は，内側のブロックで宣言されしと同じになります．図 2 のクラス Employee の状態遷た変数が，ブロック外で無効になるような場合です．デー

移モデルを図 5 に示します．

タの計算使用とは，ある変数が別の変数（あるいは同じ状態遷移モデルにおけるテストの規準は，すべての状態変数）の値を計算するために使われることを意味します．

遷移を 1 度以上起こす，というものです．図 5 の例では，データの述語使用とは，ある変数が分岐条件を判定するために使われることを意味します．図 4 にデータフローモデルの例を示します．
データフローモデルでのテストとしてもっとも典型的なものは，可能なすべての定義と使用の組み合わせをテストするというものです．たとえば，図 4 の変数 sum に(1) create add delete(2) create add remove delete(3) create add add add delete(4) create add add remove deleteの 4 通りになります．
状態遷移モデルでは，原則としてすべての状態と状態

43

ソフトウェアのテストについて

import java.util.*;public class Employee {Vector employees;
public boolean add(Employee e) {employees.add(e);return true;}
public void remove(Employee e) {employees.removeElement(e);}public int numOfSubs() {int sum = 0;
for (int i = 0; i < employees.size(); i++) {sum += ((Employee)employees.elementAt(i)).numOfSubs() + 1;}
return sum;}}
図 2 例題クラス

遷移の組み合わせが網羅されている必要があります．オ
ブジェクトが一旦生成されたら，その後は任意のメソッドが呼び出される可能性があります．またそのオブジェクトがどのような状態であっても，破棄される可能性があります．状態遷移図ですべての可能性が網羅されていない場合，状態遷移モデルの作り方が誤っていたか，あるいは仕様書に誤りがあったことになります．いずれにしてもテストを実行する以前にそれらをもう一度検討する必要があります．

3. 廣田研究室の研究テーマ
廣田研究室の基本テーマはソフトウェア工学です．前
節で紹介したソフトウェアテストに関しては，単体テストを自動化するための技術を開発しました [5]．最近は，要求分析の一環として，ビジネスプロセスモデリング [6]や，データベーススキーマ設計 [7] などの研究を行っています．また，対象領域の特質を把握してソフトウェア開発を効率化するために，ドメイン分析・モデリングの研究を行ってきました [8, 9, 10]．具体例として，建築図面の自動認識や，建築プロセスの分析と支援ツールの開発などがあります．近年は分析・モデリングといった抽象的な研究が中心になってきましたが，Java，C++，Prolog，Tcl/Tk，Python，Visual Basic など，様々なプログラミング言語を駆使して，便利なツールを開発することにも取り組んで行きたいと考えています．

♦ 参 考 文 献 ♦[1] SWECC. Guide to the Software Engineering Body ofKnowledge, Version 0.95. IEEE, 2001. (邦訳：『ソフトウェ
アエンジニアリング基礎知識体系− SWEBOK −』松本吉弘監
訳，オーム社，2003 年).
[2] Shari Lawrence Pﬂeeger. Software engineering: Theoryand Practice. Prentice-Hall, 1998. (邦訳：『ソフトウェア工学：理論と実践』 堀内泰輔訳，ピアソン・エデュケーション，2001 年).
[3] Shel Siegel. Object Oriented Software Testing. John Wiley & Sons, 1996. (邦訳：
『オブジェクト指向ソフトウェアテスト技法』 古宮， 廣田監訳，共立出版，1998 年).
[4] 廣田 豊彦, 橋本 正明. オブジェクト指向プログラムのためのデータフローテスト. 電子情報通信学会論文誌 D-I, J97-DI(10):707–718, 1996 年 10 月.
[5] 山口 嘉文, 伊藤 正之, 足立 浩二, 廣田 豊彦, 橋本 正明. 階層的漸増テスト自動実行ツール. In ソフトウェア工学の基礎 VII,pages 181–188. 近代科学社, 2000.
[6] 廣田 豊彦, 熊谷 敏, 川端 亮, 伊藤 潔. ダイアグラム変換を利用したシステム分析. 電子情報通信学会技術研究報告（知能ソフトウェア工学）, 104(49):7–12, 2004 年 5 月.
[7] 廣田 豊彦, 熊谷 敏, 稲永 健太郎. ユースケースに基づくデータベーススキーマ設計法. 電子情報通信学会技術研究報告（知能ソフトウェア工学）, 102(503):19–23, 2002 年 12 月.
[8] 伊藤 潔, 杵嶋 修三, 田村 恭久, 廣田 豊彦, 吉田 裕之 編. ドメイン分析・モデリング. 共立出版, 1996.
[9] K. Itoh, T. Hirota, S. Kumagai, and H. Yoshida, editors. Domain Oriented Sytems Development: Principles
and Approaches, volume 1 of Advanced Information Processing Technology. Gordon and Breach, 1998.
[10] K. Itoh, S. Kumagai, and T. Hirota, editors. Domain
Oriented Sytems Development: Perspective and Practices,volume 6 of Advanced Information Processing Technology.
Taylor & Francis, 2002.