JP2014203095A - 情報処理装置及び情報処理方法及びプログラム - Google Patents

Abstract

【課題】効率的にテストの計画値を生成する。【解決手段】データベース１０８は、テストカテゴリごとに、テストで消化すべきテスト項目数の標準値と、テストで発見されると推測される欠陥数の標準値とが、所定の単位作業量当たりの値として示される標準テスト計画テーブルを記憶する。入力部１０１は、開発プロジェクトでの作業量が示されるプロジェクト情報を入力する。データ作成部１０６は、プロジェクト情報に示される作業量と標準テスト計画テーブルに示されるテスト項目数の標準値とを用いて、テストカテゴリごとに、開発プロジェクトのテストで消化すべきテスト項目の数を算出し、プロジェクト情報に示される作業量と標準テスト計画テーブルに示される欠陥数の標準値とを用いて、テストカテゴリごとに、開発プロジェクトのテストで発見されると推測される欠陥の数を算出する。【選択図】図４

Description

本発明は、テストの計画値を効率的に生成し、また、テストの実績に沿ってテストの計画値を適切な値に変更する技術に関する。

近年、ソフトウェア開発における開発規模の増大に伴いソフトウェア試験時間が増加する傾向にある。
従来から、ゴンペルツ曲線などの成熟度曲線などを用いて残存欠陥数の評価により試験の完了を評価する手法が提案されている。
こうした状況におけるテスト試験分析を支援するための従来技術としては次のものがある。
特許文献１では、欠陥発生頻度とテスト時間情報を収集し、テスト時間が最短になるようにテスト実行順番を組み換える自動テスト装置が開示されている。
特許文献２では、テスト対象カテゴリ種類の項目のうちテストカテゴリを選択し、テスト項目を自動で発生する装置が開示されている。
特許文献３では、テスト条件の異なる複数のテスト項目、テスト結果を取得し、対象テストデバイスを分類する手段が開示されている。
特許文献４では、テスト項目をグループ化し、まずは代表のテスト項目を実施し、次に代表以外のテスト項目を実施する手法が開示されている。

特開平０５−２９７０６５号公報 特開平０９−８９９８９号公報 特開２００１−２４２２１５号公報 特開平０９−２９８２２１号公報

上記特許文献１では、テスト実行順番を組み換える自動テスト装置が開示されている。
しかしながら、欠陥発生頻度とテスト実行時間からテスト順番を組み換えるのみであり、欠陥発生のテストカテゴリを検出するということは実施できない。
上記特許文献２では、複数のテスト対象カテゴリからテストしたいテストカテゴリを選択し、テスト項目を自動で発生する装置が開示されている。
しかしながら、欠陥発生頻度からテスト対象カテゴリを自動で検出することはできない。
上記特許文献３では、テスト条件の異なる複数のテスト項目、テスト結果を取得し、対象テストデバイスを分類する手段が提案されている。
しかしながら、テスト項目とテスト結果からテスト対象デバイスを分類するのみであり、テスト項目数の表示までは行っていない。
上記特許文献４では、テスト項目をグループ化し、まずは代表のテスト項目を実施し、次に代表以外のテスト項目を実施する手法が提案されている。
しかしながらテスト順番を検討するのみで、テスト実施結果を分析することは行っていないという点で不十分である。

この発明は、上記のような事情に鑑みたものであり、効率的にテストの計画値を生成することを主な目的とする。

本発明に係る情報処理装置は、
複数のテストカテゴリについて、テストカテゴリごとに、テストで消化すべきテスト項目数の標準値と、テストで発見されると推測される欠陥数の標準値とが、所定の単位作業量当たりの値として示される標準値情報を記憶する記憶部と、
テスト対象の開発プロジェクトでの作業量が示されるプロジェクト情報を入力する入力部と、
前記プロジェクト情報に示される作業量と前記標準値情報に示されるテストカテゴリごとのテスト項目数の標準値とを用いて、テストカテゴリごとに、前記開発プロジェクトのテストで消化すべきテスト項目の数をテスト項目数計画値として算出し、前記プロジェクト情報に示される作業量と前記標準値情報に示されるテストカテゴリごとの欠陥数の標準値とを用いて、テストカテゴリごとに、前記開発プロジェクトのテストで発見されると推測される欠陥の数を欠陥数計画値として算出する計画値算出部とを有することを特徴とする。

