特開 2024-11920 テスト管理プログラム、テスト管理装置およびテスト管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024011920

(43)【公開日】2024-01-25

(54)【発明の名称】テスト管理プログラム、テスト管理装置およびテスト管理方法

(51)【国際特許分類】

   G06F 11/36 20060101AFI20240118BHJP

【ＦＩ】

G06F11/36 188

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2022114272

(22)【出願日】2022-07-15

(71)【出願人】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】田村 易男

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042HH19

5B042HH49

(57)【要約】

【課題】資産をリリースする場合に実施されるテストのスケジュール管理を自動化する。
【解決手段】テスト管理装置１は、運用中の環境とリリース予定環境との改修規模を用いて、リリース予定環境のテストに要する期間を算出し、リリース予定環境のテストに要する期間と、リリース予定環境のリリースの予定時期とに基づいて、リリース予定環境のテストの開始時期を決定し、テストの開始時期に応じて、運用中の環境に対する処理要求を、リリース予定環境に送信することによって、リリース予定環境のテストを実行する。
【選択図】図１

【特許請求の範囲】

【請求項1】

運用中の環境とリリース予定環境との差分を用いて、前記リリース予定環境のテストに要する期間を算出し、
前記リリース予定環境のテストに要する期間と、前記リリース予定環境のリリースの予定時期とに基づいて、前記リリース予定環境のテストの開始時期を決定し、
前記テストの開始時期に応じて、前記運用中の環境に対する処理要求を、前記リリース予定環境に送信することによって、前記リリース予定環境のテストを実行する
処理をコンピュータに実行させることを特徴とするテスト管理プログラム。

【請求項2】

前記テストに要する期間を算出する処理は、前記差分としての改修規模および改修された機能に基づいて、前記リリース予定環境のテストに要する期間を算出する
ことを特徴とする請求項１に記載のテスト管理プログラム。

【請求項3】

前記テストに要する期間を算出する処理は、前記差分としての改修規模、改修された機能および前記改修された機能と連携する機能に基づいて、前記リリース予定環境のテストに要する期間を算出する
ことを特徴とする請求項１に記載のテスト管理プログラム。

【請求項4】

前記改修規模は、改修されたステップ数である
ことを特徴とする請求項２または請求項３に記載のテスト管理プログラム。

【請求項5】

運用中の環境とリリース予定環境との差分を用いて、前記リリース予定環境のテストに要する期間を算出し、
前記リリース予定環境のテストに要する期間と、前記リリース予定環境のリリースの予定時期とに基づいて、前記リリース予定環境のテストの開始時期を決定し、
前記テストの開始時期に応じて、前記運用中の環境に対する処理要求を、前記リリース予定環境に送信することによって、前記リリース予定環境のテストを実行する、
処理を実行する制御部を含むことを特徴とするテスト管理装置。

【請求項6】

運用中の環境とリリース予定環境との差分を用いて、前記リリース予定環境のテストに要する期間を算出し、
前記リリース予定環境のテストに要する期間と、前記リリース予定環境のリリースの予定時期とに基づいて、前記リリース予定環境のテストの開始時期を決定し、
前記テストの開始時期に応じて、前記運用中の環境に対する処理要求を、前記リリース予定環境に送信することによって、前記リリース予定環境のテストを実行する
処理をコンピュータが実行することを特徴とするテスト管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、テスト管理プログラムなどに関する。

【背景技術】

【0002】

資産をリリースする際、資産についてのテストが実施される。

【0003】

資産についてのテストについて、テストのスケジューリングを更新する技術が開示されている（例えば、特許文献１参照）。かかる技術では、試験計画システムが、試験開始日付、試験終了日付を含む計画基本情報を取得して、試験期間日数、１日当たりの試験実施件数を算出し、試験項目の試験計画表を更新する。

【0004】

また、資産についてのテストについて、テストカバレッジ分布、テスト開始日、テスト持続時間などのパラメータをもとにテスト実行計画を生成する技術が開示されている（例えば、特許文献２参照）。

【0005】

また、資産についてのテストについて、リリース予定日が決まっている場合、資産をテストする管理者が、リリース予定日に合わせて資産のテストの開始日を決定し、決定したテストの開始日から資産のテストを実行する。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２００２－１３２５３９号公報

【特許文献2】特表２０１３－５０７６７５号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

しかしながら、資産をリリースする場合、リリース予定日に合わせてテストの開始日を決定して資産のテストを実行しなければならないが、人手でテストのスケジュールを管理するのは煩雑であるという問題がある。

