Scenario creating apparatus, scenario creating method, and storage medium storing scenario creating program

A scenario creating apparatus which creates a scenario for verifying operation of an information processing system in which a plurality of servers including a database server are connected, includes a collector that collects messages transmitted and received between the plurality of servers, when operation of the information processing system is being verified by a terminal apparatus that performs verification of operation; an association unit that associates the collected messages with each other; a sorter that sorts work models in ascending order of time at which access is made to the database server, the work models each being a group of the associated messages; and a scenario creating unit that creates the scenario on the basis of the sorted work models.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2009-132957, filed on Jun. 2, 2009, the entire contents of which are incorporated herein by reference.

FIELD

This embodiment relates to a scenario creating apparatus, a scenario creating method, and a storage medium storing a scenario creating program.

BACKGROUND

In a case when a bug is fixed in an information processing system, or when a new function is added to the information processing system, for example, a tester or the like who is in charge of testing the information processing system performs testing to verify that such a fix or added app is not affecting other apps. For this reason, the tester performs similar testing every time the information processing system is modified. Such testing is called “recursion testing” or “regression testing”.

Now, an example of a testing technique according to the related art will be described with reference toFIG. 23. In the example illustrated inFIG. 23, an information processing system9has a Web server13, an AP (application) server14, and a DB (Data Base) server15. The information processing system9is connected with a test terminal11via a network31.

In the example illustrated inFIG. 23, when carrying out testing, a tester H1performs a predetermined operation on the test terminal11. For example, the tester H1opens a Web browser, and inputs information defined in a test specification on the Web browser.

The test terminal11transmits an HTTP (HyperText Transfer Protocol) request or the like to the Web server13, in response to the operation performed by the tester H1. Upon receiving the HTTP request or the like, the Web server13transmits/receives a request or a response to/from the AP server14. In the meantime, the AP server14transmits/receivers a request or a response to/from the DB server15. In the following, a request and a response will be sometimes collectively referred to as “message”.

Then, for example, the test terminal11receives a response from the Web server13, and outputs information corresponding to the received response on the Web browser. Then, the tester H1checks the information outputted on the Web browser to determine pass/fail of testing.

In this way, the tester H1performs testing on the information processing system9. When performing recursion testing, the tester H1performs the same operation as previously performed, and performs the same check as previously performed. WhileFIG. 23illustrates a case in which testing is conducted by a single tester, generally, such testing is conducted by a plurality of testers.

Recently, with a view to reducing the number of man-hours required for recursion testing, an automatic testing technique has been proposed which carries out a part of recursion test automatically. Such an automatic testing technique will be described below with reference to the example illustrated inFIG. 23. It is assumed here that the automatic testing technique is applied to the test terminal11. In such a case, the test terminal11generates, for example, information containing an operation procedure performed by the tester H1, and a response received from the Web server13(hereinafter, referred to as “test data”).

Then, when performing recursion testing, for example, the tester H1does a read operation that reads the test data after initializing various kinds of database held on the DB sever15. When the read operation is performed, the test terminal11executes the operation procedure contained in the test data, and transmits a request to the Web server13. Then, the test terminal11receives a response from the Web server13, and determines pass/fail of the testing by determining whether or not the received response matches the response contained in the test data. In this way, by using the automatic testing technique, the tester H1performs recursion testing without performing a predetermined operation procedure.

For instance, Japanese Laid-open Patent Publication No. 11-184900 and Japanese Laid-open Patent Publication No. 2007-264810 are known as in relation to the automatic testing technique.

SUMMARY

According to an aspect of the invention, a scenario creating apparatus, which creates a scenario for verifying operation of an information processing system in which a plurality of servers including a database server are connected, includes a collector that collects messages transmitted and received between the plurality of servers, when operation of the information processing system is being verified by a terminal apparatus that performs verification of operation; an association unit that associates the collected messages with each other; a sorter that sorts work models in ascending order of time at which access is made to the database server, the work models each being a group of the associated messages; and a scenario creating unit that creates the scenario on the basis of the sorted work models.

The above-described embodiments of the present invention are intended as examples, and all embodiments of the present invention are not limited to including the features described above.

DESCRIPTION OF EMBODIMENTS

The above-described automatic testing technique has a problem in that pass/fail of testing cannot be determined correctly in some cases. A specific description in this regard will be given with reference toFIG. 24.FIG. 24illustrates a case in which testing is conducted by two testers H11and H12. It should be noted that inFIG. 24, solid arrows indicate messages transmitted/received between servers when testing is performed by the tester H11, and broken arrows indicate messages transmitted/received between servers when testing is performed by the tester H12.

Specifically, in the example illustrated inFIG. 24, when a test T11is performed by the tester H11, the test terminal transmits a request to the Web server13at time t11(operation S11). Thereafter, the Web server13transmits a request to the AP server14at time t12(operation S12), and the AP server14transmits a request to the DB server15at time t17(operation S17). Then, the DB server15responds to the request received from the AP server14and references or updates a database, and transmits the reference result or update result to the AP server14. In the example illustrated inFIG. 24, the DB server15transmits a response containing the reference result or update result to the AP server14at time t18(operation S18). Then, the AP server14transmits a response to the Web server13at time t21(operation S21), and the Web server13transmits a response to the test terminal at time t22(operation S22).

In addition, in the example illustrated inFIG. 24, when a test T12is carried out by the tester H12, the test terminal transmits a request to the Web server13at time t13(operation S13). Thereafter, the Web server13transmits a request to the AP server14at time t14(operation S14), and the AP server14transmits a request to the DB server15at time t15(operation S15). Then, the DB server15transmits a response to the AP server14at time t16(operation S16), and the AP server14transmits a response to the Web server13at time t19(operation S19). Thereafter, the Web server13transmits a response to the test terminal at time t20(operation S20).

In the example illustrated inFIG. 24, if the automatic testing technique according to the related art described above is applied to the test terminal, the test terminal generates test data D11corresponding to the test T11, and test data D12corresponding to the test T12. At this time, when performing recursion testing by using the test data D11, the tester returns the state of the DB server15to the state before the tests T11and T12were carried out.

Here, as illustrated inFIG. 24, in the test T11, access to the DB server15is made after access is made to the DB server15in the test T12. At this time, there is a possibility that data on the DB server15is updated by the test T12. That is, there is a possibility that a table that has been updated in the test T12is accessed in the test T11. For this reason, if the DB server15is updated in the test T12, it is required in the test T11to make access to the DB server15that has been updated.

However, when the test T11is executed using the test data D11, access cannot be made to the DB server15that has been updated in the test T12. Thus, there is a fear that the test terminal may receive from the Web server13a response different from a response contained in the test data D11. This causes a problem in which pass/fail of the testing cannot be determined correctly even though the information processing system is operating properly.

It is perceived that the operations of the respective servers illustrated inFIG. 24can be replicated by executing the tests T11and T12in the same order as that at the time of generating the test data D11and D12. However, since the order in which messages are transmitted/received between the servers varies with the conditions of the server or the conditions of the network, the operations of the servers cannot always be replicated. For this reason, in some cases, pass/fail of testing cannot be determined correctly even when the testing is executed in the same order as that at the time of generating test data.