本発明では、テストカテゴリごとに、テストで消化すべきテスト項目数の標準値と、テストで発見されると推測される欠陥数の標準値とが、所定の単位作業量当たりの値として示される。
そして、開発プロジェクトでの作業量とテストカテゴリごとのテスト項目数の標準値とを用いて、テストカテゴリごとに、開発プロジェクトのテストで消化すべきテスト項目の数を算出し、また、開発プロジェクトでの作業量とテストカテゴリごとの欠陥数の標準値とを用いて、テストカテゴリごとに、開発プロジェクトのテストで発見されると推測される欠陥の数を算出する。
このため、効率的にテストの計画値を生成することができ、テスト時間の短縮化を図ることができる。

実施の形態１に係るテスト分析支援装置の概念を示す図。 実施の形態１に係るテーブルの例を示す図。 実施の形態１に係るテスト分析支援装置の処理の概要を示す図。 実施の形態１に係るテスト分析支援装置の構成例を示す図。 実施の形態１に係る初期登録およびテスト計画作成フローを示すフローチャート図。 実施の形態１に係るテスト計画変更フローを示すフローチャート図。 実施の形態１に係る計画テスト項目消化線等を示す図。 実施の形態１に係るテスト分析支援装置のハードウェア構成例を示す図。 従来のテスト分析支援装置の概念を示す図。

実施の形態１．
本実施の形態では、テストカテゴリ毎に、テスト実施状況および欠陥の検出状況から、追加で試験すべきテストカテゴリとテストカテゴリ毎の試験項目数を算出するテスト分析支援装置を説明する。
本実施の形態では、増大するテスト時間を短縮するため、テストをカテゴリに分類し、カテゴリ毎のテスト実施項目とカテゴリ毎の欠陥数から、追加でテストすべきカテゴリと項目数を算出し、最短時間で残存欠陥数を最小化するテスト分析支援装置を説明する。

本実施の形態に係るテスト分析支援装置は、テストカテゴリ、テスト項目数、テスト順番、欠陥数などの項目を有する標準テスト計画テーブルと、実体テスト計画テーブル、テスト実績テーブル、開発したソフトウェアソースコードの変更部位及び変更カテゴリを特定する変更部位テーブルを持ち、標準テスト計画テーブル、変更部位テーブルを利用して、実体テスト計画テーブルを作成する。

さらに、テスト実施項目数と欠陥実績数から残存欠陥があるテストカテゴリを判定し、追加で実施する必要があるテストカテゴリ毎の試験項目数を算出し、実体テスト計画テーブルを更新する。

さらに、テスト実施項目数と欠陥実績数から標準テスト計画テーブルの更新を行う。

以下に、本実施の形態に係るテスト分析支援装置を図面に基づいて詳細に説明する。
本実施の形態では、ソフトウェア開発におけるテストを例にして説明を進める。
なお、この実施の形態によりこの発明が限定されるものではない。

図９は、従来のテスト分析支援装置の概念を示す図である。
従来のテスト分析支援装置は、全体のテスト実施項目数と全体の欠陥数の関係をグラフ化し、分析を支援することを行う。
つまり、従来のテスト分析支援装置では、図９に示すように、テストの全体を単位として、未消化のテスト項目の数であるテスト項目残数と、欠陥件数を管理していた。

図１は、本実施の形態に係るテスト分析支援装置の概念を示す図である。
従来は、図９に示すように、テスト全体に対する分析であり、テストカテゴリ毎には分析できなかった。
本実施の形態に係るテスト分析支援装置は、テストカテゴリ（図１の例では、カテゴリＡ、Ｂ、Ｃ）毎にテスト項目数と欠陥件数を表示することで、テストカテゴリ毎の分析を可能にするものである。
テストカテゴリ毎の試験項目数と欠陥数との関係より、追加でテストすべきテストカテゴリや試験項目数を算出する。
ここで、テストカテゴリとは、テスト観点のことであり、正常ケース、異常ケースなどである。