【0008】

例えば、試験のスケジューリングを更新する技術では、予め定められた試験開始日付、試験終了日付などを用いて、試験項目の実施日を決定するが、リリース予定日に合わせてテストの開始日を決定するものではない。また、テスト実行計画を生成する技術では、予め定められたテスト開始日をパラメータとして、テスト実行計画を生成するが、リリース予定日に合わせてテストの開始日を決定するものではない。

【0009】

また、資産をテストする管理者が、リリース予定日に合わせて資産のテストの開始日を決定し、決定したテストの開始日から資産のテストを実行するが、人手でテストのスケジュールを管理するのは煩雑である。

【0010】

本発明は、１つの側面では、資産をリリースする場合に実施されるテストのスケジュール管理を自動化することを目的とする。

【課題を解決するための手段】

【0011】

１つの態様では、テスト管理プログラムは、運用中の環境とリリース予定環境との差分を用いて、前記リリース予定環境のテストに要する期間を算出し、前記リリース予定環境のテストに要する期間と、前記リリース予定環境のリリースの予定時期とに基づいて、前記リリース予定環境のテストの開始時期を決定し、前記テストの開始時期に応じて、前記リリース予定環境を本番稼働領域に配備し、前記運用中の環境に対する処理要求を、前記リリース予定環境に送信することによって、前記リリース予定環境のテストを実行する、処理をコンピュータに実行させる。

【発明の効果】

【0012】

１実施態様によれば、資産をリリースする場合に実施されるテストのスケジュール管理を自動化することができる。

【図面の簡単な説明】

【0013】

【図1】図１は、実施例に係るテスト管理装置の機能構成の一例を示すブロック図である。

【図2】図２は、実施例に係るリリース予約テーブルの一例を示す図である。

【図3】図３は、実施例に係るイベント確認テーブルの一例を示す図である。

【図4】図４は、実施例に係るテスト期間の算出処理の一例を示す図である。

【図5A】図５Ａは、実施例に係るテスト管理処理の流れの一例を示す図（１）である。

【図5B】図５Ｂは、実施例に係るテスト管理処理の流れの一例を示す図（２）である。

【図5C】図５Ｃは、実施例に係るテスト管理処理の流れの一例を示す図（３）である。

【図6】図６は、実施例に係る決定処理のフローチャートの一例を示す図である。

【図7】図７は、実施例に係る実行処理のフローチャートの一例を示す図である。

【図8】図８は、テスト管理プログラムを実行するコンピュータの一例を示す図である。

【発明を実施するための形態】

【0014】

以下に、本願の開示するテスト管理プログラム、テスト管理装置およびテスト管理方法の実施例を図面に基づいて詳細に説明する。なお、本発明は、実施例により限定されるものではない。

【実施例0015】

［テスト管理装置の構成］
図１は、実施例に係るテスト管理装置の機能構成の一例を示すブロック図である。図１に示すテスト管理装置１は、新たにリリースする資産の稼働確認に係るテストのスケジュールを管理する。ここでいう資産とは、例えば、サーバ上で動作する業務に関するソフトウェアのことをいう。資産には、複数業務のソフトウェアが１または複数存在していても良いし、単数業務のソフトウェアが存在していても良い。資産のリリースは、機能が追加、変更または削除されたソフトウェアに置き換えることをいい、バージョンアップを含む。

【0016】

テスト管理装置１は、制御部１０と、記憶部２０とを有する。制御部１０は、算出部１１と、決定部１２と、実行部１３とを有する。記憶部２０は、リリース予約テーブル２１と、イベント確認テーブル２２と、テスト管理支援テーブル２３とを有する。なお、算出部１１、決定部１２および実行部１３は、制御部の一例である。

【0017】

リリース予約テーブル２１は、リリース対象の資産のリリース予定日を予約するために、リリース対象の資産に対応付けてリリース予定日を記憶する。なお、リリース予約テーブル２１は、例えば、リリース業務を行うベンダによって事前に登録される。

【0018】

ここで、リリース予約テーブル２１の一例を、図２を参照して説明する。図２は、実施例に係るリリース予約テーブルの一例を示す図である。図２に示すように、リリース予約テーブル２１は、資産と、予定日とを対応付けて記憶する。ここでいう資産とは、資産を一意に表す識別子のことをいう。予定日は、資産をリリースするリリース予定日を示す。一例として、資産が「Ｂ」である場合に、予定日として「ｘｘ／ｘｘ」が記憶されている。

