JP5537599B2 - Version upgrade management method in business system - Google Patents

Version upgrade management method in business system Download PDF

Info

Publication number
JP5537599B2
JP5537599B2 JP2012102029A JP2012102029A JP5537599B2 JP 5537599 B2 JP5537599 B2 JP 5537599B2 JP 2012102029 A JP2012102029 A JP 2012102029A JP 2012102029 A JP2012102029 A JP 2012102029A JP 5537599 B2 JP5537599 B2 JP 5537599B2
Authority
JP
Japan
Prior art keywords
test
module
function
environment
management method
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2012102029A
Other languages
Japanese (ja)
Other versions
JP2013228970A (en
Inventor
▲クン▼ 柳
晋 上野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2012102029A priority Critical patent/JP5537599B2/en
Publication of JP2013228970A publication Critical patent/JP2013228970A/en
Application granted granted Critical
Publication of JP5537599B2 publication Critical patent/JP5537599B2/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、いわゆる業務システムについて、バージョンアップ（世代変更）を行うための技術に関する。その中でも、特に、バージョンアップの際のテストを行う技術に関する。   The present invention relates to a technique for performing version upgrade (generation change) for a so-called business system. In particular, it relates to a technique for performing a test at the time of version upgrade.

現在、様々な業務がいわゆるコンピュータシステムで実行されている。このような場合、新たな機能追加や修正によるバージョンアップが必要になってくる。そして、バージョンアップにおいては、追加、修正する機能のテストを行う必要がある。   Currently, various tasks are executed by so-called computer systems. In such a case, it is necessary to upgrade the version by adding or correcting a new function. In the version upgrade, it is necessary to test the function to be added or modified.

このテストに関する従来技術として、特許文献１が存在する。特許文献１では、複数のコンポーネントから構成されるソフトウェアの効率的なバージョンアップ手法を提供することを目的としている。この目的を達成するために、特許文献１には、受け付けたバージョンアップ対象のコンポーネント及びそのテストプログラムをコンポーネント管理サーバ取得し、このテストプログラム等をについて、テストに失敗した場合、関連する未実行コンポーネントが存在すれば、当該コンポーネントをバージョンアップ対象のコンポーネントと共にバージョンアップを行うものである。   As a prior art relating to this test, there is Patent Document 1. Patent Document 1 aims to provide an efficient version upgrade method for software composed of a plurality of components. In order to achieve this object, Patent Document 1 discloses that a component management server obtains a received upgrade target component and its test program, and if this test program etc. fails in the test, the related unexecuted component Is present, the component is upgraded together with the component to be upgraded.

特開2008-269128号公報JP 2008-269128 A

ここで、業務システムにおいては、一度のバージョンアップにおいて、複数の機能が追加ないし変更されることがある。このような場合、あるモジュールについて、複数回のテストが実行されることがある。さらに、複数回のテストを行った場合、それぞれでモジュールに修正が入ることがあり得る。   Here, in the business system, a plurality of functions may be added or changed in one version upgrade. In such a case, a plurality of tests may be executed for a certain module. Furthermore, if a test is performed a plurality of times, the module may be modified in each case.

しかし、特許文献１においては、複数回のテストが行われることは考慮されておらず、これを如何に自動的に行うかについては開示されていない。   However, Patent Document 1 does not consider that a plurality of tests are performed, and does not disclose how to perform this test automatically.

上記の課題を解決するために、本発明では、テスト対象機能毎に、関連する各モジュールの変更の有無をタイムスタンプを用いて判断し、その結果を確定フラグとして記録することで管理するものである。この中でも特に、本発明では、テスト対象機能を識別する変更機能ＩＤを、変更があったモジュールと対応付けて記憶することで、変更後のモジュールのうち有効なものを特定することが好適である。つまり、修正があったモジュールかを、マスタテーブルに格納された変更機能ＩＤで判断し、当該変更機能ＩＤと該当するテスト機能を用いて、有効なモジュール（修正済みの）を特定するものである。   In order to solve the above problems, in the present invention, for each function to be tested, whether or not each related module is changed is determined using a time stamp, and the result is recorded as a confirmation flag for management. is there. Among these, particularly, in the present invention, it is preferable to specify a valid function among the modules after the change by storing the change function ID for identifying the function to be tested in association with the module that has been changed. . That is, it is determined whether the module has been modified based on the changed function ID stored in the master table, and the effective module (modified) is specified using the changed function ID and the corresponding test function. .

本発明によれば、複数のモジュールについて、複数回のテストがなされた場合でも容易に管理することが可能になる。   According to the present invention, it is possible to easily manage a plurality of modules even when a plurality of tests are performed.

本発明の一実施形態の対象の概念を示す図。The figure which shows the concept of the object of one Embodiment of this invention. 本発明の一実施形態での処理フローの概要を示す図。The figure which shows the outline | summary of the processing flow in one Embodiment of this invention. 本発明の一実施形態で用いられるシステム構成を示す図。The figure which shows the system configuration | structure used by one Embodiment of this invention. 本発明の一実施形態でのフローチャート。The flowchart in one Embodiment of this invention. 本発明の一実施形態でのテスト対策機能管理表。The test countermeasure function management table | surface in one Embodiment of this invention. 本発明の一実施形態でのマスタ管理表。The master management table in one Embodiment of this invention. 本発明の一実施形態での修正モジュール管理表。The correction module management table | surface in one Embodiment of this invention.

本発明の一実施形態について、図面を用いて説明する。
図１は、本実施形態の対象の概念を示す図である。まず、保守環境（サーバ）と現行(稼動)環境が存在し、それぞれがネットワークを介して接続される。そして、保守環境でテスト、修正された内容が、ネットワークを介して、現行環境に展開され、旧バージョンと差換えられる。その流れを図２を用いて説明する。まず、（１）バージョンアップの際、元になるもの（本例では、第４世代）のプログラム等をテスト環境に移行する。（２）そして、テスト環境で、新機能に対応するモジュールの追加、修正およびテストを実行する。（３）テスト完了した後、リリース候補モジュールとして、リリース管理サーバに格納する。また、これらと並行して、（４）現行環境では、ミラー領域を作成し、現行のプログラム等をミラー領域に同期させる。そして、（２）のテスト完了した場合、（５）ネットワークを介してテストが完了したプログラム等を、現行環境にネットワークを介して展開し、また、（６）新世代として(本例では第５世代)、保守環境に保存する。また、現行環境では、（５）で展開されたものを現行環境に登録し、さらなる動作確認を行う。この結果、不具合が生じた場合には、（７）バージョンアップ前に戻す、つまり、ミラー領域に格納されている内容を現行領域に上書きする。また、不具合が生じなかった場合には、ミラー領域の旧バージョン（本例では第四世代）を削除する。 An embodiment of the present invention will be described with reference to the drawings.
FIG. 1 is a diagram showing the concept of the object of this embodiment. First, a maintenance environment (server) and a current (operational) environment exist, and each is connected via a network. Then, the contents tested and corrected in the maintenance environment are deployed to the current environment via the network and replaced with the old version. The flow will be described with reference to FIG. First, at the time of (1) version upgrade, the original program (fourth generation in this example) is transferred to the test environment. (2) Then, add, modify, and test a module corresponding to the new function in the test environment. (3) After the test is completed, it is stored in the release management server as a release candidate module. In parallel with these, (4) in the current environment, a mirror area is created and the current program or the like is synchronized with the mirror area. When the test of (2) is completed, (5) the program or the like that has been tested via the network is deployed to the current environment via the network, and (6) as a new generation (in this example, the fifth Generation) and save it in the maintenance environment. Also, in the current environment, the one developed in (5) is registered in the current environment, and further operation confirmation is performed. As a result, if a problem occurs, (7) the previous version is restored, that is, the contents stored in the mirror area are overwritten on the current area. Also, if no malfunction occurs, the old version of the mirror area (fourth generation in this example) is deleted.

以下、この詳細を図面を用いて説明する。図３に本実施形態で用いるシステムの構成図を示す。本システムは、テスト環境であるユーザＡテストサーバ３１０１と、テスト要員がテスト等を実行させるための入力を行うテスト端末３１１１、３１１２と、ネットワークを介して接続される現行環境である現行サーバ３３０１、３３０２とこれを利用するための各利用者端末で構成される。そして、リリース管理サーバ３００では、図５から７に示す各種テーブルを保持している。また、マスタ管理サーバ３２０、現行サーバ３３０１、３３０２においては、業務実行するプログラム等が格納されている。また、各端末においても、いわゆるコンピュータで実現されるものであり、このプログラムに従って、CPUのような演算装置が各種処理を実行する（各サーバについても同様）。また、リリース管理サーバ３００は、複数の現行サーバ(システム)とネットワークを介して接続され、それぞれ保守（バージョンアップ）が可能になっている。   The details will be described below with reference to the drawings. FIG. 3 shows a configuration diagram of a system used in this embodiment. This system includes a user A test server 3101 that is a test environment, test terminals 3111 and 3112 that input test personnel to perform a test and the like, a current server 3301 that is a current environment connected via a network, 3302 and each user terminal for using this. The release management server 300 holds various tables shown in FIGS. The master management server 320 and the current servers 3301 and 3302 store business execution programs and the like. Each terminal is also realized by a so-called computer, and an arithmetic device such as a CPU executes various processes according to this program (the same applies to each server). Further, the release management server 300 is connected to a plurality of current servers (systems) via a network, and maintenance (version upgrade) is possible for each.

なお、本実施形態が対象とするバージョンアップにおいては、そのテストを「変更機能」単位で行う。これは、追加、修正されるモジュールやこれらと関連して動作する既存のモジュールを単位とし、これら関連は、変更表と呼ばれる対応表で対応付けられている。この変更表は、紙媒体であっても構わないし、電子媒体に電子的に記録されていもよい。   In the version upgrade targeted by the present embodiment, the test is performed in units of “change function”. This is based on modules to be added or modified and existing modules that operate in association with these, and these associations are associated with each other in a correspondence table called a change table. The change table may be a paper medium or electronically recorded on an electronic medium.

以下、図４のフローチャートを用いて、本実施形態の処理の詳細を説明する。本実施形態では、上述した（２）の処理を行うものである。   The details of the processing of this embodiment will be described below using the flowchart of FIG. In the present embodiment, the above-described process (2) is performed.

ステップ４０１において、リリース管理サーバ３００は、各テスト機能について、当該テストでテストされるモジュールを、テスト対策機能管理表（図５）に登録する。これは、テスト要員からの入力に従ってテスト端末３１１１や３１１２からの入力ないし図示しない設計情報に従って、構成欄に「既存」「新規」を登録するものである。ここで、「既存」とはバージョンアップ前から存在するモジュールを示し、「新規」とは、バージョンアップにより追加、ないし、修正されるモジュールを示す。そして、該当するテスト対策機能において、テストされるモジュールに記録される。これは、上述した変更表に基づいて特定され、テスト要員の入力に従い、あるいは電子的なデータに従って特定される。   In step 401, the release management server 300 registers, for each test function, a module to be tested in the test in the test countermeasure function management table (FIG. 5). In this case, “existing” and “new” are registered in the configuration column in accordance with input from the test terminals 3111 and 3112 according to input from the test personnel or design information not shown. Here, “existing” indicates a module existing before the version upgrade, and “new” indicates a module that is added or modified by the version upgrade. Then, it is recorded in the module to be tested in the corresponding test countermeasure function. This is specified on the basis of the change table described above, and is specified according to the input of test personnel or according to electronic data.

次に、ステップ４０２において、リリース管理サーバ３００は、テストすべきテスト対策機能を特定する。これは、テスト要員からの入力に従ってテスト端末３１１１や３１１２からの入力に従って、特定すればよい。   Next, in step 402, the release management server 300 specifies the test countermeasure function to be tested. This may be specified according to the input from the test terminals 3111 and 3112 according to the input from the test personnel.

次に、ステップ４０３において、特定されたテスト対策機能について、変更機能ＩＤの有無を判断する。変更機能ＩＤは、他のテスト対策機能でのテストにおいて、修正されたこと、および修正されたテストのテスト対策機能を識別するものである。このために、まず、テスト対策機能管理表（図５）を用いて、特定されたテスト対策機能でテストされるモジュールを、構成欄から判断する。そして、テストされるモジュールについて、マスタテーブル（図６）の対応するレコードに変更機能ＩＤ６００７が登録されているかを判断する。この結果、登録されている場合は、ステップ４０４に進む。登録されていない場合には、ステップ４０５に進む。   Next, in step 403, it is determined whether or not there is a change function ID for the specified test countermeasure function. The change function ID identifies that the test was corrected in another test countermeasure function and the test countermeasure function of the corrected test. For this purpose, first, using the test countermeasure function management table (FIG. 5), the module to be tested with the specified test countermeasure function is determined from the configuration column. Then, it is determined whether the changed function ID 6007 is registered in the corresponding record of the master table (FIG. 6) for the module to be tested. As a result, if registered, the process proceeds to step 404. If not registered, the process proceeds to step 405.

ステップ４０４において、リリース管理サーバ３００は、変更機能ＩＤを用いて、該当する実体モジュールを特定する。これは、以下の処理により実現される。まず、変更機能ＩＤを抽出する。そして、抽出された変更機能ＩＤをキーに、対象となるモジュールが修正(変更)されたテスト対象機能と、モジュールを識別する識別子を特定する。そして、これらをキーに、図７に示す修正プログラム管理表を検索し、最新（ないし有効な）モジュールを特定する。そして、このモジュールを含む当該テスト対象機能に必要なモジュールを、テスト環境に投入する。   In step 404, the release management server 300 identifies the corresponding entity module using the change function ID. This is realized by the following processing. First, the change function ID is extracted. Then, using the extracted changed function ID as a key, a test target function in which the target module is corrected (changed) and an identifier for identifying the module are specified. Then, using these as keys, the correction program management table shown in FIG. 7 is searched to identify the latest (or valid) module. Then, a module necessary for the test target function including this module is input to the test environment.

また、ステップ４０５において、ステップ４０３で変更機能ＩＤ６００７が登録されていないと判断された場合、マスタをユーザテスト環境２２０に投入する。   If it is determined in step 405 that the changed function ID 6007 is not registered in step 403, the master is input to the user test environment 220.

ステップ４０６では、新規作成・修正されるモジュールをテスト環境に投入する。以降、ステップ４０４、４０５、４０６において投入したモジュールを対象に、そのモジュールのプロパティ日付情報をテスト対策機能管理表（図５）の初期タイムスタンプ５００７に登録する。そして、ステップ４０８に機能毎テストの実施を開始する。   In step 406, a module to be newly created / modified is input to the test environment. Thereafter, the property date information of the module input in steps 404, 405, and 406 is registered in the initial time stamp 5007 of the test countermeasure function management table (FIG. 5). Then, in step 408, the execution of each function test is started.

ステップ４０９では、テスト実施した回数をカウントし、テスト対策機能管理表（図５）のテスト回数５００６に登録する。テスト回数はプログラムを変更し、テスト実施した回数を示す指標である。   In step 409, the number of times the test has been performed is counted and registered in the test count 5006 of the test countermeasure function management table (FIG. 5). The number of tests is an index indicating the number of times the program is changed and the test is performed.

次に、ステップ４１０において、テスト対象の機能について、テストを行い、テスト要員が実行結果をテスト用のチェックリストに記載する想定結果と比較し、不具合の有無を判断する。不具合が生じた場合、プログラムの変更を実施した後に、ステップ４０８に戻り、テストを再実施する。不具合がない場合、ステップ４１２に進む。   Next, in step 410, the function to be tested is tested, and the test personnel compares the execution result with the assumed result described in the test checklist to determine whether there is a defect. If a problem occurs, after changing the program, the process returns to step 408 and the test is performed again. If there is no defect, the process proceeds to step 412.

ステップ４１２において、該当機能の各構成モジュールのプロパティ日付情報をテスト対策機能管理表（図５）の最終タイムスタンプ５００８に登録する。   In step 412, the property date information of each component module of the corresponding function is registered in the last time stamp 5008 of the test countermeasure function management table (FIG. 5).

次に、ステップ４１３で、テスト対策機能管理表（図５）の構成欄５００４からモジュールの新規か既存を判断し、新規であれば、ステップ４１５に進み、テスト対策機能管理表（図５）の確定フラグ５００９が有効であることを示すように記録する。   Next, in step 413, it is determined whether the module is new or existing from the configuration column 5004 of the test countermeasure function management table (FIG. 5). If it is new, the process proceeds to step 415, and the test countermeasure function management table (FIG. 5). Record to indicate that the confirmation flag 5009 is valid.

また、バージョンアップ前から存在する既存のモジュールであれば、ステップ４１４に進み、最終タイムスタンプ５００８と初期タイムスタンプ５００７が等しいかを判断する。異なった場合には、確定フラグ５００９を有効にする。確定フラグを有効にしたモジュールは変更されたことを意味している。ステップ４１６において、修正されたモジュールの情報を修正モジュール管理表（図７）に登録する。ここで、テスト対象機能を区別するための変更機能IDとモジュールIDのほか、モジュールの実体をテスト環境以外のリリース管理サーバ上の保存先に格納しておくディレクトリの情報を記憶する。   If it is an existing module existing before the version upgrade, the process proceeds to step 414 to determine whether the final time stamp 5008 and the initial time stamp 5007 are equal. If they are different, the confirmation flag 5009 is validated. This means that the module for which the confirmation flag is valid has been changed. In step 416, the corrected module information is registered in the corrected module management table (FIG. 7). Here, in addition to the change function ID and module ID for distinguishing the test target function, information on the directory in which the module entity is stored in the save destination on the release management server other than the test environment is stored.

次に、ステップ４１７にマスタ管理表（図６）の変更機能ID６００７を登録する。そして、ステップ４１８にテスト要員がテスト項目を消化し、テスト完了を判断する。完了した場合、該当機能のテストにおいて、リリース構成を確定する（ステップ４１９）。   Next, in step 417, the change function ID 6007 of the master management table (FIG. 6) is registered. In step 418, the test personnel digests the test items and determines the completion of the test. If completed, the release configuration is confirmed in the test of the corresponding function (step 419).

なお、上述した実施形態では、変更機能ＩＤを用いたが、これを省略したものも本発明の一態様に含まれる。つまり、ステップ４０３やステップ４１６、４１７を省略し、構成（既存、新規）、確定フラグおよびタイムスタンプを用いた処理であってもよい。   In the above-described embodiment, the changed function ID is used. However, one in which this is omitted is also included in one aspect of the present invention. That is, the processing using the configuration (existing or new), the confirmation flag, and the time stamp may be performed by omitting Step 403 and Steps 416 and 417.

１００…保守環境、１１０…ネットワーク、１２０、１３０…ユーザ稼動環境、
２００…マスタ管理サーバ、２００１〜２００５…マスタ世代構成、２１０…リリース管理サーバ、２２０…ユーザテストサーバ、２３０…ネットワーク、２４０…ユーザ稼動サーバ、３００…リリース管理サーバ、３１０…テストサーバ、３２０…マスタ管理サーバ、３１１１、３１１２…テスト用端末、３３０１…ユーザＡ現用サーバ、３３０２ユーザＡ待機サーバ、３４０…ユーザＡ監視サーバ、３５０１、３５０２…ユーザ利用者端末、４０１〜４１９…フローチャート、５００１〜５００９…テスト対策機能管理表項目、
６００１〜６００７…マスタ管理表項目、７００１〜７００３…修正モジュール管理表項目 100: maintenance environment, 110: network, 120, 130: user operating environment,
200 ... Master management server, 2001-2005 ... Master generation configuration, 210 ... Release management server, 220 ... User test server, 230 ... Network, 240 ... User operation server, 300 ... Release management server, 310 ... Test server, 320 ... Master Management server, 3111, 3112 ... test terminal, 3301 ... user A active server, 3302 user A standby server, 340 ... user A monitoring server, 3501, 3502 ... user user terminal, 401 to 419 ... flowchart, 5001 to 5009 ... Test countermeasure function management table items,
6001 to 6007 ... Master management table item, 7001 to 7003 ... Correction module management table item

Claims (2)

複数のモジュールで構成される業務システムにおけるバージョンアップ管理方法であって、前記業務システムのバージョンアップにおけるテスト単位であり、複数のモジュールがテストされるテスト環境を複数格納したテストサーバおよび前記テスト環境を利用してテストを行う利用者が利用するテスト端末と接続されたリリース管理サーバが以下の処理を実行するバージョンアップ管理方法において、
前記テスト端末からの入力に従って、前記テストサーバに格納された複数のテスト環境から、テスト対象環境を特定し、
特定されたテスト対象環境について、当該テスト対象環境のテストによりモジュールに修正があったかを、当該リリース管理サーバが有するテスト対策機能管理テーブルに格納された当該モジュールに対するタイムスタンプに基づいて判断し、
当該判断の結果、修正があった場合、前記テスト対象環境を管理するテスト対象環境表の該当するモジュールについて、前記テスト対策機能管理テーブルへ修正があった旨の示す確定フラグを記録することを特徴とする業務システムにおけるバージョンアップ管理方法。 An upgrade management method for a business system composed of a plurality of modules, comprising: a test server that stores a plurality of test environments in which a plurality of modules are tested, which is a test unit for upgrading the business system; In the upgrade management method in which the release management server connected to the test terminal used by the user who performs the test performs the following processing :
According to an input from the test terminal, a test target environment is specified from a plurality of test environments stored in the test server ,
For the identified test target environment, determine whether the module has been modified by the test of the test target environment based on the time stamp for the module stored in the test countermeasure function management table of the release management server ,
The result of the determination, if there is a modification, with the appropriate module under test environment table for managing the test environment, to record the confirmation flag indicated by the fact that are modified to the test preparation function management table A version upgrade management method in a featured business system. 請求項１に記載のバージョンアップ管理方法において、
前記リリース管理サーバは、
当該リリース管理サーバが有する各モジュールに関する情報を格納するマスタテーブルに対して、前記テストにおいてモジュールに修正があった場合、当該モジュールに対応付けて修正されたテストのテスト対象環境を識別する変更機能ＩＤを登録し、
特定された前記テスト対象環境においてテストされるモジュールの修正の有無および修正が施されたテスト対象環境を、前記変更機能ＩＤを用いて判断し、
修正があると判断された場合、修正が施されたテスト対象環境と当該モジュールを識別する識別子に基づいて、有効なモジュールを特定し、
特定されたモジュールを含む情報を用いて前記テストを実行することを特徴とする業務システムにおけるバージョンアップ管理方法。 The upgrade management method according to claim 1,
The release management server
A change function ID for identifying a test target environment of a test that is corrected in association with the module when the module is corrected in the test with respect to the master table that stores information about each module of the release management server And register
The presence or absence of modification of the module to be tested in the identified test target environment and the test target environment in which the correction has been performed are determined using the change function ID,
If it is determined that there is a fix, identify a valid module based on the test environment under which the correction was made and an identifier identifying the module,
A version upgrade management method in a business system, wherein the test is executed using information including a specified module.
JP2012102029A 2012-04-27 2012-04-27 Version upgrade management method in business system Expired - Fee Related JP5537599B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012102029A JP5537599B2 (en) 2012-04-27 2012-04-27 Version upgrade management method in business system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012102029A JP5537599B2 (en) 2012-04-27 2012-04-27 Version upgrade management method in business system

Publications (2)

Publication Number Publication Date
JP2013228970A JP2013228970A (en) 2013-11-07
JP5537599B2 true JP5537599B2 (en) 2014-07-02

Family

ID=49676510

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012102029A Expired - Fee Related JP5537599B2 (en) 2012-04-27 2012-04-27 Version upgrade management method in business system

Country Status (1)

Country Link
JP (1) JP5537599B2 (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104572728B (en) * 2013-10-22 2018-06-01 阿里巴巴集团控股有限公司 For checking the description of the text of control and the method and apparatus of the uniformity of function
CN108089986A (en) * 2017-12-18 2018-05-29 江苏木盟智能科技有限公司 A kind of version updating test method and system based on robot
CN109726132B (en) * 2019-01-03 2021-03-23 京东方科技集团股份有限公司 Software testing method and software testing automatic management system
JP7218233B2 (en) 2019-04-11 2023-02-06 株式会社日立製作所 Program operation system, program operation method

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05233234A (en) * 1992-02-24 1993-09-10 Nec Corp Release processing system for software package
JP3292347B2 (en) * 1994-06-03 2002-06-17 日本電信電話株式会社 Terminal file management method
JP2009169724A (en) * 2008-01-17 2009-07-30 Nomura Research Institute Ltd Maintenance support device
JP4769826B2 (en) * 2008-02-14 2011-09-07 富士通株式会社 Level down detection program, level down detection method, and management program
JP2009295050A (en) * 2008-06-06 2009-12-17 Ntt Data Corp Product management server, product management method and program
JP2010039751A (en) * 2008-08-05 2010-02-18 Fujitsu Ltd Software development system

Also Published As

Publication number Publication date
JP2013228970A (en) 2013-11-07

Similar Documents

Publication Publication Date Title
US10949194B2 (en) Updating dependent services
EP3616066B1 (en) Human-readable, language-independent stack trace summary generation
US10621211B2 (en) Language tag management on international data storage
US9471594B1 (en) Defect remediation within a system
WO2013140608A1 (en) Method and system that assist analysis of event root cause
US9754242B2 (en) Deployment mechanism for non-versioning business process artifacts
JP5537599B2 (en) Version upgrade management method in business system
JP6722528B2 (en) Software development support method and system
JP2010009411A (en) Virtual environment operation support system and virtual environment operation support program
CN111290738A (en) Resource processing method, device and equipment of application program and storage medium
JP2012208752A (en) License management device, license management method, and program
JP6865042B2 (en) Knowledge management equipment, knowledge management methods and computer programs
JP6015750B2 (en) Log collection server, log collection system, and log collection method
US8707307B2 (en) Creating jobs by replacing execution attributes within job definition when a job activation request is received with execution attributes based on predetermined conditions being satisfied
WO2015019488A1 (en) Management system and method for analyzing event by management system
JP2014085951A (en) Source code management system, source code management method, and source code management program
US10503722B2 (en) Log management apparatus and log management method
JP5661505B2 (en) Parallel development management device
CN111192096B (en) Multi-connection electronic invoice management method and device, readable medium and electronic equipment
CN109791484A (en) The enlarging and dismounting of of short duration infrastructure for dynamic Service example deployment
JP2013097716A (en) Information processor, information processing method, and program
JP6369333B2 (en) Software installation determination program, software installation determination method, and software installation determination device
JP5652329B2 (en) Program inspection program, program inspection apparatus, and program inspection method
CN112165512A (en) File publishing method and device, terminal equipment and storage medium
JP2015056082A (en) Failure information collection device, failure information collection method, and failure information collection program

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140221

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140225

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140314

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140401

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140425

R151 Written notification of patent or utility model registration

Ref document number: 5537599

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees