JP5101447B2

JP5101447B2 - Test support system

Info

Publication number: JP5101447B2
Application number: JP2008252053A
Authority: JP
Inventors: 勇人高畠; 拓治溝口; 佑和田; 裕渡邊
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2008-09-30
Filing date: 2008-09-30
Publication date: 2012-12-19
Anticipated expiration: 2028-09-30
Also published as: JP2010086108A

Description

この発明はテスト支援システムに係り、特に、複数のクライアントとサーバを通信ネットワークで接続したオンラインシステムの全体動作を検証するオンラインテストを支援する技術に関する。 The present invention relates to a test support system, and more particularly to a technique for supporting an online test for verifying the overall operation of an online system in which a plurality of clients and servers are connected by a communication network.

複数のクライアントとサーバを通信ネットワークで接続したオンラインシステムを通じて、クライアントに対して様々なサービスを提供する機会が増えてきている。
図１７は、このようなオンラインシステムの一例を示すシステム構成図であり、オンラインシステム80は、Webブラウザプログラムを搭載したクライアント12と、PL（Presentation Logic）サーバ14と、複数のBL（Business Logic）サーバ16（第１のBLサーバ16a〜第３のBLサーバ16c）を備えている。クライアント12−PLサーバ14間、及びPLサーバ14−BLサーバ16間は、通信ネットワークを介して接続されている。 Opportunities to provide various services to clients are increasing through an online system in which a plurality of clients and servers are connected via a communication network.
FIG. 17 is a system configuration diagram showing an example of such an online system. The online system 80 includes a client 12 equipped with a Web browser program, a PL (Presentation Logic) server 14, and a plurality of BLs (Business Logic). A server 16 (first BL server 16a to third BL server 16c) is provided. The client 12 and the PL server 14 and the PL server 14 and the BL server 16 are connected via a communication network.

PLサーバ14は、クライアント12からのリクエストデータ30を受け付けた後、担当のBLサーバ16に入力データを送信して処理を依頼すると共に、BLサーバ16から返された処理結果データ32をクライアントに送信するフロントエンドサーバとして機能する。
このためPLサーバ14は、画面制御部20と、ディスパッチエンジン21と、コネクタ22を備えている。 After receiving the request data 30 from the client 12, the PL server 14 sends input data to the responsible BL server 16 to request processing, and sends the processing result data 32 returned from the BL server 16 to the client. Functions as a front-end server.
Therefore, the PL server 14 includes a screen control unit 20, a dispatch engine 21, and a connector 22.

画面制御部20は、画面遷移定義ＤＢ23を参照し、クライアント12に対して送信する画面（Htmlファイル）を生成する機能を果たす。
またディスパッチエンジン21は、ディスパッチ定義ＤＢ24を参照し、リクエストデータ30に対応したトランザクション及び担当BLサーバを特定する機能を果たす。
またコネクタ22は、各BLサーバ16が要求する固有の形式に入力データを変換すると共に、BLサーバ16から送信された処理結果データをPLサーバ14の標準形式に変換する機能を発揮する。このため、BLサーバ16毎に対応のデータ変換部（第１のBLサーバ用データ変換部22a〜第３のBLサーバ用データ変換部22c）が設けられている。 The screen control unit 20 refers to the screen transition definition DB 23 and functions to generate a screen (Html file) to be transmitted to the client 12.
The dispatch engine 21 refers to the dispatch definition DB 24 and performs a function of specifying a transaction corresponding to the request data 30 and a responsible BL server.
The connector 22 also functions to convert the input data into a specific format required by each BL server 16 and to convert the processing result data transmitted from the BL server 16 into the standard format of the PL server 14. For this reason, a corresponding data conversion unit (first BL server data conversion unit 22a to third BL server data conversion unit 22c) is provided for each BL server 16.

各BLサーバ16は、PLサーバ14から受け取った入力データに基づき、直接または図示しないDBサーバを通じて間接的に管理しているデータベース28に対する検索、更新等の業務処理を実行するバックエンドサーバとして機能する。 Each BL server 16 functions as a back-end server that executes business processing such as search and update on the database 28 that is directly or indirectly managed through a DB server (not shown) based on the input data received from the PL server 14. .

図１７では、クライアント12から送信されたリクエストデータ30に含まれるデータ(1)を第１のBLサーバ16aに送信して所定のトランザクション処理を依頼し、その処理結果データであるデータ(2)を第２のBLサーバ16bに送信して所定のトランザクション処理を依頼し、その処理結果データであるデータ(3)を第３のBLサーバ16cに送信して所定のトランザクション処理を依頼し、その処理結果データであるデータ(4)を最終的な処理結果データ32としてクライアント12に送信するパターンが例示されている。 In FIG. 17, the data (1) included in the request data 30 transmitted from the client 12 is transmitted to the first BL server 16a to request a predetermined transaction processing, and the data (2) which is the processing result data is transmitted. The second BL server 16b is transmitted to request a predetermined transaction processing, and the processing result data (3) is transmitted to the third BL server 16c to request a predetermined transaction processing, and the processing result A pattern in which data (4), which is data, is transmitted to the client 12 as final processing result data 32 is illustrated.

このようなオンラインシステム80を構築するに際しては、各サーバに搭載された個々のアプリケーションプログラムの単体テストや結合テストが必要であることは勿論であるが、サービスのリリース前にはクライアント12と各サーバを通信ネットワークを介して接続した状態で、オンラインシステム全体の動作を検証する必要がある。
また、既存のオンラインシステムに新たな機能を追加したり、バグの修正を行った場合には、他の既存機能に悪影響（デグレード）が生じていないか等を確認する必要性が生じる。 When constructing such an online system 80, it is a matter of course that unit tests and integration tests of individual application programs installed in each server are necessary. However, before the service is released, the client 12 and each server must be connected. It is necessary to verify the operation of the entire online system while being connected via a communication network.
In addition, when a new function is added to an existing online system or a bug is corrected, it is necessary to check whether other existing functions are adversely affected (degrade).

この所謂オンラインテストに際しては、予め準備された複数のシナリオに従ってオペレータがクライアント12から実際の入力を行い、システムによって提供される各種機能が正常に動作するか否かが検証される。そして、何らかの不具合が生じた場合には、少し前の地点に戻って入力をやり直し、問題箇所や原因を突き止める作業が繰り返される。 In this so-called online test, an operator performs actual input from the client 12 in accordance with a plurality of scenarios prepared in advance, and it is verified whether various functions provided by the system operate normally. And when some malfunction arises, it returns to a point before a little, and inputs again, and the operation | work which locates a problem location and a cause is repeated.

大規模なオンラインシステムともなれば、多数のサーバの連携によって処理が実行されるため、必然的にテスト項目が多岐に亘り、また不具合が生じる可能性も増大する。この結果、全項目についての確認を完了するためには、多数のオペレータが何度も同じ入力を繰り返す必要が生じる。
このため、非特許文献１及び２に示すように、オペレータによる入力作業を軽減するためのツールが幾つか提案されている。
QuickTest ProfessionalインターネットURL:http://www.ashisuto.co.jp/prod/qtp/sum/index.html検索日：平成２０年６月４日 SeleniumとはインターネットURL:http://www.thinkit.co.jp/free/article/0705/2/1/検索日：平成２０年６月４日 In the case of a large-scale online system, processing is executed by cooperation of a large number of servers, so that test items are inevitably diversified and the possibility of occurrence of defects increases. As a result, many operators need to repeat the same input many times in order to complete confirmation of all items.
For this reason, as shown in Non-Patent Documents 1 and 2, several tools for reducing the input work by the operator have been proposed.
QuickTest Professional Internet URL: http://www.ashisuto.co.jp/prod/qtp/sum/index.html Search date: June 4, 2008 What is Selenium? Internet URL: http://www.thinkit.co.jp/free/article/0705/2/1/ Search date: June 4, 2008

この種の入力支援ツールは、オペレータによる入力装置31からの入力操作と、表示装置33における表示画面を入力支援用ＤＢ82に逐一記録する機能を備えているため、オペレータが再入力することなく、同じリクエストデータ30をサーバ側に何度でも再投入することができると共に、新たな表示画面と前回の表示画面を比較し、両者が一致するか否かを判定することが可能となる。
また、各BLサーバ16が管理するデータベース28のバックアップを最初に１回だけとっておけば、これをベースにして任意の地点までの入力を再現することにより、当該地点におけるデータベース28の状態を復元することが可能となる。 This type of input support tool has the function of recording the input operation from the input device 31 by the operator and the display screen on the display device 33 in the input support DB 82 one by one, so that the operator does not re-input the same. The request data 30 can be re-entered into the server as many times as possible, and a new display screen can be compared with the previous display screen to determine whether or not they match.
Also, if the database 28 managed by each BL server 16 is backed up only once at the beginning, the state of the database 28 at that point is restored by reproducing the input up to any point based on this backup. It becomes possible to do.

しかしながら、この従来の入力支援ツールはあくまでもクライアント12毎に導入されるアプリケーションプログラムであり、監視の対象となるデータもクライアント12から送信されたリクエストデータ30と、クライアント12が受信した処理結果データ32に限定されているという問題があった。 However, this conventional input support tool is an application program introduced for each client 12, and the data to be monitored is also included in the request data 30 transmitted from the client 12 and the processing result data 32 received by the client 12. There was a problem of being limited.

実際のところ、クライアント12から１つのリクエストデータを受け付けた場合であっても、PLサーバ14を介して複数のBLサーバ16が連携して動作し、最終的な処理結果データがもたらされることが多いにかかわらず、上記の入力支援ツールで捕捉できるのは図１７におけるリクエストデータ30と処理結果データ32に限られ、PLサーバ14内においてトランザクション単位で生起したデータ(1)〜(4)のレベルでデータを保存することは出来なかった。 In fact, even when one request data is received from the client 12, a plurality of BL servers 16 operate in cooperation with each other via the PL server 14 and often result in final processing result data. Regardless of the above, only the request data 30 and the processing result data 32 in FIG. 17 can be captured by the above input support tool, and the level of the data (1) to (4) generated in the transaction unit in the PL server 14. The data could not be saved.