図２は、本実施の形態に係るテスト分析支援装置で用いられる、標準テスト計画テーブル１３、実体テスト計画テーブル１４、テスト実績テーブル１５、変更部位テーブル１６の構成を示す図である。

標準テスト計画テーブル１３は、テストカテゴリ識別１３１と、テスト項目数（標準）１３２と、欠陥数（標準）１３３を備える。
テスト項目数（標準）１３２と欠陥数（標準）１３３は、テストカテゴリ識別１３１毎に設定する。
テスト項目数（標準）１３２は、テストで消化すべきテスト項目数の標準値である。
欠陥数（標準）１３３は、テストで発見されると推測される欠陥数の標準値である。
テスト項目数（標準）１３２と欠陥数（標準）１３３は、所定の単位作業量当たりの値として示される。
例えば、テスト項目数（標準）１３２は、ソースコードライン１０００行当たりに、テスト項目ｘｘ個として定義されている（ｘｘはテスト項目の個数）。
同様に、欠陥数（標準）１３３は、ソースコードライン１０００行当たりに、欠陥ｙｙ件として定義されている（ｙｙは欠陥件数）。
なお、標準テスト計画テーブル１３は、標準値情報の例に相当する。

実体テスト計画テーブル１４は、テストカテゴリ識別１４１と、テスト項目数（計画）１４２と、欠陥数（計画）１４３を備える。
テスト項目数（計画）１４２と、欠陥数（計画）１４３は、テストカテゴリ識別１４１毎に設定する。
テスト項目数（計画）１４２は、開発プロジェクトのテストで消化すべきテスト項目の数（計画値）であり、テスト項目数計画値の例に相当する。
また、欠陥数（計画）１４３は、開発プロジェクトのテストで発見されると推測される欠陥の数（計画値）であり、欠陥数計画値の例に相当する。
テスト項目数（計画）１４２は、（テスト項目数（標準）１３２）×（ソフトウェア開発規模１６２）で算出する。
ソフトウェア開発規模１６２には、テスト対象の開発プロジェクトでの作業量（より具体的にはソースコードライン数）が記述されている。
ソフトウェア開発規模１６２は、プロジェクト情報の例に相当する。
欠陥数（計画）１４３は、（欠陥数（標準）１３３）×（ソフトウェア開発規模１６２）で算出する。

テスト実績テーブル１５は、テストカテゴリ識別１５１、テスト項目数（実績）１５２と、欠陥数（実績）１５３を備える。
テスト項目数（実績）１５２と、欠陥数（実績）１５３は、テストカテゴリ識別１５１毎に設定する。
テスト項目数（実績）１５２には、日ごとの未消化のテスト項目数の実績値（未消化テスト項目数の実績値）が記述されている。
欠陥数（実績）１５３には、日ごとの発見済みの欠陥の数の実績値（欠陥発見数の実績値）が記述されている。

変更部位テーブル１６は、ソフトウェア開発部位１６１と、ソフトウェア開発規模１６２を備える。
ソフトウェア開発規模１６２は、ソフトウェア開発部位１６１毎に設定する。
前述のように、ソフトウェア開発規模１６２には、テスト対象の開発プロジェクトでの作業量（より具体的にはソースコードライン数）が記述されている。

図４は、標準テスト計画テーブル、実体テスト計画テーブル、テスト実績テーブル、変更部位テーブルの関連の概念図である。

本実施の形態に係るテスト分析支援装置は、標準テスト計画テーブル１３において決められたテストカテゴリ識別１３１毎のテスト項目数（標準）１３２と欠陥数（標準）１３３および変更部位テーブル１６のソフトウェア開発部位１６１とソフトウェア開発規模１６２から、実体テスト計画テーブル１４のテストカテゴリ識別１４１に対するテスト項目数（計画）１４２と、欠陥数（計画）１４３を決定する。

