JP5181503B2 - Scenario creation program and scenario creation device - Google Patents

Description

  The present invention relates to a scenario creation program and a scenario creation device for creating a scenario used by a load simulator.

  As is well known, the web load test apparatus includes a load simulator and a viewer in order to apply an access load to the web server apparatus to be tested and observe the state of the web server apparatus. Among these, the load simulator generates a plurality of threads that virtually function as web clients, and a scenario that defines the order in which the web page data in the web server device to be tested is requested to the virtual web clients. This is a function for sending a request message and receiving a response message according to the scenario. The load simulator stores the response message itself received from the web server device by each virtual web client and records a response log. The viewer is a function for displaying a web page based on the web page data in the response message acquired by the virtual web client in the web load test and displaying a list of response log information.

  The scenario described above is created based on the request history when the web server device under test is actually accessed and several web pages are displayed in order before the web load test. Is data that consists of several request messages and defines their transmission order. Some request messages constituting this scenario include an argument to be delivered to the web server device by a get method or a post method.

  However, these arguments are appropriate when creating a scenario, and may not be appropriate when an access load is applied to the web server device. For example, when a virtual web client acquires a session ID [Identification] from a web server device via a response message during a web load test, the web server device originally includes the session ID in the next request message. Must be sent to However, in the web load test, the virtual web client transmits a request message including the session ID at the time of scenario creation to the web server device as it is according to the scenario data. For this reason, the web server device detects a session error based on the session ID included in the request message, and as a result, the web load test is not continued.

  Note that Patent Document 1 describes a technique in which a plurality of parameters to be changed in a scenario are prepared in advance as input parameters. However, this technique cannot be applied to a parameter such as a session ID that has a different value each time the web server device is accessed.