このため、従来の入力支援ツールは、テストの再実施もリクエスト単位に限定され、各BLサーバ16によるトランザクション単位でテストを再実行することもできなかった。この結果、図１８に示すように、あるデータベース28の状態がトランザクションα〜γによって実際には（イ）→（ロ）→（ハ）→（ニ）と順に更新されていく場合であっても、従来の入力支援ツールで再現されるのは（イ）→（ニ）の更新のみであり、途中の（ロ）及び（ハ）の状態を復元することは不可能であった。 For this reason, in the conventional input support tool, the re-execution of the test is limited to the request unit, and the test cannot be re-executed in units of transactions by each BL server 16. As a result, as shown in FIG. 18, even if the state of a certain database 28 is actually updated in the order of (a) → (b) → (c) → (d) by transactions α to γ. The conventional input support tool reproduces only (i) → (d) update, and it is impossible to restore the states (b) and (c).

また、オンラインシステムは一般に、実装言語やフレームワークを異にする複数のサーバ（ホストシステムを含む）を連携させる異機種間連携の仕組みを備えているため、上記のオンラインテストに先立って、例えば図１９に示すように、第１のBLサーバ16a（Ｃ言語に対応したTPモニタを備えたOLTPサーバ）、第２のBLサーバ16b（Java言語に対応したEJBコンテナを備えたEJBサーバ）、第３のBLサーバ16c（COBOL言語に対応したDB/BCシステムを備えたメインフレーム）毎に専用のテスタ70a〜70cを接続し、BLサーバ16単位でIN/OUTのデータの適否を確認するテストも行われている。
このため、BLサーバ16の種類に応じて複数の専用テスタを準備し、それぞれの操作法をオペレータが習得しなければならないという問題があった。 In addition, since online systems generally have a mechanism for inter-model cooperation that links multiple servers (including host systems) with different implementation languages and frameworks, prior to the online test described above, for example, FIG. As shown in FIG. 19, the first BL server 16a (OLTP server with a TP monitor compatible with C language), the second BL server 16b (EJB server with an EJB container compatible with Java language), the third A dedicated tester 70a to 70c is connected to each BL server 16c (mainframe equipped with a DB / BC system that supports the COBOL language), and tests are performed to check the suitability of IN / OUT data for each BL server 16 unit. It has been broken.
For this reason, there is a problem that a plurality of dedicated testers must be prepared according to the type of the BL server 16, and the operator has to learn each operation method.

この発明は従来の上記問題を解決するために案出されたものであり、バックエンドサーバのトランザクション単位で入力データ及び処理結果データの保存が可能であり、その結果、トランザクション単位でのテストの再実行及びデータベースの復元を可能とし、さらにバックエンドサーバの種類が多岐に亘る場合であっても、それぞれの動作をまとめてチェック可能なテスト技術の実現を目的としている。 The present invention has been devised in order to solve the above-described conventional problems, and can store input data and processing result data in units of transactions of the back-end server. The purpose is to realize a test technique that enables execution and restoration of a database, and can check each operation collectively even when there are various types of back-end servers.

上記の目的を達成するため、請求項１に記載したテスト支援システムは、クライアントと、業務処理を実行する複数のバックエンドサーバと、上記クライアントからのリクエストデータを受け取り、担当のバックエンドサーバに必要な入力データを送信して処理を依頼し、その処理結果データをクライアントに送信するフロントエンドサーバとを備えたオンラインシステムにおいて、上記フロントエンドサーバが、オンラインテストの初回ラン時に、(a)クライアントからのリクエストデータを受け付ける処理と、(b)このリクエストデータに含まれるリクエストIDに対応した複数のトランザクション、各トランザクションを担当するバックエンドサーバ及び各トランザクションの順番を特定する処理と、(c)上記リクエストデータに含まれた入力データを、最初のトランザクションを担当するバックエンドサーバが要求するデータ形式に変換した後、当該バックエンドサーバに送信する処理と、(d)データ変換前の入力データを、当該トランザクション及び担当のバックエンドサーバを特定するBEトランザクションIDと関連付けて、テスト用データベースに格納する処理と、(e)上記バックエンドサーバからトランザクションの処理結果データが送信された場合に、これを標準のデータ形式に変換した上で、上記(d)のBEトランザクションIDと関連付けて上記テスト用データベースに格納する処理と、(f)上記(e)の標準のデータ形式に変換された処理結果データを、次のトランザクションを担当するバックエンドサーバが要求するデータ形式に変換した後、当該バックエンドサーバに入力データとして送信する処理と、(g)上記(e)の標準のデータ形式に変換された処理結果データを、当該トランザクション及び担当のバックエンドサーバを特定するBEトランザクションIDと関連付けて、入力データとして上記テスト用データベースに格納する処理と、(h)上記バックエンドサーバからトランザクションの処理結果データが送信された場合に、これを標準のデータ形式に変換した上で、上記(g)のBEトランザクションIDと関連付けて上記テスト用データベースに格納する処理と、(i)上記(f)〜(h)の処理を必要回数繰り返し、最終的な処理結果データが得られた時点で、これをリクエストの処理結果データとして上記クライアントに送信する処理を実行し、同フロントエンドサーバが、オンラインテストの再ラン時には、(j)特定のBEトランザクションIDを指定した再ラン指示データを受け付ける処理と、(k)当該BEトランザクションIDに関連付けられた入力データを上記テスト用データベースから取り出し、当該BEトランザクションIDに基づいて特定されるバックエンドサーバが要求するデータ形式に変換した後、当該バックエンドサーバに送信する処理と、(l)当該バックエンドサーバからトランザクションの処理結果データが送信された場合に、この再ラン結果データを標準のデータ形式に変換した上で、上記(k)のBEトランザクションIDに関連付けて上記テスト用データベースに格納する処理を実行することを特徴としている。
上記の「初回ラン」とは、クライアントから入力されたリクエストデータに基づいて実施される第１回目のオンラインテストを意味している。これに対し「再ラン」とは、データベースに蓄積された初回ラン時のデータに基づいて再演される２回目以降のオンラインテストを意味している。

In order to achieve the above object, the test support system according to claim 1 is necessary for a client, a plurality of back-end servers that execute business processing, and request data from the clients, and is in charge of the back-end server in charge. In an online system equipped with a front-end server that sends processing input data, requests processing, and sends processing result data to the client, the front-end server performs (a) from the client at the first run of the online test. Processing to receive request data of (b), (b) a plurality of transactions corresponding to the request ID included in the request data , a back-end server in charge of each transaction, and processing for identifying the order of each transaction , (c) the request Input included in the data The chromatography data, converts the data format backend server requires in charge of first transaction, a process of transmitting to the back-end server, the input data before the conversion (d) data, the transaction and charge back in association with bE transaction ID that identifies the end server, a process of storing in the test database, when the transaction process result data is transmitted from (e) the back-end server, which was converted to a standard data format In the above process, store in the test database in association with the BE transaction ID in (d) above, and (f) process result data converted to the standard data format in (e) above in charge of the next transaction after converting the data format backend server requires that, as input data to the back-end server A process of transmitting, (g) the standard conversion process result data to the data format (e), in association with BE transaction ID for identifying the back-end server of the transaction and charge, for the test as input data (H) When transaction processing result data is sent from the back-end server, convert it to a standard data format and associate it with the BE transaction ID in (g) above. The process of storing in the test database and (i) the processes of (f) to (h) are repeated as many times as necessary, and when the final process result data is obtained, this is used as the process result data of the request. run the process to be sent to the client, the same front-end server, at the time of re-run of the online test, finger (j) specific bE transaction ID A process of receiving a re-run instruction data, the input data associated with the (k) the BE transaction ID from the database for the test, the data format backend server specified requests based on the BE transaction ID After the conversion, the process to send to the backend server, and (l) When the transaction result data is sent from the backend server, the rerun result data is converted into a standard data format, A process of storing in the test database in association with the BE transaction ID of (k) is performed.
The above-mentioned “first run” means a first online test performed based on request data input from a client. On the other hand, “rerun” means a second or later online test replayed based on the data of the first run accumulated in the database.

また、請求項２に記載したテスト支援システムは、請求項１のシステムであって、さらに上記フロントエンドサーバが、上記テスト用データベースに格納された初回ラン時の処理結果データと再ラン結果データをトランザクション単位で比較し、その結果を出力する機能を備えたことを特徴としている。 The test support system according to claim 2 is the system according to claim 1, wherein the front-end server further stores the processing result data and the rerun result data at the time of the first run stored in the test database. A feature is that it has a function to compare and output the result of each transaction.

この発明に係るテスト支援システムにあっては、オンラインテストの初回ラン時に、フロントエンドサーバによって、各バックエンドサーバへの入力データ及び出力データが、担当のバックエンドサーバ及びトランザクションに関連付けて逐一テスト用データベースに保存される仕組みであるため、オンラインテストの再ラン時にはトランザクション単位で特定のバックエンドサーバを動作させることが可能となり、よりきめ細かくオンラインシステムの正常／異常を検証することができる。この結果、各バックエンドサーバが管理するデータベースの状態も、トランザクション単位で復元することが可能となる。 In the test support system according to the present invention, at the first run of the online test, the front-end server associates the input data and output data to each back-end server with the back-end server in charge and the transaction for testing one by one. Since it is a mechanism stored in the database, it is possible to operate a specific back-end server in units of transactions at the time of online test rerun, and the normality / abnormality of the online system can be verified more finely. As a result, the state of the database managed by each back-end server can be restored in units of transactions.

しかも、バックエンドサーバに送信される入力データは、フロントエンドサーバにおいて事前に当該バックエンドサーバの要求する固有のデータ形式に変換され、またバックエンドサーバから送信された処理結果データは、フロントエンドサーバにおいて標準のデータ形式に変換された上でテスト用データベースに格納される仕組みを備えているため、バックエンドサーバの種類が多岐に亘ってもそれぞれのデータ形式の相違がフロントエンドサーバによって吸収されることとなり、各バックエンドサーバに対して統一的に機能確認テストを実施可能となる。 Moreover, the input data transmitted to the back-end server is converted in advance into a specific data format required by the back-end server in the front-end server, and the processing result data transmitted from the back-end server is converted into the front-end server. Since it is converted to the standard data format and stored in the test database, the difference in the data format is absorbed by the front-end server even if there are various types of back-end servers. As a result, it is possible to perform a function confirmation test uniformly on each back-end server.