また、本実施の形態に係るテスト分析支援装置は、実体テスト計画テーブル１４のテストカテゴリ識別１４１に対するテスト項目数（計画）１４２に基づきテストを実施した結果を、テスト実績テーブル１５のテストカテゴリ識別１５１毎のテスト項目数（実績）１５２と、欠陥数（実績）１５３に記載する。

また、本実施の形態に係るテスト分析支援装置は、テスト実績テーブル１５のテスト項目数（実績）１５２と、欠陥数（実績）１５３と実体テスト計画テーブル１４のテスト項目数（計画）１４２と欠陥数（計画）１４３を比較し、テストカテゴリ毎の計画値と実績値との差異を判定し、実体テスト計画テーブル１４のテスト項目数（計画）１４２と欠陥数（計画）１４３を変更する。
また、テストカテゴリ識別１４１の追加削除を行う。

また、本実施の形態に係るテスト分析支援装置は、テスト実績テーブル１５のテスト項目数（実績）１５２と、欠陥数（実績）１５３と標準テスト計画テーブル１３のテスト項目数（標準）１３２と欠陥数（標準）１３３を比較し、テストカテゴリ毎の標準値と実績値との差異を判定し、標準テスト計画テーブル１３のテスト項目数（標準）１３２と欠陥数（標準）１３３を変更する。
また、テストカテゴリ識別１３１の追加を行う。

図４は、本実施の形態に係るテスト分析支援装置１００の構成例を示す。
なお、テスト分析支援装置１００は情報処理装置の例に相当する。

図３において、入力部１０１は、外部からデータ（コード、テスト計画・結果）を受け付ける。
例えば、入力部１０１は、変更部位テーブル１６に格納されるソフトウェア開発規模１６２をソフトウェア開発部位１６１ごとに入力する。
更に、入力部１０１は、開発プロジェクトのテストが開始された後に、日ごとに、未消化のテスト項目数の実績値と発見された欠陥数の実績値を入力する。

出力部１０２は、外部へデータ（テスト計画・テスト結果）を出力する。
また、ユーザに対するアラームやユーザ操作を行う。

変更点抽出部１０３は、入力データとデータベース１０８に保存されたデータから変更点を抽出し変更部位テーブルに格納する。

比較・更新部１０４は、実体テスト計画テーブル１４とテスト実績テーブル１５とを比較し、実体テスト計画テーブル１４を変更する。
また、比較・更新部１０４は、標準テスト計画テーブル１３とテスト実績テーブル１５とを比較し、標準テスト計画テーブル１３を変更する。
比較・更新部１０４は、計画変更判定部及び標準値変更部の例に相当する。

残存欠陥判定部１０５は、残存欠陥数を予測する。

データ作成部１０６は、標準テスト計画テーブル１３を参照し、実体テスト計画テーブル１４を作成する。
データ作成部１０６は、前述したように、（テスト項目数（標準）１３２）×（ソフトウェア開発規模１６２）によりテスト項目数（計画）１４２を生成し、（欠陥数（標準）１３３）×（ソフトウェア開発規模１６２）により欠陥数（計画）１４３を生成する。
データ作成部１０６は、計画値算出部の例に相当する。

データ転送部１０７は、データ出力部１０２へ実体テスト計画を受け渡す。

データベース１０８は、各種情報を記憶する。
例えば、データベース１０８は、図２に示す標準テスト計画テーブル１３、実体テスト計画テーブル１４、テスト実績テーブル１５、変更部位テーブル１６を記憶する。

次に、本実施の形態に係るテスト分析支援装置１００の動作例を説明する。
図５は、初期登録およびテスト計画作成フローを示す。
また、図６は、テスト計画変更フローを示す。

図５において、入力部１０１が過去のテスト情報（テストカテゴリ識別、テスト項目数、欠陥数）を入力し、データベース１０８に登録する（Ｓ５０１）。

次に、データ作成部１０６が、過去のテスト情報の平均から、テストカテゴリごとに、テスト項目数（標準）１３２及び欠陥数（標準）１３３を計算し、標準テスト計画テーブル１３を生成し、データベース１０８に登録する（Ｓ５０２）。

