本論文の第1章ではまず、研究の背景と目的について述べた。

　ソフトウェアは、人間が開発するシステムの欠かせない要素になってきている。さまざまなシステムの中核となっているのは、ソフトウェアである。ソフトウェアの果たす役割はどんどん大きくなってきている。そしてソフトウェアは非常に複雑かつ巨大になってきた。

　しかしソフトウェアの品質は決して高いとは言えない。バグのないソフトウェアは開発できない。

　バグのないソフトウェアが開発できないとすると、どうすればよいのであろうか。答えは簡単である。早くバグを見つけて直せばよい。すなわち、バグを見つける作業、ソフトウェアテストを効率よく効果的に行えばよいのである。しかし、ソフトウェアテストは十分に研究されているとは言えない。ほとんどの技術者が勘と経験に基づいてテストを行っている。

　ある程度製品が組みあがった状態でのテストには、さまざまな過酷な条件を設定した上で、それでもきちんと動作することを調べる「システムテスト(System Testing)」がある。

　複雑な不具合はシステムテストを行わないと検出できない。そのためシステムテストはソフトウェアの品質の確保に非常に重要となる。しかしシステムテストも勘と経験によって行われているのが現状である。

　本研究では、ソフトウェアシステムに対するシステムテストの効果的な設計手法を提案することを目的とする。すなわち、より早く、より少ない工数で、より危険な不具合を発生させる手法を提案することを目的とする。

　第2章では、経験を積んだ技術者が持つ、システムテスト設計において着目すべき観点について、調査・分析を行った。偏りを極力抑えるために、種々の大手ベンダからテストを依頼されているテスト専門組織で3年以上経験のある技術者を調査対象とした。グループウェアからプリンタ制御ソフトウェアまで幅広いテスト対象を技術者に提示し、システムテスト項目を設計させる形式をとった。

　調査の結果、12のカテゴリで411件のシステムテスト項目が得られた。分析の結果、広い意味を持つさまざまな抽象度のリソースのネットワークとしてソフトウェアが構成されており、ソフトウェアの機能はそのパスに沿って連鎖的に実行されるという概念が、システムテスト設計するための観点として必要であるという結果を得ることができた。

　第3章では、第2章で得られた観点にしたがい、システムテスト設計の際にソフトウェアを捉えるモデルとして、リソースパスモデル(Resource Path Model)を提案した。まずリソースを、Beizerの定義より拡張し、ネットワークの帯域なども意味することができるよう、「プログラムの実行のために自らが保持する情報をやり取りしあうオブジェクト」とモデル化した。次にリソースパスを「ソフトウェアが動作を行うために情報を連鎖的にやり取りするリソースの列」とモデル化した。

　リソースパスモデルでは、リソースはさまざまな属性を持つ。DLLであれば作成日時といった属性を、ネットワークであれば帯域の広さといった属性を持つ。またリソースは、自らの持つ属性の種類で分類することができる。この分類名をリソースの「型」と呼ぶ。

　リソースパスモデルに従うと、リソースの属性の変化の影響が、リソースパスを媒介とすることにより、予想と一致しない出力結果や不正な現象として、外部に露呈したものであると捉えることができる。以後リソースの属性の変化を「衝突」、衝突を引き起こす条件を「衝突条件」、衝突条件の原因となったものを「衝突対象」、衝突対象と共有するリソースを「共有リソース」と呼ぶ。

　また第3章では、不具合のメカニズムをリソースパスモデルにしたがって記述した。

　まず、衝突対象のインストールなどの動作によって、衝突条件が起こる。例えば、ストレステストでは大きなサイズのデータを読み込み、構成テストでは衝突対象のインストールを行う。

　次に衝突条件によって、衝突が発生する。例えば、大きなサイズのデータを読み込んだら、ヒープというリソースの残り容量という属性がほとんどゼロに近い値になる。

　そして衝突の発生したリソースを含むリソースパスに沿って、悪影響が連鎖的に伝播し衝突不具合として露呈する。例えばDLLが新しいバージョンに変化したら、テスト対象は起動に失敗してしまう。

　リソースパスによる不具合のメカニズムを図1に示す。

　第4章では、リソースパスモデルにしたがい、新しいシステムテスト設計の方法としてリソースパステスト法(Resource Path Testing)を提案した。通常のシステムテスト設計は、経験に基づくため、いわば暗闇の中を手探りで歩くような方法である。それに対して、リソースパステスト法は、システムの構造を俯瞰する見通しの良い方法であると言える。