JP-A-2005-250945

  The present invention has been made in view of the above-described conventional circumstances, and the problem is that a virtual web client generated by a load simulator in a web load test appropriately transmits a request message and receives a response message. It is to be able to create a scenario that can be performed.

  A scenario creation program devised to solve the above problems is a scenario creation program for creating a scenario given to a plurality of virtual web clients that impose an access load on a web server device to be tested. Each time the computer receives a predetermined instruction from the operator through the input device, the request message is transmitted to the web server device based on the instruction and the response message is received from the web server device, and the request is sent. A first storage means for storing a record in which a message and a response message are associated with identification information for uniquely identifying each record, and storing the record in the scenario table in the storage device in order of request; Of the records, the request For each record that includes request parameters in the sage, search means for searching for records including response parameters having the same contents as the request parameters from the records in order before the records, and scenario table For each record that includes the request parameter in the request message among the records in the list, when the search means detects a record that is in the order before that record, the identification information of both records is associated with the storage device It is characterized by functioning as second storage means for storing in the correspondence table.

  With this configuration, each time a predetermined instruction is received from the operator, the computer executes transmission of a request message and reception of a response message, and associates the request message with the response message in the scenario table. Operates to register. After several combinations of both messages are registered in the scenario table, the computer requests the request from the records in the order earlier than the record for the record containing the request parameter among the records in the scenario table. When a record including a response parameter having the same content as the parameter is searched and the record is detected, the record in which the identification information of both records is associated is stored in the correspondence table.

  According to the scenario table and the correspondence table created by the above operation, the virtual web client sends a request parameter in the request message before sending the request message in the scenario table to the web server device to be tested. Is included, the request parameter can be replaced with the response parameter acquired during the load test based on the correspondence table. That is, parameters that should be unique values in the scenario can be identified and changed while being unique.

  A scenario creation device devised to solve the above problem is a scenario creation device for creating a scenario given to a plurality of virtual web clients that impose an access load on a web server device to be tested. Each time a predetermined instruction is received from the operator through the input device, a request message based on the instruction is transmitted to the web server device and a response message is received from the web server device, and the request message is transmitted. A first storage unit that stores identification information for uniquely identifying each record in a scenario table in the storage device in order of request, and records in the scenario table Request packet in the request message. For each record that includes a meter, a search part that searches for a record that contains a response parameter that contains the same response parameter as the request parameter from among the records that preceded that record, and records in the scenario table Among these, for each record that includes the request parameter in the request message, when the search unit detects a record that is earlier than the record, the correspondence table in the storage device is associated with the identification information of both records. It is characterized by having a second storage unit that stores the information in the memory.

  Therefore, this scenario creation device functions in the same manner as a computer on which the above-described scenario creation program of the present invention operates.

  As described above, according to the present invention, it is possible to create a scenario in which a virtual web client generated by a load simulator in a web load test can appropriately transmit a request message and receive a response message.

  Hereinafter, one embodiment for carrying out the present invention will be described with reference to the accompanying drawings.

  FIG. 1 is a configuration diagram of a computer network system according to the present embodiment.

  As shown in FIG. 1, the computer network system according to the present embodiment includes a web server device 10 to be subjected to a web load test, and a web load test device that applies an access load to the web server device 10 for the web load test. 20 Both devices 10 and 20 are connected via a network N so that they can communicate with each other.

  The web server device 10 is a general-purpose computer to which a known web server function is added. Accordingly, the web server device 10 includes hardware such as a storage unit 10a, a CPU (Central Processing Unit) 10b, a memory unit 10c, and a communication adapter 10d. Among these, the storage unit 10a is a unit that stores various programs and various data. The CPU 10b is a unit that performs processing according to a program in the storage unit. The memory unit 10c is a unit in which a program read from the storage unit is cached or a work area of the CPU 10b is expanded. The communication adapter 10d is a unit for exchanging data with other computers on the network N.

  The storage unit 10a of the web server device 10 stores basic software 11, web page data 12, and a web server program 13. The basic software 11 is software for providing many application software with basic functions such as data input / output management in the communication adapter 10d and storage area management of the storage unit 10a and the memory unit 10c. . The web page data 12 is data for displaying a web page, and is HTML [HyperText Markup Language] data or image data. The web page data 12 may include web page data 12 that includes therein information for displaying a link for jumping to another web page. The web server program 13 is a program for transmitting web page data 12 in response to a request from a web client device (not shown). Specifically, when the web server program 13 (the CPU 10b according to the web server program 13) receives a request from a web client device (not shown) through the communication adapter 10d, the web server program 13 reads the requested web page data 12 from the storage unit 10a. 10d is sent to the requesting web client device.

  The web load test apparatus 20 is a personal computer to which a web load test tool is added. Accordingly, the web load test apparatus 20 includes a display device 20a such as a liquid crystal display, an input device 20b such as a keyboard and a mouse, and a main body connected to these devices 20a and 20b. Further, the main body incorporates hardware such as a storage unit 20c, a CPU 20d, a memory unit 20e, and a communication adapter 20f.

  The storage unit 20 c of the web load test apparatus 20 stores basic software 21, a web browser 22, and web load test tool software 23. The basic software 21 is software that exhibits the same functions as the basic software 11 of the web server device 10. The web browser 22 is a program for acquiring the web page data 12 from the web server device 10 according to an instruction from the operator and displaying the web page. More specifically, the web browser 22 (the CPU 20d according to the web browser) instructs the operator to click a link button in the web page, input a URL [Uniform Resource Locator] to the web browser screen, or the web browser 22 When there is an instruction to acquire the web page data 12 using an image tag or a frame tag described in the page data 12, a web server device sends a request message for requesting transmission of the web page data 12 specified by the URL in the instruction. 10, the response message is received from the web server device 10, and the web page is displayed on the display device 20a based on the web page data 12 in the body of the response message.

  The web load test tool software 23 is a program and data for causing a personal computer to function as a web load test apparatus. The web load test tool software 23 includes a scenario creation module 23a and a load simulator 23b.

  The scenario creation module 23a is a module program for creating a scenario given to the virtual web client generated by the load simulator 23b for the web load test. Although the scenario will be described in detail later, the scenario defines the order in which the virtual web client requests the web page data 12 in the web server device 10 to be tested. The contents of the processing executed by the CPU 20d according to the scenario creation module 23a will be described later with reference to FIGS.

  The load simulator 23b is a module program for applying an access load to the web server device 10 to be tested. More specifically, the load simulator 23b (according to the CPU 20d) generates a plurality of threads that virtually function as web clients and gives a scenario to each of the plurality of virtual web clients. On the other hand, the request message is transmitted and the response message is received according to the scenario. In addition, the load simulator 23b stores the response message itself received from each web server device by each virtual web client, or records a response log. The contents of processing executed by the virtual web client will be described later with reference to FIGS.

  In the computer network system configured as described above, the CPU 20d of the web load test apparatus 20 is instructed to start the scenario creation module 23a when the input device 20b is operated by an operator who wants to perform the web load test. Then, the scenario creation module 23a is read from the storage unit 20c, and the operation of the scenario creation module 23a is started.

  FIG. 2 is a diagram showing the flow of processing by the scenario creation module 23a.

  In the first step S101 after the scenario creation process is started, the scenario creation module 23a (which executed the CPU 20d) displays a work screen in the window. This work screen is a screen for performing operations related to scenario creation, and includes several buttons (not shown). The buttons included in the work screen include a start button that should be clicked before starting access to the web server device 10 using the web browser 22 and a save button that should be clicked after the access is terminated. include.

  In the next step S102, the scenario creation module 23a stands by until a creation start instruction is issued by clicking a start button in a work screen (not shown) displayed in step S101. Then, when there is a creation start instruction, the scenario creation module 23a advances the process to step S103.

  In step S103, the scenario creation module 23a activates the web browser 22 in a window different from the work screen. Thus, the web browser 22 activated in a separate window allows the worker to surf (browse) the web page provided by the web server device 10 without being aware of the work screen. Here, the web browser 22 inputs a URL in a URL input field on a web browser screen (not shown), clicks a link button on the web page, or displays a frame tag or image tag described in the web page data 12. The request message is transmitted to the web server device 10 when the acquisition of the web page data 12 is instructed. Note that the web browser 22 notifies a part of the content of the request header to the scenario creation module 23a before transmitting a request message to the web server device 10. Further, after receiving the response message from the web server device 10, the web browser 22 delivers the response message to the scenario creation module 23a. The scenario creation module 23a proceeds to step S104 after the web browser 22 is activated.

  In step S104, the scenario creation module 23a generates a work table for associating the request header with the response message on the memory unit 20e.

    FIG. 3 is a diagram illustrating an example of the data structure of the work table 31.

  As shown in FIG. 3, the work table 31 has the same number of records as the number of times the web browser 22 has accessed the web server device 10 after the start button in the work screen (not shown) is clicked and the end button is clicked. have. Each record has fields of “ID”, “request header”, and “response message”. The “ID” field is a field in which an ID, which is identification information for uniquely identifying the access, is recorded. In the present embodiment, this identification information is a natural number that specifies the access order. The “request header” field is a field in which a request header of a request message transmitted from the web browser 22 to the web server device 10 by the access is recorded. The “response message” field is a field in which a response message received from the web server device 10 by the web browser 22 by the access is recorded.

  The scenario creation module 23a creates the work table 31 as shown in FIG. 3, and then proceeds to step S105 in FIG. However, at this time, no record is recorded in the work table 31. That is, in step S104, a new work table 31 is generated.

  In step S105, the scenario creation module 23a determines whether or not there has been a save instruction by clicking a save button in a work screen (not shown) displayed in step S101. If there is no save instruction, the scenario creation module 23a branches the process from step S104 to step S106.

  In step S106, the scenario creation module 23a determines whether or not there is a request execution notification from the web browser 22 (the CPU 20d that executed it). Note that this request execution notification is a notification that the web browser 22 transmits before transmitting the request message, as described above. If there is no request execution notification from the web browser 22, the scenario creation module 23a branches the process from step S106 and returns the process to step S105.

  If a request execution notification is received from the web browser 22 during the execution of the processing loop of steps S105 and S106, the scenario creation module 23a advances the process from step S106 to step S107.

  In step S107, the scenario creation module 23a issues a new ID that is not used in the work table 31 of FIG.

  In the next step S108, the scenario creation module 23a registers the request header received together with the request execution notification from the web browser 22 in the work table 31 of FIG. 3 together with the new ID issued in step S107.

  In the next step S109, the scenario creation module 23a stands by until a response reception notification is received from the web browser 22. Note that this response reception notification is a notification transmitted by the web browser 22 after receiving the response message, as described above. Then, when there is a response receipt notification from the web browser 22, the scenario creation module 23a advances the process to step S110.

  In step S110, the scenario creation module 23a registers the response message received together with the response receipt notification from the web browser 22 in the work table 31 of FIG. The new ID and request header registered in step S108 and the response message registered in step S110 constitute a record in the work table 31 of FIG. The scenario creation module 23a returns the process to step S105 after registering the response message.

  Further, during the execution of the processing loop of steps S105 and S106, when there is a save instruction by clicking a save button in a work screen (not shown), the scenario creation module 23a advances the process from step S105 to step S111.

  In step S111, the scenario creation module 23a stores the work table 31 of FIG. 3 in the storage unit 20c as a scenario table.

  The scenario creation module 23a (CPU 20d) that executes steps S101 to S111 corresponds to the first storage unit described above.

  In the next step S112, the scenario creation module 23a executes a parameter association subroutine.

  4 and 5 show the flow of the parameter association subroutine.

  In the first step S201 after the parameter association subroutine is started, the scenario creation module 23a generates a work table for associating the request parameter with the response parameter on the memory unit 20e.

  FIG. 6 is a diagram illustrating an example of the data structure of the work table 32.

  As shown in FIG. 6, each record in the work table 32 has fields of “ID”, “type”, “parameter name”, and “parameter variable name”. The “ID” field is a field in which the identification information of the record to which the response parameter or request parameter belongs in the scenario table 31 of FIG. 3 is recorded. The “type” field is a field in which type information for specifying whether the parameter is a response parameter or a request parameter is recorded. In FIG. 6, there are two types of type information, “store” and “apply”. “Store” indicates that the parameter is a response parameter, and “Apply” indicates that the parameter is a request parameter. The “parameter name” field is a field in which the parameter name of the parameter is recorded. The “parameter variable name” field is a field in which the name of a parameter used for temporarily substituting the parameter value of the request parameter is recorded. More specifically, this parametric variable is used when the virtual web client replaces the parameter value of the request parameter in the request message in the scenario during the web load test with the parameter value of the response parameter acquired from the web server device 10. Is used to temporarily substitute the parameter value of the response parameter. Here, substituting the parameter value in the response parameter into the parameter is referred to as “storage”, and substituting the parameter value of the request parameter in the scenario with the parameter value is referred to as “apply”. The In the type information described above, “stored” means that the parameter is a parameter necessary for assigning the parameter value to the parameter, and as a result, indicates that the parameter is a response parameter. ing. Similarly, “apply” of the type information means that the parameter is a parameter whose parameter value should be replaced with the substitution value of the parameter, and as a result, indicates that the parameter is a request parameter. Yes. In the present embodiment, the name of the parametric variable is obtained by adding the character string “m_” to the parameter name.

  The scenario creation module 23a executes the first processing loop L1 in FIG. 4 after creating the work table 32 as shown in FIG. However, at this time, no record is recorded in the work table 32. That is, in step S201, a new work table 32 is generated.

  In the first processing loop L1, the scenario creation module 23a performs step S202, step S203, and the second processing loop one by one in the access order of the web browser 22 for all the records in the scenario table 31 generated in step S111. The process consisting of L2 is executed.

  In step S202, the scenario creation module 23a searches for a request parameter (a combination of a parameter name, “=”, and a parameter value) from the value (request header) of the “request header” field of the processing target record.

  In the next step S203, the scenario creation module 23a determines whether the request parameter has been detected as a result of the search in step S202. If the request parameter cannot be detected, the scenario creation module 23a branches the process from step S203, and ends the process for this process target record in the first process loop L1. On the other hand, when the request parameter can be detected, the scenario creation module 23a executes the second processing loop L2.

  In the second processing loop L2, the scenario creation module 23a performs the processing consisting of steps S204 to S209 and the third processing loop L3 one by one for several request parameters detected by the search in step S202. Run.

  In step S204, the scenario creation module 23a assigns the value (ID) of the “ID” field of the processing target record to a variable P used to store the ID of the record in the order before the processing target record. To do. Thereafter, the scenario creation module 23a advances the process to step S205.

  In step S205, the scenario creation module 23a performs a process of updating the variable P by subtracting one substitution value. That is, the processing target records are processed one by one from the previous record.

  In the next step S206, the scenario creation module 23a determines whether or not the substitution value of the variable P is zero. If the assigned value of the variable P is not zero, the CPU 20d branches the process from step S206 to step S207.

  In step S207, the scenario creation module 23a reads a record having the same value (ID) as the substitution value of the variable P in the “ID” field from the scenario table 31 of FIG.

  In the next step S208, the scenario creation module 23a searches for a response parameter (a combination of parameter name and parameter value) from the value (response message) in the “response message” field of the record read in step S207.

  In the next step S209, the scenario creation module 23a determines whether or not a response parameter has been detected as a result of the search in step S208. If the response parameter cannot be detected, the scenario creation module 23a branches the process from step S209, and ends the process for the process target request parameter in the second process loop L2. On the other hand, when the response parameter can be detected, the scenario creation module 23a executes the third processing loop L3.

  In the third processing loop L3, the scenario creation module 23a executes the processing consisting of steps S210 to S213 one by one for several response parameters detected by the search in step S208.

  In step S210, the scenario creation module 23a compares the processing target request parameter of the second processing loop L2 with the processing target response parameter of the third processing loop L3.

  The scenario creation module 23a (CPU 20d) that executes steps S202 to S210 corresponds to the above-described search means.

  In the next step S211, the scenario creation module 23a determines whether or not the processing target request parameter matches the processing target response parameter. If the two parameters do not match, the scenario creation module 23a branches the process from step S211 and ends the process for this process target response parameter in the third process loop L3. On the other hand, if both parameters match, the scenario creation module 23a advances the process to step S212.

  In step S212, the scenario creation module 23a, the substitution value of the variable P (that is, the ID of the record from which the processing target response parameter belongs), the type information (storage) corresponding to the processing target response parameter, and the processing target response parameter Is registered in the work table 32 of FIG. 6. As a result, the work table 32 associates the value of the parameter name appearing in the request parameter with the value of the parameter received as the response parameter before the request. In other words, the work table 32 determines which record value should be used as the value of the parameter that should be consistently the same in one scenario composed of a plurality of request parameters and a plurality of response parameters. Will be shown.

  In the next step S213, the scenario creation module 23a corresponds to the value (ID) of the “ID” field of the processing target record (the processing source request parameter affiliation source) of the first processing loop L1 and the processing target request parameter. A new record including type information (application), a parameter name in the processing target request parameter, and a parameter name corresponding to the parameter name is registered in the work table 32 of FIG.

  The work table 32 shown in FIG. 6 includes a pair having the same parameter name (one record whose type information is “stored” and one whose type information is “applied” through steps S212 and S213. Or a set of records) is registered. Since the pair of records have the same parameter name, the response parameter and the request parameter specified by the ID included in the pair of records are associated with each other.

  When the scenario creation module 23a finishes registration related to the processing target response parameter and the processing target request parameter, the scenario creation module 23a ends the processing for the processing target response parameter in the third processing loop L3.

  The scenario creation module 23a (CPU 20d) that executes these steps S211 to S213 corresponds to the second storage unit described above.

  When the scenario creation module 23a finishes executing the process consisting of steps S210 to S213 for all response parameters detected by the search in step S208, the scenario creation module 23a leaves the third process loop L3 and returns the process to step S205. .

  Then, when the substitution value of the variable P becomes zero during execution of the processing loop consisting of steps S205 to S209 and the third processing loop L3, the scenario creation module 23a performs this processing target in the second processing loop L2. Ends processing for the request parameter.

  The scenario creation module 23a leaves the second processing loop L2 after executing the processing including steps S204 to S209 and the third processing loop L3 for all the request parameters detected by the search in step S202. Then, the processing for this processing target record in the first processing loop L1 is terminated.

  When the scenario creation module 23a finishes executing the process consisting of step S202, step S203, and the second process loop L2 for all the records of the scenario table 31 generated in step S108, the scenario creation module 23a starts from the first process loop L1. Detach and proceed to step S214.

  In step S214, the scenario creation module 23a stores the work table 32, in which the information related to the parameters is registered in steps S212 and S213, in the storage unit 20c as a parameter correspondence table. At this time, the parameter correspondence table 32 is associated with the scenario table 31 generated in step S108. Thereafter, the scenario creation module 23a ends the parameter association subroutine according to FIGS. 4 and 5, and also ends the scenario creation process according to FIG.

  Thus, according to the scenario creation module 23a executed by the CPU 20d, the operator clicks the start button on the work screen (not shown), surfs the web page on the web browser screen, and displays the work screen (not shown). If the upper save button is clicked, the scenario table 31 and the parameter correspondence table 32 can be created.

  Further, the CPU 20d of the web load test apparatus 20 activates the load simulator 23b by operating the input device 20b by an operator who wants to perform a web load test using the created scenario table 31 and parameter correspondence table 32. Is read from the storage unit 20c, and the operation of the load simulator 23b is started.

  The load simulator 23b (the CPU 20d according to) first receives information specifying the scenario table 31 used for the web load test from the operator through the input device 20b, and the scenario table 31 and the parameter correspondence table 32 related thereto. Are read from the storage unit 20c. Subsequently, the load simulator 23b generates a plurality of threads that virtually function as a web client on the memory unit 20e, and delivers the read scenario table 31 and parameter correspondence table 32 to the plurality of virtual web clients. Each of the virtual web clients receives these tables 31 and 32 and starts access to the web server device 10 according to the same designated scenario. Further, each virtual web client uses the parameter value received as a response from the web server device 10 to set the parameter value of the same name included in the request after the response included in the scenario. Will do.

  FIG. 7 is a diagram showing a flow of processing by the virtual web client.

  After starting the process, the virtual web client (according to the CPU 20d) executes the fourth process loop L4. In the fourth processing loop L4, the virtual web client executes the processing consisting of steps S301 to S307 one by one for all the records of the scenario table 31 delivered from the load simulator 23b.

  In step S301, the virtual web client searches for a request parameter (a combination of a parameter name, “=”, and a parameter value) from the value (request message) in the “request message” field of the processing target record.

  In the next step S302, the virtual web client determines whether or not the request parameter has been detected as a result of the search in step S301. If the request parameter cannot be detected, the virtual web client branches the process from step S302 to step S304. On the other hand, if the request parameter can be detected, the virtual web client advances the process to step S303.

  In step S303, the virtual web client executes a release subroutine.

  FIG. 8 is a diagram showing the flow of the release subroutine.

  After starting the release subroutine, the virtual web client executes a fifth processing loop L5. In the fifth processing loop L5, the virtual web client executes the processing consisting of steps S401 to S403 one by one for several request parameters detected by the search in step S301.

  In step S401, the virtual web client uses the value (ID) of the “ID” field of the processing target record, the type information of “application”, and the parameter name of the processing target request parameter as search conditions, and the parameter correspondence of FIG. The table 32 is searched.

  In the next step S402, the virtual web client determines whether or not a record has been detected as a result of the search in step S401. If no record is detected, the virtual web client branches the process from step S402, and ends the process for the process target request parameter in the fifth process loop L5. On the other hand, if the record is detected, the virtual web client advances the process to step S403.

  In the next step S403, the virtual web client reads the substitution value from the parameter specified by the value (parameter variable name) in the “parameter variable name” field of the record detected by the search in step S401. Subsequently, the virtual web client replaces the parameter value with the read substitution value in the processing target request parameter in the value (request header) of the “request header” of the processing target record. Thereafter, the virtual web client ends the processing for the processing target request parameter in the fifth processing loop L5.

  The virtual web client exits from the fifth processing loop L5 after completing the processing consisting of steps S401 to S403 for all the request parameters detected by the search in step S301, and releases the subroutine shown in FIG. Exit. Thereafter, the virtual web client advances the process to step S304 in FIG.

  In step S304, the virtual web client transmits the request data in which the parameter value of the request parameter is replaced by the substitution value of the parameter in step S403 to the web server device 10 as a request message, and waits until a response message is received. . Then, when the response message is received from the web server device 10, the virtual web client advances the process to step S305.

  In step S305, the virtual web client searches for a response parameter (a combination of parameter name and parameter value) from the received response message.

  In the next step S306, the virtual web client determines whether or not a response parameter has been detected as a result of the search in step S305. If the response parameter cannot be detected, the virtual web client branches the process from step S306, and ends the process for the process target record in the fourth process loop L4. On the other hand, if the response parameter can be detected, the virtual web client advances the process to step S307.

  In step S307, the virtual web client executes a catch subroutine.

  FIG. 9 is a diagram showing the flow of the catch subroutine.

  After the catch subroutine starts, the virtual web client executes a sixth processing loop L6. In the sixth processing loop L6, the virtual web client executes the processing consisting of steps S501 to S503 one by one for several response parameters detected by the search in step S305.

  In step S501, the virtual web client uses the (ID) field in the “ID” field of the processing target record, the type information of “storage”, and the parameter name of the processing target response parameter as search conditions, and the parameter correspondence table in FIG. 32 is searched.

  In the next step S502, the CPU 20d determines whether or not a record has been detected as a result of the search in step S501. If the record cannot be detected, the virtual web client branches the process from step S502, and ends the process for the process target response parameter in the sixth process loop L6. On the other hand, if the record can be detected, the virtual web client advances the process to step S503.

  In the next step S503, the virtual web client sets the parameter of the processing target response parameter for the parameter specified by the value (parameter variable name) of the “parameter variable name” field of the record detected by the search in step S501. Assign a value. Thereafter, the virtual web client ends the process for this process target response parameter in the sixth process loop L6.

  The virtual web client exits from the sixth processing loop L6 after completing the processing consisting of steps S501 to S503 for all response parameters detected by the search in step S305, and executes the catch subroutine according to FIG. Exit. Thereafter, the virtual web client ends the processing for this processing target record in the fourth processing loop L4.

  The virtual web client completes execution of the processing consisting of steps S301 to S307 for all the records in the scenario table 31 delivered from the load simulator 23b, and then leaves the fourth processing loop L4, and relates to FIG. The process ends.

  When each virtual web client completes the process according to FIG. 7, the load simulator 23 b stores the response message itself received from the web server device 10 by each virtual web client and also stores a response log.

  Since the computer network system of the present embodiment is configured as described above, it operates as follows. For example, when the virtual web client transmits a request message including a request header of a record whose value of the “ID” field in the scenario table 31 in FIG. 3 is “3” to the web server device 10, immediately before the transmission. The virtual web client detects the request parameter (userid = A) from the request header (steps S301 and S302).

  Subsequently, the virtual web client uses the parameter name of the request parameter (userid), the identification information of “application”, and the identification information (3) of the record to which the request parameter belongs, in the parameter correspondence table of FIG. 32 is detected. Then, the virtual web client reads the substitution value from the parameter having the parameter name (m_userid) in the detected record, and the request parameter of the request data of the record whose “ID” field value is “3”. The parameter value is converted into the substitution value, and this request data is transmitted (steps S303, S401 to S403, S304).

  The substitution value of the parameter (m_userid) used as the parameter value of the request data at this time is the value of “2” in the “ID” field of the record having the same parameter name (m_userid) in the parameter correspondence table 32 of FIG. As shown in FIG. 3, when the virtual web client transmits request data of a record whose “ID” field value in the scenario table 31 of FIG. 3 is “2” to the web server device 10, the virtual web client receives the request data from the web server device 10. The parameter value extracted from the response parameter included in the response message and assigned to the parameter (steps S305 to S307, S501 to S503).

  As described above, according to the parameter correspondence table 32 generated together with the scenario table 31 by the web load test apparatus 20 of this embodiment, the virtual web client sends the request message in the scenario table 31 to the web server apparatus 10 to be tested. If the request parameter is included in the request message before transmission, the request parameter can be replaced with the response parameter acquired during the load test based on the parameter correspondence table 32.

  Therefore, according to the web load test apparatus 20 of the present embodiment, it is possible to create a scenario in which the virtual web client generated by the load simulator 23b in the web load test can appropriately transmit the request message and receive the response message.