次に、テストの対象となる開発プロジェクトのソフトウェア部位、ソフトウェア開発規模の情報を入力部１０１が入力し、この情報を、変更部位テーブル１６としてデータベース１０８に登録する（Ｓ５０３）。

次に、データ作成部１０６が、テストの対象となる開発プロジェクトに対するテスト計画を作成する（Ｓ５０４）。
つまり、データ作成部１０６は、テストカテゴリごとに、テスト項目数（計画）１４２と欠陥数（計画）１４３とを算出する。
また、データ作成部１０６は、入力部１０１を介してユーザからテスト期間の情報を取得し、テストカテゴリごとに、算出したテスト項目数（計画）１４２に基づき、未消化のテスト項目数の日ごとの計画値を生成し、また、算出した欠陥数（計画）１４３に基づき、発見済みの欠陥数の日ごとの計画値を生成する。
そして、データ作成部１０６は、テスト項目数（計画）１４２、欠陥数（計画）１４３、未消化のテスト項目数の日ごとの計画値、発見済みの欠陥数の日ごとの計画値を、テストカテゴリ識別１４１とともに、実体テスト計画テーブル１４としてデータベース１０８に登録する。

次に、データ転送部１０７がテスト計画を出力部１０２に転送し、出力部１０２がテスト計画をユーザへ提供する（Ｓ５０５）。
例えば、出力部１０２は、未消化のテスト項目数の日別の計画値、発見済みの欠陥数の日別の計画値をグラフ化してユーザに提示する。
図７の計画テスト項目消化線は、未消化のテスト項目数の日別の計画値を表し、計画欠陥発見数線は、発見済みの欠陥数の日別の計画値を表す。
つまり、図７の計画テスト項目消化線のように未消化のテスト項目数が日ごとに次第に減少し（実施済みのテスト項目数が増加するため）、計画欠陥発見数線のように発見済みの欠陥数が日ごとに次第に増加する（発見された欠陥数の累積であるため）というテスト計画をユーザに提示する。
なお、この段階では、図７中の実績テスト項目消化線、実績欠陥発見数線は生成されておらず、ユーザに提示されない。
実績テスト項目消化線、実績欠陥発見数線については後述する。

次に、図６のフローを説明する。
図６のフローは、テストが開始された後に実施される処理フローである。
図６のフローは、所定の日数間隔で繰り返し実施される。
以下では、図６のフローが毎日、その日のテストの終了後に実施されるものとして説明を行う。

まず、入力部１０１が、その日のテスト実績（テストカテゴリ識別、テスト項目数、欠陥数）を入力し、比較・更新部１０４が、データベース１０８内のテスト実績テーブル１５にテスト実績を登録する（Ｓ６０１）。
テストの初日であれば、データベース１０８内にテスト実績テーブル１５が存在していないので、比較・更新部１０４は新たにテスト実績テーブル１５を生成し、生成したテスト実績テーブル１５にテスト実績を登録する。

次に、比較・更新部１０４は、テスト計画とテスト実績の差異を計算する（Ｓ６０２）。
具体的には、比較・更新部１０４は、毎日のテスト実績から、未消化のテスト項目数の実績値の推移が表される実績テスト項目消化線を生成し、また、欠陥発見数の実績値の推移が表される実績欠陥発見数線を生成する。
そして、比較・更新部１０４は、計画テスト項目消化線と実績テスト項目消化線とを比較し、計画欠陥発見数線と実績テスト項目消化線とを比較する。

次に、比較・更新部１０４は、比較の結果、テスト計画変更の必要性を判定する（Ｓ６０３）。
具体的には、比較・更新部１０４は、ａ＞ｂかつｃ＜ｄならば、テスト計画の変更が必要であると判定する。
ここで、ａは計画テスト項目消化線の傾きであり、ｂは実績テスト項目消化線の傾きであり、ｃは計画欠陥発見数線の傾きであり、ｄは実績欠陥発見数線の傾きである。
つまり、計画を下回るテスト項目数しか消化できておらず、また、計画を上回る欠陥数を発見している場合には、テスト計画の変更が必要であると判定する。
例えば、図７に示す状態では、テスト計画の変更が必要である。