　リソースパステスト法は、リソースパスモデルから導出された図1のメカニズムにしたがって、共有リソースに衝突を発生させることにより衝突不具合を発生させる方法である。すなわちテスト設計を行うためには、主に以下の3つの項目を決定しなくてはならない。

　I.共有リソースはどれか

　II.共有リソースを変化させるにはどうすればよいか(衝突条件は何か)

　III.どのリソースのどの機能を実行して、衝突不具合を検出するか

この項目を順に決定するよう図2に示す設計フェーズを提案した。

　リソースパステストでは、不具合の原因となるリソースの変化をテスト設計時に想定する。そのため、少ないテスト工数で早く不具合を発見することができ、また不具合の原因の特定も容易となる。また納期遅れが発生した場合に、テスト項目の省略による工数の削減と、省略によって検出不能となる不具合の危険度とのトレードオフによる評価を行うことができる。

　リソースを単位としてテスト項目を管理するため、テスト項目の重複は発生しない。また発生させたい衝突をあらかじめ想定して設計するため、抜けも生じにくい。

　また第4章では、リソースパステスト法で用いるツールおよび設計プロセスを提案した。

　まず共有リソースを特定するため、リソースの依存関係を表したリソース依存グラフ(Resource Dependency Graph, RDG)をツールとして提案した。図3に概要を示す。

　次に共有リソースの属性の変化と、属性の変化を発生させる条件とを対応させたリソース変化マトリックス(Resource Change Matrix, RCM)をツールとして提案した。図4に概要を示す。

　最後に、共有リソースの属性の変化によって以前と異なる動作をするようになった機能および、共有リソース、機能を起動するリソース、結果を観測できるリソースを含むリソースパスを列挙したリソースパスリスト(Resource Path List)をツールとして提案した。図5に概要を示す。

　さらに、図6に示すリソースパステスト法における設計プロセスも合わせて提案した。

　第5章では、リソースパステスト法をストレステスト設計に適用するための理論的考察を行った。

　リソースパステスト法で効果的にテスト設計を行うには、リソースと衝突、および衝突条件の知識が不可欠である。中でもストレステストに関する衝突条件は複雑である。そこでストレステストの設計を効果的に行うため、リソースステートモデル(Resource State Model)を提案し、衝突条件についてFT図を用い理論的考察を行った。リソースステートモデルの概要を図7に示す。

　第6章では、リソースパステスト法による品質評価について議論した。

　テストの役割は、不具合を検出するだけではない。テストの真の役割は、ソフトウェアの品質特性を動的に測定することである。品質特性とは、ソフトウェアに要求される特性のことである。

　まず、リソースパステスト法における障害対応性の評価について述べ、リソースの障害対応性の基準を図8に示すような5段階(対応せずを含めると6段階)として提案した。障害対応性の基準を図8に示す。また障害対応性の評価を簡便するための、障害対応性評価シートも合わせて提案した。

　次に、リソースパステスト法によるセキュリティの評価について議論を行った。セキュリティホールのうち、設定ミスなどは、衝突が発生していないためリソースパステスト法では検出できない。しかしバッファオーバーフローなどは衝突が発生しているため、リソースパステスト法で検出することができる。

　また新たな品質特性として「対象ソフトウェアのインストールやアンインストールといった構成変更や機能の実行によって同一システム内の他のソフトウェアの機能の実行を阻害しない属性」を両立性と定義し、両立性を調べるための両立性テストを提案した。両立性テストは、構成テストにおけるテスト対象と衝突対象を交換したテストであると考えてよい。そのためリソースパステスト法をそのまま適用してテスト設計を行うことができる。

　第7章では、実際に市場に出荷されたソフトウェアを対象として、リソースパステスト法を用いてストレステスト設計および構成テスト設計を行った適用例を示した。

　ストレステストの設計では、参考として経験的手法による結果を示し、比較および考察を行ったテスト対象は2種のWWWブラウザとした。