【0019】

図１に戻って、イベント確認テーブル２２は、稼働確認のイベントに対応付けて確認結果を記憶する。ここでいう稼働確認のイベントとは、リリース対象の資産の稼働確認が終了した際に発行されるイベントのことをいう。なお、イベント確認テーブル２２は、後述する実行部１３によって登録される。

【0020】

ここで、イベント確認テーブル２２の一例を、図３を参照して説明する。図３は、実施例に係るイベント確認テーブルの一例を示す図である。図３に示すように、イベント確認テーブル２２は、イベントと、結果とを対応付けて記憶する。イベントは、稼働確認のイベントを一意に識別する識別子であり、稼働確認に係るテストを実行するサーバからテスト終了時に発行される。結果は、稼働確認に係るテストの実行結果を示す。結果の一例として、正常終了であることを示す「ＯＫ」、異常終了であることを示す「ＮＧ」が挙げられる。なお、１つの資産について、イベントは、１つだけとは限らず、複数個の場合もある。

【0021】

一例として、イベントが「Ｂ－１」である場合に、結果として「ＯＫ」が記憶されている。

【0022】

図１に戻って、テスト管理支援テーブル２３は、テスト管理を支援するために用いられる情報を記憶する。例えば、テスト管理支援テーブル２３は、リリース対象の資産の稼働確認に係るテストに要する期間を算出するために用いられる情報を記憶する。なお、テスト管理支援テーブル２３の一例は、後述する。

【0023】

図１に戻って、算出部１１は、運用中の環境とリリース予定環境との差分を用いて、リリース予定環境のテストに要する期間を算出する。例えば、算出部１１は、稼働領域で運用中の資産とリリース予約領域に配備された資産との改修規模を用いて、リリース予約領域に配備された資産のテストに要する期間を算出する。一例として、算出部１１は、改修規模および改修された機能を入力し、テスト管理支援テーブル２３を参照してリリース予約領域に配備された資産のテストに要する期間を算出する。別の例として、算出部１１は、改修規模、改修された機能に加えて、改修された機能に連携する機能を入力し、テスト管理支援テーブル２３を参照してリリース予約領域に配備された資産のテストに要する期間を算出する。なお、算出部１１が行うテストに要する期間の算出方法は、これらに限定されるものではない。

【0024】

決定部１２は、リリース予定環境のテストに要する期間と、リリース予定環境のリリースの予定時期とに基づいて、リリース予定環境のテストの開始時期を決定する。例えば、決定部１２は、リリース予約テーブル２１を参照して、リリース予定環境に配備された資産に対応するリリース予定日を取得する。決定部１２は、取得したリリース予定日から、算出部１１によって算出されたテストに要する期間を差し引いて得られる日付を、テストの開始時期として決定する。そして、決定部１２は、決定したテストの開始時期を記憶部２０に保持する。

【0025】

実行部１３は、テストの開始時期に応じて、リリース予定環境のテストを実行する。例えば、実行部１３は、決定部１２によって決定されたテストの開始時期のタイミングで、リリース予約領域に配備された資産に対して、稼働確認のテストを実行するために、運用中の環境に対する処理要求をテスト実行要求として送信する。また、実行部１３は、リリース予約領域に配備された資産から、稼働確認のイベントを受信すると、イベントに含まれる稼働確認結果をイベント確認テーブル２２に格納する。

【0026】

ここで、実施例に係るテスト期間の算出処理について、図４を参照して説明する。図４は、実施例に係るテスト期間の算出処理の一例を示す図である。図４では、テスト管理支援テーブル２３に、標準機能テスト期間テーブル２３ａおよび機能管理テーブル２３ｂが含まれる。なお、各テーブルに記載される数値は、一例であって、これに限定されるものではない。

【0027】

標準機能テスト期間テーブル２３ａは、開発ステップに対するテスト期間であって機能をテストする際の標準的なテスト期間を記憶する。一例として、差分の開発ステップが「１００」である場合には、標準機能テスト期間として「２」が記憶されている。差分の開発ステップが「８００」である場合には、標準機能テスト期間として「１０」が記憶されている。なお、標準機能テスト期間テーブル２３ａは、予め生成されていれば良いし、適宜変更される。標準機能テスト期間の単位は、例えば、日数であるが、時間であっても良いし、期間に関する重みであっても良い。ここでは、日数であるとして説明する。