As described above, since recursion testing is frequency performed in the field of information processing systems, the number of man-hours required for such recursion testing has been increasing. Under such a circumstance, the challenge is how to create test data that allows pass/fail of the testing to be determined correctly.

Hereinbelow, scenario creating apparatus, scenario creating method, and storage medium storing scenario creating program disclosed by this application will be described in detail with reference to the drawings. It should be noted that this embodiment does not limit the scenario creating apparatus, scenario creating method, and storage medium storing scenario creating program.

Configuration of Information Processing System According to Embodiment 1

First, referring toFIG. 1, a description will be given of the configuration of an information processing system1including a scenario creating apparatus100according to Embodiment 1.FIG. 1depicts an exemplary configuration of the information processing system1according to Embodiment 1. In the example illustrated inFIG. 1, the information processing system1has a load distribution apparatus12, a plurality of Web servers13, an AP server14, and a DB sever15.

As illustrated inFIG. 1, the load distribution apparatus12, the Web servers13, the AP server14, and the DB server15are respectively connected via routers22to25. In addition, in the example illustrated inFIG. 1, a firewall32is installed between the Web servers13and the AP server14. In addition, in the example illustrated inFIG. 1, the test terminal11is connected to the load distribution apparatus12via a router21and a network31. In addition, in the example illustrated inFIG. 1, the scenario creating apparatus100is connected to the AP server14and the load distribution apparatus12.

The test terminal11is a terminal apparatus such as a personal computer operated by a tester. The load distribution apparatus12receives a request from the test terminal11, and transfers the received request to the Web servers13. For example, the load distribution apparatus12transfers a request in such a way that loads on the plurality of Web servers13become uniform. In response to the request from the test terminal11, the Web servers13each transmit a response containing HTML (HyperText Markup Language) data, image data, and the like to the test terminal11.

The AP server14has applications for implementing various kinds of service provided by the information processing system1. In the example illustrated inFIG. 1, the AP server14receives a request from the Web servers13, and performs various kinds of processing in accordance with the received request. Specifically, by transmitting a request to the DB server15, the AP server14acquires various kinds of data from the DB server15, or updates various kinds of data held on the DB server15.

The DB server15stores various kinds of information. In the example illustrated inFIG. 1, the DB server15receives a request for access to a database from the AP server14, and controls access to the database. Specifically, in accordance with a request received from the AP server14, the DB server15references or updates the database, and transmits a response containing the reference result or update result to the AP server14.

Under such configuration, when testing is carried out by the tester on the information processing system1, the scenario creating apparatus100according to Embodiment 1 creates a test scenario for replicating such testing.

Specifically, when testing is carried out by the tester on the information processing system1, the scenario creating apparatus100collects various kinds of message transmitted/received by the test terminal11and between the individual servers. In the example illustrated inFIG. 1, the scenario creating apparatus100collects messages transmitted/received between the test terminal11and the load distribution apparatus12, and messages transmitted/received between the load distribution apparatus12and the Web servers13, by using a port monitoring (also expressed as capture in some cases) function from a router22to which the load distribution apparatus12is connected. In addition, the scenario creating apparatus100collects messages transmitted/received between the Web servers13and the AP server14, and messages transmitted/received between the AP server14and the DB server15, by using a port monitoring function from a router24to which the AP server14is connected.

Subsequently, the scenario creating apparatus100stores, among the collected messages, related messages in association with each other. The expression “related messages” as used herein refers to requests and responses transmitted/received between individual servers in response to predetermined requests and responses.

For example, in a case when a request Req1is transmitted from the load distribution apparatus12to the Web servers13, and a request Req2is transmitted from the Web servers13to the AP server14in response to the request Req1, the requests Req1and Reg2are related. Also, suppose that a request Req3is transmitted from the AP server14to the DB server15in response to the request Req2, and a response Res1is transmitted from the DB server15to the AP server14in response to the request Req3. In such a case, the requests Req1, Req2, and Req3, and the response Res1are related.

It should be noted that in the following, the process from when a request is transmitted from the test terminal11to the load distribution apparatus12to when a response is transmitted from the load distribution apparatus12to the test terminal11in response to the request will be referred to as “transaction”. Also, in the following, each group of messages within the same transaction which are associated with each other by the scenario creating apparatus100will be referred to as “work model”.

Subsequently, the scenario creating apparatus100sorts generated work models in ascending order of the time when access to the DB server15is started. Then, the scenario creating apparatus100generates a scenario on the basis of the sorted work models.

Referring to the example illustrated inFIG. 24, when the test T11is carried out, the scenario creating apparatus100collects messages transmitted/received in operations S11, S12, S17, S18, S21, and S22. Then, the scenario creating apparatus100generates a work model M1by associating the collected messages with each other. In addition, when the test T12is carried out, the scenario creating apparatus100collects messages transmitted/received in operations S13, S14, S15, S16, S19, and S20, thereby generating a work model M2.

Then, since the test T12makes access to the DB server15earlier than the test T11, the scenario creating apparatus100sorts the work models in the order of the work model M2and the work model M1. Then, the scenario creating apparatus100creates a scenario on the basis of the sorted work models M2and M1.

The scenario created in this way serves as test data for carrying out testing in the order of the test T12and the test T11. Specifically, when the above-mentioned scenario is executed by the test terminal11, first, the work model M2is executed, and then the work model M1is executed. That is, the work model M1makes access to the DB server15after access to the DB server15is made by the work model M2. Therefore, upon executing the above-mentioned scenario when the information processing system1is operating properly, the test terminal11can receive the same responses as the responses received when the tests T11and T12are performed. Therefore, the test terminal11can correctly perform test pass/fail determination by using the scenario generated by the scenario creating apparatus100.

In this way, the scenario creating apparatus100according to Embodiment 1 collects messages transmitted/received between individual servers, and associate messages transmitted/received within the same transactions with each other to generate work models. Then, the scenario creating apparatus100sorts the generated work models in ascending order of the time when access to the DB server15is started, thereby creating a scenario.

That is, the scenario creating apparatus100generates a scenario in such a way that the order of access to the DB server15when testing is carried out by the tester, and the order of access to the DB server15at the time when the scenario is executed become the same. Thus, the scenario generated by the scenario creating apparatus100makes it possible to determine pass/fail of testing correctly.

It should be noted that the scenario creating apparatus100according to Embodiment 1 also performs various kinds of processing other than those described above. For example, after sorting work models, the scenario creating apparatus100creates a scenario by multiplexing those work models which do not cause any problem even when carried out in parallel. By way of example, in the example illustrated inFIG. 24, if a table in the database accessed in the test T11and a table in the database accessed in the test T12are different, there is no problem in carrying out the test T11and the test T12in parallel. In such a case, the scenario creating apparatus100creates a scenario by multiplexing the work model corresponding to the test T11, and the work model corresponding to the test T12. Hereinbelow, the configuration of the scenario creating apparatus100will be described, and also various kinds of processing including such multiplexing will be specifically described.

Configuration of Scenario Creating Apparatus According to Embodiment 1

Next, referring toFIG. 2, the configuration of the scenario creating apparatus100according to Embodiment 1 will be described.FIG. 2depicts an exemplary configuration of the scenario creating apparatus100according to Embodiment 1. In the example illustrated inFIG. 2, the scenario creating apparatus100has an interface (hereinafter, referred to as “IF”) unit110, an input unit120, an output unit130, a control unit140, a work model storing unit151, and a scenario storing unit152.

The IF unit110transmits/receives various kinds of data to/from an external apparatus. In the example illustrated inFIG. 1, the IF unit110of the scenario creating apparatus100receives messages transmitted/received between individual serves, by using a port monitoring function from the router22to which the load distribution apparatus12is connected and from the router24to which the AP server14is connected.

The input unit120is an input device for inputting various kinds of information and operational instructions, and is, for example, a keyboard or a mouse. The tester performs testing by operating the input unit120. The output unit130is an output device for outputting various kinds of information, and is, for example, a liquid crystal panel or a speaker. The tester determines pass/fail of testing by checking information displayed on the output unit130, for example.

The control unit140has an internal memory for storing a control program, programs specifying various kinds of procedure and the like, and necessary data, and controls the scenario creating apparatus100as a whole. As in the example illustrated inFIG. 2, the control unit140according to Embodiment 1 has a collector141, an association unit142, a sorter143, a swapper144, a multiplexer145, and a scenario creating unit146.

The collector141collects messages transmitted/received between individual servers when the operation of the information processing system1is being verified by the tester. Specifically, the collector141collects various kinds of message transmitted/received between the load distribution apparatus12and servers such as the Web servers13when a request is transmitted by the test terminal11to the load distribution apparatus12, via the IF unit110.

Referring toFIG. 3, message collection performed by the collector141will be described.FIG. 3depicts an example of message collection performed by the collector141. In the example illustrated inFIG. 3, testing is performed by using test terminals11ato11c. As illustrated inFIG. 3, when testing is being performed by using the test terminals11ato11c, requests are transmitted from the test terminals11ato11cto the load distribution apparatus12. Thus, requests and responses are transmitted/received between the load distribution apparatus12and the Web servers13, between the Web servers13and the AP server14, and between the AP server14and the DB server15. The collector141collects requests and responses transmitted/received between the servers, and retains the requests and responses as capture data.

Now, referring toFIG. 4, messages collected by the collector141will be described.FIG. 4depicts an example of messages collected by the collector141. As in the example illustrated inFIG. 4, the collector141collects, as requests to be transmitted from the load distribution apparatus12to the Web servers13, for example, an HTTP request, the time (time stamp) at which the HTTP request is transmitted, and the like. In addition, as responses to be transmitted from the Web servers13to the load distribution apparatus12, the collector141collects, for example, an HTTP response, a time stamp of when the HTTP response is transmitted, an HTTP status code, and the like.

As illustrated inFIG. 4, the collector141collects, as requests to be transmitted from the Web servers13to the AP server14, for example, a message containing information for identifying an application, a time stamp, and the like. Also, the collector141collects, as responses to be transmitted from the AP server14to the Web servers13, for example, a return value, a time stamp, and the like.

As illustrated inFIG. 4, the collector141collects, as requests to be transmitted from the AP server14to the DB server15, for example, an SQL statement, a control statement, a time stamp, and the like. Also, the collector141collects, as responses to be transmitted from the DB server15to the AP server14, for example, an SQL execution result, a return value, a time stamp, and the like.

Returning to the explanation ofFIG. 2, among messages collected by the collector141, the association unit142associates messages transmitted/received within the same transactions with each other, thereby generating work models. The association unit142assigns each generated work model with an attribute for identifying the mode of processing performed on the DB server15. Then, the association unit142stores the work model assigned with the attribute into the work model storing unit151.

Referring toFIGS. 5 and 6, an association performed by the association unit142will be described.FIGS. 5 and 6depict an example of association performed by the association unit142. It is assumed that the messages illustrated inFIG. 5are to be transmitted/received within the same transaction. In such a case, the association unit142associates messages transmitted/received between the load distribution apparatus12and the Web servers13, messages transmitted/received between the Web servers13and the AP server14, and messages transmitted/received between the AP server14and the DB server15with each other.

In the example illustrated inFIG. 6, the test terminal11transmits a request Req11to the Web servers13via the load distribution apparatus12. Also, the Web servers13each transmit a response Res11to the test terminal11via the load distribution apparatus12. In the example illustrated inFIG. 6, the process from when the request Req11is transmitted from the test terminal11to when the response Res11is transmitted to the test terminal11represents a single transaction.

In such a case, the association unit142generates a work model by associating the requests Req11to Req16and the responses Res11to Res16illustrated inFIG. 6with each other. Then, the association unit142assigns the generated work model with an attribute, and stores the resulting work model into the work model storing unit151.

Now, a supplemental description will be given of an attribute assigned to each work model. In Embodiment 1, the association unit142assigns an attribute “update type” to a work model which performs updating to the DB server15. Also, the association unit142assigns an attribute “reference type (shared)” to a work model which does not perform updating to the DB server15and performs referencing with a shared lock. Also, the association unit142assigns an attribute “reference type (no lock)” to a work model which performs only referencing with no shared lock to the DB server15.

For example, if updating and referencing are performed in the work model M3, the association unit142assigns the work model M3with an attribute “update type”. If, for example, referencing with a shared lock and referencing with no shared lock are performed in the work model M4, the association unit142assigns the work model M4with an attribute “reference type (shared lock). If, for example, only referencing with no shared lock is performed in the work model M5, the association unit142assigns the work model M5with an attribute “reference type (no lock)”.

Referring toFIGS. 7A to 7C, a brief description will be given of “update type”, “reference type (shared lock)”, and “reference type (no lock)” mentioned above.FIG. 7Adepicts an exclusive control at the time of updating.FIG. 7Bdepicts an exclusive control at the time of referencing with a shared lock.FIG. 7Cdepicts an exclusive control at the time of referencing with no shared lock.

As illustrated inFIG. 7A, when performing updating to a table, an arbitrary transaction acquires an exclusive lock. According to Embodiment 1, when an exclusive lock is acquired by an arbitrary transaction, other transactions cannot perform referencing and updating to the same table.

As illustrated inFIG. 7B, when perform referencing to a table, an arbitrary transaction can acquire a shared lock. According to Embodiment 1, when a shared lock is acquired by an arbitrary transaction, other transactions can perform referencing but cannot perform updating.

As illustrated inFIG. 7C, it is also possible for an arbitrary transaction not to acquire a lock when perform referencing to a table. According to Embodiment 1, when a reference is being performed by an arbitrary transaction without acquiring a lock, other transactions can perform referencing and updating to the same table.

Returning to the explanation ofFIG. 2, the sorter143sorts work models generated by the association unit142in ascending order of the start time of access to the DB server15. Specifically, the sorter143acquires work models from the work model storing unit151, and merges the acquired work models. Then, the sorter143sorts the merged work models in ascending order of the start time of access to the DB server15.

Referring toFIGS. 8A to 8C, a description will be given of sorting performed by the sorter14.FIG. 8Adepicts three work models M11to M13. This illustrates a case in which three transactions are generated in a single test.FIG. 8Bdepicts two work models M21and M22. This illustrates a case in which two transactions are generated in a single test.