図１は、この発明に係るテスト支援システムを含むオンラインシステム10を示しており、Webブラウザプログラムを搭載したクライアント12と、PLサーバ14と、複数のBLサーバ16（第１のBLサーバ16a、第２のBLサーバ16b、第３のBLサーバ16c）と、テスト端末18を備えている。クライアント12−PLサーバ14間、PLサーバ14−BLサーバ16a〜16c間、PLサーバ14−テスト端末18間は、通信ネットワークを介して接続されている。 FIG. 1 shows an online system 10 including a test support system according to the present invention, which includes a client 12 loaded with a Web browser program, a PL server 14, and a plurality of BL servers 16 (first BL server 16a, first A second BL server 16b, a third BL server 16c), and a test terminal 18. The client 12 and the PL server 14, the PL server 14 and the BL servers 16a to 16c, and the PL server 14 and the test terminal 18 are connected via a communication network.

PLサーバ14は、クライアント12からのリクエストデータ30を受け付け、当該リクエストを実現するのに必要なトランザクション及び担当のBLサーバ16を特定した後、担当のBLサーバ16に入力データ（引数）を送信して処理を依頼すると共に、BLサーバ16から返された最終的な処理結果データ32を含む画面をクライアント12に送信する、フロントエンドサーバとして機能する。
このためPLサーバ14は、画面制御部20と、ディスパッチエンジン21と、コネクタ22を備えている。 The PL server 14 receives the request data 30 from the client 12, identifies the transaction necessary for realizing the request and the responsible BL server 16, and then sends input data (argument) to the responsible BL server 16. Function as a front-end server that sends a screen including the final processing result data 32 returned from the BL server 16 to the client 12.
Therefore, the PL server 14 includes a screen control unit 20, a dispatch engine 21, and a connector 22.

画面制御部20は、画面遷移定義ＤＢ23を参照し、クライアント12に対して送信する画面（Htmlファイル）を生成する機能を主として果たす。 The screen control unit 20 mainly functions to generate a screen (Html file) to be transmitted to the client 12 with reference to the screen transition definition DB 23.

ディスパッチエンジン21は、ディスパッチ定義ＤＢ24を参照し、クライアント12からのリクエストに対応したトランザクション及び担当のBLサーバ16を特定する機能を果たす。
また、ディスパッチエンジン21内には、テスト支援部25が生成されており、PLサーバ14のディスク内に設けられたテスト用ＤＢ26を管理している。このテスト支援部25の機能、及びその生成方法については後述する。 The dispatch engine 21 performs a function of referring to the dispatch definition DB 24 and specifying a transaction corresponding to a request from the client 12 and a responsible BL server 16.
A test support unit 25 is generated in the dispatch engine 21 and manages the test DB 26 provided in the disk of the PL server 14. The function of the test support unit 25 and the generation method thereof will be described later.

コネクタ22は、各BLサーバ16が要求する固有のフォーマットに入力データを変換すると共に、BLサーバ16から送信された処理結果データをPLサーバ14の標準形式に変換する機能を発揮する。このため、BLサーバ16a〜16c毎に複数のデータ変換部（第１のBLサーバ用データ変換部22a〜第３のBLサーバ用データ変換部22c）が設けられている。
例えば、第１のBLサーバ16aがＣ言語に対応したTPモニタを搭載している場合、第１のBLサーバ用データ変換部22aは、TPモニタ向けのデータ変換機能を備える。また、第２のBLサーバがEJB（Enterprise Java Beans）コンテナを搭載している場合、第２のBLサーバ用データ変換部22bは、EJBコンテナ向けのデータ変換機能を備える。また、第３のBLサーバ16cがCOBOL言語に対応したDB/BCシステムを搭載している場合、第３のBLサーバ用データ変換部22cは、ホストOS向けのデータ変換機能を備える。 The connector 22 functions to convert input data into a unique format required by each BL server 16 and to convert processing result data transmitted from the BL server 16 into a standard format of the PL server 14. Therefore, a plurality of data converters (first BL server data converter 22a to third BL server data converter 22c) are provided for each of the BL servers 16a to 16c.
For example, when the first BL server 16a is equipped with a TP monitor corresponding to the C language, the first BL server data conversion unit 22a has a data conversion function for the TP monitor. When the second BL server is equipped with an EJB (Enterprise Java Beans) container, the second BL server data conversion unit 22b has a data conversion function for the EJB container. When the third BL server 16c is equipped with a DB / BC system compatible with the COBOL language, the third BL server data conversion unit 22c has a data conversion function for the host OS.

BLサーバ16a〜16cは、PLサーバ14から受け取った入力データに基づき、直接または図示しないDBサーバを通じて間接的に管理しているデータベース28に対する検索、更新等の業務処理を実行するバックエンドサーバとして機能する。 The BL servers 16a to 16c function as back-end servers that execute business processes such as search and update for the database 28 that is directly or indirectly managed through a DB server (not shown) based on input data received from the PL server 14. To do.

つぎに、図２のフローチャートに従い、このオンラインシステム10に対する初回ラン時の処理手順を説明する。
初回ラン時には、まずクライアント12からリクエストデータ30が送信される。例えば、オペレータがテストシナリオに従い、検索画面の入力欄に入力装置31を介して検索文字列を入力すると、クライアント12からPLサーバ14に対して、検索のリクエストID及び検索文字列を含んだリクエストデータ30が送信される。 Next, the processing procedure at the time of the first run for the online system 10 will be described according to the flowchart of FIG.
In the first run, request data 30 is first transmitted from the client 12. For example, when the operator inputs a search character string via the input device 31 in the input field of the search screen according to the test scenario, the request data including the search request ID and the search character string is sent from the client 12 to the PL server 14. 30 is sent.

このリクエストデータ30を受信した画面制御部20は（Ｓ10）、当該リクエストデータ30に含まれているリクエストIDを取得する（Ｓ11）。つぎに画面制御部20は、画面遷移定義ＤＢ23を参照し、当該リクエストIDに対応したPLトランザクションIDを特定する（Ｓ12）。このPLトランザクションIDは、ディスパッチエンジン21に渡される。 The screen control unit 20 that has received the request data 30 (S10) acquires the request ID included in the request data 30 (S11). Next, the screen control unit 20 refers to the screen transition definition DB 23 and identifies the PL transaction ID corresponding to the request ID (S12). This PL transaction ID is passed to the dispatch engine 21.

画面制御部20からPLトランザクションIDを受け取ったディスパッチエンジン21は、このPLトランザクションIDをキーにディスパッチ定義ＤＢ24を検索し、当該PLトランザクションIDに関連付けられたBEトランザクションIDを特定する（Ｓ13）。 Upon receiving the PL transaction ID from the screen control unit 20, the dispatch engine 21 searches the dispatch definition DB 24 using this PL transaction ID as a key, and specifies the BE transaction ID associated with the PL transaction ID (S13).

BEトランザクションIDは、特定のBLサーバに対する特定の処理（トランザクション）を規定するものであり、PLトランザクションIDには１または複数のBEトランザクションIDが処理の順番通りに関連付けられている。このため、ディスパッチエンジン21はPLトランザクションIDに基づいて複数のBEトランザクションIDを特定した時点で、今回のリクエストに応えるために必要なトランザクション、それぞれの担当BLサーバ16、トランザクションの順番等を認識することができる。 The BE transaction ID defines a specific process (transaction) for a specific BL server, and one or more BE transaction IDs are associated with the PL transaction ID in the order of processing. For this reason, when the dispatch engine 21 identifies a plurality of BE transaction IDs based on the PL transaction ID, the dispatch engine 21 recognizes the transactions necessary for responding to the current request, each responsible BL server 16, the order of the transactions, etc. Can do.

ここでは、クライアント12から送信された検索文字列であるデータ(1)を第１のBLサーバ16aに送信して所定の検索処理を依頼し、その処理結果データであるデータ(2)を第２のBLサーバ16bに送信して所定の検索処理を依頼し、その処理結果データであるデータ(3)を第３のBLサーバ16cに送信して所定の検索処理を依頼し、その処理結果データであるデータ(4)を最終的な処理結果データ32としてクライアント12に送信する処理手順が、ディスパッチ定義ＤＢ24に規定されているものと想定する。 Here, data (1), which is a search character string transmitted from the client 12, is transmitted to the first BL server 16a to request a predetermined search process, and data (2), which is the process result data, is stored in the second data. To the BL server 16b and request a predetermined search process, and the data (3) which is the process result data is transmitted to the third BL server 16c to request the predetermined search process, and the process result data It is assumed that a processing procedure for transmitting certain data (4) to the client 12 as final processing result data 32 is defined in the dispatch definition DB 24.

この場合、まずディスパッチエンジン21は、データ(1)をコネクタ22の第１のBLサーバ用データ変換部22aに出力する。第１のBLサーバ用データ変換部22aは、このデータ(1)を第１のBLサーバ16a向けの固有のデータ形式に変換した後、第１のBLサーバ16aに送信する（Ｓ14）。 In this case, the dispatch engine 21 first outputs the data (1) to the first BL server data converter 22 a of the connector 22. The first BL server data conversion unit 22a converts this data (1) into a unique data format for the first BL server 16a, and then transmits it to the first BL server 16a (S14).

これと並行してテスト支援部25が、第１のBLサーバ16a用に変換される前のデータ(1)を捕捉し、検索トランザクション及び第１のBLサーバ16aを特定する情報と関連付けてテスト用ＤＢ26に格納する（Ｓ15）。具体的には、図３に示すように、BEトランザクションID「１１１」のINデータ（＝入力データ）の項目に、データ(1)が登録される。
この場合、BEトランザクションID「１１１」が、検索トランザクション及び第１のBLサーバ16aを特定する情報に該当する。
図示の通り、このテスト用ＤＢ26には、各トランザクション単位でリクエストID、PLトランザクションID、BEトランザクションIDからなる制御情報が格納されている。 In parallel with this, the test support unit 25 captures the data (1) before being converted for the first BL server 16a, and associates it with the information for specifying the search transaction and the first BL server 16a. Store in DB26 (S15). Specifically, as shown in FIG. 3, data (1) is registered in the IN data (= input data) field of BE transaction ID “111”.
In this case, the BE transaction ID “111” corresponds to information specifying the search transaction and the first BL server 16a.
As illustrated, the test DB 26 stores control information including a request ID, a PL transaction ID, and a BE transaction ID for each transaction.

