JP2004220269A - 統合テスト管理システム - Google Patents

Abstract

【課題】限られたスケジュール、リソースの中で常に品質の高いソフトウエアを開発するためには、技術者の経験に頼らない客観的なデータによるソフトウエアの分析と効率的なテストケースの選択および最適なリソース配分による効率的なテストの実行が課題である。
【解決手段】プログラム複雑性評価部とリソース評価部によってソフトウエアおよび利用可能なリソースを客観的に評価し、その評価結果を基にしながら、ソフトウエア全体の品質が向上する最適なテストの組み合わせを探索することでテスト方法の決定を支援し、その後、決定されたテスト方法にもとづいて、テストの自動生成、そして利用可能なリソースを用いてのテストの自動実行を行う統合テスト管理システムを提供する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、ソフトウエア開発におけるテスト工程の自動化、省力化に関する統合テスト管理システムに関するものである。
【０００２】
【従来の技術】
ソフトウエア開発においては、開発されたソフトウエアの品質を確認するために、さまざまな観点から複数のテストを実施している。通常の場合は、ソフトウエアを構成する最小単位のプログラムであるユニットの機能の確認であるユニットテストを実施して、問題がなければ、複数のユニットを組み合わせてコンポーネントテスト、次に機能テスト、システムテストへと徐々にテスト内容を広げていくことで、ソフトウエアの品質を確認する。
【０００３】
これらの各テストでは、それぞれのテストで確認しなければならないさまざまな確認項目を定義し、それらの項目を確認するための操作方法と期待する動作の対を作成する。この各確認項目をテストケースと呼び、それらのテストケースをまとめてテスト仕様書という形の資料を作成する方法が一般的である。通常の場合には、テスト仕様書の作成は、プログラムを作成した技術者もしくは、テスト担当の技術者が作成している。
【０００４】
ソフトウエアの品質の確認は、このテスト仕様書で定義されている各テストケースを基にテストを行い、ソフトウエアがあらかじめ期待する動作を行うかどうかの確認をすることで行う。したがって、テスト仕様書の品質によって最終的なソフトウエアの品質が決まるといえる。
【０００５】
このため、品質の高いソフトウエアを開発するためには、ソフトウエアを構成する各プログラムを正しく作成することのみならず、テスト仕様書を高い品質で作成し、テスト仕様書にしたがって正しくテストを実施する必要がある。
前述のように通常は、技術者がテスト仕様書の作成とテストの実施を行うが、近年では自動的にテスト仕様書を作成するソフトウエアや、予め決められた形式で作成されたテスト仕様書に沿って自動的にテストを実行するソフトウエア、あるいはこれらを統合したソフトウエアも開発され商用化されている。以降このようなソフトウエアを自動テストツールと称する。
【０００６】
予め決められた形式で技術者が作成したテスト仕様書に沿って自動的にソフトウエアのテストを実行する自動テストツールでは、ユニットテストからシステムテストの実施が可能になってきている。しかし、自動的にテストケースを作成する自動テストツールに関しては、抽象度の高いシステム要件を自動テストツールが処理できるように記述する手法が確立されていないため、具体的に仕様を記述することが比較的容易であるユニットレベル、コンポーネントレベルでの活用にとどまっている。
【０００７】
また、近年の研究によっては、プログラムのソースコードを解析することで、プログラム上の論理的な誤りを抽出するといった手法を用いて、ソフトウエアの品質を確認する自動テストツールや、解析結果を基に自動的にテスト仕様書の作成、テストの実行に必要なテストプログラムの自動生成、それに基づき自動的にテストを実施するソフトウエアも開発されてきている。
【０００８】
【発明が解決しようとする課題】
本来であれば、ソフトウエアの品質を１００％確認するためには、内部の全ての処理経路を少なくとも一回は実行する必要があるが、ソフトウエア全体の経路を全て網羅するようにテストすることは、実際には不可能である。これは、プログラムの中に終了しないループが存在する場合やループの中にループが存在するような場合がありうるためである。このような場合には、全ての処理経路を網羅するようなテストの実施が不可能となる場合や、ビジネスの要求する時間内でテストの実施を終わらせることが不可能な場合が多く存在する。
【０００９】
したがって、ビジネスの要求する時間内でどれだけ多くの処理経路を網羅するか、あるいは、全ての処理経路が網羅できないのであれば、どの処理経路をテストした場合にソフトウエアとしての品質がより多く向上するかという二つの視点から、最適なテストケースの組み合わせを見つける必要性が出てくる。そして、見つけられたテストケースを間違いなく実行することが必要となる。
しかしながら、現在の自動テストツールでは、プログラムの最小単位であるユニット単位でのテストの実行が中心であり、特定の処理経路のみを抽出してテストをするといった機能しか持たない。このため、ソフトウエアを構成するプログラムのどの経路をテストすることが品質向上につながるかの判断は技術者の経験に頼っているのが実情である。
【００１０】
したがって、限られた時間内で品質の高いソフトウエアを開発するために、経験豊かな技術者がソフトウエアの品質を向上させるために最適な処理経路を選択し、自動テストツールを用いてテストを実行すること必要になってくる。このことは、ソフトウエアの品質は自動テストツールを利用しても、それを使う技術者のスキルに依存するということである。
それに対して、今日では開発しなければならないソフトウエアの数の増加の早さに比べて、スキルの高い技術者の育成速度は遅いため、相対的にスキルの高い技術者の比率が下がると考えられる。このことは自動化テストツールによる省力化が可能であっても、品質の高いソフトウエアを安定して開発することは困難であるということを示している。
【００１１】
このことから、品質の高いソフトウエアを安定して開発し続けるためには、経験者の経験によらないテストの実現方法の確立と自動化による省力化、短納期化の実現が課題となっている。
【００１２】
【課題を解決するための手段】
以下に、上記課題を解決するための本発明における手段とその効果を示す。
１．統合テストシステムとしての統合化による自動化、省力化
本願の第１の発明では、ソースコードがソフトウエア全体に与える影響をソースコード複雑性評価部にて算出し、各ユニットのテストを実施するのに必要なリソースの見積りをテスト方法毎にリソース評価部にて算出し、この二つの評価部の情報を基に、操作者によって指定されたテスト実施に対する制約条件を満たした上で最もソフトウエア全体の品質が向上するように各ユニットのテスト方法の組み合わせを自動的に探索し操作者に対して提示を行うテスト方法決定支援部と、操作者によって決定されたテスト方法に合わせて各ユニットのテストプログラムを自動的に生成する自動テスト生成部と、自動的に生成されたテストプログラムを効率よく実行することが出来る自動テスト実行部を持つことで、テスト実施に対して操作者による介在を最小限に抑えることを可能とし、今まで人手による作業が中心であったテスト作業の自動化を行い、同時に省力化を達成することを可能とする。
【００１３】
２．高スキル技術者不要のユニットのリスク認識
本願の第２の発明では、各ユニットプログラムの処理を処理フローとしてモデル化、データの使われ方をデータフローとしてモデル化することで、行数の比較に代表されるような単純なプログラム量の判断ではなく、処理の流れの複雑さおよびデータの使われ方の複雑さを算出することを可能とし、さらに、ユニットが他のユニットでどのように使われているかを分析することで、ソフトウエア全体に対する単一のユニットの不具合がもたらす影響を算出することを可能とし、今まで経験者によって行われていた重要性の判断を自動化することを可能とする。
【００１４】
３．リソース消費の見積り精度の向上
本願の第３の発明では、投入可能なリソースに関しての過去のテスト実施実績の情報を基にして、新しいユニットのテストに必要な時間の見積りを精度良く行うことを可能とする。
【００１５】
４．制約条件を考慮したユニットのテスト方法選定の自動化、省力化
本願の第４の発明では、操作者によって入力された制約条件を満たす形で、各ユニットのシステム全体に与えるリスクを基に、リスクの高いユニットほど十分なテストを行うことが出来るようなテスト方法の組み合わせを算出することを可能とし、今まで経験を積んだ技術者が行っていたテスト方法の選定作業を自動化、省力化することを可能とする。
【００１６】
５．テストケース自動化による省力化とミスの低減
本願の第５の発明では、今まで人手によって行ってきたソフトウエアのテストを自動的に行うことを可能とするために、テストプログラムの作成をソースコード複雑性評価部のソースコード解析結果の一部であるフローモデルを、選択されたテスト方法に合わせて必要な深さで探索をおこないテストプログラムを生成することで、人手によるテストケースの作成とテストデータの作成工数を大幅に省力化し、テスト実行時のヒューマンエラーを排除することを可能とする。
【００１７】
【発明の実施の形態】
図１は、本発明の構成を示したものである。以下に、図１の構成図を用いて本発明全体および各部の機能の概要について説明する。
図１において、ソースコード１０は、テスト対象となるソフトウエアシステムのソースコードを示す。ソースコード複雑性評価部２０は、ソースコード１０を入力として、プログラムの解析を行い、ソフトウエアシステムを構成する各ユニットプログラムのモデル化処理を実施して複雑性を算出する。同時に同ユニットプログラムがソフトウエア全体に与える影響度の算出も行い、ユニットプログラムのリスク評価を行う。
リソース評価部３０では、前記ソースコード複雑性評価部２０の処理の結果を基に、該当ユニットをテストするために必要とされるコンピュータリソースや人的リソースの消費量の見積りを行う。
【００１８】
テスト方法決定支援部４０では、操作者より入力された全体のテスト方法、テスト実施時間、投入可能リソース情報に代表されるテスト実行に当たっての諸条件を基に、前記ソースコード複雑性評価部２０とリソース評価部３０の処理結果を基に、入力された条件を満たすようなテスト方法案を生成する。操作者は、この案の内容を吟味し、必要に応じて修正をおこない、最終的に確定処理を行うことで、テストの実施方法を決定する。
【００１９】
自動テストプログラム生成部５０では、前記テスト方法決定支援部４０にて確定したテスト実施方法に基づき、前記ソースコード複雑性評価部２０でのソースコードのモデル化処理の結果を用いて、経路探索および条件抽出処理を行いテストプログラムの生成を行う。また、操作者が新しいテストプログラムを作成して、自動生成されたプログラムと同様に取り扱うことも可能とする。
【００２０】
自動テスト実行部６０では、前記自動テストプログラム生成部５０にて生成もしくは、操作者によって入力されたテストプログラムと、テスト対象のソフトウエアシステムのソースコード１０を用いて、テストを実施する。また、テスト結果を表示もしくは出力する機能を有し、容易にテスト結果を操作者が把握できるようにする。
【００２１】
以上の概要に述べたように、本発明による統合テスト管理システムを用いることで、以下の方法で課題の解決が可能である。
１．最適なテストの組み合わせ探索
ソースコード複雑性評価部２０、リソース評価部３０の出力結果を用いることで、テスト方法決定支援部４０では、あらかじめ入力された制約条件のもとでテスト方法の探索を行うことが可能となる。
２．客観的数値に基づくプログラム評価
ソースコード複雑性評価部２０では、プログラムの利用頻度や複雑さを数値化することで、技術者の経験に頼っていた注目してテストすべき部分の把握を自動的に行うことが出来るようになる。
３．ソフトウエア品質の向上
前記、最適なテストの組み合わせ探索と客観的数値に基づくプログラム評価によって、技術者の経験の如何に関わらず安定して、品質の高いソフトウエアを開発するためのテストが実現可能となる。
４．自動化によるテスト期間の短縮
自動テストプログラム作成部４０および自動テスト実行部５０によって、今まで人手をかけて行ってきたテストの大部分が自動化されることによって、人的工数の削減が可能となり、テスト期間の短縮が可能となる。
５．省力化によるテストコスト削減
また、自動化によって人的工数が削減されることによって、人件費の圧縮が可能となり、テストコストの削減を行うことも可能となる。
【００２２】
次に、本発明における各構成の詳細について説明する。
図２は、ソースコード複雑性評価部２０の内部構成を示す図である。
ソースコード複雑性評価部２０は、図２に示すようにソースコード解析部２０１、フローモデル生成部２０２、利用率算出部２０３、リスク評価部２０４の４つの処理ブロックとプログラム構造データ２０５と、フローモデル２０６と、利用率データ２０７とリスク情報２０８の４種類の情報の格納部から構成されている。
【００２３】
ソースコード解析部２０１では、テスト対象のソフトウエアを構成する各ユニットのソースコード１０を処理の経路の分岐の存在に注目して解析を行い図３に例を示すプログラム構造データ２０５を生成する。同時に分岐条件、分岐先、分岐間の処理の量および呼び出す他のユニットに代表される情報項目の抽出を行う。
【００２４】
フローモデル生成部２０２では、前記ソースコード解析部２０１にて生成されたプログラム構造データをもとにしてフローモデル２０６を生成する。フローモデル２０６は、プログラムの分岐による処理の流れに注目した情報である処理フロー２０６１とデータの流れに注目した情報であるデータフロー２０６２の二種類のフローモデルを生成する。図４に処理フロー２０６１とデータフロー２０６２の例を示す。
図４に示す処理フロー２０６１は、処理の始まり、分岐、合流、終了を示すリンクと呼ばれる円の部分とノードと呼ばれる各円を処理の流れに応じて結ぶ線の部分を有し、プログラムの処理の流れを示した情報である。また、図４に示すデータフロー２０６２は、プログラムの中にて用いられる変数の状態と同変数に対する宣言、代入、使用、削除の各処理を抽出した情報である。
ＯＬＥ＿ＬＩＮＫ２ ＯＬＥ＿ＬＩＮＫ２フローモデル生成部２０２による処理フロー２０６１およびデータフロー２０６２の生成方法の具体例を示す。
フローモデル生成部２０２では、最初に処理の始まりと終了を示すリンクを作成した後に、プログラム構造データ２０５に示す木構造を左から辿りながら、分岐処理を探し出す。分岐処理を発見した場合には、同分岐処理を新しいリンクとして処理の始まりと終了間に作成する。同時に分岐処理のとび先があれば、合流としてノードの対応する場所にリンクを作成する。この処理をプログラム構造データ２０５の木構造の全ての部分に関して繰り返す。このようにして、処理の始まりと終わりの間に全ての分岐および合流を示すリンクを作成することで、処理フロー２０６１が完成する。
リスク評価部２０４では、リンクとノードの数を複雑度の計算に使用し、リソース見積り部２０６では、ノードの数をリソース消費量の見積もりに使用し、フロー探索部５０１では、リンクとノードによるプログラム構造データ２０５の全てをテストプログラム作成のための処理経路を決定に使用する。
また、データフロー２０６２に関しては、分岐処理ではなく変数の宣言、代入、使用、削除をプログラム構造データ２０５の木構造の左から探し出していくことで生成される。プログラム構造データを探索していく中で、変数に関しての処理が見つかった場合には、その処理が先に生成された処理フロー２０６１のどのノードに該当するかを確認しながら、それらの変数の状態と使用方法をデータフロー２０６２に登録していく。ここで変数の状態とは、該当する変数がすでに定義済みか、それとも未定義かどうかをしめす。また使用方法では、変数をどのように使用しているかを示し、定義、代入、判定、使用、未使用の使用方法が挙げられる。なお、定義と同時に代入する場合には、「定義、代入」という使用方法を用いるものとする。このデータフロー２０６２は、フロー探索部５０１にて、前記処理フロー２０６１と一緒にデータフローテストのための経路情報を決定するために使用される。
【００２５】
利用率算出部２０３では、ソースコード解析部２０１によって抽出されたプログラム構造データ２０５および、フローモデル生成部２０２にて生成されたフローモデル２０６をもとにして、各ユニット間の呼び出し処理の集計処理をおこない各ユニットのソフトウエア全体での利用率データ２０７を算出する。図５に利用率データの例を示す。利用率データ２０７は、ユニットプログラム毎に呼び出しを行ったユニットプログラムと、同呼び出しの行われたノード、およびノード内での呼び出し回数を集計したものである。
以下に利用率算出部２０３による利用率データ生成方法の例を示す。
利用率算出部２０３では、プログラム構造データ２０５に示す木構造を左側から呼び出し処理に注目して探索する。呼び出し処理を見つけた場合には、呼び出し先のユニット名の抽出と処理フロー２０６１におけるどのノードに対応するかを確認したのちに、利用率データ２０７に呼び出し情報を登録する。ただし、この登録時には、現在の処理中のユニット名と呼び出し先のユニット名、呼び出しノードを用いて一旦利用率データの検索を行い、すでに同一呼び出しが登録されていた場合には、呼び出し回数を１増加させる。もし、同一呼び出しが登録されていない場合には、呼び出し回数を１にして、利用率データ２０７への登録を行う。この処理をテスト対象のシステム内の全てのプログラムに対して行うことで、利用率データ２０７が生成される。
【００２６】
リスク評価部２０４では、ソースコード解析部２０１によって抽出されたプログラム構造データ２０５および、フローモデル生成部２０２にて生成されたフローモデル２０６および、利用率算出部２０３にて算出された利用率データ２０７を用いて、ソフトウエア全体に対する対象ユニットのリスク情報２０８を算出する。リスク情報算出方法の一例としては、フローモデル２０６の情報を基にして、分岐の数やノードの数によって算出対象ユニットの複雑性を計算し、各ユニットの複雑性と利用率の値にそれぞれ補正係数をかけて標準化をおこなったうえで、ユニットのリスクを複雑性と利用率の値それぞれＸ軸とＹ軸による二次元平面上の点に見立て原点からの距離として評価する方法が挙げられる。この場合には、同程度の複雑性であれば利用率の高いユニットほどリスクが高くなり、逆に同程度の利用率であれば複雑性が高いほどリスクも高いことになる。なお、ここで計算される複雑性の例としては、ＭｃＣａｂｅのメトリックスと呼ばれる複雑性を示す値がある。このＭｃＣａｂｅのメトリックスでは、処理フロー２０６１における開始、終了、分岐を表す円の数をリンク数とし、円と円を結ぶ矢印の数をノード数として定義し、複雑性をリンク数からノード数を引いた値に、主プログラムとサブルーチンの数を足して２倍した値を足したものとして定義されている。
図６にリスク情報２０８の例を示す。リスク情報２０８は、ユニット名、出現頻度、複雑性およびリスク値によって構成されている。ここでユニット名はリスク評価対象のユニットプログラムの名前を示し、それぞれのユニットに関して、システム全体で同ユニットが参照されている回数である出現頻度を示す値と、前記例ではＭｃＣａｂｅのメトリックスと呼ばれるユニットの複雑性を表す値と、ユニットのリスクの大きさを示す値であるリスク値を含んでいる。
【００２７】
図７は、図１におけるリソース評価部３０の内部構成を示す図である。
リソース評価部３０は、図７に示すように、リソース見積り部３０１、リソース評価データ３０２、統計処理部３０３、リソース情報入力部３０４、リソース情報３０５にて構成されている。
リソース見積り部ＯＬＥ＿ＬＩＮＫ１３０１ＯＬＥ＿ＬＩＮＫ１では、前記ソースコード複雑性評価部２０にて生成されたプログラム構造データ２０５、フローモデルデータ２０６、利用率データ２０７およびリソース情報３０５を入力にして、ユニットプログラムのテストを実施するために必要なリソース消費量を概算して、リソース評価データ３０２を生成する。ここでいうリソース消費量とは、テスト対象のプログラムを実行するために必要な処理時間を標準化した値であり、テスト対象の開発言語における命令毎に基本的なリソース消費量があらかじめ算出してある。このように定義された各命令のリソース消費量を元に、テストを実施するために必要なリソース消費量は各テスト時の処理の流れのなかで実行される全命令のリソース消費量を合計して計算を行う。なお、テスト方法の例として、少なくとも一回はプログラムの全てのステートメントの実行をおこなうステートカバレッジテストを実施するか、分岐命令のとび先を少なくとも一回は実行するブランチカバレッジテストを実施するか、全ての変数について使われ方の全てのパターンをテストするデータフローテストを実施するか、あるいは全ての処理フローの経路を実行するフルパステストを実施するかといったテスト方法が存在する。これらのテスト方法によってテスト実行に必要とされるリソース消費量は変化するために、各種テスト方法でのリソース消費量を概算し、リソース評価データ３０２を生成するものとする。なお、これらのテスト方法によるカバレッジの割合は、ステートメントカバレッジテストが最も少なく、ブランチカバレッジテスト、データフローテスト、フルパステストの順でカバレッジが大きくなる。
通常の場合、経験のある技術者がプログラムの複雑度をみながら、どの程度テストに時間が必要かを見積もるのであるが、本発明では、リソース消費量というプログラムの実行に必要な値を求め、その値をテスト実行に使用するコンピュータの単位時間当たりのリソース消費量で割ることによって、テスト実施に必要とされる時間を経験者による見積りより精度良く算出することが出来る。
【００２８】
図８は、前記リソース見積り部３０１にて生成されたリソース評価データ３０２の例を示す。リソース評価データ３０２では、ユニット名およびテストを実施するリソース名、テスト方法およびテスト実施に必要なリソース量にて構成されている。
【００２９】
統計処理部３０３は、自動テスト実行部６０におけるテストの実行結果を示すテスト実行結果６０４の情報を基にして、リソース評価データ３０２での見積もり結果との差異を算出し、統計的に処理を行うことで、リソース情報３０５のうちのコンピュータリソース情報３０５１での性能情報あるいは、プログラマリソース情報３０５２のパフォーマンス値を更新する。ここで行われる統計処理の例として、テスト実施回数によって性能の変化しないコンピュータリソースの場合には、単純に全ての実行結果の平均値を算出し、また、テスト実施回数によって経験を積みパフォーマンスの向上が見込めるプログラマリソースの場合には、最も新しい５回の実行結果の平均値を算出するような処理があげられる。
【００３０】
リソース情報入力部３０４はリソース情報３０５のデータを修正するときに用いる。本リソース情報入力部３０４は、図９のリソース情報一覧画面３０４１、図１０のコンピュータリソース情報編集画面３０４２、図１１のプログラマリソース情報編集画面３０４３を表示する。各画面の目的を以下に示す。
【００３１】
図９のリソース情報一覧画面３０４１では、コンピュータリソースおよびプログラマリソースを一覧することが可能である。
本リソース一覧画面３０４１にて新規作成ボタンをクリックすることで、新しくリソースを登録するために各項目が空白になったコンピュータリソース情報編集画面３０４２もしくは、プログラマリソース情報編集画面３０４３が表示され、新しいリソースの新規登録を行うことが可能である。なお、各編集画面が現在表示しているリソースの種類に応じて自動的に変更される。つまり、コンピュータリソースを一覧表示している場合には、コンピュータリソース情報編集画面３０４２が表示され、プログラマリソースを一覧表示している場合にはプログラマリソース情報編集画面が表示される。
あるいは、一覧されている既存のリソースを示す行をクリックすることで、行を反転表示させてから編集ボタンをクリックすることで、選択したリソースの種類に従ってコンピュータリソース編集画面３０４２もしくは、プログラマリソース編集画面３０４３が表示される。この表示された画面を用いて各リソース情報の確認と必要に応じて編集をおこなうことが可能である。
また、既存のリソースを示す行をクリックすることで、行を反転表示させてから削除ボタンをクリックすることで、既存リソースをリソース情報３０５からの削除を行なうことが可能である。
【００３２】
図１０のコンピュータリソース情報編集画面３０４２では、各コンピュータリソースに関する各種情報を編集することが可能である。ここで編集可能な情報は、リソース情報３０５に含まれているコンピュータリソース情報３０５１であり、編集項目としては図１０で示すように、リソース名、ＣＰＵタイプ、ＣＰＵスピード、ＣＰＵ数、メモリ容量、ディスク容量、一日あたりの使用料、備考、稼動状況が編集可能である。性能指数に関しては統計処理部３０３の処理で更新されるため、当コンピュータリソース編集画面では修正を行うことが出来ない。なお、新規登録時については、既存の他の類似リソース情報を用いて性能指数の値の設定がおこなわれる。
【００３３】
図１１のプログラマリソース情報編集画面３０４３では、テスト実施に投入可能なプログラマリソースに関する各種情報を編集することが可能である。ここで編集可能な情報は、リソース情報３０５に含まれえているプログラマリソース情報３０５２であり、編集項目としては、図１１の例で示すように、リソース名、職種、要件理解スキル、設計スキル、コーディングスキル、テストスキル、時間単価、時間外単価、稼動状況が上げられる。これらの入力値はそれぞれ次のように用いられる。リソース名、職種はプログラマを識別するために使用される単なる参照項目である。要件理解スキル、設計スキル、コーディングスキル、テストスキルの各スキル値を基にして、新規登録時のパフォーマンスの標準値が決定される。時間単価、時間外単価および稼動状況については、テスト方法決定支援部４０における最適解探索部４０２にて、テスト予定投入金額の条件を満たすかどうかの計算や、リソースがテスト予定期間に利用することが可能かどうかの判断のために使用される。パフォーマンス値に関しては、統計処理部３０３の処理で更新されるために、当プログラマリソース情報編集画面では編集を行うことが出来ない。なお、新規登録時については、既存の他の類似リソース情報を用いてパフォーマンス値の設定がおこなわれる。
【００３４】
図１２のリソース情報３０５では、コンピュータリソース情報３０５１およびプログラマリソース情報３０５２を含んでいる。コンピュータリソース情報３０５１は、前記コンピュータリソース情報編集画面３０４２を用いて編集することが可能であり、含まれている項目は、リソース名、ＣＰＵタイプ、ＣＰＵスピード、ＣＰＵ数、メモリ容量、ディスク容量、一日あたりの使用料、備考、性能指数がある。また、プログラマリソース情報３０５２は、プログラマリソース情報編集画面３０４２を用いて編集することが可能であり、含まれている項目は、リソース名、職種、要件理解スキル、設計スキル、コーディングスキル、テストスキル、時間単価、時間外単価、稼動状況およびパフォーマンス値がある。
【００３５】
図１のテスト方法決定支援部４０の構成を図１３に示す。
テスト方法決定支援部４０は、操作部４０１、最適解探索部４０２、テスト方法情報４０３によって構成される。
図１４に操作部４０１におけるテスト条件設定画面４０１１を示す。操作者は前記テスト条件設定画面４０１１を用いて、テスト計画を策定するための基本方法となるべき制約条件の入力を行う。ここで設定される制約条件の実施例としては、テスト方法、テスト予定時間、テスト投入予定金額、一日の作業時間、投入可能リソースがある。
【００３６】
図１３における最適解探索部４０２では、前記操作部４０１におけるテスト条件設定画面４０１１にて入力された制約条件を用いて、リスク情報２０８およびリソース評価データ３０２の情報を基に制約条件を満たしつつテストカバレッジの値が最大となるようなテスト方法を探索する。たとえば、テスト実行時間に制限がある場合には、実行可能なテスト時間の中で、システム全体に対する重要性の高い部分についてカバレッジの高いテスト方法、たとえばフルパステストやデータフローテストなどカバレッジの高い方法を用いて、最も多くの処理フローやデータフローを確認できるようにし、重要でない部分については、ステートメントテストを実施することでテスト時間を短縮するといったテスト方法の組み合わせを探索することである。あるいは、利用可能なリソースに制限がある場合には、利用可能なリソースのみを用いて、最も多くの処理フロー、データフローが確認できるテスト方法の組み合わせを探索することである。最適解探索部４０２で探索されたテスト方法情報４０３は、図１５のテスト方法結果表示画面４０１２に表示される。
【００３７】
ここでの探索方法は複数の方法が考えられるが、一例として、重要度の高いユニットプログラムに対して高いカバレッジのテストを実施することでソフトウエア全体の品質が向上するというアルゴリズムを用いた最適解探索フローチャートを図１６に示す。
図１６の処理４０２１では、ソフトウエアシステム全体を制約条件の範囲内でもっとも低いカバレッジとなるテスト方法でのテストを行った場合のリソース消費量および実施推定時間、必要な費用を算出する。判断４０２２にて、前記処理４０２１の算出結果が制約条件を満たしているかどうか判断を行う。もし、処理４０２１の算出結果が制約条件を満たしていない場合には、処理４０２７にて操作者に対して制約条件エラーを表示して、探索処理を終了する。もし、処理４０２１の算出結果が制約条件を満たしていた場合には、次の処理４０２３を実施する。
処理４０２３では、テスト対象のユニットプログラムのうち重要度の高い順に全体の２０％の個数のユニットプログラムを選択し、選択されたユニットプログラムのテスト方法を最大のテストカバレッジと設定する。これは、一般的に上位２０％の項目が全体に対する８０％の重みを持つと言われているパレートの法則（２０：８０の法則）を基にした処理手法である。つまり、重要度の高い２０％のユニットプログラムを重点的にテストすることで、システム全体の品質の８０％の向上を行えるという一般的な経験則を利用したものである。処理４０２４では、前記処理４０２３にて設定が修正されたテストカバレッジを用いてテストを行う場合のリソース消費量、実施推定時間、必要な費用を再度算出しなおす。
【００３８】
判断４０２５では、前記処理４０２４にて算出された結果が制約条件を満たしているかどうか判断をおこなう。もし、処理４０２４の算出結果が制約条件を満たしている場合には、再度処理４０２３を実施して、テストカバレッジの値を修正する。たとえば、一つの例としては、探索された全てのテストケースを実行するために必要な時間の概算値がテスト実施可能時間内におさまっている場合には、テスト時間が多くなるようにつまりテストカバレッジがより大きくなるようにテスト方法を選択しなおす。もし、処理４０２４の算出結果が制約条件を満たしていない場合には、処理４０２６を実施する。
処理４０２６では、前回の算出条件を図１７のテスト処理情報として記憶する。この処理４０２６の終了後、探索処理は終了する。
【００３９】
前記図１６のようなアルゴリズムを持つ図１３の最適解探索部４０２による探索処理の結果は、前記図１５のテスト方法探索結果表示画面４０１２を用いて操作者に提示される。操作者は同テスト方法探索結果表示画面４０１２を参照することで、テスト予定時間、投入予算、一日の作業時間、各カバレッジの値を確認することが出来る。操作者が生成されたテスト方法に問題なしと判断した場合には、「確定／テスト生成」ボタンを選択することで、自動テストプログラム生成部５０の処理が開始される。また、生成されたテスト方法に何らかの問題を見つけた場合には、「条件変更」ボタンを選択することで、前記図１４に示すテスト条件設定画面４０１１が再度表示され、新しいテスト条件を設定可能となる。また、図１に示す自動テスト実施までの一連の処理を終了する場合には、「キャンセル」ボタンを選択する。
【００４０】
前記テスト方法探索結果表示画面４０１２にて、「確定／テスト生成」ボタンが選択された場合には、図１の自動テストプログラム生成部５０の処理が開始される。図１８に自動テストプログラム生成部の内部構造を示す。自動テストプログラム生成部５０はフロー探索部５０１、分岐条件生成部５０２、プログラム生成部５０３、テストプログラム格納部５０４および、プログラム入力部５０５から構成される。
フロー探索部５０１では、前記ソースコード複雑性評価部２０にて生成されるプログラム構造データ２０５、フローモデル２０６および前記テスト方法決定支援部４０にて生成されるテスト方法情報４０３の情報を入力として処理を行う。本フロー探索部５０１では、前記テスト方法情報４０３にて示されるテスト方法でユニットプログラムをテストするために、プログラム構造データ２０５およびフローモデル２０６の情報を基にして、プログラムの開始部分から終了部分までの各処理経路の洗い出しを行う。
【００４１】
前記フロー探索部５０１にて洗い出された処理経路に対して、分岐条件生成部５０２では、それぞれの経路を正しく辿るために必要な各条件分岐部分の条件式の値を前記プログラム構造データ２０５およびフローモデル２０６の情報を用いて生成を行う。この場合の分岐条件生成部の処理の例としては、選択された経路を終了部分からノードを辿っていき、分岐処理があった場合には、正しく分岐条件を辿るために必要な条件式を記憶し、ノードを辿っていく途中で、記憶している条件式で使用されている変数に対する演算処理が行われていた場合には、その処理も記憶しながら処理の最初まで辿っていき、条件分岐および、条件分岐に関連する演算処理を全て抽出する。この抽出結果を基に、各演算処理を逆算していくことで、正しく経路をたどるための初期条件を生成するアルゴリズムが挙げられる。
【００４２】
プログラム生成部５０３では、前記分岐条件生成部５０２にて生成された初期条件に関する情報を基に、テスト対象となるユニットプログラムを実行するために必要な呼び出しプログラムと処理結果の判定処理プログラムを含むテストプログラムの生成を行い、テストプログラム格納部５０４へテストプログラムを格納する。
【００４３】
テストプログラム格納部５０４では、前記プログラム生成部５０３にて生成されたテストプログラムのソースコードを格納し管理を行う。
【００４４】
プログラム入力部５０５では、自動的に生成されたテストプログラムのみでなく、技術者が作成したテストプログラムをテストプログラム格納部５０４へ格納することを可能とする。本プログラム入力部５０５を用いてテストプログラム格納部に格納されたテストプログラムは、自動生成されたテストプログラムと同様の扱いとなり、図１に示す自動テスト実行部６０における自動テスト実行対象のテストプログラムとなる。
【００４５】
図１の自動テスト実行部６０の構成を図１９に示す。自動テスト実行部６０は、テスト実行管理部６０１、テスト情報通信部６０２、テスト実行処理部６０３、テスト実行結果データ６０４、テスト結果表示部６０５、テスト結果出力部６０６から構成されている。
テスト実行管理部６０１は、テスト対象のソースコード１０および、前記自動テストプログラム生成部５０内部のテストプログラム格納部５０４に格納されているテストプログラムを順次読み込み、テスト情報通信部６０２を通じてテスト実行処理部に対して、テスト実施に必要な情報を伝達し、テストの実施およびその結果の取得を行い、実行結果をテスト実行結果データ６０４に格納する。
【００４６】
テスト実行管理部６０１からテスト実行処理部６０３に対して送信される情報は、テスト対象のプログラムおよびテストプログラムである。逆にテスト実行処理部６０３からテスト実行管理部に対して送信される情報は、テストの合否を示すテスト結果に関する情報である。
【００４７】
また、テスト実行管理部６０１とテスト実行処理部６０３の間には、テスト情報通信部６０２が存在するため、前記テスト実行管理部６０１とテスト実行処理部６０３が同一のコンピュータ上で実行される必要はない。たとえば、図２１のテスト実施環境例にて示すように、テスト実行管理部６０１の実行される管理コンピュータ６０７とテスト実行処理部６０２が実行されるテスト実行コンピュータ６０８が別のコンピュータであっても良く、これらのコンピュータ間はＬＡＮ、公衆回線、インターネット、専用線、シリアル通信線、パラレル通信線などの方法を用いて、テスト情報通信部が通信を行うことで動作をしている。
【００４８】
図２０にはテスト実行結果データ６０４を示す。テスト実行結果データ６０４では、ユニット名、テスト方法、テスト実施時間、ステートカバレッジ、ブランチカバレッジ、テスト件数、エラー件数を管理している。
このテスト実行結果データ６０４は、テスト結果表示部６０５もしくは、テスト結果出力部６０６によって操作者のわかる形で表示もしくは出力される。
図２２にテスト結果表示部によって表示されるテスト結果表示画面を示す。テスト結果表示画面では、テスト方法、テスト実施時間、実施費用、ステートカバレッジ、ブランチカバレッジ、総テスト件数、総エラー件数および、ユニットプログラム毎のテスト結果の表示を行う。また、再テスト実施ボタンを選択することで、再度同一のテストを繰り替えることが可能である。また、「結果印刷」ボタンを選択することで、図１９のテスト結果出力部６０６を用いて、テスト結果７０を出力することも可能である。
【００４９】
【発明の効果】
本発明を用いることで、以下のような効果を得ることができる。
１．今まで技術者の経験に基づいて、テスト計画の策定およびテスト仕様書を作成していたが、本発明を用いることで、客観的な数値に基づき、テスト計画を作成し、テスト仕様書を作成できることで、経験深い技術者がいなくても、品質確認レベルの高い、テストを実施可能である。
【００５０】
２．本発明を活用することで、自動的にテストを実施することが出来るようになり、テストの品質を落とさずに、テスト工程の省力化が可能となる。このことによってテスト工程におけるコスト削減を行うことが可能となる。
【００５１】
３．また、今まで経験ある技術者が作成していたテスト仕様書の作成が自動化され、手作業によるテストも削減されるため、テスト工程の短縮が可能となる。
【図面の簡単な説明】
【図１】本発明の統合テスト管理システムの構成を示す図である。
【図２】ソースコード複雑性評価部の内部構成を示す図である。
【図３】ソースコード複雑性評価部内部のプログラム構造データに格納されるデータの代表例を示す図である。
【図４】ソースコード複雑性評価部内部のフローモデルに格納される処理フロー情報とデータフロー情報の代表例を示す図である。
【図５】ソースコード複雑性評価部内部の利用率データの代表例を示す図である。
【図６】ソースコード複雑性評価部内部のリスク情報の代表例を示す図である。
【図７】リソース評価部の内部構成を示す図である。
【図８】リソース評価部内部のリソース評価データの代表例を示す図である。
【図９】リソース情報一覧画面を示す図である。
【図１０】コンピュータリソース情報編集画面を示す図である。
【図１１】プログラマリソース情報編集画面を示す図である。
【図１２】リソース評価部内部のリソース情報に格納されるコンピュータリソース情報およびプログラマリソース情報の代表例を示す図である。
【図１３】テスト方法決定支援部の内部構成を示す図である。
【図１４】テスト条件設定画面を示す図である。
【図１５】テスト方法探索結果表示画面を示す図である。
【図１６】テスト方法探索部内の最適解探索部のフローチャートである。
【図１７】テスト方法探索部内のテスト方法情報の代表例を示す図である。
【図１８】自動テストプログラム生成部の内部構成を示す図である。
【図１９】自動テスト実行部の内部構成を示す図である。
【図２０】自動テスト実行部内のテスト実行結果データの代表例を示す図である。
【図２１】自動テスト実施環境の代表例を示す図である。
【図２２】テスト結果表示画面を示す図である。
【符号の説明】
１０・・・ソースコード、
２０・・・ソースコード複雑性評価部、
３０・・・リソース評価部、
４０・・・テスト方法決定支援部、
５０・・・自動テストプログラム生成部、
６０・・・自動テスト実行部、
７０・・・テスト結果、
８０・・・操作者、
２０１・・・ソースコード解析部、
２０２・・・フローモデル生成部、
２０３・・・利用率算出部、
２０４・・・リスク評価部、
２０５・・・プログラム構造データ、
２０６・・・フローモデル、
２０７・・・利用率データ、
２０８・・・リスク情報、
２０６１・・・処理フロー、
２０６２・・・データフロー、
３０１・・・リソース見積り部、
３０２・・・リソース評価データ、
３０３・・・統計処理部、
３０４・・・リソース情報入力部、
３０５・・・リソース情報、
３０４１・・・リソース情報一覧画面、
３０４２・・・コンピュータリソース情報編集画面、
３０４３・・・プログラマリソース情報編集画面、
３０５１・・・コンピュータリソース情報、
３０５２・・・プログラマリソース情報、
４０１・・・操作部、
４０２・・・最適解探索部、
４０３・・・テスト方法情報、
４０１１・・・テスト条件設定画面、
４０１２・・・テスト方法探索結果表示画面、
５０１・・・フロー探索部、
５０２・・・分岐条件生成部、
５０３・・・プログラム生成部、
５０４・・・テストプログラム格納部、
５０５・・・プログラム入力部、
６０１・・・テスト実行管理部、
６０２・・・テスト情報通信部、
６０３・・・テスト実行処理部、
６０４・・・テスト実行結果データ、
６０５・・・テスト結果表示部、
６０６・・・テスト結果出力部、
６０７・・・管理コンピュータ、
６０８・・・テスト実行コンピュータ、
６０５１・・・テスト結果表示画面