【0028】

機能管理テーブル２３ｂは、機能と連携先の機能がある場合の標準的なテスト期間を記憶する。一例として、資産としての機能が「Ｋ１」である場合には、総ステップ数として「３０００」、資産としての連携先機能として「Ｋ３，Ｋ４」、標準連携テスト期間として「３」が記憶されている。なお、機能管理テーブル２３ｂは、予め生成されていれば良いし、適宜変更される。標準連携テスト期間の単位は、標準機能テスト期間の単位と同じであれば良い。

【0029】

標準機能テスト期間テーブル２３ａおよび機能管理テーブル２３ｂを用いて、算出部１１は、稼働領域で運用中の資産Ａとリリース予約領域に配備された資産Ｂとの改修規模（差分）から、資産Ｂのテストに要する期間（テスト期間と同義）を算出する。ここでは、資産Ａに含まれる機能Ｋ１が改修され、改修規模（差分）は８００ステップであるとする。

【0030】

このような状況の下、算出部１１は、改修規模（差分）および改修された機能を入力し、テスト管理支援テーブル２３を参照してリリース予約領域に配備された資産Ｂのテスト期間を算出する。ここでは、改修規模（差分）は「８００」である。改修された機能は「Ｋ１」である。算出部１１は、標準機能テスト期間テーブル２３ａから、差分「８００」に対応する標準機能テスト期間として「１０」を取得する。そして、算出部１１は、機能管理テーブル２３ｂから、改修された機能「Ｋ１」に対応する標準連携テスト期間を「３」として取得する。そして、算出部１１は、取得した「１０」と「３」とを加算し、加算して得られた「１３」をテスト期間として算出する。その後、決定部１２は、資産Ｂのテスト期間と、資産Ｂのリリース予定時期とに基づいて、資産Ｂのテストの開始時期を決定する。一例として、資産Ｂのリリース予定時期が「ＸＸ／ＸＸ」である場合には、法定休日および法定外休日を除く日について、「ＸＸ／ＸＸ」から「１３」を差し引いて得られる日がテストの開始時期と決定される。

【0031】

なお、図４では、算出部１１が、改修規模（差分）および改修された機能から資産Ｂのテスト期間を算出すると説明した。しかしながら、算出部１１は、これに限定されず、例えば、改修規模（差分）、改修された機能に加えて、改修された機能に連携する機能から資産Ｂのテスト期間を算出しても良い。一例として、改修規模（差分）が改修機能の総ステップの半分以上である場合には、改修機能と連携する連携先機能と正しく連携できない場合がある。かかる場合には、算出部１１は、改修規模（差分）、改修された機能に加えて、改修された機能に連携する機能から資産Ｂのテスト期間を算出しても良い。ここでは、算出部１１は、機能「Ｋ１」が改修された場合、「１３」に加えて、連携先機能「Ｋ３」に対応する標準連携テスト期間「２」および連携先機能「Ｋ４」に対応する標準連携テスト期間「８」を加算しても良い。

【0032】

図５Ａ～図５Ｃは、実施例に係るテスト管理処理の流れの一例を示す図である。

【0033】

図５Ａは、リリース準備の段階である。エンドユーザＵ０は、通常通り、本番稼働領域の資産Ａで通常業務を実施している。通常業務は、負荷分散装置を介して本番サーバ＃１または本番サーバ＃２で実施される。負荷分散装置は、通常業務に係るリクエストを、利用可能な本番サーバに配信する。

【0034】

リリース業務を行うベンダＶ０は、リリース予定の資産Ｂのリリース予定を事前にテスト管理装置１のリリース予約テーブル２１に格納する（＜１＞）。そして、ベンダＶ０は、本番サーバのリリース予約領域にリリース予定の資産Ｂを配備する（＜２＞）。

【0035】

図５Ｂは、リリース作業の段階である。リリース作業は自動で行われる。テスト管理装置１では、算出部１１が、例えばテスト管理者からテスト管理要求を受け付けると、資産Ａと資産Ｂの差分（改修規模）を用いて、資産Ｂのテスト（稼働確認）に要する期間を算出する（＜３＞）。

【0036】