つぎに、第１のBLサーバ16aから処理結果データが返されると（Ｓ16）、第１のBLサーバ用データ変換部22aにおいてPLサーバ14向けの標準形式に変換された後（Ｓ17）、データ(2)としてディスパッチエンジン21に出力される。 Next, when processing result data is returned from the first BL server 16a (S16), the data is converted into the standard format for the PL server 14 in the first BL server data conversion unit 22a (S17), and the data ( It is output to the dispatch engine 21 as 2).

この際、テスト支援部25がデータ(2)を捕捉し、テスト用ＤＢ26に第１のBLサーバ16aからの検索トランザクションの処理結果データとして格納する（Ｓ18）。具体的には、BEトランザクションID「１１１」のOUTデータ（＝処理結果データ）の項目に、データ(2)が登録される。 At this time, the test support unit 25 captures the data (2) and stores it as the processing result data of the search transaction from the first BL server 16a in the test DB 26 (S18). Specifically, data (2) is registered in the item of OUT data (= processing result data) of BE transaction ID “111”.

つぎにディスパッチエンジン21は、上記のディスパッチ定義に従い、データ(2)をコネクタ22の第２のBLサーバ用データ変換部22bに出力する。第２のBLサーバ用データ変換部22bは、このデータ(2)を第２のBLサーバ16b向けのデータ形式に変換した後、第２のBLサーバ16bに送信する（Ｓ19）。 Next, the dispatch engine 21 outputs the data (2) to the second BL server data converter 22b of the connector 22 in accordance with the above dispatch definition. The second BL server data converter 22b converts this data (2) into a data format for the second BL server 16b, and then transmits it to the second BL server 16b (S19).

同時に、テスト支援部25がデータ(2)を捕捉し、検索トランザクション及び第２のBLサーバ16bを特定する情報と関連付けてテスト用ＤＢ26に格納する（Ｓ20）。具体的には、BEトランザクションID「２２２」のINデータの項目に、データ(2)が登録される。
この場合、BEトランザクションID「２２２」が、検索トランザクション及び第２のBLサーバ16bを特定する情報に該当する。 At the same time, the test support unit 25 captures the data (2), and stores it in the test DB 26 in association with the search transaction and information specifying the second BL server 16b (S20). Specifically, data (2) is registered in the IN data item of BE transaction ID “222”.
In this case, the BE transaction ID “222” corresponds to information specifying the search transaction and the second BL server 16b.

第２のBLサーバ16bから処理結果データが返されると（Ｓ21）、第２のBLサーバ用データ変換部22bにおいてPLサーバ14向けの標準形式に変換された後（Ｓ22）、データ(3)としてディスパッチエンジン21に出力される。 When processing result data is returned from the second BL server 16b (S21), the data is converted into a standard format for the PL server 14 in the second BL server data conversion unit 22b (S22), and then data (3) Output to the dispatch engine 21.

この際、テスト支援部25がデータ(3)を捕捉し、テスト用ＤＢ26に第２のBLサーバ16bからの検索トランザクションの処理結果データとして格納する（Ｓ23）。具体的には、BEトランザクションID「２２２」のOUTデータの項目に、データ(3)が登録される。 At this time, the test support unit 25 captures the data (3) and stores it in the test DB 26 as search transaction processing result data from the second BL server 16b (S23). Specifically, data (3) is registered in the OUT data item of BE transaction ID “222”.

つぎにディスパッチエンジン21は、上記のディスパッチ定義に従い、データ(3)をコネクタ22の第３のBLサーバ用データ変換部22cに出力する。第３のBLサーバ用データ変換部22cは、このデータ(3)を第３のBLサーバ16c向けのデータ形式に変換した後、第３のBLサーバ16cに送信する（Ｓ24）。 Next, the dispatch engine 21 outputs the data (3) to the third BL server data converter 22c of the connector 22 in accordance with the above dispatch definition. The third BL server data converter 22c converts this data (3) into a data format for the third BL server 16c, and then transmits it to the third BL server 16c (S24).

同時に、テスト支援部25がデータ(3)を捕捉し、検索トランザクション及び第３のBLサーバ16cを特定する情報と関連付けてテスト用ＤＢ26に格納する（Ｓ25）。具体的には、BEトランザクションID「３３３」のINデータの項目に、データ(3)が登録される。
この場合、BEトランザクションID「３３３」が、検索トランザクション及び第３のBLサーバ16cを特定する情報に該当する。 At the same time, the test support unit 25 captures the data (3), and stores it in the test DB 26 in association with the search transaction and the information specifying the third BL server 16c (S25). Specifically, data (3) is registered in the IN data item of BE transaction ID “333”.
In this case, the BE transaction ID “333” corresponds to information specifying the search transaction and the third BL server 16c.

第３のBLサーバ16cから処理結果データが返されると（Ｓ26）、第３のBLサーバ用データ変換部22cにおいてPLサーバ14向けの標準形式に変換された後（Ｓ27）、データ(4)としてディスパッチエンジン21に出力される。 When processing result data is returned from the third BL server 16c (S26), the data is converted into the standard format for the PL server 14 in the third BL server data conversion unit 22c (S27), and then the data (4). Output to the dispatch engine 21.

この際、テスト支援部25がデータ(4)を捕捉し、テスト用ＤＢ26に第３のBLサーバ16cからの処理結果データとして格納する（Ｓ28）。具体的には、BEトランザクションID「３３３」のOUTデータの項目に、データ(4)が登録される。 At this time, the test support unit 25 captures the data (4) and stores it as test result data from the third BL server 16c in the test DB 26 (S28). Specifically, data (4) is registered in the OUT data item of BE transaction ID “333”.

このデータ(4)は、画面制御部20によって最終的なリクエストの処理結果データ32として処理結果表示画面中に埋め込まれ、クライアント12に送信される（Ｓ29）。
この結果、クライアント12の表示装置33上に処理結果データ32が表示される。 This data (4) is embedded in the processing result display screen as the final request processing result data 32 by the screen control unit 20 and transmitted to the client 12 (S29).
As a result, the processing result data 32 is displayed on the display device 33 of the client 12.

以上のように、クライアント12から一つのリクエストデータ30が送信された場合、テスト支援部25の働きにより、テスト用ＤＢ26には第１のBLサーバ16a、第２のBLサーバ16b、第３のBLサーバ16cに係る入力データ及び処理結果データが、トランザクション単位で蓄積されることとなる。 As described above, when one request data 30 is transmitted from the client 12, the test support unit 25 causes the test DB 26 to store the first BL server 16a, the second BL server 16b, and the third BL. Input data and processing result data related to the server 16c are accumulated in units of transactions.

もちろん、複数のBLサーバ16に対して所定の処理を順番に依頼する場合に限られず、１つのBLサーバ16に対して複数の処理を連続して依頼する場合や、複数のBLサーバ16に対して同時並列的に複数の処理を依頼する場合にも、テスト支援部25によってトランザクション毎に入力データと処理結果データがテスト用ＤＢ26に記録されることとなる。 Of course, it is not limited to the case where a plurality of BL servers 16 are sequentially requested for a predetermined process, or when a plurality of processes are continuously requested to one BL server 16, or to a plurality of BL servers 16. Even when a plurality of processes are requested simultaneously in parallel, the test support unit 25 records the input data and the processing result data in the test DB 26 for each transaction.

つぎに、初回ランによって収集したトランザクション毎の入力データ及び処理結果データに基づいて、同様のテストを再ランする場合について説明する。
図４は、再ラン時におけるオンラインシステム10のシステム構成図であり、クライアント12や画面制御部20の関与なしに再ランが実行されることを表現している。 Next, a case where a similar test is rerun based on input data and processing result data for each transaction collected by the first run will be described.
FIG. 4 is a system configuration diagram of the online system 10 at the time of rerun, and expresses that rerun is executed without involvement of the client 12 or the screen control unit 20.

以下、図５のフローチャートに従い、再ラン時の処理手順を説明する。
まず、テスト端末18からPLトランザクションID「１１１１」を特定した再ランの指示データが送信されると、これを受けたテスト支援部25は（Ｓ40）、再ランの実行範囲を特定する（Ｓ41）。ここで、PLトランザクションID「１１１１」はBEトランザクションID「１１１」〜「３３３」を包含する上位概念であるため、テスト支援部25は初回ランと同じ範囲で再ランを行うべきものと判断する。 Hereinafter, the processing procedure at the time of rerun will be described according to the flowchart of FIG.
First, when the rerun instruction data specifying the PL transaction ID “1111” is transmitted from the test terminal 18, the test support unit 25 receiving this (S40) specifies the rerun execution range (S41). . Here, since the PL transaction ID “1111” is a superordinate concept including the BE transaction IDs “111” to “333”, the test support unit 25 determines that rerun should be performed within the same range as the initial run.

そこでテスト支援部25は、テスト用ＤＢ26からBEトランザクションID「１１１」の入力データであるデータ(1)を取り出し（Ｓ42）、ディスパッチエンジン21に渡す。 Therefore, the test support unit 25 takes out the data (1) which is the input data of the BE transaction ID “111” from the test DB 26 (S42) and passes it to the dispatch engine 21.

ディスパッチエンジン21は、データ(1)をコネクタ22の第１のBLサーバ用データ変換部22aに出力する。第１のBLサーバ用データ変換部22aは、このデータ(1)を第１のBLサーバ16a向けのデータ形式に変換した後、第１のBLサーバに送信する（Ｓ43）。 The dispatch engine 21 outputs the data (1) to the first BL server data converter 22 a of the connector 22. The first BL server data conversion unit 22a converts this data (1) into a data format for the first BL server 16a, and then transmits it to the first BL server (S43).

そして、第１のBLサーバ16aから処理結果データが返されると（Ｓ44）、第１のBLサーバ用データ変換部22aにおいてPLサーバ14向けの標準形式に変換された後（Ｓ45）、データ(2)'としてディスパッチエンジン21に出力される。 When the processing result data is returned from the first BL server 16a (S44), the data is converted into the standard format for the PL server 14 in the first BL server data conversion unit 22a (S45), and the data (2 ) 'Is output to the dispatch engine 21.