It should be noted that in the examples illustrated inFIGS. 8A and 8B, “(Table X update)” illustrated inside each rectangle representing a work model indicates that updating is performed to Table X in the work model. Also, “(Table X shared)” illustrated inside each rectangle representing a work model indicates that referencing with a shared lock is performed to Table X in the work model. Also, “(Table X reference)” illustrated inside each rectangle representing a work model indicates that referencing with no shared lock is performed to Table X in the work model. Also, numerical values illustrated in the portion after “start” illustrated inside each rectangle representing a work model indicates the time at which access to the DB server15is started, and numerical values illustrated in the portion after “finish” indicates the time at which access to the DB server15is finished.

That is, the work model M11illustrated inFIG. 8Aindicates that a reference is performed to Table A, access to the DB server15is started at “12 h 00 m 00 s”, and access to the DB server15is finished at “12 h 00 m 01 s”. The work model M12illustrated inFIG. 8Aindicates that updating is performed to Table B, access to the DB server15is started at “12 h 02 m 00 s”, and access to the DB server15is finished at “12 h 02 m 01 s”.

Now, suppose that the work models M11to M13, M21, and M22illustrated inFIGS. 8A and 8Bare stored in the work model storing unit151. In such a case, as illustrated in the example illustrated inFIG. 8C, the sorter143merges the work models M11to M13, M21, and M22acquired from the work model storing unit151, and then sorts the work models in the order of the work models M11, M12, M21, M22, and M13. Thus, the work models M11, M12, M21, M22, and M13are rearranged in ascending order of the start time of access to the DB server15.

Returning to the explanation ofFIG. 2, in order for multiplexing to be efficiently performed by the multiplexer145described later, the swapper144swaps the order of the work models sorted by the sorter143so that work models with the same attribute become adjacent to each other. Specifically, the swapper144makes reference-type work models adjacent to each other, and makes update-type work models adjacent to each other. At this time, if, after an update-type work model, a reference-type work model that references a table updated by such an update-type work model is placed, the swapper144does not swap the order of the update-type work model and the reference-type work model.

In Embodiment 1, by using a bubble sort, the swapper144swaps the order of work models while comparing each two adjacent work models. Specifically, the swapper144performs swapping beginning with the work model whose access start time is closest to the current time. For example, when performing swapping with respect to the work models illustrated inFIG. 8C, first, the swapper144compares the work model M13placed at the rear end with the work model M22placed second from the rear end. Subsequently, the swapper144compares the work models placed second and third from the rear end with each other, and then compares the work models placed third and fourth from the rear end with each other.

FIG. 9depicts conditions upon which work models are swapped by the swapper144. The example illustrated inFIG. 9indicates such a condition that a reference-type work model be placed before an update-type work model. In the example illustrated inFIG. 9, the “Current work model” indicates, of two work models to be compared, the work model located in rear of the other, and the “immediately preceding work model” indicates, of two work models to be compared, the work model located in front of the other. In other words, the “current work model” indicates, of two work models to be compared, the work model closer to the current time. Also, in the example illustrated inFIG. 9, the “tables to be referenced/updated” indicates whether or not the tables referenced or updated in the “current work model” and the “immediately preceding work model” are the same.

For example, as illustrated inFIG. 9, if the attribute of the current work model is “update type”, the swapper144does not swap the work models to be compared, irrespective of the attribute of the immediately preceding work model. This is because, as described above, the example illustrated inFIG. 9indicates a condition that a reference-type work model be placed before an update-type work model.

Also, for example, as illustrated inFIG. 9, if the attribute of the current work model is “reference type”, and the attribute of the immediately preceding work model is “update type”, the swapper144determines whether or not the “tables to be referenced/updated” by the two work models are the same. Then, if the tables to be updated by the two work models are the same, the swapper144does not swap the two work models.

This is because if works models that access the same table are arranged in the order of “update type and reference type”, it is required that the two work models be processed in that order. For example, if a work model M7that performs referencing to Table A is placed after a work model M6that performs updating to Table A, it is required that the work model M7be executed after Table A is updated by the work model M6. Therefore, in the case of the above-mentioned example, the swapper144does not swap the order of the work models M6and M7.

On the other hand, if the “tables to be referenced/updated” by the two work models are different in the above-mentioned example, the swapper144swaps the two work models. This is because, as described above, the swapper144according to Embodiment 1 places a reference-type work model before an update-type work model.

Now, referring toFIGS. 10A and 10B, swapping performed by the swapper144will be described.FIGS. 10A and 10Bdepict an example of swapping performed by the swapper144.FIG. 10Adepicts an example of work models sorted by the sorter143. It should be noted that the work models illustrated inFIG. 10Aare the same as the work models illustrated inFIG. 8C. The swapper144swaps the work models illustrated inFIG. 10Ain accordance with the conditions illustrated inFIG. 9. Specifically, as illustrated inFIG. 10B, the swapper144swaps the work models in the order of the work models M11, M21, M12, M22, and M13. In this way, the swapper144swaps the order of the work models sorted by the sorter143, in accordance with the conditions illustrated inFIG. 9.

Returning to the explanation ofFIG. 9, the multiplexer145multiples the work models that have been swapped by the swapper144. Specifically, among the work models that have been swapped by the swapper144, the multiplexer145rearranges those work models which may be executed in parallel into parallel. In Embodiment 1, the multiplexer145swaps the order of work models while comparing each two adjacent work models by using a bubble sort. Specifically, among work models that have been swapped by the swapper144, the multiplexer145performs multiplexing beginning with the work model placed in the rear.

FIG. 11depicts conditions upon which work models are multiplexed by the multiplexer145. The multiplexer145multiplexes work models that have been swapped by the swapper144, in accordance with the conditions illustrated inFIG. 11.

For example, as illustrated inFIG. 11, if “tables to be referenced/updated” by two work models to be compared are different, the multiplexer145rearranges such two work models in parallel. This is because if the “tables to be referenced/updated” by two models are different, such two models may be executed in parallel.

Also, if two work models to be compared are both “reference type” as illustrated inFIG. 11, the multiplexer145rearranges the two work models to be compared in parallel, irrespective of whether or not the “tables to be referenced/updated” are the same. This is because if two work models are “reference type”, such two work models may be executed in parallel irrespective of whether the “tables to be referenced/updated” are the same.

Now, referring toFIGS. 12A and 12B, multiplexing performed by the multiplexer145will be described.FIG. 12Adepicts an example of work models that have been swapped by the swapper144. It should be noted that the work models illustrated inFIG. 12Aare the same as the work models illustrated inFIG. 10B.

The multiplexer145swaps the work models illustrated inFIG. 12Ain accordance with the conditions illustrated inFIG. 11. Specifically, as illustrated inFIG. 12B, the multiplexer145rearranges the work models M11, M21, and M12in parallel, and also rearranges the work models M22and M13in parallel. The work models illustrated inFIG. 12Bindicate that the work model M11, M21, and M12are executed in parallel, and the work model M22and M13are executed in parallel.

Also, in addition to the multiplexing described above, the multiplexer145assigns information indicating that synchronization is to be performed (hereinafter, referred to as “synchronization information”). Specifically, the multiplexer145assigns synchronization information if the condition illustrated in the Remarks inFIG. 11is met.

