(57)【特許請求の範囲】
【請求項１】
コンピュータを用いて、複数のプログラムモジュールを有するソフトウェアシステムのテスト計画を作成する方法であって、
前記コンピュータの品質情報記憶手段に、前記ソフトウェアシステムのプログラムモジュールごとの不具合数の予測に有効な品質情報として少なくともソース規模と担当者のスキルに対応する値を設定するモジュール品質情報設定工程と、
前記コンピュータの演算手段により、前記品質情報記憶手段に設定した値を用いて前記プログラムモジュールごとの不具合数を予測し、かつ当該不具合を検出のために必要となる工数である不具合検出工数を予測し、当該不具合検出工数および前記不具合数とを前記コンピュータの不具合記憶手段に記憶するモジュール不具合検出工数予測工程と、
前記コンピュータの対応関係記憶手段に、前記プログラムモジュールと前記ソフトウェアシステムの仕様書から抽出される仕様項目との対応関係、当該仕様項目へプログラムモジュールが寄与する度合を示す値を設定するモジュール・仕様項目対応関係設定工程と、
前記コンピュータの演算手段により、前記不具合記憶手段の前記不具合検出工数および前記不具合数と前記対応関係記憶手段の前記プログラムモジュールが寄与する度合を示す値とを用いて、仕様項目ごとの不具合検出工数を予測して当該不具合検出工数を前記コンピュータの仕様項目不具合検出工数記憶手段に記憶する仕様項目不具合検出工数予測工程と、
前記コンピュータの演算手段により、前記仕様項目不具合検出工数記憶手段の仕様項目ごとの前記不具合検出工数に基づいて、前記ソフトウェアシステムのテストに利用可能なテストリソースとして少なくともテスト期間、テスト担当者の人数および能力の配分をテスト計画として作成し、配分されたテストリソースを前記コンピュータのリソース配分記憶手段に記憶するテスト計画作成工程とを備えたことを特徴とするテスト計画作成支援方法。
【請求項２】
複数のプログラムモジュールを有するソフトウェアシステムについてのテスト計画の作成を支援するように、コンピュータを動作させるテスト計画作成支援プログラムであって、
前記コンピュータの品質情報記憶手段に、前記ソフトウェアシステムのプログラムモジュールごとの不具合数の予測に有効な品質情報として少なくともソース規模と担当者のスキルに対応する値を設定させるモジュール品質情報設定機能と、
前記コンピュータの演算手段に、前記品質情報記憶手段の値を用いて前記プログラムモジュールごとの不具合数を予測し、かつ当該不具合を検出のために必要となる工数である不具合検出工数を予測し、当該不具合検出工数および前記不具合数とを前記コンピュータの不具合記憶手段に記憶させるモジュール不具合検出工数予測機能と、
前記コンピュータの対応関係記憶手段に、前記プログラムモジュールと前記ソフトウェアシステムの仕様書から抽出される仕様項目との対応関係、当該仕様項目へプログラムモジュールが寄与する度合を示す値を設定させるモジュール・仕様項目対応関係設定機能と、
前記コンピュータの演算手段に、前記不具合記憶手段の前記不具合検出工数および前記不具合数と前記対応関係記憶手段の前記プログラムモジュールが寄与する度合を示す値とを用いて、仕様項目ごとの不具合検出工数を予測して当該不具合検出工数を前記コンピュータの仕様項目不具合検出工数記憶手段に記憶させる仕様項目不具合検出工数予測機能と、
前記コンピュータの演算手段に、前記仕様項目不具合検出工数記憶手段の仕様項目ごとの前記不具合検出工数に基づいて、前記ソフトウェアシステムのテストに利用可能なテストリソースとして少なくともテスト期間、テスト担当者の人数および能力の配分をテスト計画として作成し、配分されたテストリソースを前記コンピュータのリソース配分記憶手段に記憶させるテスト計画作成機能と
を備えたことを特徴とするテスト計画作成支援プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、ソフトウェアシステムの信頼性を向上させるためのテスト技術ならびに検証技術に関係し、これらのテスト・検証を効率的に行うテスト計画の作成を支援する方法ならびにプログラムに関する。
【０００２】
【従来の技術】
従来、ソフトウェアシステムの信頼性を保証するためにソフトウェアテスト技術が広く用いられている。ソフトウェアテスト技術では、テスト対象となるソフトウェアに対してどのようなテストケースをどのようなテスト計画で利用するかが重要となる。テストケースとテスト計画の良し悪しによって、テストの品質と効率が大きく異なってくる。
【０００３】
テストケースは、対象ソフトウェアの機能を網羅的にテストするように設計する必要があるが、最近のソフトウェアシステムは大規模化・複雑化しており、すべての機能を網羅的にテストするためには、膨大な工数を用いて膨大なテストケースを消化する必要がある。一方でソフトウェアシステム開発に当てられる開発期間には限度があるため、限られた時間内にすべてを実施することは不可能に近い。そのため、信頼性や重要度などの基準に応じてテストする部分に優先順位をつけ、優先順位によってテストケースの詳細度を変えることで、必要十分な量の効率的なテストケースを設計することが必要となってきている。これに対して、発明者らは、システム仕様書などからシステムの特徴を表現し、そのシステムにとって適当なテスト戦略を選択する手段を提供して、重要な機能を優先的にテストできるテストケースの設計支援方法を提案している(特願２００１−２９０３８０)。
【０００４】
一方で、テストの実行には、テストケースと並んでテスト計画も必要である。テスト計画とは、具体的に誰が、どのテストケースを、いつ、どれだけの工数をかけて行うかを定めたものである。同一のテストケースを用いても、そのテストを担当する技術者の力量や、実際にテストで不具合を検出するのにかかる工数などテスト作業に関するメトリクスによって、テストの効果は異なるものとなる。したがって、テストケースの作成と同様、テスト計画の作成においても、どのメトリクスを重視するかの判定基準を、テストの戦略として意図的に設定しなければ、効率的なテストの実現は難しい。
【０００５】
従来技術では、テスト作業に関するメトリクスに注目してテスト計画を作成することはしていなかったが、より効率の良いテストを実現するためには、このようなテスト計画作成手法が必要とされる。
【０００６】
【発明が解決しようとする課題】
このように、従来の技術では、システム仕様書などからそのシステムの特徴を表現し、そのシステムにとって適当なテスト戦略を選択して、品質上重要な機能かそうでない機能かを判断するテスト優先度を導出してテストケースを設計しているが、そのテストケースを効率的に実行するためのテスト計画を、テスト作業に関するメトリクスに注目して作成してはいなかった。
【０００７】
そこで本発明では、優先的にテストできるように設計されたテストケースに対して、モジュールごとに測定されるプログラムの品質メトリクスや、開発したプログラマの技術力などの要因を分析することで、どのテストにおいて不具合が発生する可能性が高いかを予測し、どのテストにどれだけのリソースをどのように割り当てるべきかを、テスト計画として決定することを支援する方法およびプログラムを提供する。
【０００８】
【課題を解決するための手段】
上記課題を解決するために、本発明では、ソフトウェアシステムのプログラムモジュールごとの品質情報を設定するモジュール品質情報設定工程と、前記品質情報から前記プログラムモジュールの不具合検出工数を予測するモジュール不具合検出工数予測工程と、前記モジュールと前記ソフトウェアシステムの仕様書から抽出される仕様項目との対応関係を表すモジュール・仕様項目対応関係情報を作成するモジュール・仕様項目対応関係設定工程と、前記不具合検出工数と前記モジュール・仕様項目対応関係情報とから仕様項目不具合検出工数を予測する仕様項目不具合検出工数予測工程と、前記仕様項目不具合検出工数に基づいて、前記ソフトウェアシステムのテストに利用可能なテストリソースを配分するテスト計画を作成するテスト計画作成工程とを備えたことを特徴とするテスト計画作成支援方法を提供する。
【０００９】
また、本発明では、ソフトウェアシステムのプログラムモジュールごとの品質情報を設定するモジュール品質情報設定機能と、前記品質情報から前記プログラムモジュールの不具合検出工数を予測するモジュール不具合検出工数予測機能と、前記モジュールと前記ソフトウェアシステムの仕様書から抽出される仕様項目との対応関係を表すモジュール・仕様項目対応関係情報を作成するモジュール・仕様項目対応関係設定機能と、前記不具合検出工数と前記モジュール・仕様項目対応関係情報とから仕様項目不具合検出工数を予測する仕様項目不具合検出工数予測機能と、前記仕様項目不具合検出工数の基づいて、前記ソフトウェアシステムのテストにかけることのできるテストリソースを配分するテスト計画を作成するテスト計画作成機能とをコンピュータに実現させることを特徴とするテスト計画作成支援プログラムを提供する。
【００１０】
上記した本発明によれば、各モジュールの品質に関わる情報を設定・利用して、モジュールごとの不具合検出工数を予測し、モジュール・仕様項目対応関係情報から仕様項目ごとの不具合検出工数を予測することが可能となった。その結果、仕様項目ごとのテスト優先度、不具合検出工数予測、および利用可能なテストリソースから、効率的なソフトウェアテストを実現するためのテスト計画を作成することが可能となった。
【００１１】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照しつつ詳細に説明する。
【００１２】
図１は本発明の全体の流れを、ブロック図を用いて示したものである。同図において、２２はモジュール・仕様項目対応関係設定部、２４はモジュール品質情報設定部、２６はモジュール不具合検出工数予測部、２８は仕様項目不具合検出工数予測部、３０はテスト計画作成部、１６はテストケース設計部、１８はテスト実行・結果出力部である。
【００１３】
本発明では、テスト対象となるソフトウェアシステム製品のモジュールリスト３２をもとに、モジュール品質情報設定部２４を利用してモジュールごとの品質情報を設定し、モジュール品質情報２５からモジュール不具合検出工数予測部２６を利用してモジュール不具合検出工数２７を予測する。さらに、システム仕様書から抽出された仕様項目リスト１と、モジュール・仕様項目対応関係設定部２２を利用してモジュール・仕様項目対応関係情報２３を作成する。これらモジュール不具合検出工数２７とモジュール・仕様項目対応関係情報２３とから、仕様項目不具合検出工数予測部２８を利用して仕様項目不具合検出工数２９を予測する。そして、テストに利用される資源やスケジュールなどからなるテストリソース１３、どの仕様項目を優先的にテストするかを表わすテスト優先度つき仕様項目リスト１０、仕様項目不具合検出工数２９からテスト計画作成部３０を利用して、効率的なソフトウェアテストを可能にするテスト計画３１を作成する。
【００１４】
次に、テスト優先度つき仕様項目リスト１０と、テストリソース１３、テストケース設計部１６を利用して、テスト対象ソフトウェアにとって最適なテストケース１７を作成する。このテストケース１７とテスト計画３１にもとづいてテスト実行された結果発見された不具合情報は、テスト実行・結果出力部１８を利用してテスト結果１９として出力される。なお、本発明は、テスト計画の作成までを主として支援するものであり、テスト実行・結果出力部は設けなくても良い。また、テスト優先度つき仕様項目リストの情報はテスト計画の作成にあたって使用しなくても良い。
【００１５】
以下、上記した各部の機能について詳細に説明する。なお、各機能はソフトウェアによりコンピュータを用いて実現されるものであっても良い。
【００１６】
＜モジュール品質情報の設定＞
本発明では、ソフトウェアを構成するプログラムモジュールごとに、その品質に関する情報（モジュール品質情報）を設定する。設定された品質情報を用いて、後に、その不具合検出工数を予測することになる。
【００１７】
まずは、設定される品質情報の例を図２に示す。図２にあるように、品質情報にはその開発プロセスに関する特徴と、開発されたモジュールのソースコードに関する特徴とに大きく分けられる。開発プロセスに関する特徴は、主に主観的に設定されるものであり、一方、ソースコードに関する特徴は、機械的に測定可能なものである。なお、テスト計画を作成するのはテスト実行にかなり近い段階でも良いので、ソースコードを利用することが可能となる。
【００１８】
モジュール品質情報設定の具体的な手順の例を図３に示す。まず、設定する品質情報を一つ選択する（Ｓ８１）。それが開発プロセスに関する品質情報か否かを判断し（Ｓ８２）、そうである場合には、その開発プロセスについての調査を行い（Ｓ８３）、その結果について主観的あるいは客観的に評価して、１−１０の点数を与える（Ｓ８４）。他にも評価したいモジュール品質情報がある場合には、Ｓ８１に戻って作業を繰り返す（Ｓ８５）。一方、選択した品質情報が、モジュールソースコードに関する品質情報の場合には（Ｓ８６）、その品質情報に対応するソースコードの特徴値あるいはメトリクスを、ツールを利用、もしくは手作業にて測定する（Ｓ８７）。さらに測定結果にもとづいて、１−１０の点数を与える（Ｓ８８）。他にも評価したい品質情報がある場合には、Ｓ８１に戻って作業を繰り返す。
【００１９】
＜モジュール不具合検出工数の予測＞
モジュールごとに、そのモジュールからどの程度の不具合が検出され、その検出工数がそのモジュールのトータルでどの程度になるかを予測する。どのようにモジュール検出工数を予測するかには、様々な手順が考えられるが、ここでは、最も基本的な手順を図４にて説明する。まず、不具合検出工数を予測するモジュールを一つ選択する（Ｓ９１）。つづいて不具合数の予測に有効な品質情報を選択し（Ｓ９２）、それらから、ソースコードの単位規模に対する不具合の数を予測する（Ｓ９３）。また、不具合検出工数の予測に有効な品質情報を選択し（Ｓ９４）、それらから、不具合当たりの検出工数を予測する（Ｓ９５）。最後に、それらの積をとることで、トータルの不具合検出工数を算出する（Ｓ９６）。不具合検出工数が未知のモジュールが残っていたら、Ｓ９１へ戻って作業を繰り返す（Ｓ９７）。
【００２０】
前記した品質情報の例（図２参照）の一部を利用して、不具合検出工数予測の例を以下に述べる。まず、不具合数の予測に有効な品質情報として、ソース規模と担当者のスキルを利用する。担当者のスキルを把握すれば、そのレベルのプログラマが作成したプログラムに、例えば１０００行あたりに何個程度の不具合が含まれているかを予測することができる。例えば、プログラム経験の浅いプログラマの担当したモジュールについては、１０００行あたりに５個の不具合を仮定して、ソース規模からモジュールの総不具合数を予測する、などである。この情報を用いて、トータルで何個程度の不具合が含まれているかを予測する。次に、不具合検出工数の予測に有効な品質情報として、ソースコードの複雑さを利用する。ソースコードが複雑であれば、そのソースコードの実行パスも多岐に渡り、特定のパスに存在する不具合を検出するのに、より多くの工数が必要となる。通常の一個あたりの検出工数を設定し、複雑さに応じてそれに調整をほどこす。例えば、一定レベル以上の複雑さをもつモジュールについては、単位あたりの不具合検出工数を通常の１．５倍にする、などである。この検出工数と、予測した不具合数との積をとることで、トータルの不具合検出工数を予測することができる。
【００２１】
＜モジュール・仕様項目対応関係情報の設定＞
一般にシステム仕様書には、ソフトウェアシステムで実現される機能が仕様項目として記述されている。これらの項目の一覧をリストとして抽出した仕様項目リスト（詳細は後述）と、その仕様項目の実現に利用されるモジュールとの対応関係の情報を設定する。この情報は、後に仕様項目ごとの不具合検出工数を予測するために必要となる。設定すべき情報は、図５のようである。各仕様項目の実現に際して、どのモジュールが使用されているか、またその寄与の度合はどの程度になるか、を設定する。実際の手順としても、図のような表を埋めていく形で行われる。基本的な手順は、図６のようである。一つの仕様項目を選択し（Ｓ１０１）、その仕様項目を実現するために使用されるモジュールを洗い出し（Ｓ１０２）、各モジュールのこの仕様項目実現への寄与の度合を、比率（パーセント）で設定する（Ｓ１０３）。以上の手順を、すべての仕様項目に対して繰り返す（Ｓ１０４）。
【００２２】
＜仕様項目不具合検出工数の予測＞
モジュール・仕様項目対応関係情報と、モジュールごとの不具合検出工数予測とから、それぞれの仕様項目ごとに、仕様項目不具合検出工数を予測する。基本的な手順例は図７のようである。一つのモジュールに対して（Ｓ１１１）そのモジュールの、各仕様項目への寄与の度合の比率を計算する（Ｓ１１２）。そのモジュールの寄与する仕様項目ごとに、不具合検出工数の予測値を、（Ｓ１１２）にて決定した比率で分配する（Ｓ１１３）。この分配をすべてのモジュールについて繰り返す（Ｓ１１４）。次に、一つの仕様項目を選択し（Ｓ１１５）、各モジュールからこの仕様項目への不具合検出工数の分配値のトータルをとり、この仕様項目の不具合検出工数予測値とする（Ｓ１１６）。この手順をすべての仕様項目に対して繰り返す（Ｓ１１７）。図のようにして、仕様項目ごとの不具合検出工数を予測する。
【００２３】
例えば、あるモジュールの不具合検出工数が２人日であり、二つの仕様項目に寄与しているとする。この時、それぞれの仕様項目への寄与率がそれぞれ４０％、６０％であった場合は、寄与の比率は２：３となり、それぞれへの不具合検出工数の分配は、０．８人日、１．２人日になる。
【００２４】
＜テスト計画の作成＞
テストに利用される資源やスケジュールなどを表わすテストリソース、テスト優先度付き仕様項目リスト、予測された仕様項目不具合検出工数の三つから、テスト計画を作成する。
【００２５】
テストリソースとしては、「担当」「期間」「資源」等の分類にしたがって、必要なリソースが定義されている（詳細は後述）。テスト優先度つき仕様項目リストは、仕様項目リストの各項目に対してテスト優先度という値が与えられたものである（詳細は後述）。テスト優先度とは、その値が大きいほどテストの実行順序やテストの量などに関して優先的・重点的にテストを実施することを表わす指標である。また、テスト計画とは、それぞれのテスト担当者に対して、誰が、どの仕様項目に対するテストを、どのタイミングで、どれだけの不具合検出工数をかけて、行うかを定めたものである。すなわち、テスト計画は、仕様項目不具合検出工数の予測値に基づいて、テストリソースの配分を決定するものである。テスト計画は、例えば図８のような線表として表現することができる。
【００２６】
ここでは、テスト計画作成の非常に基本的な手順を図９に示す。テストリソースとして、テスト期間、テスト担当者の人数構成と各担当者の能力が与えられたものとする。この例では、テスト担当者の能力は、基準とする担当者の能力を基準（１．０）にして、それに対して単位時間に処理できる不具合検出工数の相対比で表現する。したがって、基準となるものよりも２０％能力の高い技術者とは、同一時間に１．２倍の工数分のテストを行えるもののことである。その段階で割り当てられていない仕様項目のテストのうち、最もテスト優先度の高いものを選択し（Ｓ１２１）、途中段階の作業計画から、割り当て可能なテスト担当者を選択し（Ｓ１２２）、その仕様項目の不具合検出工数予測値をテスト担当者の能力比で割った値を、その仕様項目テスト期間として割り当てる（Ｓ１２３）。上記の手順をすべての仕様項目に対して行う（Ｓ１２４）。以上のようにして、テスト計画を作成することが可能となる。さらに図８の状況を例にとると、次に割り当てるべき仕様項目はＣａｓｅ２であり、その不具合検出工数は２．４、割り当て可能な担当者はB、能力は１．２である。この場合は、担当者Bに対して、２．４／１．２＝２日を割り当てることになる。
【００２７】
前記の通り、この手順は非常に基本的で単純な例を示したものである。テスト担当者の得手不得手によって、仕様項目ごとに担当者の能力比を変え、担当者の選択時に、最も能力の高い担当者を選ぶようにする、テスト優先度の高いものに対しては基本となる不具合検出工数にさらに予備の工数を付与する、優先度の高いものだけを集めた仕様項目のテストケースと、通常の全仕様項目のテストケースを用意して交互に繰り返しテストするなど、様々の工夫が可能である。
【００２８】
そこで、第二の実施形態として、予備の工数を利用したテスト計画作成のアルゴリズムを説明する。これは、テストに利用可能な工数をあらかじめ基本の不具合検出工数（基本工数）と予備の不具合検出工数（予備工数）として区別しておく。基本工数と予備工数の総和が、テストに利用可能な総不具合検出工数になる。基本工数は予測される仕様項目不具合検出工数にもとづいて配分し、予備の不具合検出工数はテスト優先度にもとづいて分配する、というアルゴリズムである。このアルゴリズムを利用することにより、テスト優先度の高い仕様項目については、テスト順序を先にするだけではなく、より多くの不具合検出工数を割り当てることが可能となり、テスト優先度の高い仕様項目に対するテストの十分性をさらに高めることができる。
【００２９】
図１０にこの例の手順を示す。まず、全仕様項目に関する不具合検出工数の予測値の和をとりＣｐ（Ｔ）とする（Ｓ１３１）。次に利用可能な工数を基本工数Ｃ（Ｂ）と予備工数Ｃ（Ｐ）とに、Ｃ（Ｂ）≦Ｃｐ（Ｔ）となるように分ける（Ｓ１３２）。このうち、予備工数の方をテスト優先度に基づいて分配することになる。まずは、基本工数を不具合検出工数の大きさにもとづいて分配する。Ｃ（Ｂ）＝Ｃｐ（Ｔ）の場合には（Ｓ１３３）、各仕様項目に不具合検出工数を分配することが可能なので、仕様項目（ｉ）ごとの不具合検出工数はＣ（ｉ）＝Ｃｐ（ｉ）とする（Ｓ１３４）。ただし、Ｃｐ（ｉ）は、仕様項目（ｉ）の不具合検出工数予測値である。Ｃ（Ｂ）＜Ｃｐ（Ｔ）の場合には、不具合検出工数をすべての仕様項目に割り振ることはできないので、基本工数を不具合検出工数予測値の比で分配し、Ｃ（ｉ）＝Ｃ（Ｂ）＊Ｃｐ（ｉ）／Ｃｐ（Ｔ）、となる（Ｓ１３５）。この時点でのＣ（ｉ）は基本工数を分配したものであり、この後、予備工数の分配に入る。予備工数の分配は、テスト仕様項目のテスト優先度値Ｐ（ｉ）のテスト優先度値の総和Ｐ（Ｔ）に対する比にもとづいて行う。Ｃ（ｉ）＝Ｃ（ｉ）＋Ｃ（Ｐ）＊Ｐ（ｉ）／Ｐ（Ｔ）という形で、予備工数の分配分を、仕様項目ごとの不具合検出工数に追加する。これにより、テスト優先度の高い仕様項目に対してより多くの工数を割り当てることができる（Ｓ１３６）。これより後のテスト計画作成は、前の例とほとんど同じである。その段階で割り当てられていない仕様項目のテストのうち、最もテスト優先度の高いものを選択し(Ｓ１３７)、途中段階の作業計画から、割り当て可能なテスト担当者について（Ｓ１３８）、その仕様項目の不具合検出工数予測値をテスト担当者の能力比で割った値を、その仕様項目テスト期間として割り当てる（Ｓ１３９）。上記の手順をすべての仕様項目に対して行う（Ｓ１４０）。以上のようにして、テスト計画を作成することが可能となる。
【００３０】
第三の実施形態として、不具合修正が頻繁に行われる開発形態でのリグレッションテストとして利用する例を示す。リグレッションテストとは、同じテストケースを、一定量の不具合が修正されるたびに繰り返し行うテストのことである。このテストは、不具合修正によってシステムに悪影響が出ていないかを調べるために実施される。
【００３１】
ここでは、優先度の高いものだけを集めた重要仕様項目リストと通常の全仕様項目リストの両方を用意して、二つの仕様項目リストのテストを交互に繰り返し実行するような、リグレッションテストの応用となるテスト計画作成アルゴリズムを説明する。このアルゴリズムを利用することにより、テスト優先度の高い仕様項目については、テスト優先度の低い仕様項目と比較してより多くの回数テストされ、より多くの不具合検出工数を割り当てることができる。重要仕様項目に対するテストと通常の全仕様項目に対するテストを組み合わせて利用することで、テスト効率とテスト十分性をさらに高めることができる。
【００３２】
図１１にこの例の手順を示す。まず、すべての仕様項目を集合Ｕｔにセットする（Ｓ１４１）。次にＵｔに属する仕様項目をテスト優先度値の大きいものから順に並べた配列Ａ（Ｕｔ）を作成する（Ｓ１４２）。次に、集合Ｕｔに属する全仕様項目に関する不具合検出工数の予測値の総和を計算してＣｐ（Ｔ）とする（Ｓ１４３）。重要仕様項目として選択したい項目の比率ｘ（０≦ｘ≦１）を決定する（Ｓ１４４）。配列Ａ（Ｕｔ）の先頭の仕様項目から順番に一つずつ取り出して集合Ｕｘに加え、Ｕｘに属する仕様項目に関する不具合検出工数の予測値の和Ｃｐ（ｘ）を計算する（Ｓ１４５）。ここで、Ｃｐ（ｘ）≦ｘ＊Ｃｐ（Ｔ）ならば（Ｓ１４６）、配列Ａ（Ｕｔ）から次の仕様項目を取り出して集合Ｕｘに加えて同様にＣｐ（ｘ）を計算する（Ｓ１４５）。もしＣｐ（ｘ）＞ｘ＊Ｃｐ（Ｔ）となれば（Ｓ１４６）、最後に加えた項目はＵｘから削除する（Ｓ１４７）。こうして求めた部分集合Ｕｘに対し、前述の第一、第二の実施形態に挙げたような任意のアルゴリズムを用いてテスト計画Ｐｘを立てる（Ｓ１４８）。次に仕様項目全体の集合Ｕｔに対して、同様に任意のアルゴリズムを用いてテスト計画Ｐｔを立てる（Ｓ１４９）。これらのテスト計画ＰｘとＰｔを任意に組み合わせることで、全体のテスト計画を作成する（Ｓ１５０）。全仕様項目のテスト計画Ｐｔの実行回数に対する重要仕様項目テスト計画Ｐｘの実行回数を増やすことで、テスト優先度の高い仕様項目により多くの不具合検出工数を割り当てることが可能になる。また、部分集合ＵｘをＵｔとみなし、再起的にこのアルゴリズムを適用して、さらに詳細なテスト計画を作成することも可能である。
【００３３】
＜テストの実行＞
こうして作成されたテスト計画と、公知の手段で設計されたテストケースによってテスト実行された結果は、テスト実行・結果出力部を利用してテスト結果として出力される。公知のテストケース設計手段としては、例えば特開２００１−１８４２３２のようにシステム仕様からテストケースを設計する手法を用いる。テスト実行・結果出力部における手順は後述する。
【００３４】
次に、システム仕様書などからシステムの特徴を表現し、そのシステムにとって適当なテスト戦略を選択する手段を提供して、重要な機能を優先的にテストできるテストケースの設計支援方法について説明する。
【００３５】
図１２は、かかる設計支援方法の全体の流れを、ブロック図を用いて示したものである。なお、ここには図１で示したテスト計画を設計する流れが併記されているが、ここでは該当部分に同じ符号を用いることにより説明を省略する。
【００３６】
図１２において３は仕様項目特性値設定部、５はテスト戦略作成部、７はテスト戦略選択部、９はテスト優先度導出部、１１はテスト戦略評価部、１６はテストケース設計部、１８はテスト実行・結果出力部、２１はテスト結果検証部である。
【００３７】
ここでは、まずテスト対象となるソフトウェアシステム製品のシステム仕様書から抽出された仕様項目リスト１と、ソフトウェアシステムの特徴を表現するために用意された評価観点データベース２をもとに、仕様項目特性値設定部３を利用して、そのソフトウェアシステムの特徴を表わす特性値つき仕様項目リスト４を作成する。
【００３８】
次に評価観点データベース２をもとにテスト戦略作成部５を利用して、どの評価観点にどれくらい重点をおいてテストするかを設定するためのテスト戦略を作成し、テスト戦略データベース６に登録する。
【００３９】
テスト戦略選択部７では、テスト戦略データベース６から任意のテスト戦略を選択してテスト優先度導出部９に出力する。テスト優先度導出部９では、与えられたテスト戦略と特性値つき仕様項目リスト４をもとに、どの仕様項目を優先的にテストするかを表わすテスト優先度つき仕様項目リスト１０が作成される。
【００４０】
テスト戦略評価部１１では、テスト優先度つき仕様項目リスト１０と過去の不具合データ１２を入力として、選択されたテスト戦略を適用して得られる不具合検出傾向をシミュレーションし、選択されたテスト戦略がテスト対象ソフトウェアシステムに適しているかどうかを判断する。必要ならば複数のテスト戦略を順次選択して不具合検出傾向をシミュレーションし、最適だと思われるテスト戦略およびテスト優先度つき仕様項目リストを、テストケース設計用に選択する。
【００４１】
次に、テストケース設計用に選択されたテスト優先度つき仕様項目リスト１０と、テストに利用される資源やスケジュールなどからなるテストリソース１３、過去に生成された類似テストケース１４、および不足分のテストケースの補充、過多なテストケースの削除をするためのテストケース設計手順１５をもとに、テストケース設計部１６を利用して、テスト対象ソフトウェアにとって最適なテストケース１７を作成する。このテストケース１７によりテスト実行された結果発見された不具合情報は、テスト実行・結果出力部１８を利用してテスト結果１９として出力される。通常のテストでは、開発・デバッグの進行に合わせてテストが繰り返し実行される。現在テスト対象となっているソフトウェアへのすべてのテスト結果は、現テスト対象の不具合データ２０に登録される。
【００４２】
テスト結果検証部２１では、現テスト対象の不具合データ２０と適用されたテスト優先度つき仕様項目リスト１０を入力として適用テスト戦略を再度検証し、テスト戦略評価部に記憶されている他のテスト戦略によるテスト優先度つき仕様項目リストとも比較して、必要ならば適用テスト戦略を入れ替えて再テストを実施する。このようにして、常に最適なテスト戦略を選択して、最も効果的なテストケースが生成されるようにする。
【００４３】
以下、上記した各部の機能について詳細に説明する。なお、各機能はソフトウェアによりコンピュータを用いて実現されるものであっても良い。
【００４４】
＜特性値つき仕様項目リストの作成＞
仕様項目特性値設定部３では、システム仕様書から抽出された仕様項目リスト１とシステムの特徴を表現するための評価観点データベース２を入力として、特性値つき仕様項目リスト４を作成する。様々な視点からシステムの特徴を表現するために、ソフトウェアシステムを構成している各仕様項目に対して、複数の評価観点に基づいて特性値を与えることができる。これにより、ソフトウェアシステムを複数の視点から仕様項目単位で評価することが可能となる。
【００４５】
一般にシステム仕様書には、ソフトウェアシステムで実現される機能が仕様項目として記述されている。これらの項目の一覧をリストとして抽出した仕様項目リスト１が仕様項目特性値設定部３の入力となる。一方、評価観点はシステムをいろいろな観点から評価してその特徴を表現するために用意されるもので、システム仕様書の内容や設計段階での開発情報などからシステム開発の早期に評価できるものが主として選ばれ、評価観点データベース２に蓄積される。評価観点として考えられる一例を図１３に示す。ここでは、評価観点をプログラムの品質等の分類ごとに整理して示している。
【００４６】
これらの仕様項目リスト１と評価観点データベース２を入力として仕様項目特性値設定部３に与え、各仕様項目に対して評価観点に基づいたパラメータを仕様項目特性値として指定することで、特性値つき仕様項目リスト３を生成する。その具体的な手順を図１４に示す。
【００４７】
まず、評価観点並びに仕様項目リストを読み込み（Ｓ１，Ｓ２）、設定する評価観点を一覧から選択する（Ｓ３）。続いて仕様項目リストから仕様項目を検索し（Ｓ４）、選択した評価観点で評価した特性値を検索した仕様項目に入力する（Ｓ５）。かかる操作を仕様項目の検索が終了するまで繰り返し行う（Ｓ６）。次に、入力された仕様項目特性値の正規化を行う（Ｓ７）。仕様項目特性値は一般に仕様項目間の比較による相対評価として与えられることが多い。そのため、各々の評価観点について特性値がすべての仕様項目に与えられた段階で、特性値が、例えば１から１０までの範囲に収まるように正規化を行い、評価観点間の基準をそろえる。こうして、必要となるすべての評価観点について特性値が仕様項目に与えられたかを確認し（Ｓ８）、特性値つき仕様項目リストが作成される（Ｓ９）。
【００４８】
特性値つき仕様項目リストの一例を図１５に示す。ここで、仕様項目は大項目と中項目とからなり、ここでは、「ファイル」と「編集」に関する各項目について、選択された「不具合致命度」「機能利用頻度」「複雑さ」の各評価観点について特性値が与えられている。
【００４９】
＜テスト戦略の作成＞
テスト戦略作成部５では、テストを実行する際にどの評価観点にどれだけ重点をおいたテストをするかを示すテスト戦略を作成する。テスト戦略とは、システムの特徴を表現するために仕様項目に与えられた複数の仕様項目特性値に対して、どの評価観点による特性値をどの程度重視したテストを行うかを表わしており、図１６のように各評価観点に対する重み付けとして表現される。より重視する評価観点ほど、設定される重みが大きくなる。例えば、致命度重視型のテスト戦略では、評価観点のうち「不具合致命度」に関する重みが最も高い０．７に設定され、「機能利用頻度」および「仕様の複雑さ」に関する重みはそれぞれ０．１５となっている。
【００５０】
テスト戦略を作成するテスト戦略作成部における手順を図１７に示す。まず、評価観点一覧の読み込みを行い（Ｓ１０）、テスト戦略を新規に作成する必要があるか否かの判断を行う（Ｓ１１）。ここで、テスト戦略を新たに作成しない場合は、テスト戦略データベースから編集したいテストデータを選択する（Ｓ１２）。テスト戦略作成部には、評価観点データベースから入力が与えられ、各評価観点に対する重みを設定することでテスト戦略を作成する。続いて、重みを設定する評価観点を一覧から選択し（Ｓ１３）、選択した評価観点に対して重みを設定する（Ｓ１４）。すべての評価観点に対して重みが設定されれば（Ｓ１５）、それらの合計が１になるように正規化する（Ｓ１６）。ここで、新たに作成されたテスト戦略若しくは編集されたテスト戦略は、テスト戦略データベースに登録される（Ｓ１７）。
【００５１】
＜テスト戦略の選択＞
テスト戦略選択部７では、テストを実行する際にどのようなテスト戦略に基づいてテストを行うかを決定する。
【００５２】
テスト戦略選択部７では、テスト戦略データベース６に登録されたテスト戦略の中から、テスト優先度導出部９に与えるテスト戦略８を選択して出力する。テスト戦略８を選択するテスト戦略選択部７における手順を図１８に示す。最初は任意のテスト戦略を選択するが（Ｓ２１）、テストサイクルの進行に伴い、テスト戦略評価部やテスト結果検証部からより最適なテスト戦略を選択するように指示が来るので（Ｓ２０）、その指示に基づいてテスト戦略をテスト戦略データベースから選択する。例えば、テスト戦略データベースからまだテスト優先度を導出していないテスト戦略を選択する（Ｓ２２）。指示に適したテスト戦略がデータベースに存在するか否かを確認し（Ｓ２３）、無い場合には、テスト戦略作成部でテスト戦略を作成してデータベースに登録した後、そのテスト戦略を選択する（Ｓ２４）。そして選択されたテスト戦略は出力するようにしても良い（Ｓ２５）。
【００５３】
＜テスト優先度つき仕様項目リストの作成＞
テスト優先度導出部９では、選択されたテスト戦略８を適用することでソフトウェアシステムのどの部分を特に重点的にテストする必要があるかを、仕様項目単位に評価した指標であるテスト優先度を導出する。ここで作成されるテスト優先度つき仕様項目リスト１０は、特性値つき仕様項目リスト４とテスト戦略８をもとにテスト優先度導出部９にて生成されるもので、図２０に示すように仕様項目リストの各項目に対してテスト優先度という値が与えられたものである。
【００５４】
テスト優先度とは、その値が大きいほどテストの実行順序やテストの量などに関して優先的・重点的にテストを実施することを表わす指標である。テスト優先度導出部９では、各仕様項目に与えられた評価観点ごとの特性値と、テスト戦略として設定された各評価観点への重みづけから、その仕様項目に対するテスト優先度を算出する。その具体的な手順を図１９に示す。まず、テスト戦略と特性値つき仕様項目リストが読み込まれる（Ｓ３１，Ｓ３２）。続いて、仕様項目リストから順次項目を検索し（Ｓ３３）、テスト戦略で設定された各評価観点への重みづけと、特性値つき仕様項目リストの各仕様項目に与えられた特性値とから、その項目のテスト優先度を算出する（Ｓ３４）。かかる優先度の算出は、仕様項目の検索が終了するまで繰り返し行われる（Ｓ３５）。一般にテスト優先度は、各仕様項目 ｉに対してｎ個の評価観点に基づいた仕様項目特性値
【００５５】
【数１】
0003883449.tif 000002
【００５６】
が与えられたとき、テスト戦略による各評価観点への重みが
【００５７】
【数２】
0003883449.tif 000003
【００５８】
ならば、テスト優先度  は以下の数式（１）で表現される。
【００５９】
【数３】
0003883449.tif 000004
【００６０】
ただしテスト優先度を導出する計算式は、仕様項目特性値と各評価観点への重みとを組み合わせたものであれば異なる計算式を用いてもよい。こうして得られたテスト優先度を各仕様項目に持たせて、図２０に示すようなテスト優先度つき仕様項目リストを作成する（Ｓ３６）。
【００６１】
＜適用テスト戦略の評価＞
テスト戦略評価部１１では、適用されたテスト戦略によって各仕様項目に与えられたテスト優先度に基づいたテストが、ソフトウェアシステムに対してどれだけ有効なのか、テストの目的に合致しているのかどうかを評価する。また評価結果はすべて記憶しておき、複数のテスト戦略から最適なものを選択するために比較・検討することができる。新規のシステム開発においてはこのフェーズは実行できないが、過去に類似のシステム仕様構成をもつソフトウェアシステムの開発情報があれば、これを利用して適用テスト戦略の評価が可能となる。
【００６２】
テスト戦略評価部１１では、テスト優先度つき仕様項目リスト１０と過去の不具合データ１２が入力として与えられ、過去の不具合データ１２と比較して適用したテスト戦略がテスト対象ソフトウェアシステムに対して適当かどうかを評価する。過去の不具合データ１２には、図２２に示すようにシステムをバージョンアップする前の開発情報などの、類似のシステム仕様構成を持つソフトウェアシステム開発プロジェクトの不具合情報が蓄積され、各仕様項目にどれだけの不具合が存在していたかを示すデータが含まれている。なお図２２中の不具合数で「＊」が記入されている仕様項目は、その開発バージョンではまだ実装されていなかったことを示している。
【００６３】
テスト戦略評価部における手順を図２１に示す。まず、テスト優先度つき仕様項目リストを読み込み（Ｓ４１）、過去の不具合データが存在するかを確認して（Ｓ４２）、存在する場合は入力されたテスト優先度つき仕様項目リストを、過去の不具合データと比較して不具合が多く存在しそうな項目がどの程度テスト優先度の上位に位置しているかをシミュレーションする。具体的には、テスト優先度つき使用項目リストと過去の不具合データから不具合検出傾向を予測し（Ｓ４３）、この予測した不具合検出傾向をテスト優先度つき仕様項目及びそのテスト戦略と対応付けて記憶し（Ｓ４４）、記憶されている不具合検出傾向一覧を比較して、最適なテスト優先度つき仕様項目リストを選択する（Ｓ４５）。別のテスト戦略についてもシミュレーションを実行したければ（Ｓ４６）、テスト戦略データベースから別のテスト戦略を選択するように、テスト戦略選択部に指示を出す。こうして選択された新たなテスト戦略からテスト優先度導出部にてテスト優先度つき仕様項目リストを導出し（Ｓ４７）、過去の不具合データと比較して同様に評価する。この手順を繰り返して記憶したテスト戦略評価の一覧を比較し、実際のテストケース設計に適用するテスト戦略をひとつ選択し、テストケース設計部に出力する（Ｓ４８）。
【００６４】
＜テストケース設計＞
テストケース設計部１６では、適用されたテスト戦略８によって導出したテスト優先度に基づいて、各仕様項目に対してどのくらい重点的にテストを実行するかを決定し、テストケースを設計する。
【００６５】
テストケース設計部１６では、テスト優先度つき仕様項目リスト１０と共に、テストリソース１３、過去の類似テストケース１４、テストケース設計手段１５が入力として与えられる。テストケース設計部１６における手順を図２４に示す。まず、テスト優先度つき仕様項目リストの読み込みが行われる（Ｓ５１）。次に、テストに利用される資源やスケジュールなどを表わすテストリソースを読み込み（Ｓ５２）、各仕様項目に与えられたテスト優先度に応じて仕様項目ごとに配分する（Ｓ５３）。テストリソースの例を図２３に挙げる。テストリソースとしては、「担当」「期間」「資源」等の分類にしたがって、必要なリソースが定義されている。
【００６６】
各仕様項目のテスト優先度と配分されたテストリソースに応じて、仕様項目ごとに必要十分なテストケース量を予測する。次に、類似のシステム仕様に対して過去に生成されたテストケースがあれば、それを読み込み（Ｓ５４）、仕様項目をリストから順次検索して（Ｓ３５）、その情報を利用してテストケースを設計する（Ｓ５６）。各仕様項目のテストケース量を検討し（Ｓ５７）、過去の類似テストケースが全く存在しないか、あるいは予測したテストケース量に比べてテストケースが不足していれば、その不足分を補充するために公知のテストケース設計手段を用いて不足分のテストケースを作成する（Ｓ５８）。公知のテストケース設計手段としては、特開２００１−１８４２３２のようにシステム仕様からテストケースを設計する手法を用いる。逆に予測したテストケース量に比べてテストケースが過多であるような場合には、テストケースを削減して適当な量にする（Ｓ５９）。こうして、全ての仕様項目について検索が終了すると（Ｓ６０）、テスト対象にとって最適なテストケースが生成される（Ｓ６１）。
【００６７】
＜テスト結果の再利用＞
こうして設計されたテストケースによりテスト実行された結果は、テスト実行・結果出力部１８を利用してテスト結果１９として出力される。テスト実行・結果出力部１８における手順を図２５に示す。テスト実行・結果出力部では、テストケースを読込み（Ｓ６５）、読込まれたテストケースに基づいてテストを実行し（Ｓ６６）、その結果発見された不具合とその重要度を、システムの各仕様項目と対応づけて記録する（Ｓ６７）。こうして各仕様項目に関係する不具合数および重要度を集計し、テスト結果として出力する（Ｓ６８）。出力されるテスト結果の例を図２６に示す。また、テストはソフトウェアの開発・デバッグを通じて繰り返し行われ、各テストサイクルでテスト結果が出力される。現テスト対象に対して行われる各テストサイクルのすべてのテスト結果は、何回目のテストサイクルで得られたテスト結果であるかとあわせて、現テスト対象の不具合データとして保存される。
【００６８】
テスト結果検証部２１では、現テスト対象の不具合データ２０と適用されたテスト優先度つき仕様項目リスト１０を入力として、適用テスト戦略が適当であったかどうかを検証する。テスト結果検証部２１における手順を図２７に示す。まず、テストケース設計に適用したテスト優先度つき仕様項目リストとテスト戦略部で記憶した不具合検出傾向予測を読込む（Ｓ７１，Ｓ７２）。入力される現テスト対象の不具合データには、何回目のテストサイクルで見つかった不具合なのか、またその不具合の重要度がどの程度であるかが、仕様項目ごとに記録されている。テスト結果検証部では、この不具合データとテスト優先度つき仕様項目リストを比較して（Ｓ７３）、適用テスト戦略で期待された通りの効果が得られているかどうかを検証する（Ｓ７４）。検証の結果、期待通りの効果が得られており、かつまだ不具合が収束していなければ（Ｓ７５）、再テストを同じテスト戦略を用いて再度実行して（Ｓ７６）、適用中のテスト優先度つき仕様項目リストを再出力する（Ｓ７７）。一方、期待通りの効果が得られていないか、効果は得られているが既に不具合が収束しているようならば（Ｓ７４，Ｓ７５）、別のテスト戦略を新たに選択することを決定し、テスト戦略選択部に指示を出す（Ｓ７８）。そして、適当なテスト優先度つき仕様項目リストが存在する場合は（Ｓ７９）、現テスト対象の不具合データから不具合検出傾向を検証し、より最適なテスト戦略を選択する（Ｓ８０）。一方、適当なテスト優先度つき仕様項目リストが存在しない場合は（Ｓ７９）、テスト戦略選択部において新たにテスト戦略を選択し、テスト優先度につき仕様項目リストを導出して、テスト戦略評価部で評価・記憶を行う（Ｓ８１）。なお、選択された最適なテスト戦略は別のテスト戦略と比較しても良く（Ｓ８２）、最終的に選択されたテスト優先度つき仕様項目リストが出力される（Ｓ８３）。
【００６９】
このようにテストサイクルを通して常に最適なテスト戦略を選択し、最も効果的なテストケースが生成されるようにする。
【００７０】
また現テスト対象の不具合データは過去の不具合データにも現バージョンでの不具合情報として登録され、次バージョンのテスト戦略評価の際に不具合データとして利用されることになる。
【００７１】
【発明の効果】
以上説明したように、本発明は、各モジュールの品質に関わる情報を設定し利用して、モジュールごとの不具合検出工数を予測し、モジュールとシステム仕様書から抽出された仕様項目との対応情報から、仕様項目ごとの不具合検出工数を予測することが可能となった。 その結果、優先的にテストすべき仕様項目を示すテスト優先度、仕様項目不具合検出工数、および利用可能なテストリソースから、効率的なソフトウェアテストを実現するためのテスト計画を作成することが可能となっている。
【図面の簡単な説明】
【図１】  本発明（テスト計画作成支援方法）の全体の流れを示すブロック図。
【図２】  品質情報の一例を示す図。
【図３】  品質情報を設定する過程を示すフローチャート。
【図４】  モジュール不具合検出工数を予測する過程を示すフローチャート。
【図５】  仕様項目とモジュールとの対応関係として設定する情報の一例を示す図。
【図６】  仕様項目とモジュールとの対応関係情報を設定する過程を示すフローチャート。
【図７】  仕様項目の不具合検出工数を予測する過程を示すフローチャート。
【図８】  テスト計画の作成過程での一例を示す図。
【図９】  テスト計画を作成する第一の例の過程を示すフローチャート。
【図１０】  テスト計画を作成する第二の例の過程を示すフローチャート。
【図１１】  テスト計画を作成する第三の例の過程を示すフローチャート。
【図１２】  本発明の全体の流れを示すブロック図。
【図１３】  評価観点の一例を示す図。
【図１４】  特性値つき仕様項目リストを作成する過程を示すフローチャート。
【図１５】  図１４で生成される特性値つき仕様項目リストの一例を示す図。
【図１６】  テスト戦略の一例を示す図。
【図１７】  テスト戦略を作成する過程を示すフローチャート。
【図１８】  テスト戦略を選択する過程を示すフローチャート。
【図１９】  特性値つき仕様項目リストとテスト戦略からテスト優先度つき仕様項目リストを作成する過程を示すフローチャート。
【図２０】  図１９で作成されるテスト優先度つき仕様項目リストの一例を示す図。
【図２１】  選択されたテスト戦略から作成されたテスト優先度つき仕様項目リストを、過去の不具合データを用いて評価する過程を示すフローチャート。
【図２２】  図２１で利用する過去の不具合データの一例を示す図。
【図２３】  テストリソースの一例を示す図。
【図２４】  図１９で作成されるテスト優先度つき仕様項目リストとテストリソース、過去の類似テストケースおよび公知のテストケース設計手段から、テストケースを設計する過程を示すフローチャート。
【図２５】  図２４で設計されたテストケースを用いてテスト実行した結果、発見された不具合をテスト結果として作成する過程を示すフローチャート。
【図２６】  図２５で作成されるテスト結果の一例を示す図。
【図２７】  図２６で作成されるテスト結果を利用してテスト戦略を再度検証する過程を示すフローチャート。
【符号の説明】
１  システム仕様書仕様項目
２  評価観点データベース
３  仕様項目特性値設定部
４  特性値つき仕様項目リスト
５  テスト戦略作成部
６  テスト戦略データベース
７  テスト戦略選択部
８  テスト戦略
９  テスト優先度導出部
１０  テスト優先度付き仕様項目リスト
１１  テスト戦略評価部
１２  過去の不具合データ
１３  テストリソース
１４  過去の類似テストケース
１５  テストケース設計手段
１６  テストケース設計部
１７  テストケース
１８  テスト実行・結果出力部
１９  テスト結果
２０  現テスト対象の不具合データ
２１  テスト結果検証部
２２  モジュール・仕様項目対応関係設定部
２３  モジュール・仕様項目対応関係情報
２４  モジュール品質情報設定部
２５  モジュール品質情報
２６  モジュール不具合検出工数予測部
２７  モジュール不具合検出工数
２８  仕様項目不具合検出工数予測部
２９  仕様項目不具合検出工数
３０  テスト計画作成部
３１  テスト計画
３２  モジュールリスト
【図１】
0003883449.tif 000005
【図２】
0003883449.tif 000006
【図３】
0003883449.tif 000007
【図４】
0003883449.tif 000008
【図５】
0003883449.tif 000009
【図６】
0003883449.tif 000010
【図７】
0003883449.tif 000011
【図８】
0003883449.tif 000012
【図９】
0003883449.tif 000013
【図１０】
0003883449.tif 000014
【図１１】
0003883449.tif 000015
【図１２】
0003883449.tif 000016
【図１３】
0003883449.tif 000017
【図１４】
0003883449.tif 000018
【図１５】
0003883449.tif 000019
【図１６】
0003883449.tif 000020
【図１７】
0003883449.tif 000021
【図１８】
0003883449.tif 000022
【図１９】
0003883449.tif 000023
【図２０】
0003883449.tif 000024
【図２１】
0003883449.tif 000025
【図２２】
0003883449.tif 000026
【図２３】
0003883449.tif 000027
【図２４】
0003883449.tif 000028
【図２５】
0003883449.tif 000029
【図２６】
0003883449.tif 000030
【図２７】
0003883449.tif 000031