次に、テスト管理装置１では、決定部１２が、資産Ｂのテスト（稼働確認）に要する期間と、リリース予約テーブル２１に記憶されたリリースの予定日とに基づいて、資産Ｂのテストの開始日を決定し、記憶部２０に保持する。そして、実行部１３は、テストの開始日になると、資産Ｂに対してテストの実行要求を送信して、資産Ｂの稼働確認を実行する（＜４＞）。なお、決定部１２は、所定のスケジューラにテストの開始日を登録し、実行部１３は、スケジューラによってテストの開始日が検知されると、資産Ｂに対してテストの実行要求を送信しても良い。

【0037】

この後、テスト管理装置１では、実行部１３は、資産Ｂから稼働確認のイベントを受信すると、イベント確認テーブル２２に確認結果を格納する（＜５＞）。そして、リリース予約監視シェルが常時監視し、確認結果がすべてＯＫであり、リリースの予定日となった場合に、資産Ｂを本番稼働領域へリリースする（＜６＞）。

【0038】

図５Ｃは、リリース後の段階である。エンドユーザＵ０は、リリース後の資産Ｂで業務を実施する。リリース業務を行うベンダＶ０は、次回のリリースが決定した場合に、再度リリース予定をテスト管理装置１のリリース予約テーブル２１に格納する。

【0039】

このようにして、テスト管理装置１は、資産をリリースする場合に実施されるテストのスケジュール管理を自動化することができる。

【0040】

ここで、算出部１１および決定部１２によって行われる決定処理のフローチャートについて、図６を参照して説明する。図６は、実施例に係る決定処理のフローチャートの一例を示す図である。

【0041】

決定処理は、テスト管理要求があったか否かを判定する（ステップＳ１１）。テスト管理要求がなかったと判定した場合には（ステップＳ１１；Ｎｏ）、決定処理は、テスト管理要求があるまで、判定処理を繰り返す。

【0042】

一方、テスト管理要求があったと判定した場合には（ステップＳ１１；Ｙｅｓ）、決定処理は、改修規模によりテストに要する期間を算出する（ステップＳ１２）。例えば、決定処理は、稼働領域で運用中の資産とリリース予約領域に配備された資産との改修規模（差分）を取得する。そして、決定処理は、取得した差分および改修された機能を入力し、テスト管理支援テーブル２３を参照してリリース予約領域に配備された資産のテストに要する期間を算出する。

【0043】

そして、決定処理は、算出されたテストに要する期間と、リリース予約テーブル２１に記憶されたリリース予定日とからテスト開始日を決定する（ステップＳ１３）。そして、決定処理は、決定したテスト開始日を記憶部２０に保持する（ステップＳ１４）。そして、決定処理は、プロセスを終了する。

【0044】

次に、実行部１３によって行われる実行処理のフローチャートについて、図７を参照して説明する。図７は、実施例に係る実行処理のフローチャートの一例を示す図である。なお、リリース予定の資産がリリース予定環境に配備されているものとする。

【0045】

実行処理は、テスト開始日になったか否かを判定する（ステップＳ２１）。テスト開始日になっていないと判定した場合には（ステップＳ２１；Ｎｏ）、実行処理は、テスト開始日になるまで、判定処理を繰り返す。

【0046】

一方、テスト開始日になったと判定した場合には（ステップＳ２１；Ｙｅｓ）、実行処理は、テスト実行要求をリリース予定環境に送信する（ステップＳ２２）。

【0047】

この後、実行処理は、稼働確認のイベントを受信したか否かを判定する（ステップＳ２３）。稼働確認のイベントを受信していないと判定した場合には（ステップＳ２３；Ｎｏ）、実行処理は、稼働確認のイベントを受信するまで、判定処理を繰り返す。

【0048】

一方、稼働確認のイベントを受信したと判定した場合には（ステップＳ２３；Ｙｅｓ）、実行処理は、稼働確認結果をイベント確認テーブル２２に格納する（ステップＳ２４）。そして、実行処理は、プロセスを終了する。

【0049】

［実施例の効果］
このようにして、上記実施例では、テスト管理装置１は、運用中の環境とリリース予定環境との差分を用いて、リリース予定環境のテストに要する期間を算出する。テスト管理装置１は、リリース予定環境のテストに要する期間と、リリース予定環境のリリースの予定時期とに基づいて、リリース予定環境のテストの開始時期を決定する。テスト管理装置１は、テストの開始時期に応じて、運用中の環境に対する処理要求を、リリース予定環境に送信することによって、リリース予定環境のテストを実行する。かかる構成によれば、テスト管理装置１は、資産をリリースする場合に実施されるテストのスケジュール管理を自動化することができる。

【0050】