The above-mentioned processing will be described by way of an example. For example, suppose that two adjacent work models are placed in the order of “the work model M8and the work model M9”. Then, suppose that the work model M8is a reference-type one, and the work model M9is an update-type one. In such a case, the multiplexer145assigns synchronization information between the work model M8and the work model M9so that the work model M9is executed after execution of the work model M8is finished. This is to prevent the work model M9from being executed while the reference-type work model M8is being executed.

Referring toFIGS. 12C and 12D, synchronization information assignment performed by the multiplexer145will be described.FIG. 12Cdepicts an example of synchronization information assignment performed by the multiplexer145.FIG. 12Cillustrates an example of work models that have been swapped by the swapper144. It is assumed that among the work models illustrated inFIGS. 12C and 12D, work models M31to M37and M39all reference or update the same table. That is, among the work models illustrated inFIGS. 12C and 12D, a work model M38performs updating to a table different from the table updated by the work models M31to M37and M39.

In such a case, the multiplexer145rearranges the work models illustrated inFIG. 12Cinto the order as illustrated inFIG. 12D, in accordance with the conditions illustrated inFIG. 11. Then, the multiplexer145assigns synchronization information between the work models M31to M33and the work model M34. That is, the multiplexer145assigns synchronization information indicating that the work model M34is not to be executed until execution of the work models M31to M33is finished. Thus, the multiplexer145can prevent the work model M34from being executed before execution of the work models M31to M33is finished.

The multiplexer145also assigns synchronization information between the work models M35and M36, and the work models M37and M38. Thus, the multiplexer145can prevent the work models M37and M38from being executed before execution of the work models M35and M36is finished.

Returning to the explanation ofFIG. 2, the scenario creating unit146creates a scenario on the basis of the work models that have been multiplexed by the multiplexer145, and stores the created scenario into the scenario storing unit152. The scenario created by the scenario creating unit146makes access to the DB server15in the same order in which the DB server15is accessed when testing is performed by the tester. Thus, the scenario created by the scenario creating unit146makes it possible to determine pass/fail of testing correctly. In addition, in the scenario created by the scenario creating unit146, work models that meet the conditions illustrated inFIG. 11are executed in parallel. Thus, the scenario created by the scenario creating unit146can reduce the time required for test execution.

It should be noted that in cases such as when it is not necessary to reduce the time required for test execution, the scenario creating unit146may create a scenario on the basis of work models sorted by the sorter143.

Next, referring toFIG. 13, the procedure of scenario creation performed by the scenario creating apparatus100will be described.FIG. 13depicts a flowchart of a scenario creation procedure performed by the scenario creating apparatus100.

As illustrated inFIG. 13, when operation of the information processing system1is being verified by the tester (Yes in operation S11), the collector141of the scenario creating apparatus100collects messages transmitted/received between individual servers (operation S12).

Subsequently, among the messages collected by the collector141, the association unit142associates messages transmitted/received within the same transactions with each other, thereby generating work models (operation S13).

Subsequently, the sorter143performs sorting (operation S14). Specifically, the sorter143sorts the work models generated by the association unit142in ascending order of the start time of access to the DB server15. It should be noted that the sorting performed by the sorter143will be described later with reference toFIG. 14.

Subsequently, the swapper144performs swapping (operation S15). Specifically, the swapper144swaps the order of the work models sorted by the sorter143so that work models of the same attribute become adjacent to each other. It should be noted that the swapping performed by the swapper144will be described later with reference toFIGS. 15 and 16.

Subsequently, the multiplexer145performs multiplexing (operation S16). Specifically, the multiplexer145multiplexes the work models that have been swapped by the swapper144. It should be noted that the multiplexing performed by the multiplexer145will be described later with reference toFIGS. 17 to 21.

Then, the scenario creating unit146creates a scenario on the basis of the work models that have been multiplexed by the multiplexer145, and stores the created scenario into the scenario storing unit152(operation S17).

Next, referring toFIG. 14, the procedure of the sorting illustrated in operation S14inFIG. 13will be described.FIG. 14depicts a flowchart of a sorting procedure performed by the sorter143. In the following, the description will be given by way of the examples illustrated inFIGS. 8A and 8B.

First, in the example illustrated inFIG. 14, the sorter143merges work models stored in the work model storing unit151, and then substitutes each of the merged work models into an array Z(i). For example, when the work model storing unit151is in the state as illustrated inFIG. 8A, the sorter143substitutes the work models M22, M21, M13, M12, and M11into Z(1) to Z(5), respectively.

Then, as illustrated inFIG. 14, the sorter143substitutes the number of elements into a variable n (operation S101). The term “number of elements” as used herein refers to the number of work models stored in the work model storing unit151. For example, when the work model storing unit151is in the state illustrated inFIG. 8A, the number of work models is “5”, so the sorter143substitutes “5” into n.

Subsequently, the sorter143repeats the procedure in operations S102to S110until a condition “n≦1” is met. Here, since “n=5”, the condition “n≦1” is not met. Therefore, the sorter143substitutes “1” into a variable i (operation S103).

Then, the sorter143repeats the procedure in operations S104to S108until a condition “i=n” is met. Here, since “n=5” and “i=1”, the condition “i=n” is not met. Therefore, the sorter143compares the start time of access to the DB server15in the work model of Z(i), with the start time of access to the DB server15in the work model of Z(i+1) (operation S105).

Then, if the access start time in Z(i) is not larger than the access start time in Z(i+1), the sorter143swaps the work model substituted in Z(i) and the work model substituted in Z(i+1) (operation S106). Specifically, as illustrated inFIG. 14, after substituting the work model substituted in Z(i) into a work variable w, the sorter143substitutes the work model substituted in Z(i+1) into Z(i), and substitutes the work model substituted in the work variable w into Z(i+1).

It should be noted that the expression “time A is larger than time B” as used in this specification means that time A is closer to the current time than time B. In other words, the expression “time A is smaller than time B” means that time A is past with reference to time B.

On the other hand, if the access start time in Z(i) is larger than the access start time in Z(i+1), the sorter143does not swap the work model substituted in Z(i) and the work model substituted in Z(i+1).

Here, since “i=1”, the sorter143compares Z(1) and Z(2) with each other. That is, in the case of the above-mentioned example, the sorter143compares the access start time in the work model M22with the access start time in the work model M21. As illustrated inFIG. 8A, the access start time in the work model M22is larger than the access start time in the work model M21, so the sorter143does not swap the order of the work model M22and the work model M21.

Subsequently, the sorter143increments the variable i (operation S107). Here, the sorter143updates the variable i to “2”. That is, since “n=5” and “i=2”, the condition “i=n” in operation S104is not met. Therefore, the sorter143performs the processing in operations S105to S107. Specifically, the sorter143compares Z(2) with Z(3).

That is, in the case of the above-mentioned example, the sorter143compares the access start time in the work model M21with the access start time in the work model M13. As illustrated inFIG. 8A, the access start time in the work model M21is not larger than the access start time in the work model M13, so the sorter143swaps the order of the work model M21and the work model M13.