　提案した手法では、テスト対象の開発組織では検出できなかった不具合を簡便に検出することができた。特に、セキュリティホールになりうる確実に検出し修正しておかなくてはならない不具合を検出できた意義は非常に大きい。一方別種のテストでは、提案した手法を用いると、経験的手法で検出された改行位置ずれおよび改行余計という不具合が検出できず、また優先順位が後になってしまった不具合もあった。とはいえ提案した手法による検出結果をテスト実行後に検討した結果、リソース推測漏れの設計ミスが明らかになった。しかしその後設計レビューを行った結果、リソース推測漏れを容易に指摘することができた。一方経験的手法による設計レビューはテストケースごとに検討しなくてはならないため繁雑かつ困難であり、検出漏れの原因も判明しなかった。

　構成テストの設計では、参考として経験的手法およびMyers、Beizer、Kanerの手法との比較及び考察を行った。テスト対象は商用ワードプロセッサ、衝突対象は3種のWWWブラウザとした。

　不具合の検出に関しては、提案した手法が最も早いという結果となった。工数に関しては、提案した手法と経験的手法、Kanerの手法がそれぞれ3構成で最も少なかった。原因となる衝突対象の特定に関しても、提案した手法が最も早いという結果となった。一方テスト機能の順序に関しては、提案した手法でも経験的に定めざるを得なかった。しかし既存の手法では順不同となり、実際のテスト現場では適宜経験によって補完するものと推察されるため、あまり差がないという結論が得られた。またテスト工数の削減に関して、経験的手法では不具合の発生傾向とユーザの使用頻度から経験的に判断しており、Kanerの手法では品種が近ければ挙動も似ているという経験的な判断基準を用いていた。すなわち客観的に判断できるのは、省略により見逃す不具合の危険性を考慮できる提案した手法のみであった。したがって、この例では提案した手法が最も効果的であり、テスト経験が十分豊富であれば経験的手法も次いで効果的であるという結果になった。

　さらに第7章では、リソースパステスト法を応用することによって、検出した不具合の原因の究明を試みた。その結果、検出した不具合はある補助的な機能が含まれているために発生する、という結論を、非常に少ない工数で得ることができた。

　その結果、リソースパステスト法は、既存の手法に比べて、より早く、より少ない工数でより危険な不具合を検出できる方法であることが明らかになった。そして現実のテスト設計プロセスの抱える工数の減少という問題点を解決すべく、テストを止めた時点での危険性を評価することのできる手法であることも明らかになった。

　最後に今後の展望として、リソースパステスト法を通じた"Test-Centered Development"などと呼ばれる開発プロセスの充実について触れた。これは、製品設計と同時にテスト設計を行うことによって、Testabilityを、ひいては製品の品質を向上させる開発プロセスのことである。これまでTCDという概念そのものは提示されていたが、具現化するテスト手法やツールは提示されてこなかった。リソースパステスト法の充実を通じてTCDへの適用を行い、より品質の高いソフトウェアを生み出す開発プロセスの構築に寄与すべきであろう。

図1　衝突不具合のメカニズム

図2　リソースパステスト法の設計フェーズ

図3　リソース依存グラフ

図4　リソース変化マトリックス

図5　リソース依存グラフとリソースパスリスト

図6　リソースパステスト法の設計プロセス

図7　リソースステートモデルの概要

図8　リソースの障害対応性の基準

　本論文は「ソフトウェアシステムに対するシステムテストの設計」と題し,全8章から成っている.人間が開発するさまざまなシステムにおいてソフトウェアの重要性が増している.複雑かつ巨大になったソフトウェアの品質は高いとは言えないが,始めから高品質のソフトウェアを開発することも事実上不可能であり,不具合を効率的に見つけて修正する技術の進歩が望まれる.なかでも,「システムテスト」と呼ばれる,さまざまな過酷な条件を設定し複雑な不具合を検出する総合的なテストが重要である.本論文は,ソフトウェアシステムに対して,より早く,より少ない工数で,より危険な不具合を発見するシステムテストの効果的な設計手法を提案するものである.

　第1章は序論であり,本研究の背景と目的について述べている.

　第2章では,経験豊かな技術者が持つ,システムテスト設計において着目すべき観点について調査・分析を行った結果を述べている.調査において12のカテゴリで411件のシステムテスト項目が得られ,それらの項目の分析の結果,システムテスト設計をするための観点として,広い意味を持つさまざまな抽象度のリソースのネットワークとしてソフトウェアが構成されており,ソフトウェアの機能はその連なりであるリソースパスに沿って連鎖的に実行されるという概念が必要であるとの結論を得ている.