また、上記実施例では、テスト管理装置１は、差分としての改修規模および改修された機能に基づいて、リリース予定環境のテストに要する期間を算出する。かかる構成によれば、テスト管理装置１は、改修規模および改修された機能に応じたテスト期間を自動的に算出できる。

【0051】

また、上記実施例では、テスト管理装置１は、差分としての改修規模、改修された機能および改修された機能と連携する機能に基づいて、リリース予定環境のテストに要する期間を算出する。かかる構成によれば、テスト管理装置１は、改修規模、改修された機能に加えて、改修された機能と連携する機能を用いることで、リリース予定環境のテスト期間をさらに精度良く算出できる。

【0052】

また、上記実施例では、テスト管理装置１は、改修されたステップ数および改修された機能に基づいて、リリース予定環境のテストに要する期間を算出する。かかる構成によれば、テスト管理装置１は、改修されたステップ数および改修された機能に応じたテスト期間を自動的に算出できる。

【0053】

［その他］
なお、上記実施例では、ベンダが、本番サーバのリリース予約領域にリリース予定の資産を配備すると説明した。しかしながら、テスト管理装置１の実行部１３が、決定部１２によって決定されたテストの開始時期に応じて、リリース予定の資産を本番サーバのリリース予約領域に配備しても良い。そして、実行部１３は、リリース予約領域に配備された資産に対して、運用中の環境に対する処理要求をテスト実行要求として送信すれば良い。

【0054】

また、図示したテスト管理装置１の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、算出部１１を、テスト管理要求を受け付ける受付部と、リリース予定の資産のテスト期間を算出する算出部とに分散しても良い。また、算出部１１と、決定部１２とを１つの部として統合しても良い。また、記憶部２０をテスト管理装置１の外部装置としてネットワーク経由で接続するようにしても良い。

【0055】

また、上記実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１に示したテスト管理装置１と同様の機能を実現する監視プログラムを実行するコンピュータの一例を説明する。図８は、テスト管理プログラムを実行するコンピュータの一例を示す図である。

【0056】

図８に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ（Central Processing Unit）２０３と、ユーザからのデータの入力を受け付ける入力装置２１５と、表示装置２０９とを有する。また、コンピュータ２００は、記憶媒体からプログラムなどを読取るドライブ装置２１３と、ネットワークを介して他のコンピュータとの間でデータの授受を行う通信Ｉ／Ｆ（Interface）２１７とを有する。また、コンピュータ２００は、各種情報を一時記憶するメモリ２０１と、ＨＤＤ（Hard Disk Drive）２０５を有する。そして、メモリ２０１、ＣＰＵ２０３、ＨＤＤ２０５、表示装置２０９、ドライブ装置２１３、入力装置２１５、通信Ｉ／Ｆ２１７は、バス２１９で接続されている。

【0057】

ドライブ装置２１３は、例えばリムーバブルディスク２１１用の装置である。ＨＤＤ２０５は、テスト管理プログラム２０５ａおよびテスト管理処理関連情報２０５ｂを記憶する。通信Ｉ／Ｆ２１７は、ネットワークと装置内部とのインターフェースを司り、他のコンピュータからのデータの入出力を制御する。通信Ｉ／Ｆ２１７には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

【0058】

表示装置２０９は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する表示装置である。表示装置２０９は、例えば、液晶ディスプレイや有機ＥＬ（Electroluminescence）ディスプレイなどを採用することができる。

【0059】

ＣＰＵ２０３は、テスト管理プログラム２０５ａを読み出して、メモリ２０１に展開し、プロセスとして実行する。かかるプロセスはテスト管理装置１の各機能部に対応する。テスト管理処理関連情報２０５ｂは、リリース予約テーブル２１、イベント確認テーブル２２およびテスト管理支援テーブル２３などに対応する。そして、例えばリムーバブルディスク２１１が、テスト管理プログラム２０５ａなどの各情報を記憶する。

【0060】

なお、テスト管理プログラム２０５ａについては、必ずしも最初からＨＤＤ２０５に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に当該プログラムを記憶させておく。そして、コンピュータ２００がこれらからテスト管理プログラム２０５ａを読み出して実行するようにしても良い。

【符号の説明】

【0061】

１ テスト管理装置
１０ 制御部
１１ 算出部
１２ 決定部
１３ 実行部
２０ 記憶部
２１ リリース予約テーブル
２２ イベント確認テーブル
２３ テスト管理支援テーブル

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図6】

【図7】

【図8】