In this way, the sorter143repeats the procedure in operations S104to S108until the condition “i=n” in operation S104is met. Then, when the condition “i=n” is met, the sorter143decrements the variable n (operation S109). Then, the sorter143repeats the procedure in operations S102to5110until the condition “n≦1” in operation S102is met.

Next, referring toFIG. 15, a description will be given of the procedure of the swapping illustrated in operation S15inFIG. 13.FIG. 15depicts a flowchart of a swapping procedure performed by the swapper144. It should be noted that inFIG. 15, the description will be given by way of the example illustrated inFIG. 10. Also, inFIG. 15, it is assumed that each of work models obtained after executing the procedure illustrated inFIG. 14is substituted into an array Z(i). That is, here, the work models M13, M22, M21, M12, and M11are substituted into Z(1) to Z(5), respectively.

First, as illustrated inFIG. 15, the swapper144substitutes the number of elements into a variable n (operation S201). In the case of the above-mentioned example, the number of work models is “5”, so the swapper144substitutes “5” into n.

Subsequently, the swapper144repeats the procedure in operations S202to S211until a condition “n≦1” is met. Here, since “n=5”, the condition “n≦1” is not met. Therefore, the swapper144substitutes “1” into a variable i (operation S203).

Then, the swapper144repeats the procedure in operations S204to S209until a condition “i=n” is met. Here, since “n=5” and “i=1”, the condition “i=n” is not met. Therefore, the swapper144performs swapping determination by comparing Z(i) with Z(i+1) (operation S205). It should be noted that the swapping determination performed by the swapper144will be described later with reference toFIG. 16.

If it is determined as a result of the swapping determination to “perform swapping” (Yes in operation S206), the swapper144swaps the work model substituted in Z(i) and the work model substituted in Z(i+1) (operation S207). Specifically, as illustrated inFIG. 15, after substituting the work model substituted in Z(i) into a work variable w, the swapper144substitutes the work model substituted in Z(i+1) into Z(i), and substitutes the work model substituted in the work variable w into Z(i+1).

If it is determined as a result of the swapping determination “not to perform swapping” (No in operation S206), the swapper144does not swap the work model substituted in Z(i) and the work model substituted in Z(i+1).

Subsequently, the swapper144increments the variable i (operation S208). Here, the swapper144updates the variable i to “2”. That is, since “n=5” and “i=2”, the condition “i=n” in operation S204is not met. Therefore, the swapper144performs the processing in operations S205to S208.

In this way, the swapper144repeats the procedure in operations S204to S208until the condition “i=n” in operation S204is met. Then, when the condition “i=n” is met, the swapper144decrements the variable n (operation S210). Then, the swapper144repeats the procedure in operations S202to S211until the condition “n≦1” in operation S202is met.

Next, referring toFIG. 16, a description will be given of the procedure of the swapping determination illustrated in operation S205inFIG. 15.FIG. 16depicts a flowchart of a swapping determination procedure performed by the swapper14. It should be noted that inFIG. 16, as in the example illustrated inFIG. 15, it is assumed that each of work models obtained after executing the procedure illustrated inFIG. 14is substituted into an array Z(i).

When performing swapping determination, first, the swapper144substitutes the name of a table referenced or updated in the work model of Z(i) into a variable ZT(i) (operation S301). Also, the swapper144substitutes the name of a table referenced or updated in the work model of Z(i+1) into a variable ZT(i+1) (operation S301).

Subsequently, if the work model of Z(i) is “update type” (Yes in operation S302), the swapper144determines “not to perform swapping” (operation S303). Specifically, the swapper144determines not to perform swapping of Z(i) and Z(i+1). This indicates a case in which, among the conditions illustrated inFIG. 9, the “attribute of current work model” is “update type”.

On the other hand, if the work model of Z(i) is not “update type” (No in operation S302), the swapper144determines whether or not ZT(i) and ZT(i+1) are equal (operation S304). Then, if ZT(i) and ZT(i+1) are equal (Yes in operation S304), the swapper144determines “not to perform swapping” (operation S305). This indicates a case in which, among the conditions illustrated inFIG. 9, the “attribute of current work model” is “reference type (shared)” or “reference type (no lock)”, and that the “tables to be referenced/updated” are the “same”.

On the other hand, if ZT(i) and ZT(i+1) are different (No in operation S304), the swapper144determines to “perform swapping” (operation S306). This indicates a case in which, among the conditions illustrated inFIG. 9, the “attribute of current work model” is “reference type (shared)” or “reference type (no lock)”, and that the “tables to be referenced/updated” are “different”.

This will be described by way of the above-mentioned example. If “i=1”, the work model of Z(i)=Z(1) is the work model M13, and the work model of Z(i+1)=Z(2) is the work model M22. As illustrated inFIG. 10, the attribute of the work model M13is reference type (shared) (No in operation S302). Also, as illustrated inFIG. 10, the “tables to be referenced/updated” by the work model M13and the work model M22are both Table B and are thus the “same” (Yes in operation S304). Therefore, if “i=1”, the swapper144determines not to swap the work model M13and the work model M22.

Next, referring toFIG. 17andFIGS. 18A to 18D, the procedure of the multiplexing illustrated in operation S16inFIG. 13will be described.FIG. 17depicts a flowchart of a multiplexing procedure performed by the multiplexer145.FIGS. 18A to 18Dare diagrams for explaining an example of multiplexing performed by the multiplexer145.

FIG. 18Adepicts work models M101to M121to be multiplexed. The work models M101to M121illustrated inFIG. 18Ahave been swapped by the swapper144, and are substituted into Z(1) to Z(21), respectively.

FIG. 18Bdepicts an array Y(j, k) used when multiplexing is performed by the multiplexer145. The multiplexer145performs multiplexing by substituting a work model substituted in an array Z(i) into the array Y(j, k). Here, of the array Y(j, k), work models substituted into the same row (j) indicate that these work models are executed in parallel.

FIG. 18Cdepicts an array X(j). Such an array X(j) indicates the number of work models stored in the row (j) of the array Y(j, k).FIG. 18Ddepicts an array W(j). Such an array W(j) indicates whether or not synchronization is to be performed in the row (j).

It should be noted that the array Y(j, k) illustrated inFIG. 18B, the array X(j) illustrated inFIG. 18C, and the array W(j) illustrated inFIG. 18Deach indicate a state after multiplexing is performed by the multiplexer145.

Hereinbelow, the procedure illustrated inFIG. 17will be described with reference to the examples illustrated inFIGS. 18A to 18D. It should be noted that in the initial state, the array Y(j, k) is empty.

First, as illustrated inFIG. 17, the multiplexer145performs initialization (operation S401). Specifically, the multiplexer145substitutes “0” into an array X(j) and an array W(j). It should be noted that the initialization performed by the multiplexer145will be described later with reference toFIG. 19.

Subsequently, the multiplexer145substitutes the number of elements into a variable n, and substitutes “1” into a variable i (operation S402). In the example illustrated inFIG. 18A, the number of work models is “21”, so the multiplexer145substitutes “21” into n.

Subsequently, the multiplexer145repeats the procedure in operations S403to S417until a condition “n≦1” is met. Here, since “n=21”, the condition “n≦1” is not met. Therefore, the multiplexer145substitutes “i” into a variable j (operation S404). Here, since “i=1”, the multiplexer145substitutes “1” into the variable j.