次に、比較・更新部１０４は、ユーザに対して、計画変更の必要性の判断を確認する（Ｓ６０４）。
例えば、比較・更新部１０４は、出力部１０２を介して、図７に示すようなグラフを表示し、また、ユーザにテスト計画の変更を行うか否かを問い合わせるメッセージを表示する。

ユーザによりテスト計画の変更が指示された場合に、比較・更新部１０４は、テスト計画を変更する（Ｓ６０５）。

具体的には、比較・更新部１０４は、翌日以降の各日の新たな未消化テスト項目数の計画値を、例えば以下の式１で算出する。
Ａｘ’＝Ａｘ−（Ｂ０−Ａ０） 式１
ここで、Ａｘは、ｘにおける未消化テスト項目数の現時点の計画値である。
また、ｘは翌日以降の各日を示す。
図６のフローを実施しているのがテスト３日目であれば、ｘは４日目、５日目・・・最終日の各日である（以下も同様）。
Ａ’ｘは、ｘにおける未消化テスト項目数の変更後の計画値である。
Ａ０は、最新日の未消化テスト項目数の現時点の計画値である。
最新日は、図６のフローを実施している日（例えば、テスト３日目）である（以下も同様）。
Ｂ０は、最新日の未消化テスト項目数の実績値である。

また、比較・更新部１０４は、翌日以降の各日の新たな欠陥発見数の計画値を、例えば以下の式２で算出する。
Ｃｘ’＝Ｃｘ＋（Ｄ０−Ｃ０） 式２
ここで、Ｃｘは、ｘにおける欠陥発見数の現時点の計画値である。
Ｃ’ｘは、ｘにおける欠陥発見数の変更後の計画値である。
Ｃ０は、最新日の欠陥発見数の現時点の計画値である。
Ｄ０は、最新日の欠陥発見数の実績値である。

最後に、比較・更新部１０４は、出力部１０２を介して、変更後のテスト計画をユーザへ提供する（Ｓ６０６）。
例えば、変更後の値を図７のようにグラフ化してユーザに提示する。

また、図６のフローに合わせて、または図６のフローから独立して、比較・更新部１０４は、テスト実績を反映させて、標準テスト計画テーブル１３のテスト項目数（標準）１３２と欠陥数（標準）１３３を変更してもよい。
テスト項目数（標準）１３２と欠陥数（標準）１３３の変更は、テスト実績の値を含めて新たに平均値をとることで実現できる。

以上のように、本実施の形態に係るテスト分析支援装置は、標準テスト計画テーブルから当該テスト計画を作成し、テスト実施結果により標準テスト計画テーブルを更新し、より精度の高いテスト計画作成を支援すると共に、当該テストにおける残存欠陥数を予測し、追加テストを最適に計画することを支援することで、テスト期間を短縮する際に有用である。
特に、テスト完了までに期間が短い場合に、特に有用である。

また、本実施の形態によれば、ソフトウェア開発における試験実施項目数をソフトウェアカテゴリ毎に検討でき、かつテスト実施結果を元に、残存欠陥数を予測し、最適な追加のテストを実施することが可能となる。
さらに、テストカテゴリ毎の標準テスト計画をテスト実績から更新することで、より精度の高いテスト計画を作成できるようになるという効果を奏する。

以上、本実施の形態では、変更箇所と標準テスト計画から、今回の開発において必要であるテストカテゴリとテストカテゴリ毎のテスト項目数を算出し、テスト計画の作成を支援するテスト分析支援装置を説明した。

また、本実施の形態では、テストの実施状況と欠陥の検出状況を表示し、テストカテゴリ毎に分析を支援することを可能にするテスト分析支援装置を説明した。

また、本実施の形態では、テストカテゴリ毎の試験項目数と欠陥数の関係から、追加でテストすべきテストカテゴリと試験項目数を算出し、追加のテスト計画作成を支援するテスト分析支援装置を説明した。