このデータ(2)'は、テスト支援部25によって捕捉され、テスト用ＤＢ26に格納される（Ｓ46）。具体的には、図６に示すように、BEトランザクションID「１１１」の再ラン結果データの項目に、データ(2)'が登録される。 This data (2) ′ is captured by the test support unit 25 and stored in the test DB 26 (S46). Specifically, as shown in FIG. 6, data (2) ′ is registered in the rerun result data item of BE transaction ID “111”.

つぎにテスト支援部25は、テスト用ＤＢ26からBEトランザクションID「２２２」の入力データであるデータ(2)を取り出し（Ｓ47）、ディスパッチエンジン21に渡す。 Next, the test support unit 25 takes out the data (2) which is the input data of the BE transaction ID “222” from the test DB 26 (S47) and passes it to the dispatch engine 21.

ディスパッチエンジン21は、データ(2)をコネクタ22の第２のBLサーバ用データ変換部22bに出力する。第２のBLサーバ用データ変換部22bは、このデータ(2)を第２のBLサーバ16b向けのデータ形式に変換した後、第２のBLサーバ16bに送信する（Ｓ48）。 The dispatch engine 21 outputs the data (2) to the second BL server data converter 22b of the connector 22. The second BL server data converter 22b converts this data (2) into a data format for the second BL server 16b, and then transmits it to the second BL server 16b (S48).

そして、第２のBLサーバ16bから処理結果データが返されると（Ｓ49）、第２のBLサーバ用データ変換部22bにおいてPLサーバ14向けの標準形式に変換された後（Ｓ50）、データ(3)'としてディスパッチエンジン21に出力される。 When the processing result data is returned from the second BL server 16b (S49), the second BL server data conversion unit 22b converts the data into the standard format for the PL server 14 (S50), and the data (3 ) 'Is output to the dispatch engine 21.

このデータ(3)'は、テスト支援部25によって捕捉され、テスト用ＤＢ26に格納される（Ｓ51）。具体的には、BEトランザクションID「２２２」の再ラン結果データの項目に、データ(3)'が登録される。 This data (3) ′ is captured by the test support unit 25 and stored in the test DB 26 (S51). Specifically, data (3) ′ is registered in the rerun result data item of BE transaction ID “222”.

つぎにテスト支援部25は、テスト用ＤＢ26からBEトランザクションID「３３３」のINデータであるデータ(3)を取り出し（Ｓ52）、ディスパッチエンジン21に渡す。 Next, the test support unit 25 takes out the data (3) which is the IN data of the BE transaction ID “333” from the test DB 26 (S52) and passes it to the dispatch engine 21.

ディスパッチエンジン21は、上記のディスパッチ定義に従い、データ(3)をコネクタ22の第３のBLサーバ用データ変換部22cに出力する。第２のBLサーバ用データ変換部22cは、このデータ(3)を第３のBLサーバ16c向けのデータ形式に変換した後、第３のBLサーバ16cに送信する（Ｓ53）。 The dispatch engine 21 outputs the data (3) to the third BL server data converter 22c of the connector 22 in accordance with the dispatch definition. The second BL server data conversion unit 22c converts this data (3) into a data format for the third BL server 16c, and then transmits it to the third BL server 16c (S53).

そして、第３のBLサーバ16cから処理結果データが返されると（Ｓ54）、第３のBLサーバ用データ変換部22cにおいてPLサーバ14向けの標準形式に変換された後（Ｓ55）、データ(4)'としてディスパッチエンジン21に出力される。 When the processing result data is returned from the third BL server 16c (S54), the data is converted into the standard format for the PL server 14 in the third BL server data conversion unit 22c (S55), and the data (4 ) 'Is output to the dispatch engine 21.

このデータ(4)'は、テスト支援部25によって捕捉され、テスト用ＤＢ26に格納される（Ｓ56）。具体的には、BEトランザクションID「３３３」の再ラン結果データの項目に、データ(4)'が登録される。 This data (4) ′ is captured by the test support unit 25 and stored in the test DB 26 (S56). Specifically, data (4) ′ is registered in the rerun result data item of BE transaction ID “333”.

つぎに、テスト支援部25はテスト用ＤＢ26に格納された初回ラン時の各BEトランザクションIDの処理結果データ（OUTデータ）と再ラン結果データとを比較し（Ｓ57）、その比較結果のリストをテスト端末18に送信する（Ｓ58）。 Next, the test support unit 25 compares the processing result data (OUT data) of each BE transaction ID stored in the test DB 26 with the rerun result data at the time of the first run (S57), and displays a list of the comparison results. The data is transmitted to the test terminal 18 (S58).

例えば、バグの修正を行う前に初回ランを実行しておき、バグの修正後に再ランを行えば、バグの修正によって悪影響が生じているか否かを確認することができる。すなわち、比較結果リストが全て「一致」であれば問題ないが、「不一致」の場合にはデグレードが生じている可能性があるため、より細かいレベルでの再ランを行う必要がある。 For example, if a first run is performed before a bug is corrected and a rerun is performed after the bug is corrected, it can be confirmed whether or not the bug correction has caused an adverse effect. That is, there is no problem if all the comparison result lists are “match”, but there is a possibility that degradation has occurred in the case of “mismatch”, and therefore it is necessary to perform rerun at a finer level.

このテスト支援システムにおいては、トランザクション単位で個別に再ランを行うこともできる。
例えば、テスト端末18からBEトランザクションID「２２２」を指定した再ランの指示データが送信された場合、図７に示すように、テスト支援部25はテスト用ＤＢ26から「２２２」の入力データであるデータ(2)を取り出し、ディスパッチエンジン21に渡す。 In this test support system, rerun can be performed individually for each transaction.
For example, when rerun instruction data specifying the BE transaction ID “222” is transmitted from the test terminal 18, the test support unit 25 is input data “222” from the test DB 26 as shown in FIG. Data (2) is extracted and passed to the dispatch engine 21.

ディスパッチエンジン21は、データ(2)をコネクタ22の第２のBLサーバ用データ変換部22bに出力する。第２のBLサーバ用データ変換部22bは、このデータ(2)を第２のBLサーバ16b向けのデータ形式に変換した後、第２のBLサーバ16bに送信する。 The dispatch engine 21 outputs the data (2) to the second BL server data converter 22b of the connector 22. The second BL server data converter 22b converts the data (2) into a data format for the second BL server 16b, and then transmits the data format to the second BL server 16b.

そして、第２のBLサーバ16bから処理結果データが返されると、第２のBLサーバ用データ変換部22bにおいてPLサーバ14向けの標準形式に変換された後、データ(3)'としてディスパッチエンジン21に出力される。
このデータ(3)'は、テスト支援部25によって捕捉され、テスト用ＤＢ26におけるBEトランザクションID「２２２」の再ラン結果データの項目に登録される。 When the processing result data is returned from the second BL server 16b, the second BL server data conversion unit 22b converts the processing result data into a standard format for the PL server 14, and then dispatches the dispatch engine 21 as data (3) '. Is output.
This data (3) ′ is captured by the test support unit 25 and registered in the rerun result data item of the BE transaction ID “222” in the test DB.

このように、トランザクション単位で再ランを実施し、初回ラン時の処理結果データと再ラン結果データとを比較することにより、リクエスト単位で入力データと処理結果データを比較する従来の入力支援ツールに比べ、よりきめ細かいレベルでBLサーバ16の動作を検証することが可能となる。 In this way, a rerun is performed for each transaction, and the processing result data at the first run and the rerun result data are compared, thereby comparing the input data with the processing result data for each request. In comparison, the operation of the BL server 16 can be verified at a finer level.

また、このようにBLサーバ16のトランザクション単位での再ランが可能であることから、このテスト支援システムによれば、データベース28の状態もトランザクション単位で復元することが可能となる。
すなわち、各BLサーバ16が管理するデータベース28については、初回ランの直前にバックアップが取られているため、このバックアップされたデータに基づいて必要なトランザクションを順次実行することにより、各データベース28の更新具合をその都度確認することが可能となる。 In addition, since the BL server 16 can be rerun in units of transactions as described above, according to this test support system, the state of the database 28 can be restored in units of transactions.
In other words, since the database 28 managed by each BL server 16 is backed up immediately before the first run, the necessary transactions are sequentially updated based on the backed up data to update each database 28. It is possible to check the condition each time.

図８は、ある住所管理データベース28に対する更新状況を例示するものであり、トランザクションαによって「TEL」が更新され、トランザクションβによって「FAX」が、またトランザクションγによって「住所」が更新される仕組みである場合、トランザクションα〜γを順にワンステップずつ再ランさせることにより、データベース28が（イ）→（ロ）→（ハ）→（ニ）と更新されてきた様子を個別に確認することができる。 FIG. 8 exemplifies the update status for a certain address management database 28, in which “TEL” is updated by transaction α, “FAX” is updated by transaction β, and “address” is updated by transaction γ. In some cases, by rerunning transactions α to γ one step at a time, it is possible to individually confirm how the database 28 has been updated as (b) → (b) → (c) → (d). .

これに対し、従来の入力支援ツールを用いた場合は、リクエスト単位でしか再ランが実施できず、BLサーバ16のトランザクション単位で再ランを実施することができなかったため、図１８に示したように、データベース28の（イ）と（ハ）の状態のみを比較するしかなく、途中の（ロ）地点、（ハ）地点の状態を確認することはできなかった。 On the other hand, when the conventional input support tool is used, rerun can be performed only in units of requests, and rerun cannot be performed in units of transactions of the BL server 16, as shown in FIG. In addition, only the states (a) and (c) in the database 28 were compared, and the states at points (b) and (c) could not be confirmed.