Configuration diagram of the computer network system of the present embodiment Diagram showing the flow of processing by the scenario creation module The figure which shows an example of the data structure of a work table (scenario table) Diagram showing the flow of the parameter mapping subroutine Diagram showing the flow of the parameter mapping subroutine The figure which shows an example of the data structure of a work table (parameter correspondence table) Diagram showing the flow of processing by virtual web client Diagram showing the flow of the release subroutine Diagram showing the flow of the catch subroutine

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Web server apparatus 10a Storage unit 10c Memory unit 10d Communication adapter 12 Web page data 13 Web server program 20 Web load test apparatus 20a Display apparatus 20b Input apparatus 20c Storage unit 20e Memory unit 20f Communication adapter 22 Web browser 23 Web load test tool software Software 23a Scenario creation module 23b Load simulator 31 Scenario table 32 Work table (parameter correspondence table)

Claims (4)

A scenario creation program for creating a scenario given to a plurality of virtual web clients that impose an access load on a web server device to be tested,
Computer
Each time a predetermined instruction is received from the operator through the input device, a request message based on the instruction is transmitted to the web server device and a response message is received from the web server device, and the request message and the response A first storage unit for storing records associated with a message, adding identification information for uniquely identifying each record, and storing the records in a scenario table in the storage device in order of request;
Among the records in the scenario table, for each record including the request parameter in the request message, the response parameter having the same content as the request parameter is selected in the response message from the records in the order before the record. Search means for searching for records including, and
Among the records in the scenario table, for each record that includes a request parameter in the request message, when the search means detects a record that is earlier than the record, the identification information of both records is handled. attached to, the scenario creation program for causing to function as a second storage means for storing a correspondence table in the storage device. The second storage means is the identification information of the record in which the response message identification information that is the identification information of the retrieved record and the request parameter used as the retrieval condition of the record are included in the request message. Parameter indicating the parameter that should be rewritten to the value of the variable identified by the variable name when sending the request message in the record identified by the request side record identifying information, the variable name, and the request side record identifying information The scenario creation program according to claim 1, wherein the specification information is associated with each other and stored in a correspondence table in the storage device. A scenario creation device for creating a scenario given to a plurality of virtual web clients that impose an access load on a web server device to be tested,
Each time a predetermined instruction is received from the operator through the input device, a request message based on the instruction is transmitted to the web server device and a response message is received from the web server device, and the request message and the response A first storage unit for storing records associated with messages, adding identification information for uniquely identifying each record, and storing the records in a scenario table in the storage device in order of request;
Among the records in the scenario table, for each record including the request parameter in the request message, the response parameter having the same content as the request parameter is selected in the response message from the records in the order before the record. A search unit for searching for records including, and
Among the records in the scenario table, for each record that includes a request parameter in the request message, when the search unit detects a record that is earlier than the record, the identification information of both records is handled. put, the scenario creating device, characterized in that it comprises a second storage unit for storing a correspondence table in the storage device. Each of the plurality of virtual web clients
A message transmission process for transmitting a request message in each record stored in the scenario table in the order in which the records are stored in the scenario table, and the identification information is stored as request-side record identification information in the correspondence table At the time of transmission of the request message in each record, the parameter designation information and variable name associated with the request side record identification information and stored in the correspondence table are obtained, and the parameter indicated by the obtained parameter designation information A message sending process that sends a request message after changing the parameter value of the parameter to the value of the variable identified by the variable name
A message reception process for receiving a response message for each request message transmitted by the message transmission process. If a response parameter is included in the received response message, the response table stores the response message based on the response parameter. A message reception process for identifying a variable name in which the parameter value of the response parameter is stored from among the variable names being stored, and storing the parameter value in a variable identified by the identified variable name;
The scenario creation program according to claim 2, wherein the scenario creation program is executed by a computer in parallel.