また、本実施の形態では、テストカテゴリ毎の試験項目数と欠陥数の関係から、標準テスト計画における標準テストカテゴリと標準テストカテゴリ毎のテスト項目数と欠陥数を更新するテスト分析支援装置を説明した。

最後に、本実施の形態に示したテスト分析支援装置１００のハードウェア構成例を図８を参照して説明する。
テスト分析支援装置１００はコンピュータであり、テスト分析支援装置１００の各要素をプログラムで実現することができる。
テスト分析支援装置１００のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。

演算装置９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）である。
外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
データベース１０８は、例えば外部記憶装置９０２により実現される。
主記憶装置９０３は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。
通信装置９０４は、例えばＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）である。
入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。

プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
プログラムは、図１に示す「〜部」として説明している機能を実現するプログラムである。
更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、図１に示す「〜部」の機能を実現するプログラムを実行する。
また、本実施の形態の説明において、「〜の判断」、「〜の判定」、「〜の抽出」、「〜の検知」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の生成」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３にファイルとして記憶されている。
また、暗号鍵・復号鍵や乱数値やパラメータが、主記憶装置９０３にファイルとして記憶されてもよい。

なお、図８の構成は、あくまでもテスト分析支援装置１００のハードウェア構成の一例を示すものであり、テスト分析支援装置１００のハードウェア構成は図８に記載の構成に限らず、他の構成であってもよい。

また、本実施の形態に示す手順により、本発明に係る情報処理方法を実現可能である。

１００ テスト分析支援装置、１０１ 入力部、１０２ 出力部、１０３ 変更点抽出部、１０４ 比較・更新部、１０５ 残存欠陥判定部、１０６ データ作成部、１０７ データ転送部、１０８ データベース。

Claims (11)

1. 複数のテストカテゴリについて、テストカテゴリごとに、テストで消化すべきテスト項目数の標準値と、テストで発見されると推測される欠陥数の標準値とが、所定の単位作業量当たりの値として示される標準値情報を記憶する記憶部と、
   テスト対象の開発プロジェクトでの作業量が示されるプロジェクト情報を入力する入力部と、
   前記プロジェクト情報に示される作業量と前記標準値情報に示されるテストカテゴリごとのテスト項目数の標準値とを用いて、テストカテゴリごとに、前記開発プロジェクトのテストで消化すべきテスト項目の数をテスト項目数計画値として算出し、前記プロジェクト情報に示される作業量と前記標準値情報に示されるテストカテゴリごとの欠陥数の標準値とを用いて、テストカテゴリごとに、前記開発プロジェクトのテストで発見されると推測される欠陥の数を欠陥数計画値として算出する計画値算出部とを有することを特徴とする情報処理装置。
2. 前記計画値算出部は、
   テストカテゴリごとに、算出したテスト項目数計画値に基づき、未消化のテスト項目の数である未消化テスト項目数の日ごとの計画値を生成し、
   テストカテゴリごとに、算出した欠陥数計画値に基づき、発見済みの欠陥の数である欠陥発見数の日ごとの計画値を生成し、
   前記情報処理装置は、更に、
   前記開発プロジェクトのテストが開始された後に、日ごとに、未消化テスト項目数の実績値と欠陥発見数の実績値とを更新し、
   テストカテゴリごとに、日ごとの未消化テスト項目数の実績値と欠陥発見数の実績値とに基づき、未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更するか否かを判定する計画変更判定部を有することを特徴とする請求項１に記載の情報処理装置。
3. 前記計画変更判定部は、
   テストカテゴリごとに、
   未消化テスト項目数の日ごとの計画値の推移が表される計画テスト項目消化線と、未消化テスト項目数の日ごとの実績値の推移が表される実績テスト項目消化線との比較の結果と、
   欠陥発見数の日ごとの計画値の推移が表される計画欠陥発見数線と、欠陥発見数の日ごとの実績値の推移が表される実績欠陥発見数線との比較の結果とに基づき、
   未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更するか否かを判定することを特徴とする請求項２に記載の情報処理装置。