また、このテスト支援システムの場合には、上記のようにコネクタ22において入力データが各BLサーバ16a〜16c向けのデータ形式に変換された上で送信されると共に、各BLサーバ16a〜16cからの処理結果データがコネクタ22においてPLサーバ14の標準フォーマットに変換される機能を備えている。このため、オンラインシステム10が実装言語やフレームワークを異にする複数種のBLサーバ16を連携させたものであっても、テスト支援部25は各種BLサーバ16のテストを標準フォーマットに基づいて統一的に実行することが可能となり、従来のようにBLサーバ16a〜16c毎に専用のテスタを接続し、BLサーバ単位でIN/OUTのデータ確認を行う必要がない。この結果、オペレータもテスト支援部25の操作法のみを習得すれば済むこととなる。 In the case of this test support system, the input data is transmitted after being converted into the data format for each BL server 16a to 16c in the connector 22 as described above, and from each BL server 16a to 16c. The processing result data is provided with a function of being converted into the standard format of the PL server 14 at the connector 22. For this reason, even if the online system 10 links multiple types of BL servers 16 with different implementation languages and frameworks, the test support unit 25 unifies the tests of various BL servers 16 based on a standard format. Therefore, it is not necessary to connect a dedicated tester to each of the BL servers 16a to 16c and perform IN / OUT data confirmation for each BL server as in the prior art. As a result, the operator only has to learn the operation method of the test support unit 25.

ところで、オンラインシステムにおいては、同一のデータベースに対して複数のクライアントが同時にアクセスし、相互に矛盾した更新処理が実行されることを防止する目的で、「楽観的排他ロック」と称する機能が一般に設けられている。 By the way, in an online system, a function called “optimistic exclusive lock” is generally provided for the purpose of preventing a plurality of clients from accessing the same database at the same time and performing update processing contradictory to each other. It has been.

図９は、この楽観的排他ロックの仕組みを説明するための図であり、データベース28の各レコードには「最終更新日時」のデータ項目42が設けられている。
ここで、図９(a)に示すように、クライアント12から「社員ID＝001」を指定した検索リクエストデータ30が送信されると、PLサーバ14経由でこれを受け取ったBLサーバ16は、データベース28から検索条件にマッチしたレコードを抽出し、PLサーバ14経由でクライアント12に検索処理結果データ32を送信することとなるが、この検索処理結果データ32には「更新日時」のデータ項目43が設けられており、データベース28の「最終更新日時」の値である「05/24/10:00」がタイムスタンプとして充填されている。 FIG. 9 is a diagram for explaining the mechanism of this optimistic exclusive lock, and each record of the database 28 is provided with a data item 42 of “last update date”.
Here, as shown in FIG. 9 (a), when the search request data 30 specifying “employee ID = 001” is transmitted from the client 12, the BL server 16 that has received this via the PL server 14 The record that matches the search condition is extracted from 28, and the search processing result data 32 is transmitted to the client 12 via the PL server 14. The search processing result data 32 includes a data item 43 of “update date”. “05/24/10: 00”, which is the value of “last updated date / time” in the database 28, is filled as a time stamp.

このタイムスタンプ自体はクライアント12の画面上に表示されることはないが、画面を構成するHtmlファイル中には記述されているため、同クライアント12から「社員ID＝001」のレコードについての更新リクエストデータが送信される場合には、このデータにも上記の「更新日時」が引き継がれることとなる。
例えば、図９(b)に示すように、５月24日の14:00にクライアント12から同社員の所属を「営業部」から「総務部」に変更する内容の更新リクエストデータ30が送信される場合、「05/24/10:00」のデータが付加されている。 Although this time stamp itself is not displayed on the screen of the client 12, since it is described in the Html file that composes the screen, an update request for the record of “employee ID = 001” from the client 12 When data is transmitted, the “update date / time” is also carried over to this data.
For example, as shown in FIG. 9 (b), at 14:00 on May 24, update request data 30 is sent from the client 12 to change the employee's affiliation from “sales department” to “general affairs department”. In this case, data “05/24/10: 00” is added.

この更新リクエストデータ30を受信したBLサーバ16は、その更新日時とデータベース28に格納された対応レコードの最終更新日時を比較し、両者が一致していることを確認した上で、当該レコードへの更新を実行する。この際、当該レコードの最終更新日時は「05/24/14:00」に更新される。また、クライアント12に対しては更新処理結果データ32が送信されるが、このデータの更新日時には最新の「05/24/14:00」が記録される。 The BL server 16 that has received the update request data 30 compares the update date and time with the last update date and time of the corresponding record stored in the database 28, and confirms that they match. Perform the update. At this time, the last update date and time of the record is updated to “05/24/14: 00”. The update processing result data 32 is transmitted to the client 12, and the latest “05/24/14: 00” is recorded as the update date and time of this data.

これに対し、更新リクエストデータ30の更新日時とデータベース28側の最終更新日時が一致しない場合には、その間に他のクライアントによって当該レコードに更新がなされたことを意味しているため、BLサーバ16からクライアント12に対してエラーメッセージが送信され、データの更新が拒絶されることとなる。 On the other hand, if the update date / time of the update request data 30 does not match the last update date / time on the database 28 side, it means that the record has been updated by another client in the meantime. An error message is transmitted from the client to the client 12, and the data update is rejected.

以上のように、楽観的排他ロック機構を備えることにより、オンラインシステムに含まれるデータベースに矛盾が生じることを有効に抑えることが可能となる。
しかしながら、この楽観的排他ロック機構を備えたオンラインシステムにこのテスト支援システムをそのまま適用すると再ラン時に問題が生じるため、これを回避するための仕組みを講じておく必要がある。以下において、この問題とその回避方法について説明する。 As described above, by providing the optimistic exclusive lock mechanism, it is possible to effectively suppress the occurrence of contradiction in the database included in the online system.
However, if this test support system is applied as it is to an online system equipped with this optimistic exclusive lock mechanism, a problem will occur at the time of rerun, and it is necessary to take a mechanism to avoid this. In the following, this problem and how to avoid it will be described.

まず、図１０は初回ラン時の手順を示すものであり、図１０(a)に示すように、05/24/14:00の時点でクライアント12から(A)の更新リクエストデータ（更新日時：05/24/10:00）が送信されると、PLサーバ14経由でこれを受け取ったBLサーバ16は、当該更新リクエストデータ(A)の更新日時とデータベース28側の最終更新日時と比較し、両者が一致していることを確認した後、所属を「営業部」から「総務部」に変更する更新処理を実行する。この際、当該レコードの最終更新日時も「05/24/14:00」に更新される。 First, FIG. 10 shows the procedure at the time of the first run. As shown in FIG. 10 (a), the update request data (update date and time :) from the client 12 at the time of 05/24/14: 00. 05/24/10: 00) is transmitted, the BL server 16 receiving this via the PL server 14 compares the update date / time of the update request data (A) with the last update date / time of the database 28 side, After confirming that both match, an update process is executed to change the affiliation from “sales department” to “general affairs department”. At this time, the last update date / time of the record is also updated to “05/24/14: 00”.

同時に、BLサーバ16からクライアント12に対しては、PLサーバ14経由で更新処理結果データ(B)が送信される。この更新処理結果データ(B)の更新日時にも、最終更新日時である「05/24/14:00」が記録されている。
この間、テスト用ＤＢ26には、テスト支援部25（図示省略）によって更新リクエストデータ(A)及び更新処理結果データ(B)が格納される。 At the same time, update processing result data (B) is transmitted from the BL server 16 to the client 12 via the PL server 14. “05/24/14: 00” that is the last update date / time is also recorded in the update date / time of the update processing result data (B).
During this time, update request data (A) and update processing result data (B) are stored in the test DB 26 by the test support unit 25 (not shown).

つぎに、図１０(b)に示すように、05/24/16:00の時点でクライアント12から所属を「法務部」に変更する更新リクエストデータ(C)が送信されると、BLサーバ16は当該更新リクエストデータ(C)の更新日時「05/24/14:00」とデータベース28側の最終更新日時「05/24/14:00」を比較し、両者が一致していることを確認した後、所属を「総務部」から「法務部」に変更する更新処理を実行する。この際、当該レコードの最終更新日時も「05/24/16:00」に更新される。 Next, as shown in FIG. 10 (b), when update request data (C) for changing the affiliation to “legal department” is transmitted from the client 12 at 05/24/16: 00, the BL server 16 Compares the update date / time “05/24/14: 00” of the update request data (C) with the last update date / time “05/24/14: 00” on the database 28 side, and confirms that they match. After that, an update process is executed to change the affiliation from “General Affairs Department” to “Legal Affairs Department”. At this time, the last update date and time of the record is also updated to “05/24/16: 00”.

同時に、BLサーバ16からクライアント12に対しては、PLサーバ14経由で更新処理結果データ(D)が送信される。この更新結果データ(D)の更新日時にも、最終更新日時である「05/24/16:00」が記録されている。
この間、テスト用ＤＢ26には、テスト支援部25によって更新リクエストデータ(C)及び更新結果データ(D)が格納される。 At the same time, update processing result data (D) is transmitted from the BL server 16 to the client 12 via the PL server 14. “05/24/16: 00” which is the last update date / time is also recorded in the update date / time of the update result data (D).
During this time, update request data (C) and update result data (D) are stored in the test DB 26 by the test support unit 25.

つぎに、図１１は再ラン時の手順を示すものであり、図１１(a)に示すように、05/24/21:00の時点でPLサーバ14から(A)の更新リクエストデータ（更新日時：05/24/10:00）が送信されると、BLサーバ16は当該更新リクエストデータ(A)の更新日時とデータベース28側の最終更新日時と比較する。再ラン時には、初回ランの直前にバックアップされたデータが用いられるため、両日時は当然に一致することから、BLサーバ16は所属を「営業部」から「総務部」に変更する更新処理を実行する。この際、当該レコードの最終更新日時は現在時刻の「05/24/21:00」に更新される。 Next, FIG. 11 shows the procedure at the time of rerun. As shown in FIG. 11A, the update request data (update) of (A) is received from the PL server 14 at 05/24/21: 00. Date / time: 05/24/10: 00), the BL server 16 compares the update date / time of the update request data (A) with the last update date / time of the database 28 side. Since the data backed up immediately before the first run is used at the time of rerun, both dates and times naturally match, so the BL server 16 executes an update process to change the affiliation from “Sales Department” to “General Affairs Department” To do. At this time, the last update date and time of the record is updated to “05/24/21: 00” of the current time.