　第3章では,第2章で得られた観点にしたがい,システムテスト設計のために対象となるソフトウェアを理解するためのモデルとして,「リソースパスモデル」を提案している.すなわち,まず第2章で得られた観点に基づいて「リソース」と「リソースパス」のモデル化を行い,次にリソースのさまざまな性質を表す「属性」,リソースの属性の変化を表す「衝突」,開発者の意図しない衝突を表す「障害モード」,衝突を引き起こす原因となるソフトウェアやハードウェアを表す「衝突対象」,衝突を引き起こす条件を表す「衝突条件」,衝突対象とテスト対象との間で共有されるリソースを表す「共有リソース」,衝突に起因する不具合を表す「衝突不具合」という概念を提示している.そして,衝突対象による衝突条件の発生によって,共有リソースに障害モードが発生し,リソースパスに沿って連鎖的に伝播することで不具合が発生する,という不具合のメカニズムをリソースパスモデルで記述している.

　第4章では,第3章で記述したメカニズムを検出するシステムテスト設計の方法として,「リソースパステスト法」を提案している.この方法は5つの設計フェーズと18のステップから構成されるシステムテスト設計プロセスである.そして,テスト設計を支援するツールとして,共有リソースを特定するためにリソースの依存関係を表す「リソース依存グラフ」,衝突と衝突条件の対応関係を表す「リソース変化マトリックス」,衝突不具合を検出するリソースパスと機能とを列挙した「リソースパスリスト」を提案している.

　第5章では,リソースパステスト法をストレステストの設計に適用するための理論的考察を行っている.リソースパステスト法で効果的にテスト設計を行うには,リソースと衝突,および衝突条件の知識が不可欠である.なかでもストレステストに関する衝突条件は複雑である.そこでストレステストの設計を効果的に行うため,「リソースステートモデル」を提案し,衝突条件についてFT図を用いて理論的考察を行っている.

　第6章では,リソースパステスト法による品質評価について論じている.テストの役割は不具合を検出するだけではなく,ソフトウェアの品質特性を動的に測定することであるとして,まずリソースパステスト法における障害対応性の評価について述べ,障害対応性の基準,および障害対応性評価シートを提案している.また,リソースパステスト法によるセキュリティの評価についても検討している.さらに,ソフトウェアシステムで把握すべき新たな品質特性として「両立性」を提案し,リソースパステスト法により評価できることを述べている.

　第7章では,実際に市場に出荷されたソフトウェアを対象として,リソースパステスト法を用いてストレステスト設計および構成テスト設計を行った適用例を示している.ストレステストの設計では,上級技術者が経験に基づいてテスト設計を行った結果,論文提出者がリソースパステスト法を用いてテスト設計を行った結果,経験の少ない技術者がリソースパステスト法を用いてテスト設計を行った結果を示し,比較および考察を行っている.構成テストの設計では,上級技術者が経験的にテストを行った結果および,既存の手法としてMyers, Beizer, Kanerの手法を用いてテスト設計を行った結果を示し,比較及び考察を行っている.いずれにおいても,提案した手法によって,テスト対象の開発組織では検出できなかった不具合を検出することができ,また経験の少ない技術者にも効果的であるとしている.

　終章である第8章では,今後の展望として,製品設計と同時にテスト設計を行うことによってソフトウェアシステムの品質を向上させる開発プロセスである"Test-Centered Development"を,リソースパステスト法によって実現すべきであると述べている.製品設計時に用いられるデザインパターンを,リソースパスモデルを用いて整備するとともに,デザインパターンの持つ脆弱性を障害モードとしてとらえ蓄積することによって,製品設計と同時にテスト設計を進行させ,極めて品質の高いソフトウェアを生み出すことのできる次々世代のソフトウェアシステム開発プロセスを実現できる可能性を示唆している.

　以上要するに,本研究は,実世界で実施されているシステムテスト項目の分析結果から,システムテストの設計において有すべき視点を挙げ,これを具現化するシステム設計の方法論を,それを支援する技法とともに提案するものであり,これらの手法やツールはそのままでシステムテスト設計のレベルアップに多大な貢献をするものとして評価できる.さらに,本研究は,これまで経験的になされてきたシステムテスト設計に対する新たな理論的枠組みを与えるものとして,工学的に価値の高いものである.

　よって,本論文は博士(工学)の学位請求論文として合格と認められる.