4. 前記計画変更判定部は、
   前記計画テスト項目消化線の傾きよりも前記実績テスト項目消化線の傾きが小さく、前記計画欠陥発見数線の傾きよりも前記実績欠陥発見数線の傾きが大きいテストカテゴリに対して、未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更すると決定することを特徴とする請求項３に記載の情報処理装置。
5. 前記計画変更判定部は、
   所定の日数の間隔で、テストカテゴリごとに、未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更するか否かを判定し、
   特定の日に、未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更すると決定した場合に、
   未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更すると決定したテストカテゴリに対して、
   前記特定の日の未消化テスト項目数の実績値から前記特定の日の未消化テスト項目数の計画値を減算し、前記特定の日の翌日以降の各日の未消化テスト項目数の計画値を、各日の未消化テスト項目数の計画値から減算値を減算して得られる値に変更し、
   前記特定の日の欠陥発見数の実績値から前記特定の日の欠陥発見数の計画値を減算し、前記特定の日の翌日以降の各日の欠陥発見数の計画値を、各日の欠陥発見数の計画値から減算値を加算して得られる値に変更することを特徴とする請求項４に記載の情報処理装置。
6. 前記計画変更判定部は、
   未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更したテストカテゴリに対して、更に未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更することを特徴とする請求項２〜５のいずれかに記載の情報処理装置。
7. 前記計画変更判定部は、
   特定の日に、未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更したテストカテゴリに対して、更に未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更すると決定した場合に、
   当該テストカテゴリに対して、
   前記特定の日の未消化テスト項目数の実績値から前記特定の日の未消化テスト項目数の計画値を減算し、前記特定の日の翌日以降の各日の未消化テスト項目数の計画値を、各日の未消化テスト項目数の直近の変更の後の計画値から減算値を減算して得られる値に変更し、
   前記特定の日の欠陥発見数の実績値から前記特定の日の欠陥発見数の計画値を減算し、前記特定の日の翌日以降の各日の欠陥発見数の計画値を、各日の欠陥発見数の直近の変更の後の計画値から減算値を加算して得られる値に変更することを特徴とする請求項６に記載の情報処理装置。
8. 前記計画変更判定部は、
   日ごとに、未消化テスト項目数の日ごとの計画値と欠陥発見数の日ごとの計画値とを変更するか否かを判定することを特徴とする請求項２〜７のいずれかに記載の情報処理装置。
9. 前記情報処理装置は、更に、
   前記開発プロジェクトのテストで消化されたテスト項目数に基づき、前記標準値情報のテスト項目数の標準値を変更し、
   前記開発プロジェクトのテストで発見された欠陥数に基づき、前記標準値情報の欠陥数の標準値を変更する標準値変更部を有することを特徴とする請求項１〜８のいずれかに記載の情報処理装置。
10. 複数のテストカテゴリについて、テストカテゴリごとに、テストで消化すべきテスト項目数の標準値と、テストで発見されると推測される欠陥数の標準値とが、所定の単位作業量当たりの値として示される標準値情報、を記憶するコンピュータが行う情報処理方法であって、
    前記コンピュータが、テスト対象の開発プロジェクトでの作業量が示されるプロジェクト情報を入力する入力ステップと、
    前記コンピュータが、前記プロジェクト情報に示される作業量と前記標準値情報に示されるテストカテゴリごとのテスト項目数の標準値とを用いて、テストカテゴリごとに、前記開発プロジェクトのテストで消化すべきテスト項目の数をテスト項目数計画値として算出し、前記プロジェクト情報に示される作業量と前記標準値情報に示されるテストカテゴリごとの欠陥数の標準値とを用いて、テストカテゴリごとに、前記開発プロジェクトのテストで発見されると推測される欠陥の数を欠陥数計画値として算出する計画値算出ステップとを有することを特徴とする情報処理方法。
11. コンピュータを、請求項１に記載された情報処理装置として機能させることを特徴とするプログラム。

Images