Subsequently, the multiplexer145repeats the procedure in operations S405to S413until a condition “j<1” is met. Here, since “j=1”, the condition “j<1” is not met. Therefore, the multiplexer145substitutes X(j) into a variable k (operation S406). Here, since “j=1”, the multiplexer145substitutes “0” into the variable k.

Subsequently, the multiplexer145repeats the procedure in operations S407to S411until a condition “k<1” is met. Here, since “k=0”, the condition “k<1” is met. Therefore, the multiplexer145decrements the variable j (operation S412). Here, since “j=1”, the multiplexer145updates the variable j to a value “0” equal to “1” subtracted by “1”.

Subsequently, the multiplexer145determines whether or not a condition “j<1” in operation S405is met. Here, since “j=0”, the condition “j<1” is met. Therefore, the multiplexer145performs the procedure in operation S414.

Specifically, the multiplexer145updates the variable j from “0” to “1”. Also, the multiplexer145substitutes “X(j)+1” into X(j). Here, since “j=1” and “X(1)=0”, the multiplexer145substitutes “0+1” into X(1). In addition, the multiplexer145substitutes X(j) into the variable k. Here, since “X(1)=1”, the multiplexer145substitutes “1” into the variable k. Also, the multiplexer145substitutes Z(i) into Y(j, k). Here, since “i=1”, “j=1”, “k=1”, and the work model M101is substituted in Z(1), as illustrated inFIG. 18B, the multiplexer145substitutes the work model M101into Y(1,1).

Subsequently, the multiplexer145performs synchronization setting (operation S415). It should be noted that the synchronization setting performed by the multiplexer145will be described later with reference toFIG. 21. Subsequently, the multiplexer145decrements the variable n, and increments the variable i. Here, the multiplexer145updates the variable n from “21” to “20”, and updates the variable i from “1” to “2”.

Subsequently, the multiplexer145determines whether or not the condition “n≦1” in operation S403is met. Here, since “n=20”, the condition “n≦1” is not met. Therefore, the multiplexer145substitutes i into the variable j (operation S404). Here, since “i=2”, the multiplexer145substitutes “2” into the variable j.

Subsequently, the multiplexer145determines whether or not the condition “j<1” in operation S405is met. Here, since “j=2”, the condition “j<1” is not met. Therefore, the multiplexer145substitutes X(j) into the variable k (operation S406). Here, since “j=2”, and “X(2)=0”, the multiplexer145substitutes “0” into the variable k.

Subsequently, the multiplexer145determines whether or not the condition “k<1” in operation S407is met. Here, since “k=0”, the condition “k<1” is met. Therefore, the multiplexer145updates the variable j from “2” to “1” (operation S412).

Subsequently, the multiplexer145determines whether or not the condition “j<1” in operation S405is met. Here, since “j=1”, the condition “j<1” is not met. Therefore, the multiplexer145substitutes X(j) into the variable k (operation S406). Here, since “j=1”, and “X(1)=1”, the multiplexer145substitutes “1” into the variable k.

Subsequently, the multiplexer145determines whether or not the condition “k<1” in operation S407is met. Here, since “k=1”, the condition “k<1” is not met. Therefore, the multiplexer145performs multiplexing determination (operation S408). It should be noted that the multiplexing determination performed by the multiplexer145will be described later with reference toFIG. 20.

If it is determined to perform multiplexing as a result of the multiplexing determination, the multiplexer145decrements the variable k (operation S410). On the other hand, if it is determined not to perform multiplexing, the multiplexer145performs the procedure in operation S414.

It should be noted that here, since the multiplexer145determines not to perform multiplexing, the multiplexer145performs the procedure in operation S414. Specifically, the multiplexer145updates the variable j from “1” to “2”. Also, the multiplexer145substitutes “X(j)+1” into X(j). Here, since “j=2” and “X(2)=0”, the multiplexer145substitutes “0+1” into X(2). Also, the multiplexer145substitutes X(j) into the variable k. Here, since “X(2)=1”, the multiplexer145substitutes “1” into the variable k. In addition, the multiplexer145substitutes Z(i) into Y(j, k). Here, since “i=2”, “j=2”, “k=1”, and the work model M102is substituted in Z(2), as illustrated inFIG. 18B, the multiplexer145substitutes the work model M102into Y(2,1).

In this way, the multiplexer145performs the above-described procedure until the condition “n≦1” in operation S403is met. Thus, as illustrated inFIG. 18B, the work models M101to M121substituted in the array Z(i) illustrated inFIG. 18Aare substituted into the array Y(j, k). The example illustrated inFIG. 18Billustrates that work models substituted in the same row are multiplexed. For example, it is illustrated that the work models M101and M103are multiplexed. Then, the example illustrated inFIG. 18Billustrates that after the work models M101and M103are executed in parallel, the work models M102, M105, and M107are executed in parallel. Then, the example illustrated inFIG. 18Billustrates that the work models M118and M120are executed lastly.

Next, referring toFIG. 19, the procedure of the initialization illustrated in operation S401inFIG. 17will be described.FIG. 19depicts a flowchart of an initialization procedure performed by the multiplexer145.

As illustrated inFIG. 19, the multiplexer145first substitutes the number of elements into a variable n (operation S501). Subsequently, the multiplexer145repeats the procedure in operations S502to S505until a condition “n≦1” is met.

Specifically, the multiplexer145substitutes “0” into an array X(n) and an array W(n) (operation S503). Subsequently, the multiplexer145decrements the variable n (operation S504). That is, the multiplexer145substitutes “0” into elements X(1) to X(n) of the array X(n), and elements W(1) to W(n) of the array W(n).

Next, referring toFIG. 20, the procedure of the multiplexing determination illustrated in operation S408inFIG. 17will be described.FIG. 20depicts a flowchart of a multiplexing determination procedure performed by the multiplexer145.

When performing multiplexing determination, first, the multiplexer145substitutes the name of a table referenced or updated in the work model of Z(i) into a variable ZT(i) (operation S601). Also, the multiplexer145substitutes the name of a table referenced or updated in the work model of Y(j, k) into a variable YT(j, k) (operation S601).

Subsequently, the multiplexer145determines “not to perform multiplexing” if the work model of Z(i) is “update type” (Yes in operation S602), and ZT(i) and YT(j, k) are equal (Yes in operation S603) (operation S604).

On the other hand, the multiplexer145determines to “perform multiplexing” if the work model substituted in Z(i) is “update type” (Yes in operation S602), and ZT(i) and YT(j, k) are different (No in operation S603) (operation S605).

If the work model substituted in Z(i) is not “update type” (No in operation S602), the multiplexer145determines whether or not the work model substituted in Y(j, k) is “update type” (operation S606).

Then, if the work model substituted in Y(j, k) is “update type” (Yes in operation S606), and ZT(i) and YT(j, k) are equal (Yes in operation S607), the multiplexer145determines “not to perform multiplexing” (operation S608).

On the other hand, if the work model substituted in Y(j, k) is “update type” (Yes in operation S606), and ZT(i) and YT(j, k) are different (No in operation S607), the multiplexer145determines to “perform multiplexing” (operation S609).