同時に、BLサーバ16からPLサーバ14に対しては、更新処理結果データ(B)'が送信される。この更新処理結果データ(B)'の更新日時にも、最終更新日時である「05/24/21:00」が記録されている。
この間、テスト用ＤＢ26には、テスト支援部25によって更新結果データ(B)'が格納される。 At the same time, update processing result data (B) ′ is transmitted from the BL server 16 to the PL server 14. “05/24/21: 00” that is the last update date / time is also recorded in the update date / time of the update processing result data (B) ′.
During this time, update result data (B) ′ is stored in the test DB 26 by the test support unit 25.

つぎに、図１１(b)に示すように、05/24/23:00の時点でPLサーバ14から(C)の更新リクエストデータ（更新日時：05/24/14:00）が送信されると、BLサーバ16は当該更新リクエストデータ(C)の更新日時とデータベース28側の最終更新日時と比較する。この場合には更新日時が不一致となるため、BLサーバ16からPLサーバ14に対してエラーメッセージが送信され、データベース28の更新処理は当然ながら拒絶されることとなる。
この間、テスト用ＤＢ26には、テスト支援部25によってエラーメッセージ(D)'が再ラン結果データとして記録される。 Next, as shown in FIG. 11 (b), update request data (update date and time: 05/24/14: 00) of (C) is transmitted from the PL server 14 at 05/24/23: 00. Then, the BL server 16 compares the update date and time of the update request data (C) with the last update date and time on the database 28 side. In this case, since the update date / time does not match, an error message is transmitted from the BL server 16 to the PL server 14, and the update process of the database 28 is naturally rejected.
During this time, the error message (D) ′ is recorded in the test DB 26 as rerun result data by the test support unit 25.

以上を要するに、楽観的排他ロック機構の下においてこのテスト支援システムをそのまま適用すると、以下の問題が生じる。
(1)初回ラン時にテスト用ＤＢ26格納された入力データの更新日時と、再ラン時にBLサーバ16によって更新されたデータベースの最終更新日時とが不一致となるため、楽観的排他ロックが発動され、再ラン結果データがエラーとなる。
(2)再ラン結果データの更新日時には再ラン時の現在日時が付与されるため、各トランザクションの処理結果データと再ラン結果データを比較する際に、更新日時の不一致を理由に「比較結果＝不一致」と判定されてしまう。
そこで、このテスト支援システムは、更新日時に関して「引継ぎ」及び「マスキング」という手法を適用することにより、上記の問題を解消している。 In short, if this test support system is applied as it is under the optimistic exclusive lock mechanism, the following problems arise.
(1) Since the update date and time of the input data stored in the test DB 26 at the first run and the last update date and time of the database updated by the BL server 16 at the time of rerun do not match, an optimistic exclusive lock is activated and Run result data is an error.
(2) Since the current date and time at the time of rerun is given to the update date and time of the rerun result data, when comparing the processing result data of each transaction with the rerun result data, `` Comparison result '' == “mismatch”.
Therefore, this test support system solves the above problem by applying the methods of “takeover” and “masking” with respect to the update date and time.

まず「引継ぎ」とは、図１２(a)に示すように、BLサーバ16によって再ラン結果データ(B)'に付与された更新日時「05/24/21:00」を用いて、後続トランザクションの入力データ(C)に対して初回ラン時に付与された「05/24/14:00」の更新日時を上書きした後、BLサーバ16に送信する手法を意味する。この更新日時の引継ぎは、テスト支援部25によって実行される。 First, “takeover” means that, as shown in FIG. 12A, using the update date and time “05/24/21: 00” assigned to the rerun result data (B) ′ by the BL server 16, This is a method of overwriting the update date and time of “05/24/14: 00” given at the time of the first run to the input data (C), and then transmitting to the BL server 16. The takeover of the update date and time is executed by the test support unit 25.

この結果、更新リクエストデータ(C)の更新日時とデータベース28側の最終更新日時とが一致することとなり、社員ID＝001の所属を「総務部」から「法務部」に変更する更新処理が、BLサーバ16において正しく実行されることとなる。
また、BLサーバ16からPLサーバ14に対しては、更新結果データ(D)'が送信される。この更新結果データ(D)'の更新日時には、最終更新日時である「05/24/23:00」が記録されている。この更新結果データ(D)'は、テスト支援部25によってテスト用ＤＢ26の再ラン結果データ項目に登録される。 As a result, the update date and time of the update request data (C) and the last update date and time on the database 28 side match, and the update process for changing the affiliation of employee ID = 001 from “General Affairs Department” to “Legal Affairs Department” It will be executed correctly in the BL server 16.
Further, update result data (D) ′ is transmitted from the BL server 16 to the PL server 14. In the update date / time of the update result data (D) ′, “05/24/23: 00” which is the last update date / time is recorded. This update result data (D) ′ is registered in the rerun result data item of the test DB 26 by the test support unit 25.

つぎに「マスキング」とは、図１３(a)に示すように、テスト用ＤＢ26に格納された処理結果データ(B)と再ラン結果データ(B)'をそのまま比較すると、更新日時が異なるために全体が不一致と判定されてしまう場合に、図１３(b)に示すように、両データの更新日時にマスク処理を施した上で比較する手法を意味する。具体的には、両データの更新日時を共通の文字列「***」等に置き換えることが該当する。
このマスク処理も、テスト支援部25によって実行される。 Next, as shown in FIG. 13 (a), “masking” means that the update date and time are different when the processing result data (B) stored in the test DB 26 and the rerun result data (B) ′ are compared as they are. Means that a comparison is made after performing a mask process on the update date and time of both data, as shown in FIG. 13 (b). Specifically, it corresponds to replacing the update date of both data with a common character string “***” or the like.
This mask processing is also executed by the test support unit 25.

この結果、楽観的排他ロックのために便宜的に付与される更新日時項目の値の不一致によって、残りの実質的なデータ項目の値に変更がない場合であっても全体が不一致と判定されてしまう不都合を回避可能となる。
図示は省略したが、処理結果データ(D)と再ラン結果データ(D)'との比較時にも、それぞれの更新日時にはマスク処理が施される。 As a result, due to inconsistency in the values of the update date and time items that are given for the sake of optimistic exclusive lock, the entire data is determined to be inconsistent even when there are no changes in the values of the remaining substantial data items. It is possible to avoid the inconvenience.
Although illustration is omitted, masking processing is performed on each update date and time when comparing the processing result data (D) and the rerun result data (D) ′.

テスト支援部25は、上記の通り、ディスパッチエンジン21内に組み込まれ、ディスパッチエンジン21を通過するデータを捕捉してテスト用ＤＢ26に格納する機能、再ラン時にテスト用ＤＢ26から必要なデータを取り出してディスパッチエンジン21に渡し、所定のBLサーバ16への送信を依頼する機能、BLサーバ16から送信されたデータを捕捉してテスト用ＤＢ26に格納すると共に、初回ラン時のデータと比較する機能を発揮するが、テスト終了後の本番時においては全く不要となる。
このため、ディスパッチエンジン21用のアプリケーション内にテスト支援部25用のコードを予め組み込んでおくのは好ましくない。
また、本番時とテスト時とではマシン構成や回線容量等の環境が異なる場合が多いため、通常はテスト終了後にアプリケーションの設定を本番用に書き換えることが行われているが、この際にバグが混入する危険性があった。 As described above, the test support unit 25 is incorporated in the dispatch engine 21, captures data passing through the dispatch engine 21 and stores it in the test DB 26, and retrieves necessary data from the test DB 26 during rerun. A function to send to the dispatch engine 21 and request transmission to the specified BL server 16, a function to capture the data transmitted from the BL server 16 and store it in the test DB 26, and compare it with the data at the first run However, it is not necessary at all after the test.
For this reason, it is not preferable to incorporate the code for the test support unit 25 in the application for the dispatch engine 21 in advance.
Also, because the environment such as machine configuration and line capacity is often different between the production and test, the application settings are usually rewritten for production after the test is completed. There was a risk of contamination.

そこでこのシステム10では、テスト対象となるアプリケーションプログラム自体には手を加えることなく、テスト時にのみテスト支援部25を外部からディスパッチエンジン21内に組み込むと共に、外部に配置されたテスト用の設定情報を反映させる仕組みを採用している。 Therefore, in this system 10, the test support unit 25 is incorporated from the outside into the dispatch engine 21 only at the time of testing, without changing the application program itself to be tested, and setting information for testing arranged outside is also provided. Adopting a mechanism to reflect.

図１４は、この仕組みを説明するための模式図であり、PLサーバ14のディスク領域50には、ディスパッチエンジン用実行ファイル51（Webアプリケーション）と、テスト支援部用ライブラリ52と、テスト設定ファイル53が格納されている。ディスパッチエンジン用実行ファイル51には、本番設定ファイル54が含まれている。 FIG. 14 is a schematic diagram for explaining this mechanism. In the disk area 50 of the PL server 14, a dispatch engine execution file 51 (Web application), a test support unit library 52, and a test setting file 53 are shown. Is stored. The dispatch engine execution file 51 includes a production setting file 54.

また、PLサーバ14のメモリ空間56には、上位クラスローダ57が設けられており、この上位クラスローダ57内に予めスイッチモジュール58が配置されている。
この上位クラスローダ57は、Java（登録商標）の動作環境であるJ2EE（Java 2 Enterprise Edition）の仕様に基づいて実現されるものであり、この上位クラスローダ57内に配置されたモジュールは、メモリ空間56に展開された全てのアプリケーションから参照できるという特徴を備えている。
このスイッチモジュール58は、スイッチモジュール用のライブラリを予めPLサーバ14の所定のディレクトリに格納しておくことで、JVM（Java Virtual Machine）の起動時に上位クラスローダ57内に自動的に配置される。 Further, an upper class loader 57 is provided in the memory space 56 of the PL server 14, and a switch module 58 is arranged in advance in the upper class loader 57.
This upper class loader 57 is realized based on the specification of J2EE (Java 2 Enterprise Edition) which is an operating environment of Java (registered trademark), and the modules arranged in the upper class loader 57 are memory It has a feature that it can be referred to from all applications developed in the space 56.
The switch module 58 is automatically placed in the upper class loader 57 when a JVM (Java Virtual Machine) is started by storing a library for the switch module in a predetermined directory of the PL server 14 in advance.