Claims (5)

1. ソフトウエアを構成するユニットの障害がソフトウエア全体に与えるリスクを評価するソースコード複雑性評価手段と、
   ユニットのテストを実施するために必要なリソースを評価するリソース評価手段と、
   前記ソースコード複雑性評価手段によって得られたリスクデータと、前記リソース評価手段によって得られたリソース評価データを基に、各ユニットのテスト方法の決定を支援するテスト方法決定支援手段と、
   同テスト方法にしたがって、各ユニットをテストするプログラムを自動的に生成する自動テストプログラム生成手段と、
   同自動生成されたテストプログラムを自動的に実行しテスト結果を出力する自動テスト実行手段と
   を備えたことを特徴とする統合テスト管理システム。
2. 前記ソースコード複雑性評価手段は、ソースコードの処理フローの解析およびデータフローの解析によってソフトウエアを構成するユニットの複雑性と利用率を算出し、算出された複雑性と利用率から該当ユニットがソフトウエア全体に与えるリスクを算出することが可能なリスク評価機能を有することを特徴とする請求項１に記載の統合テスト管理システム。
3. 前記リソース評価手段は、前記ソースコード複雑性評価手段にて解析されたソフトウエアに関する情報と、あらかじめ登録されている利用可能なリソースに関する情報を基にしてテスト方法ごとにテスト実施にかかる想定時間および想定リソース消費量を算出することを特徴とする請求項１記載の統合テスト管理システム。
4. 前記テスト方法決定支援手段は、ユニットのリスク評価結果とリソース評価結果および操作者によって入力された制約条件から、制約条件範囲内でソフトウエア全体の品質が最も高くなるユニット毎のテスト方法の組み合わせを自動的に選択しテスト方法案を自動的に作成することを特徴とする請求項１記載の統合テスト管理システム。
5. 前記自動テストプログラム生成手段は、前記ソースコード複雑性評価手段によるユニットプログラムの解析結果を基にして、指定されたテスト方法にあわせて同ユニットプログラムをテストするためのテストプログラムを自動的に生成することを特徴とする請求項１記載の統合テスト管理システム。

Images