プログラムチェックリスト作成システム
【課題】
既存アプリケーションの修正のテスト工程において、テストの実行結果から、そのプログラムの性能及びテストの品質を保証する。
【解決手段】
プログラムチェックリスト作成及びテスト実績の情報収集機能により、プログラムチェックリストを作成しながら、ＤＢにテスト結果及び、テスト実施にかかった時間を記録し、テスト実績の統計情報作成機能により、その収集したテスト実績からテストの失敗率や成功時の実行時間等を用いて統計情報を出力し、コーディング補正機能によりコーディングノウハウ上、性能悪化と推測されるプログラムソースを自動補正する。
既存アプリケーションの修正のテスト工程において、テストの実行結果から、そのプログラムの性能及びテストの品質を保証する。
【解決手段】
プログラムチェックリスト作成及びテスト実績の情報収集機能により、プログラムチェックリストを作成しながら、ＤＢにテスト結果及び、テスト実施にかかった時間を記録し、テスト実績の統計情報作成機能により、その収集したテスト実績からテストの失敗率や成功時の実行時間等を用いて統計情報を出力し、コーディング補正機能によりコーディングノウハウ上、性能悪化と推測されるプログラムソースを自動補正する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラムチェックリスト作成システムに係り、特に、プログラムソースからプログラムチェックリストを作成するシステムにおいて、過去と現在のテスト実績から、テストの統計情報を出力するプログラムチェックリスト作成システムに関するものである。
【背景技術】
【０００２】
プログラムのテスト作業は、通常、チェックリストに基づいて作成したテスト用データファイルを被テストプログラムに入力・実行させてテストを実施している。このテスト作業では、テストの回数を削減し、テスト作業をより迅速に効率よく行うことが重要である。
【０００３】
この関連技術として、例えば、特許文献１には、被テストプログラムに対して、テスト結果検証ロジックとチェックリスト消込みロジックを付加したチェックリスト自動消込みプログラムにテスト用データファイルとチェックリスト情報ファイルを入力して実行するようにして、出力されたテスト結果データが対応するチェック項目の確認データと一致しているか否かを検証し、検証済みチェック項目以外の項目で入力条件と確認内容が合致しているチェック項目を検索して自動的に消込みを行う、チェックリスト自動消込みシステムが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平７−２００３５６公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一般的に、既存アプリケーションを修正或いは拡張する際のテスト作業を迅速かつ品質を確保して実施するためには、テスト工程を自動化することが必要である。従来、テストの実行とテスト結果のドキュメント化を自動化することで、この種の課題に対処している。
【０００６】
しかし、テスト結果のドキュメント化を自動化しても、そのテスト結果が妥当かどうか判断する必要があり、それを怠ると品質の保証はできない。具体的には、最低限のプログラム品質を保証できるテストを実施しているか確認するためには、関数ごとに、下記(１)〜(３)のような条件を満たす必要がある。
（１）１つの関数において、１つ以上のテストを行っている。
（２）１つの関数において、正常ケースと異常ケースのテストがある。
（３）数値項目を引数にもつ関数は、境界値テストがある。
【０００７】
また、性能面においては、過去に実施したテストの実行時間と同等の実行時間であることが必要である。
このように、従来の技術では、テストの品質を保証するのは、人任せであるため、定量的な判断ができず、また、性能面において、改変前のシステムとどれほど違いがあるのかが判断しにくいという課題があった。
【０００８】
本発明の目的は、既存アプリケーションの修正のテスト工程において、テストの実行結果から、そのプログラムの性能及びテストの品質を保証するプログラムチェックリスト作成システムを提供することである。
【課題を解決するための手段】
【０００９】
本発明は、プログラムソースからドキュメントを作成するシステムにおいて、プログラムチェックリストを作成しテスト実績の統計情報をＤＢに格納するプログラムチェックリスト作成及びテスト実績の情報収集機能と、収集したテスト実績から統計情報を出力するテスト実績の統計情報作成機能と、プログラムソースの補正を行うプログラムコーディング自動修正機能を有することを特徴とするプログラムチェックリスト作成システムとして構成される。
【発明の効果】
【００１０】
本発明によれば、テストの実行結果から、そのテストが最低限のテストを実施しているかを確認することができる。また、過去のテスト実績から、プログラム性能が大幅に悪くなっていないか、定量的に判断できる。
また、過去に実施したプログラムのテスト状況を格納しているので、ソース改変による既存システムに与える影響を推測するための統計情報がわかる。
更に、機能としては満たしているコーディングでも、性能悪化につながるコーディングを自動的に修正することができる。
【図面の簡単な説明】
【００１１】
【図１】一実施形態によるプログラムチェックリスト作成システムの全体構成図である。
【図２】プログラムチェックリスト作成システム全体の処理動作を示す処理フローである。
【図３】チェックリスト作成及びテスト結果の統計情報収集機能の処理動作を示す処理フローである。
【図４Ａ】テスト実績の統計情報作成機能の動作を示す処理フローである。
【図４Ｂ】テスト実績の統計情報作成機能の動作を示す処理フローである。
【図５】コーディング補正機能の動作を示す処理フローである。
【図６】テストヘッダテーブル１１４の構成例を示す図である。
【図７】テスト詳細結果テーブル１１５の構成例を示す図である。
【図８】閾値テーブル１１２の構成例を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照して本発明の一実施形態について説明する。
まず、図１を参照して、プログラムチェックリスト作成システムの全体構成について説明する。
【００１３】
プログラム開発者は、クライアントＰＣ（開発者用ＰＣ）１０１を用いてプログラムの開発及びテストを実施する。プログラム開発者は、プログラムの開発が終了すると、ネットワーク１０２を介して接続されたプログラムチェックリスト作成システム１０４のサーバ１０３に対して、開発したプログラムのプログラムソース１０５、テストソース１０６、テスト結果ＸＭＬ１０７を入力する。
【００１４】
ここで、プログラムチェックリスト作成システム１０４は、アプリケーションプログラムの実行によってサーバ１０３上に構築されるシステムであり、主に、プログラムチェックリスト作成機能１０８、プログラム統計情報収集機能１０９、及びコーディング補正機能１１０の３つの機能を有する。
これらの機能により、システム１０４は、実行したテストのプログラムチェックリスト１１１、そのテストの統計情報データ１１６、及び補正後プログラムソースデータ１１７を出力する。
【００１５】
特に、プログラム統計情報収集機能１０９は、システム内部にあるプログラム統計情報ＤＢ１１３に統計情報を保管し、またその統計情報の分析を行う。ここで、プログラム統計情報ＤＢ１１３は、テストヘッダテーブル１１４と、テスト詳細結果テーブル１１５を有する。また、収集した統計情報を分析する際に、閾値テーブル１１２より閾値を取得して、分析数値に利用する。
【００１６】
次に、図６〜図８を参照して、各テーブルの構成について説明する。
図６は、一連のテスト全体の情報を保存するテストヘッダテーブル１１４の構成例を示す。テストＩＤは、実施したテストを一意に指定するための固有の情報であり、テスト実施毎に自動採番される。テスト開始日時はテストを開始した日時であり、それを"yyyy/MM/dd hh:mm:ss"形式で保持する。テスト対象プログラム名は実行したテストのテスト対象プログラム名、テスト実行時間(s)は一連のテストにかかった総時間である。
【００１７】
図７は、テスト詳細結果テーブル１１５を示す。
テスト詳細結果テーブル１１５は一つ一つのテストの内容、実行結果を保存するテーブルである。テストＩＤは実施したテストを一意に指定するための固有の情報であり、テストヘッダテーブル１１４とテスト詳細結果テーブル１１５を紐付けるキー情報となる。詳細ＩＤはテストメソッド毎の固有の情報であり、テストメソッド毎に自動採番される。
テスト対象クラス名は、テスト対象のクラス名であり、テストソースのJavaDocコメント（Javaは登録商標です）に記載された@targetClassタグの値を格納する。テスト対象メソッド名は、同様にテスト対象のメソッド名であり、テストソースに記載された@targetMethodタグの値を格納する。テスト対象シグニチャは、テストメソッドをさらに細かく一意に区別するためのものであり、JavaDocコメントに書かれた、@targrtSignitreタグの値を格納する。
【００１８】
テストクラス名はテストを実施したクラスのクラス名、テストメソッド名はテストを実施したメソッドの名前を示す。テストタイプはテストの種類を示し、Ｎ:正常ケース、Ｅ:異常ケース、Ｉ:インターフェース、Ｌ:境界などの種類を表す。テストタイプの項目は、JavaDocの@typeタグの値を格納する。
テスト結果項目は実施したテストの結果を示し、成功:"success"、失敗:"failure"、異常"exception"などで表す。本システムに入力したテスト結果ＸＭＬより、テスト結果を格納する。テスト時間は、同様にテスト結果ＸＭＬのtime属性から、テスト実行に掛かった時間を格納する。エラー内容は、失敗したテストのエラー内容をテスト結果ＸＭＬから読み込み、格納する。
【００１９】
図８は、閾値テーブル１１２を示す。
閾値テーブル１１２は、テスト実績の統計情報作成機能において用いられる閾値を格納する。閾値Ａは、テストの失敗率を判断する値、閾値Ｂ，Ｃは、テストの実行時間が以前のテストに比べて妥当であったかを判断するときに使用される値である。
【００２０】
次に、図２のフローチャートを参照して、システム全体の処理動作を説明する。
処理が開始されると、チェックリスト作成及びテスト実績の情報収集処理（Ｓ２０４）が実行される。この処理は、テストソース１０６とテスト結果ＸＭＬ１０７を入力とし、プログラムチェックリスト１１１を出力する。また、その処理において、プログラム統計情報ＤＢ１１３に情報を書き込む。
【００２１】
次のテスト実績の統計情報作成処理（Ｓ２０６）では、チェックリスト作成及びテスト実績の情報収集処理（Ｓ２０４）の処理で書き込んだプログラム統計情報ＤＢ１１３と、プログラムソース１０５を入力として、統計情報データ１１６を出力する。最後に、プログラムコーディング自動補正処理（Ｓ２０８）では、プログラムソース２０３を入力として、コーディングレベルで性能悪化となる部分を自動修正した、補正後プログラムソース１１７を出力する。
【００２２】
次に、図３を参照して、チェックリスト作成処理及びテスト結果の統計情報収集処理機能１０８（チェックリスト作成及びテスト実績の情報収集処理Ｓ２０４）について詳細に説明する。
処理が開始されると、テストソース１０６の内容を読み込む(Ｓ３０４)。次に、システム内に保存しているプログラムチェックリストのテンプレートファイルをコピーして、出力ファイルを作成する(Ｓ３０５)。そして、テストヘッダテーブル１１４にテスト全体の情報を書き込む(Ｓ３０６)。
【００２３】
処理ステップＳ３０７〜Ｓ３１８は、テストソースのテストクラス（関数群）毎に処理する。まず、テスト結果ＸＭＬ１０７を入力し、クラスに対するテスト結果のＸＭＬファイルを取得する(Ｓ３０８)。ステップＳ３０９とＳ３１７の間は、テストメソッド(関数）ごとに処理を実施する。
まず、１テストメソッドに対して、指定のJavaDocコメント(@conditionタグ、@contentsタグ、@typeタグ)が存在するかチェックする(Ｓ３１０)。チェックの結果、存在しない場合は、処理Ｓ３１１〜Ｓ３１５を実施しない。一方、指定のJavaDocが存在する場合は、テスト詳細結果テーブル１１５の詳細ＩＤを取得して、プログラムチェックリスト１１１に書き込む(Ｓ３１１)。
その後、テストソース１０６のJavaDocコメントから取得した、次の内容をそれぞれ、プログラムチェックリスト１１１に書き込む(Ｓ３１２)。この書き込み処理において、@conditionタグはテスト条件に、@contentタグはテスト内容に、@typeタグはテストタイプに、@targetClassタグはテスト対象クラスに、@targetMethodタグはテスト対象メソッドに、@targetSignatureタグはテスト対象シグニチャにそれぞれ書き込まれる。
【００２４】
次に、ステップＳ３１２で読み込んだテスト結果によって処理を分岐する。即ち、テスト結果ＸＭＬの<testcase>ノード下にある、ノードが<success>か、<failure>を判定する(Ｓ３１３)。判定の結果が<failure>の場合は、<failure>ノードの"message"属性の値を取得し(Ｓ３１４)、テスト結果をプログラムチェックリスト３２３に書き込む（Ｓ３１５）。一方、判定の結果が<success>の場合は、テスト結果項目に"success"を書込む(Ｓ３１５)。
また、判定の結果が<failure>の場合は、テスト結果項目に"failure"と書込み、エラー内容にステップＳ３１４で取得したエラー詳細を書き込む（Ｓ３１５）。
このように、処理ステップＳ３１１，Ｓ３１２，Ｓ３１５で取得したテスト結果情報をテスト詳細結果テーブル１１５に書き込む。
【００２５】
テストメソッド毎のループ（Ｓ３１７）、及びテストクラス毎のループ（Ｓ３１８）が終了したら、プログラムチェックリストにプログラム全体の概要シートを作成する（Ｓ３１９）。この概要シートには、クラス毎のテストの成功件数、失敗件数及び、テスト時間合計を記載する。最後、出力ファイルへ書き込み（クローズ処理）を実施して（Ｓ３２０）、一連の処理を終了する。
【００２６】
次に、図４Ａ，図４Ｂを参照して、テスト実績の統計情報作成機能（処理Ｓ２０６）について説明する。
処理が開始されると、閾値テーブル１１２から閾値を読み込む（Ｓ４０４）。そして、テスト詳細結果テーブル１１５より、今回のテストＩＤに紐づくテストメソッドの一覧を取得する（Ｓ４０５）。以後、テストメソッド毎に、処理ステップＳ４０６〜Ｓ４１４を処理する。
【００２７】
即ち、テスト詳細結果テーブル１１５全てから、該当するテストメソッドのテスト結果を取得して、テスト失敗回数及びテスト回数を算出する（Ｓ４０７）。算出した値から、テスト失敗回数÷テスト回数を求めて、閾値Ａとの関係の判定を行う（Ｓ４０８）。判定の結果、閾値Ａよりテスト失敗回数の割合が大きい場合は、要注意テストとして、統計情報データ１１６に書き込む（Ｓ４０９）。
【００２８】
一方、閾値Ａ以下の場合は、テスト詳細結果テーブル１１５から、過去のテストの平均実行時間を算出する（Ｓ４１０）。具体的には、テスト詳細結果テーブル１１５から、該当のテストメソッドのテスト結果のうち、テスト結果項目が"success"ののテスト時間を取得し、その平均値を算出する。そして、その算出したテスト平均実行時間を判定する（Ｓ４１１）。即ち、今回のテスト時間が、テスト平均実行時間に閾値Ｂを掛けた値より小さい場合は、性能改善テストとして、統計情報に書き込む（Ｓ４１２）。また、テスト実行時間が、テスト平均実行時間に閾値Ｃを掛けた値より大きい場合は、性能悪化テストとして、統計情報に書き込む（Ｓ４１３）。更に、テスト時間が上記の２つに該当しない場合は、何も処理せず、処理ステップＳ４１４に移行する。
【００２９】
以後、図４Ｂに示すように、プログラムソースを元として、各種テストを実施済みかどうかの情報を収集して行く。まず、プログラムソース１０５を入力とし、プログラムソースのメソッド情報を取得する（Ｓ４１８）。そして、プログラムソースのメソッドごとに、処理ステップＳ４１９〜Ｓ４２８を実施する。
即ち、テスト詳細結果テーブル１１５から対象メソッドのテストデータを取得する（Ｓ４２０）。テスト詳細結果テーブル１１５の検索キーは、テストＩＤ、テスト対象クラス、テスト対象メソッド、テスト対象メソッドシグニチャである。そして、検索した結果、対照メソッドのテストデータが存在しているか否かで、そのメソッドのテストを実行したか判断する（Ｓ４２１）。判断の結果、テストが実行されていない場合は、テスト未実施として統計情報データ１１６に書き込む（Ｓ４２２）。
【００３０】
一方、判断の結果、テストが実行されている場合は、メソッド引数に数値項目があるかどうか判定する（Ｓ４２３）。具体的には、int、Integer、long、Long、double、Doubleなどが含まれているか確認する。メソッド引数に数値がある場合、境界値チェックを実施しているか確認する（Ｓ４２４）。具体的には、処理ステップ４２０で絞り込んだデータに、テストタイプがＬ(境界チェック)のものがあるか判定する（Ｓ４２４）。その結果、Ｌ(境界チェック)のものがなかった場合は、境界値テスト不備として、統計情報データ１１６に書き込む（Ｓ４２５）。
【００３１】
そして、正常ケースと異常ケースのテストが実行しているか判定する（Ｓ４２６）。これは、対象メソッドのテストデータに、テストタイプがＮ(正常)のものとＥ(異常)のものがあるかを判断する。その結果、無かった場合、テスト不備として統計情報データに書き込む（Ｓ４２７）。以上のループをメソッドごとに繰り返して、一連の処理を終了する。
【００３２】
次に、図５を参照して、コーディング補正機能（処理Ｓ２０８）について説明する。
ここでは、Java言語において、問題となるString型の文字連結について修正する。Java言語におけるString型の文字連結では、値の書き換えを行わず、新たに領域を確保するため、大量にStringオブジェクトが作成され、性能が悪化する。この対策として、StringBuffer型を用いることで、解決するのであるが、これを自動的に補正することを実現する。
【００３３】
処理が開始されると、プログラムソース１０５を読み込んで、メソッド情報を取得する（Ｓ５０３）。以後、処理ステップＳ５０４〜Ｓ５１４をプログラムのメソッドごとに繰り返し処理する。
まず、メソッド内で定義されているローカル変数をリストアップする（Ｓ５０５）。次の、処理ステップＳ５０６〜Ｓ５１３でメソッド内の行ごとに繰り返し処理する。
【００３４】
即ち、行頭がString型の変数で始まる行でなければ、処理Ｓ５１２に移る。一方、行頭がString型の変数で始まれば、String型の変数の次の演算子が、等号記号か否かの判定をする（Ｓ５０８）。その判定の結果、等号記号でなかった場合は、処理Ｓ５１２へ移る。一方、等号記号であった場合は、該当行の等号記号の後に"+"演算子があるか否かの判定を行う（Ｓ５０９）。判定の結果、"+"演算子がある場合、この変数をStringBuffer型に再定義し、該当の"+"演算子を.append()関数に修正して（Ｓ５１０）、該当行以外の、この変数を使っている場所を、"変数名.toString()"に置換する（Ｓ５１１）。
このように、String変数をStringBuffer変数に置換したものを、補正後プログラムソースデータ１１７に出力する（Ｓ５１２）。
【符号の説明】
【００３５】
１０１：クライアントＰＣ １０２：ネットワーク １０３：サーバ
１０４：プログラムチェックリスト作成システム １０５：プログラムソース
１０６：テストソース １０７：テスト結果ＸＭＬ
１０８：チェックリスト作成及びテスト結果の統計情報収集機能
１０９：テスト実績の統計情報作成機能
１１０：コーディング補正機能 １１１：プログラムチェックリスト
１１２：閾値ＤＢ １１３：プログラム統計情報ＤＢ
１１４：テストヘッダテーブル １１５：テスト詳細結果テーブル
１１６：統計情報データ １１７：補正後プログラムソースデータ。
【技術分野】
【０００１】
本発明は、プログラムチェックリスト作成システムに係り、特に、プログラムソースからプログラムチェックリストを作成するシステムにおいて、過去と現在のテスト実績から、テストの統計情報を出力するプログラムチェックリスト作成システムに関するものである。
【背景技術】
【０００２】
プログラムのテスト作業は、通常、チェックリストに基づいて作成したテスト用データファイルを被テストプログラムに入力・実行させてテストを実施している。このテスト作業では、テストの回数を削減し、テスト作業をより迅速に効率よく行うことが重要である。
【０００３】
この関連技術として、例えば、特許文献１には、被テストプログラムに対して、テスト結果検証ロジックとチェックリスト消込みロジックを付加したチェックリスト自動消込みプログラムにテスト用データファイルとチェックリスト情報ファイルを入力して実行するようにして、出力されたテスト結果データが対応するチェック項目の確認データと一致しているか否かを検証し、検証済みチェック項目以外の項目で入力条件と確認内容が合致しているチェック項目を検索して自動的に消込みを行う、チェックリスト自動消込みシステムが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平７−２００３５６公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一般的に、既存アプリケーションを修正或いは拡張する際のテスト作業を迅速かつ品質を確保して実施するためには、テスト工程を自動化することが必要である。従来、テストの実行とテスト結果のドキュメント化を自動化することで、この種の課題に対処している。
【０００６】
しかし、テスト結果のドキュメント化を自動化しても、そのテスト結果が妥当かどうか判断する必要があり、それを怠ると品質の保証はできない。具体的には、最低限のプログラム品質を保証できるテストを実施しているか確認するためには、関数ごとに、下記(１)〜(３)のような条件を満たす必要がある。
（１）１つの関数において、１つ以上のテストを行っている。
（２）１つの関数において、正常ケースと異常ケースのテストがある。
（３）数値項目を引数にもつ関数は、境界値テストがある。
【０００７】
また、性能面においては、過去に実施したテストの実行時間と同等の実行時間であることが必要である。
このように、従来の技術では、テストの品質を保証するのは、人任せであるため、定量的な判断ができず、また、性能面において、改変前のシステムとどれほど違いがあるのかが判断しにくいという課題があった。
【０００８】
本発明の目的は、既存アプリケーションの修正のテスト工程において、テストの実行結果から、そのプログラムの性能及びテストの品質を保証するプログラムチェックリスト作成システムを提供することである。
【課題を解決するための手段】
【０００９】
本発明は、プログラムソースからドキュメントを作成するシステムにおいて、プログラムチェックリストを作成しテスト実績の統計情報をＤＢに格納するプログラムチェックリスト作成及びテスト実績の情報収集機能と、収集したテスト実績から統計情報を出力するテスト実績の統計情報作成機能と、プログラムソースの補正を行うプログラムコーディング自動修正機能を有することを特徴とするプログラムチェックリスト作成システムとして構成される。
【発明の効果】
【００１０】
本発明によれば、テストの実行結果から、そのテストが最低限のテストを実施しているかを確認することができる。また、過去のテスト実績から、プログラム性能が大幅に悪くなっていないか、定量的に判断できる。
また、過去に実施したプログラムのテスト状況を格納しているので、ソース改変による既存システムに与える影響を推測するための統計情報がわかる。
更に、機能としては満たしているコーディングでも、性能悪化につながるコーディングを自動的に修正することができる。
【図面の簡単な説明】
【００１１】
【図１】一実施形態によるプログラムチェックリスト作成システムの全体構成図である。
【図２】プログラムチェックリスト作成システム全体の処理動作を示す処理フローである。
【図３】チェックリスト作成及びテスト結果の統計情報収集機能の処理動作を示す処理フローである。
【図４Ａ】テスト実績の統計情報作成機能の動作を示す処理フローである。
【図４Ｂ】テスト実績の統計情報作成機能の動作を示す処理フローである。
【図５】コーディング補正機能の動作を示す処理フローである。
【図６】テストヘッダテーブル１１４の構成例を示す図である。
【図７】テスト詳細結果テーブル１１５の構成例を示す図である。
【図８】閾値テーブル１１２の構成例を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照して本発明の一実施形態について説明する。
まず、図１を参照して、プログラムチェックリスト作成システムの全体構成について説明する。
【００１３】
プログラム開発者は、クライアントＰＣ（開発者用ＰＣ）１０１を用いてプログラムの開発及びテストを実施する。プログラム開発者は、プログラムの開発が終了すると、ネットワーク１０２を介して接続されたプログラムチェックリスト作成システム１０４のサーバ１０３に対して、開発したプログラムのプログラムソース１０５、テストソース１０６、テスト結果ＸＭＬ１０７を入力する。
【００１４】
ここで、プログラムチェックリスト作成システム１０４は、アプリケーションプログラムの実行によってサーバ１０３上に構築されるシステムであり、主に、プログラムチェックリスト作成機能１０８、プログラム統計情報収集機能１０９、及びコーディング補正機能１１０の３つの機能を有する。
これらの機能により、システム１０４は、実行したテストのプログラムチェックリスト１１１、そのテストの統計情報データ１１６、及び補正後プログラムソースデータ１１７を出力する。
【００１５】
特に、プログラム統計情報収集機能１０９は、システム内部にあるプログラム統計情報ＤＢ１１３に統計情報を保管し、またその統計情報の分析を行う。ここで、プログラム統計情報ＤＢ１１３は、テストヘッダテーブル１１４と、テスト詳細結果テーブル１１５を有する。また、収集した統計情報を分析する際に、閾値テーブル１１２より閾値を取得して、分析数値に利用する。
【００１６】
次に、図６〜図８を参照して、各テーブルの構成について説明する。
図６は、一連のテスト全体の情報を保存するテストヘッダテーブル１１４の構成例を示す。テストＩＤは、実施したテストを一意に指定するための固有の情報であり、テスト実施毎に自動採番される。テスト開始日時はテストを開始した日時であり、それを"yyyy/MM/dd hh:mm:ss"形式で保持する。テスト対象プログラム名は実行したテストのテスト対象プログラム名、テスト実行時間(s)は一連のテストにかかった総時間である。
【００１７】
図７は、テスト詳細結果テーブル１１５を示す。
テスト詳細結果テーブル１１５は一つ一つのテストの内容、実行結果を保存するテーブルである。テストＩＤは実施したテストを一意に指定するための固有の情報であり、テストヘッダテーブル１１４とテスト詳細結果テーブル１１５を紐付けるキー情報となる。詳細ＩＤはテストメソッド毎の固有の情報であり、テストメソッド毎に自動採番される。
テスト対象クラス名は、テスト対象のクラス名であり、テストソースのJavaDocコメント（Javaは登録商標です）に記載された@targetClassタグの値を格納する。テスト対象メソッド名は、同様にテスト対象のメソッド名であり、テストソースに記載された@targetMethodタグの値を格納する。テスト対象シグニチャは、テストメソッドをさらに細かく一意に区別するためのものであり、JavaDocコメントに書かれた、@targrtSignitreタグの値を格納する。
【００１８】
テストクラス名はテストを実施したクラスのクラス名、テストメソッド名はテストを実施したメソッドの名前を示す。テストタイプはテストの種類を示し、Ｎ:正常ケース、Ｅ:異常ケース、Ｉ:インターフェース、Ｌ:境界などの種類を表す。テストタイプの項目は、JavaDocの@typeタグの値を格納する。
テスト結果項目は実施したテストの結果を示し、成功:"success"、失敗:"failure"、異常"exception"などで表す。本システムに入力したテスト結果ＸＭＬより、テスト結果を格納する。テスト時間は、同様にテスト結果ＸＭＬのtime属性から、テスト実行に掛かった時間を格納する。エラー内容は、失敗したテストのエラー内容をテスト結果ＸＭＬから読み込み、格納する。
【００１９】
図８は、閾値テーブル１１２を示す。
閾値テーブル１１２は、テスト実績の統計情報作成機能において用いられる閾値を格納する。閾値Ａは、テストの失敗率を判断する値、閾値Ｂ，Ｃは、テストの実行時間が以前のテストに比べて妥当であったかを判断するときに使用される値である。
【００２０】
次に、図２のフローチャートを参照して、システム全体の処理動作を説明する。
処理が開始されると、チェックリスト作成及びテスト実績の情報収集処理（Ｓ２０４）が実行される。この処理は、テストソース１０６とテスト結果ＸＭＬ１０７を入力とし、プログラムチェックリスト１１１を出力する。また、その処理において、プログラム統計情報ＤＢ１１３に情報を書き込む。
【００２１】
次のテスト実績の統計情報作成処理（Ｓ２０６）では、チェックリスト作成及びテスト実績の情報収集処理（Ｓ２０４）の処理で書き込んだプログラム統計情報ＤＢ１１３と、プログラムソース１０５を入力として、統計情報データ１１６を出力する。最後に、プログラムコーディング自動補正処理（Ｓ２０８）では、プログラムソース２０３を入力として、コーディングレベルで性能悪化となる部分を自動修正した、補正後プログラムソース１１７を出力する。
【００２２】
次に、図３を参照して、チェックリスト作成処理及びテスト結果の統計情報収集処理機能１０８（チェックリスト作成及びテスト実績の情報収集処理Ｓ２０４）について詳細に説明する。
処理が開始されると、テストソース１０６の内容を読み込む(Ｓ３０４)。次に、システム内に保存しているプログラムチェックリストのテンプレートファイルをコピーして、出力ファイルを作成する(Ｓ３０５)。そして、テストヘッダテーブル１１４にテスト全体の情報を書き込む(Ｓ３０６)。
【００２３】
処理ステップＳ３０７〜Ｓ３１８は、テストソースのテストクラス（関数群）毎に処理する。まず、テスト結果ＸＭＬ１０７を入力し、クラスに対するテスト結果のＸＭＬファイルを取得する(Ｓ３０８)。ステップＳ３０９とＳ３１７の間は、テストメソッド(関数）ごとに処理を実施する。
まず、１テストメソッドに対して、指定のJavaDocコメント(@conditionタグ、@contentsタグ、@typeタグ)が存在するかチェックする(Ｓ３１０)。チェックの結果、存在しない場合は、処理Ｓ３１１〜Ｓ３１５を実施しない。一方、指定のJavaDocが存在する場合は、テスト詳細結果テーブル１１５の詳細ＩＤを取得して、プログラムチェックリスト１１１に書き込む(Ｓ３１１)。
その後、テストソース１０６のJavaDocコメントから取得した、次の内容をそれぞれ、プログラムチェックリスト１１１に書き込む(Ｓ３１２)。この書き込み処理において、@conditionタグはテスト条件に、@contentタグはテスト内容に、@typeタグはテストタイプに、@targetClassタグはテスト対象クラスに、@targetMethodタグはテスト対象メソッドに、@targetSignatureタグはテスト対象シグニチャにそれぞれ書き込まれる。
【００２４】
次に、ステップＳ３１２で読み込んだテスト結果によって処理を分岐する。即ち、テスト結果ＸＭＬの<testcase>ノード下にある、ノードが<success>か、<failure>を判定する(Ｓ３１３)。判定の結果が<failure>の場合は、<failure>ノードの"message"属性の値を取得し(Ｓ３１４)、テスト結果をプログラムチェックリスト３２３に書き込む（Ｓ３１５）。一方、判定の結果が<success>の場合は、テスト結果項目に"success"を書込む(Ｓ３１５)。
また、判定の結果が<failure>の場合は、テスト結果項目に"failure"と書込み、エラー内容にステップＳ３１４で取得したエラー詳細を書き込む（Ｓ３１５）。
このように、処理ステップＳ３１１，Ｓ３１２，Ｓ３１５で取得したテスト結果情報をテスト詳細結果テーブル１１５に書き込む。
【００２５】
テストメソッド毎のループ（Ｓ３１７）、及びテストクラス毎のループ（Ｓ３１８）が終了したら、プログラムチェックリストにプログラム全体の概要シートを作成する（Ｓ３１９）。この概要シートには、クラス毎のテストの成功件数、失敗件数及び、テスト時間合計を記載する。最後、出力ファイルへ書き込み（クローズ処理）を実施して（Ｓ３２０）、一連の処理を終了する。
【００２６】
次に、図４Ａ，図４Ｂを参照して、テスト実績の統計情報作成機能（処理Ｓ２０６）について説明する。
処理が開始されると、閾値テーブル１１２から閾値を読み込む（Ｓ４０４）。そして、テスト詳細結果テーブル１１５より、今回のテストＩＤに紐づくテストメソッドの一覧を取得する（Ｓ４０５）。以後、テストメソッド毎に、処理ステップＳ４０６〜Ｓ４１４を処理する。
【００２７】
即ち、テスト詳細結果テーブル１１５全てから、該当するテストメソッドのテスト結果を取得して、テスト失敗回数及びテスト回数を算出する（Ｓ４０７）。算出した値から、テスト失敗回数÷テスト回数を求めて、閾値Ａとの関係の判定を行う（Ｓ４０８）。判定の結果、閾値Ａよりテスト失敗回数の割合が大きい場合は、要注意テストとして、統計情報データ１１６に書き込む（Ｓ４０９）。
【００２８】
一方、閾値Ａ以下の場合は、テスト詳細結果テーブル１１５から、過去のテストの平均実行時間を算出する（Ｓ４１０）。具体的には、テスト詳細結果テーブル１１５から、該当のテストメソッドのテスト結果のうち、テスト結果項目が"success"ののテスト時間を取得し、その平均値を算出する。そして、その算出したテスト平均実行時間を判定する（Ｓ４１１）。即ち、今回のテスト時間が、テスト平均実行時間に閾値Ｂを掛けた値より小さい場合は、性能改善テストとして、統計情報に書き込む（Ｓ４１２）。また、テスト実行時間が、テスト平均実行時間に閾値Ｃを掛けた値より大きい場合は、性能悪化テストとして、統計情報に書き込む（Ｓ４１３）。更に、テスト時間が上記の２つに該当しない場合は、何も処理せず、処理ステップＳ４１４に移行する。
【００２９】
以後、図４Ｂに示すように、プログラムソースを元として、各種テストを実施済みかどうかの情報を収集して行く。まず、プログラムソース１０５を入力とし、プログラムソースのメソッド情報を取得する（Ｓ４１８）。そして、プログラムソースのメソッドごとに、処理ステップＳ４１９〜Ｓ４２８を実施する。
即ち、テスト詳細結果テーブル１１５から対象メソッドのテストデータを取得する（Ｓ４２０）。テスト詳細結果テーブル１１５の検索キーは、テストＩＤ、テスト対象クラス、テスト対象メソッド、テスト対象メソッドシグニチャである。そして、検索した結果、対照メソッドのテストデータが存在しているか否かで、そのメソッドのテストを実行したか判断する（Ｓ４２１）。判断の結果、テストが実行されていない場合は、テスト未実施として統計情報データ１１６に書き込む（Ｓ４２２）。
【００３０】
一方、判断の結果、テストが実行されている場合は、メソッド引数に数値項目があるかどうか判定する（Ｓ４２３）。具体的には、int、Integer、long、Long、double、Doubleなどが含まれているか確認する。メソッド引数に数値がある場合、境界値チェックを実施しているか確認する（Ｓ４２４）。具体的には、処理ステップ４２０で絞り込んだデータに、テストタイプがＬ(境界チェック)のものがあるか判定する（Ｓ４２４）。その結果、Ｌ(境界チェック)のものがなかった場合は、境界値テスト不備として、統計情報データ１１６に書き込む（Ｓ４２５）。
【００３１】
そして、正常ケースと異常ケースのテストが実行しているか判定する（Ｓ４２６）。これは、対象メソッドのテストデータに、テストタイプがＮ(正常)のものとＥ(異常)のものがあるかを判断する。その結果、無かった場合、テスト不備として統計情報データに書き込む（Ｓ４２７）。以上のループをメソッドごとに繰り返して、一連の処理を終了する。
【００３２】
次に、図５を参照して、コーディング補正機能（処理Ｓ２０８）について説明する。
ここでは、Java言語において、問題となるString型の文字連結について修正する。Java言語におけるString型の文字連結では、値の書き換えを行わず、新たに領域を確保するため、大量にStringオブジェクトが作成され、性能が悪化する。この対策として、StringBuffer型を用いることで、解決するのであるが、これを自動的に補正することを実現する。
【００３３】
処理が開始されると、プログラムソース１０５を読み込んで、メソッド情報を取得する（Ｓ５０３）。以後、処理ステップＳ５０４〜Ｓ５１４をプログラムのメソッドごとに繰り返し処理する。
まず、メソッド内で定義されているローカル変数をリストアップする（Ｓ５０５）。次の、処理ステップＳ５０６〜Ｓ５１３でメソッド内の行ごとに繰り返し処理する。
【００３４】
即ち、行頭がString型の変数で始まる行でなければ、処理Ｓ５１２に移る。一方、行頭がString型の変数で始まれば、String型の変数の次の演算子が、等号記号か否かの判定をする（Ｓ５０８）。その判定の結果、等号記号でなかった場合は、処理Ｓ５１２へ移る。一方、等号記号であった場合は、該当行の等号記号の後に"+"演算子があるか否かの判定を行う（Ｓ５０９）。判定の結果、"+"演算子がある場合、この変数をStringBuffer型に再定義し、該当の"+"演算子を.append()関数に修正して（Ｓ５１０）、該当行以外の、この変数を使っている場所を、"変数名.toString()"に置換する（Ｓ５１１）。
このように、String変数をStringBuffer変数に置換したものを、補正後プログラムソースデータ１１７に出力する（Ｓ５１２）。
【符号の説明】
【００３５】
１０１：クライアントＰＣ １０２：ネットワーク １０３：サーバ
１０４：プログラムチェックリスト作成システム １０５：プログラムソース
１０６：テストソース １０７：テスト結果ＸＭＬ
１０８：チェックリスト作成及びテスト結果の統計情報収集機能
１０９：テスト実績の統計情報作成機能
１１０：コーディング補正機能 １１１：プログラムチェックリスト
１１２：閾値ＤＢ １１３：プログラム統計情報ＤＢ
１１４：テストヘッダテーブル １１５：テスト詳細結果テーブル
１１６：統計情報データ １１７：補正後プログラムソースデータ。
【特許請求の範囲】
【請求項１】
プログラムソースからドキュメントを作成するシステムにおいて、プログラムチェックリストを作成しテスト実績の統計情報をＤＢに格納するプログラムチェックリスト作成及びテスト実績の情報収集機能と、収集したテスト実績から統計情報を出力するテスト実績の統計情報作成機能と、プログラムソースの補正を行うプログラムコーディング自動修正機能を有することを特徴とするプログラムチェックリスト作成システム。
【請求項２】
前記統計情報を格納する前記ＤＢは、
実施したテストを一意に指定するテストＩＤと、テストを開始した日時と、実行したテストのテスト対象プログラム名と、一連のテストにかかったテスト実行時間に関する情報を保管するテストヘッダテーブルと、
実施したテストを一意に指定する該テストＩＤと、テスト対象クラス名と、テスト対象メソッド名と、テストメソッドをさらに細かく一意に区別するテスト対象シグニチャと、テストを実施したクラスのテストクラス名と、テストを実施したメソッドの名前を示すテストメソッド名と、テストタイプはテストの種類を示すテストタイプと、実施したテストの結果を示すテスト結果項目と、テスト実行に掛かったテスト時間と、テストのエラー内容、に関する情報を保管するテスト詳細結果テーブルと、
を格納することを特徴とする請求項１のプログラムチェックリスト作成システム。
【請求項１】
プログラムソースからドキュメントを作成するシステムにおいて、プログラムチェックリストを作成しテスト実績の統計情報をＤＢに格納するプログラムチェックリスト作成及びテスト実績の情報収集機能と、収集したテスト実績から統計情報を出力するテスト実績の統計情報作成機能と、プログラムソースの補正を行うプログラムコーディング自動修正機能を有することを特徴とするプログラムチェックリスト作成システム。
【請求項２】
前記統計情報を格納する前記ＤＢは、
実施したテストを一意に指定するテストＩＤと、テストを開始した日時と、実行したテストのテスト対象プログラム名と、一連のテストにかかったテスト実行時間に関する情報を保管するテストヘッダテーブルと、
実施したテストを一意に指定する該テストＩＤと、テスト対象クラス名と、テスト対象メソッド名と、テストメソッドをさらに細かく一意に区別するテスト対象シグニチャと、テストを実施したクラスのテストクラス名と、テストを実施したメソッドの名前を示すテストメソッド名と、テストタイプはテストの種類を示すテストタイプと、実施したテストの結果を示すテスト結果項目と、テスト実行に掛かったテスト時間と、テストのエラー内容、に関する情報を保管するテスト詳細結果テーブルと、
を格納することを特徴とする請求項１のプログラムチェックリスト作成システム。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１０−２８６９７５（Ｐ２０１０−２８６９７５Ａ）
【公開日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願番号】特願２００９−１３９１９２（Ｐ２００９−１３９１９２）
【出願日】平成２１年６月１０日（２００９．６．１０）
【出願人】（０００１５２９８５）株式会社日立情報システムズ (409)
【Ｆターム（参考）】
【公開日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願日】平成２１年６月１０日（２００９．６．１０）
【出願人】（０００１５２９８５）株式会社日立情報システムズ (409)
【Ｆターム（参考）】
[ Back to top ]