つぎに、図１５のフローチャートに従い、テスト支援部25の組込及びテスト用設定情報の反映手順について説明する。
まず、ディスパッチエンジン用実行ファイル51を起動させ、メモリ空間56のWARクラスローダ59内にフレームワーク60、固有機能部61、本番設定情報62を配置させる（Ｓ51）。J2EEの環境下においては、各WebアプリケーションはWARクラスローダ単位で管理される。 Next, a procedure for incorporating the test support unit 25 and reflecting the setting information for testing will be described with reference to the flowchart of FIG.
First, the dispatch engine execution file 51 is activated, and the framework 60, the specific function unit 61, and the production setting information 62 are arranged in the WAR class loader 59 in the memory space 56 (S51). Under the J2EE environment, each Web application is managed in units of WAR class loaders.

つぎに、フレームワーク60が上位クラスローダ57内にスイッチモジュール58が存在しているか否かをチェックする（Ｓ52）。
ここで、スイッチモジュール58が存在している場合（Ｓ53／YES）、フレームワーク60はテストモードであると認識し、テスト支援部用ライブラリ52を自己のWARクラスローダ59内にロードし（Ｓ54）、テスト支援部25を生成する。 Next, the framework 60 checks whether or not the switch module 58 exists in the upper class loader 57 (S52).
If the switch module 58 exists (S53 / YES), the framework 60 recognizes that it is in the test mode, and loads the test support unit library 52 into its own WAR class loader 59 (S54). Then, the test support unit 25 is generated.

このテスト支援部25は、PLサーバ14のディスク領域50から対応のテスト設定ファイル53をメモリ空間56上に読み込み（Ｓ55）、WARクラスローダ59内に展開された本番設定情報をテスト設定情報で上書きする。 The test support unit 25 reads the corresponding test setting file 53 from the disk area 50 of the PL server 14 into the memory space 56 (S55), and overwrites the actual setting information expanded in the WAR class loader 59 with the test setting information. To do.

以上の結果、図１６(b)に示すように、メモリ空間のWARクラスローダ59内には、ディスパッチエンジン固有の機能を担当する固有機能部61とフレームワーク60の他に、テスト支援部25が組み込まれると共に、本番用の設定情報62がテスト用設定情報63に切り替えられることとなる。 As a result of the above, as shown in FIG. 16B, in the WAR class loader 59 in the memory space, in addition to the specific function unit 61 and the framework 60 in charge of functions specific to the dispatch engine, the test support unit 25 At the same time, the setting information 62 for production is switched to the setting information 63 for testing.

そして、オンラインテストが完了した後は、スイッチモジュール用ライブラリを削除してJVMを再起動させ、上位クラスローダ57内のスイッチモジュール58を除去しておくだけで、Ｓ54〜Ｓ56の処理がスキップされ、図１６(a)に示すように、WARクラスローダ59内にはフレームワーク60と固有機能部61及び本番設定情報62が配置される。
この結果、ディスパッチエンジン用実行ファイル51に手を加えることなく、ディスパッチエンジン21を本番仕様に切り替えることが可能となる。 After the online test is completed, the switch module library is deleted, the JVM is restarted, and the switch module 58 in the upper class loader 57 is removed, and the processing of S54 to S56 is skipped. As shown in FIG. 16A, a framework 60, a specific function unit 61, and production setting information 62 are arranged in the WAR class loader 59.
As a result, the dispatch engine 21 can be switched to the production specification without modifying the dispatch engine execution file 51.

この発明に係るテスト支援システムの初回ラン時における構成を示すシステム構成図である。It is a system configuration diagram showing the configuration at the time of the first run of the test support system according to the present invention. オンラインテストの初回ラン時における処理手順を示すフローチャートである。It is a flowchart which shows the process sequence at the time of the first run of an online test. テスト用ＤＢのデータ項目例を示す説明図である。It is explanatory drawing which shows the data item example of test DB. テスト支援システムの再ラン時における構成を示すシステム構成図である。It is a system configuration figure showing the composition at the time of rerun of a test support system. オンラインテストの再ラン時における処理手順を示すフローチャートである。It is a flowchart which shows the process sequence at the time of the rerun of an online test. テスト用ＤＢのデータ項目例を示す説明図である。It is explanatory drawing which shows the data item example of test DB. テスト支援システムにおける再ランの要領を示す概念図である。It is a conceptual diagram which shows the point of the rerun in a test assistance system. テスト支援システムの再ラン時にBLサーバのデータベースがトランザクション単位で更新される様子を示す説明図である。It is explanatory drawing which shows a mode that the database of BL server is updated per transaction at the time of a test run system rerun. 楽観的排他ロックの一般的な仕組みを説明する模式図である。It is a schematic diagram explaining the general mechanism of an optimistic exclusive lock. このテスト支援システムにおいて楽観的排他ロックを動作させた場合の問題点を示す模式図である。It is a schematic diagram which shows a problem at the time of operating the optimistic exclusive lock in this test support system. このテスト支援システムにおいて楽観的排他ロックを動作させた場合の問題点を示す模式図である。It is a schematic diagram which shows a problem at the time of operating the optimistic exclusive lock in this test support system. テスト支援システムにおいて楽観的排他ロックを動作させた場合の問題点を回避する方法を示す模式図である。It is a schematic diagram which shows the method of avoiding the problem at the time of operating optimistic exclusive lock in a test support system. テスト支援システムにおいて楽観的排他ロックを動作させた場合の問題点を回避する方法を示す模式図である。It is a schematic diagram which shows the method of avoiding the problem at the time of operating optimistic exclusive lock in a test support system. ディスパッチエンジンにオンライン支援部を組み込みテスト用の設定を施す際の要領を示す模式図である。It is a schematic diagram which shows the point at the time of incorporating an online support part in a dispatch engine and performing the setting for a test. ディスパッチエンジンにオンライン支援部を組み込みテスト用の設定を施す際の手順を示すフローチャートである。It is a flowchart which shows the procedure at the time of giving an online support part to a dispatch engine and setting for a test. ディスパッチエンジンをテストモードと本番モードとの間でスイッチ可能としたことを示す説明図である。FIG. 10 is an explanatory diagram showing that the dispatch engine can be switched between a test mode and a production mode. 従来のオンラインシステムの一例を示すシステム構成図である。It is a system configuration diagram showing an example of a conventional online system. 従来のオンラインテストにおけるデータベースの再現性を示す説明図である。It is explanatory drawing which shows the reproducibility of the database in the conventional online test. 言語使用やフレームワークの異なるBLサーバ毎に専用のテスタを用いてテストを行う従来のテスト方法を示す模式図である。It is a schematic diagram which shows the conventional test method which tests using a dedicated tester for every BL server from which language use and a framework differ.

Explanation of symbols

10 オンラインシステム
12 クライアント
14 PLサーバ
16 BLサーバ
16a 第１のBLサーバ
16b 第２のBLサーバ
16c 第３のBLサーバ
18 テスト端末
20 画面制御部
21 ディスパッチエンジン
22 コネクタ
22a 第１のBLサーバ用データ変換部
22b 第２のBLサーバ用データ変換部
22c 第３のBLサーバ用データ変換部
25 テスト支援部
26 テスト用データベース
28 データベース
30 リクエストデータ
31 入力装置
32 処理結果データ
33 表示装置
42 「最終更新日時」のデータ項目
43 「更新日時」データ項目
50 PLサーバのディスク領域
51 ディスパッチエンジン用実行ファイル
52 テスト支援部用ライブラリ
53 テスト設定ファイル
54 本番設定ファイル
56 PLサーバのメモリ空間
57 上位クラスローダ
58 スイッチモジュール
59 WARクラスローダ
60 フレームワーク
61 固有機能部
62 本番設定情報
63 テスト用設定情報 10 Online system
12 clients
14 PL server
16 BL server
16a First BL server
16b Second BL server
16c Third BL server
18 Test terminal
20 Screen controller
21 dispatch engine
22 Connector
22a Data converter for the first BL server
22b Second BL server data converter
22c Third BL server data converter
25 Test Support Department
26 Test database
28 Database
30 Request data
31 Input device
32 Processing result data
33 Display device
42 Data item of "Last modified"
43 "Update Date / Time" data item
50 PL server disk space
51 Executable file for dispatch engine
52 Library for test support
53 Test configuration file
54 Production configuration file
56 PL server memory space
57 Upper class loader
58 Switch module
59 WAR class loader
60 Framework
61 Unique functions
62 Production setting information
63 Test setup information

Claims

Receives request data from the client, multiple back-end servers that execute business processing, and the above clients, sends necessary input data to the back-end server in charge, requests processing, and sends the processing result data to the client In an online system with a sending front-end server,
When the above front-end server runs the first online test,
(a) Processing to accept request data from the client,
(b) A process for identifying a plurality of transactions corresponding to the request ID included in the request data , a back-end server in charge of each transaction, and the order of each transaction ;
(c) after converting the input data included in the request data into a data format required by the back-end server in charge of the first transaction, and sending to the back-end server,
(d) the input data before data conversion, in association with BE transaction ID for identifying the back-end server of the transaction and charge, a process of storing in the test database,
(e) When transaction result data is sent from the back-end server, convert it to a standard data format and store it in the test database in association with the BE transaction ID in (d) above. Processing,
(f) The processing result data converted into the standard data format of (e) above is converted into the data format required by the back-end server in charge of the next transaction, and then sent to the back-end server as input data Processing,
(g) The processing result data converted into the standard data format of (e ) above is stored in the test database as input data in association with the BE transaction ID that identifies the transaction and the back-end server in charge. When,
(h) When transaction result data is sent from the back-end server, convert it to a standard data format and store it in the test database in association with the BE transaction ID in (g) above. Processing,
(i) The above processes (f) to (h) are repeated as many times as necessary, and when final process result data is obtained, a process of transmitting this as request process result data to the client is executed.
When the front-end server reruns the online test,
(j) processing for accepting rerun instruction data specifying a specific BE transaction ID ;
(k) The input data associated with the BE transaction ID is extracted from the test database, converted to the data format required by the back-end server specified based on the BE transaction ID, and then sent to the back-end server. Processing to
(l) When transaction processing result data is sent from the back-end server, convert the rerun result data into a standard data format and associate it with the BE transaction ID in (k) above. A test support system characterized by executing processing stored in a database.

2. The front-end server has a function of comparing processing result data at the time of initial run stored in the test database and rerun result data for each transaction, and outputting the result. Test support system as described in.