Also, if the work model substituted in Y(j, k) is not “update type” (No in operation S606), the multiplexer145determines to “perform multiplexing” (operation S610). In this way, the multiplexer145determines whether or not to perform multiplexing, in accordance with the conditions illustrated inFIG. 11.

Next, referring toFIG. 21, a description will be given of the procedure of the synchronization setting illustrated in operation S415inFIG. 17.FIG. 21depicts a flowchart of a synchronization setting procedure performed by the multiplexer145.

As illustrated inFIG. 21, when performing synchronization setting, the multiplexer145first decrements a variable j (operation S701). Subsequently, the multiplexer145determines whether or not the variable j is smaller than “1” (operation S702).

Then, if the variable j is smaller than “1”, the multiplexer145ends the processing. On the other hand, if the variable j is not smaller than “1”, the multiplexer145substitutes the value of X(j) into a variable k (operation S703).

Subsequently, the multiplexer145repeats the procedure in operations S704to S708until a condition “k≦1” is met. Specifically, the multiplexer145compares Z(i) with Y(j, k), and if Z(i) is update type and Y(j, k) is reference type, the multiplexer145determines that synchronization setting is unnecessary (operation S705). Then, the multiplexer145decrements the variable k (operation S706).

On the other hand, if Z(i) is not update type, or if Y(j, k) is not reference type, the multiplexer145determines that synchronization setting is necessary (operation S705). Then, the multiplexer145increments the variable j, and substitutes “1” into W(j) (operation S707).

For example, if the multiplexer145has performed multiplexing with respect to the work models M101to M121illustrated inFIG. 18A, the multiplexer145substitutes the values illustrated inFIG. 18Dinto the array W(j). This indicates that of the array Y(j, k), synchronization information is assigned to the rows of “j=3 to 6”.

Advantages of Embodiment 1

As described above, the scenario creating apparatus100according to Embodiment 1 collects messages transmitted/received between individual servers, and associates messages transmitted/received within the same transactions with each other to generate work models. Then, the scenario creating apparatus100sorts the generated work models in ascending order of the start time of access to the DB server15, thereby creating a scenario. Thus, the scenario creating apparatus100can create a scenario that makes it possible to determine pass/fail of testing correctly.

In addition, since the scenario creating apparatus100according to Embodiment 1 multiplexes the work models sorted in ascending order of the start time of access to the DB server15, it is possible to create a scenario that requires a short test execution time.

Further, since the scenario created by the scenario creating apparatus100has been multiplexed, the scenario can be also used for load testing. Also, since the scenario created by the scenario creating apparatus100retains messages transmitted/received between individual servers, when the result of test verification is NG, it is possible to identify between which servers an error has occurred. Thus, use of the scenario generated by the scenario creating apparatus100makes it possible to identify the location of an error with ease and in a short time.

Incidentally, the scenario creating apparatus or the like disclosed by this application may be implemented in various other modes other than the above-described embodiment. Accordingly, in Embodiment 2, another embodiment of the scenario creating apparatus or the like disclosed by this application will be described.

[Attribute of Work Model]

Embodiment 1 mentioned above illustrates an example in which, as illustrated inFIGS. 9 and 11, it is determined with respect to two adjacent work models whether or not the “tables to be referenced/updated” are the same. Now, a case is also conceivable in which a plurality of tables are referenced or updated by a single work model. In such a case, the swapper144or the multiplexer145determines the “tables to be referenced/updated” to be the “same” if there is an overlap of even a single table referenced or updated by two work models to be compared. In other words, the swapper144or the multiplexer145determines the “tables to be referenced/updated” to be “different” if the tables referenced or updated by two work models to be compared are all different.

For example, in a case when the current work model performs updating to Tables A, B, and C, and the immediately preceding work model performs referencing to Tables C, D, and E, the swapper144or the multiplexer145determines the “tables to be referenced/updated” by the current work model and the immediately preceding work model to be the “same”. This is because both the work models perform updating or referencing to Table C.

Also, for example, in a case when the current work model performs updating to Tables A, B, and C, and the immediately preceding work model performs referencing to Tables D and E, the swapper144or the multiplexer145determines the “tables to be referenced/updated” by the current work model and the immediately preceding work model to be “different”. This is because both the work models perform referencing or updating to tables that are all different.

The various kinds of processing described in Embodiment 1 above can be implemented by executing a program prepared in advance by a computer such as a personal computer or a workstation. Accordingly, in the following, with reference toFIG. 22, a description will be given of an example of a computer that executes a scenario creating program having the same function as the scenario creating apparatus100according to Embodiment 1 mentioned above.

FIG. 22depicts a computer that executes a scenario creating program. As illustrated inFIG. 22, a computer1000has a RAM (Random Access Memory)1010, a cache1020, an HDD1030, a ROM (Read Only Memory)1040, and a CPU (Central Processing Unit)1050. The RAM1010, the cache1020, the HDD1030, the ROM1040, and the CPU1050are connected via a bus1060.

In the ROM1040, a scenario creating program that exhibits the same function as the scenario creating apparatus100according to Embodiment 1 mentioned above is stored in advance. Specifically, in the ROM1040, a collection program1041, an association program1042, a sorting program1043, a swapping program1044, a multiplexing program1045, and a scenario creating program1046are stored.

Then, the CPU1050reads the collection program1041, the association program1042, the sorting program1043, the swapping program1044, the multiplexing program1045, and the scenario creating program1046to execute these programs. Thus, as illustrated inFIG. 22, the collection program1041becomes a collection process1051, the association program1042becomes an association process1052, and the sorting program1043becomes a sorting process1053. In addition, the swapping program1044becomes a swapping process1054, the multiplexing program1045becomes a multiplexing process1055, and the scenario creating program1046becomes a scenario creating process.

It should be noted that the collection process1051corresponds to the collector141illustrated inFIG. 2, the association process1052corresponds to the association unit142illustrated inFIG. 2, and the sorting process1053corresponds to the sorter143illustrated inFIG. 2. In addition, the swapping process1054corresponds to the swapper144illustrated inFIG. 2, the multiplexing process1055corresponds to the multiplexer145illustrated inFIG. 2, and the scenario creating process1056corresponds to the scenario creating unit146illustrated inFIG. 2.

As illustrated inFIG. 22, the HDD1030is provided with scenario-creation-related data1031. The scenario-creation-related data1031corresponds to the work model storing unit151or the scenario storing unit152illustrated inFIG. 2.

It should be noted that the programs1041to1046mentioned above may not necessarily be stored in the ROM1040. For example, the programs1041to1046may be stored on a “portable physical medium” inserted into the computer1000, such as a flexible disc (FD), a CD-ROM, an MO disc, a DVD disc, a magneto-optical disc, and an IC card. Alternatively, the programs1041to1046may be stored on a “stationary physical medium” provided inside or outside the computer1000, such as a hard disk drive (HDD). Alternatively, the programs1041to1046may be stored on “another computer (or server)” connected to the computer1000via a public circuit, the Internet, the LAN, the WAN, or the like. Then, the computer1000may execute the programs by reading the programs from the flexible disc or the like mentioned above.