JP5896862B2 - Test apparatus, test method and program - Google Patents

Description

  The present invention relates to a technique for testing a server device.

Conventionally, a test (for example, a load test) for a server device (for example, an authentication server device) is performed using a load test tool that emulates the operation of the client device.
In order to apply a load that meets the test requirements, in the conventional technology, various load tests are performed by providing parameters from the outside of the load test tool (for example, Patent Document 1 and Patent Document 2).
Patent Document 1 suggests changing the load applied to the computer system by changing an external parameter.
Patent Document 2 suggests that in a load test, an overload state is generated for a computer by inputting an external condition.

Japanese Patent Laid-Open No. 2005-182813 JP 2008-234407 A

In the conventional load test method, a parameter relating to the number of requests to be transmitted to the authentication server device and a parameter relating to the transmission timing of the request are externally given to the load test tool for testing.
In order to perform a load test that meets the test requirements, it is necessary to adjust various parameters.
In the conventional load test method, an appropriate parameter is derived by repeating a test several times based on the experience of the tester and past test results.
When carrying out a large-scale load test, a large number of load test agents that generate an actual load are required, and a plurality of load test controllers that control the load test agents are also required.
The tester performs parameter adjustment for each load test controller, but the complexity of parameter adjustment is proportional to the number of load test agents controlled by each load test controller (the number of load test agents, load test controllers Fine adjustment is required depending on the PC / server in operation.)
For this reason, in a large-scale load test using a large number of load test agents and a plurality of load test controllers, a great amount of time is spent for parameter adjustment.

  The main object of the present invention is to solve the above-described problems, and an object thereof is to shorten the time for parameter adjustment.

The test apparatus according to the present invention includes:
A test apparatus for testing the test target server apparatus by transmitting a plurality of requests to the test target server apparatus from a plurality of test tools each emulating a client apparatus,
A performance information storage unit that stores performance information indicating the request transmission performance of each test tool;
Collected by an active server device that receives a plurality of requests from a client device, and the reception history of requests in the active server device is based on a pair of a request classification identifier that is an identifier for classifying a request and a reception time of the request A log data input section for inputting the displayed log data;
Each request classification identifier indicated in the log data is analyzed and classified into one of a plurality of request types, and the number of received requests in the active server device is totaled in units of request types every predetermined unit time. A log aggregating unit for generating log aggregating data indicating the number of requests received in the active server device in units of request types per unit time;
Based on the number of requests received per request type per unit time indicated in the log aggregation data and the request transmission performance of each test tool indicated in the performance information, each test tool is the test target server device as a test parameter. And a test parameter designating unit for designating the request transmission timing and the request transmission timing in units of request types per unit time.

  In the present invention, the request transmission performance of each test tool is collated with the actual request reception history, and the test parameter for each test tool is generated. Therefore, the test parameter suitable for the actual system environment can be obtained in a short time. .

1 is a diagram illustrating a system configuration example including a load test control system according to a first embodiment. FIG. 4 is a diagram illustrating an example of request type information according to the first embodiment. FIG. 4 is a diagram showing an example of load model information according to the first embodiment. FIG. 4 is a diagram showing an example of load parameter information according to the first embodiment. FIG. 4 is a diagram illustrating an example of controller information according to the first embodiment. FIG. 6 is a diagram showing an example of agent information according to the first embodiment. FIG. 3 is a flowchart showing an example of load model generation processing according to the first embodiment. FIG. 4 is a flowchart showing an example of load parameter generation processing according to the first embodiment. FIG. 3 shows an example of a test sample according to the first embodiment. FIG. 10 is a diagram illustrating an example of a load distribution definition table according to the second embodiment. FIG. 9 is a flowchart showing an example of load model generation processing according to the second embodiment. FIG. 10 is a diagram showing a system configuration example including a load test control system according to a third embodiment. FIG. 10 is a diagram illustrating an example of feedback adjustment policy information according to the third embodiment. FIG. 10 is a flowchart showing an example of feedback adjustment processing according to the third embodiment. FIG. 10 is a diagram showing an outline of feedback adjustment processing according to the third embodiment. FIG. 10 is a diagram illustrating an example of feedback load model information according to the fifth embodiment. FIG. 10 is a diagram illustrating an example of feedback adjustment policy information according to the fifth embodiment. The figure which shows the relationship example of the load model which concerns on Embodiment 5, a trial result, and an adjustment result. The figure which shows the example of the authentication system request log which concerns on Embodiment 1. FIG. The figure which shows the hardware structural example of the test apparatus which concerns on Embodiment 1-6.

Embodiment 1 FIG.
In the present embodiment, a configuration for shortening the time for adjusting the load test when performing a large-scale load test will be described.

  FIG. 1 shows a system configuration example including a load test control system according to the present embodiment.

The load test control system (1) tests the authentication server devices (60-1), (60-2), and (60-3) in the authentication system (6).
The authentication server devices (60-1), (60-2), and (60-3) each correspond to an example of a test target server device.
The authentication system (6) integrates the authentication / authorization functions of the business system A (7-1) and the business system B (7-2).
In addition, when it is not necessary to distinguish each of authentication server apparatus (60-1), (60-2), and (60-3), it only describes with the authentication server apparatus (60).
Each authentication server device (60) receives a plurality of types of HTTP (HyperText Transfer Protocol) requests from the client device, and performs processing according to the received HTTP requests.
In FIG. 1, there are three authentication server devices (60) constituting the authentication system (6), but any number may be used depending on the configuration.
Further, as an element constituting the authentication system (6), an authentication repository (61) that manages user information for authentication, and a load distribution device that distributes the load of HTTP requests to a plurality of authentication server devices (60) ( 62).

The load test control system (1) includes a load test controller 1 (4-1) and a load test controller 2 (4-2).
The load test controller 1 (4-1) controls the load test agent 1 (5-1) and the load test agent 2 (5-2).
The load test controller 2 (4-2) controls the load test agent 3 (5-3) and the load test agent 4 (5-4).
The load test controller 1 (4-1) and the load test controller 2 (4-2) are components that control the test among general load test tools. Here, the number is two, but increases as necessary. It is possible and there is no upper limit.
The load test agent 1 (5-1), the load test agent 2 (5-2), the load test agent 3 (5-3), and the load test agent 4 (5-4) are also actually authentication systems among the load test tools. In this example, the number of components is four, but can be increased as necessary.
The load test controller 1 (4-1), the load test agent 1 (5-1), and the load test agent 2 (5-2) emulate a client device and transmit an HTTP request to the authentication server device (60). .
The load test controller 1 (4-1), the load test agent 1 (5-1), and the load test agent 2 (5-2) constitute one test tool.
Similarly, the load test controller 2 (4-2), the load test agent 3 (5-3), and the load test agent 4 (5-4) also emulate the client device and send an HTTP request to the authentication server device (60). Send.
The load test controller 2 (4-2), the load test agent 3 (5-3), and the load test agent 4 (5-4) constitute one test tool.
When there is no need to distinguish between the load test controller 1 (4-1) and the load test controller 2 (4-2), they are simply expressed as a load test controller (4).
Similarly, when it is not necessary to distinguish between the load test agent 1 (5-1), the load test agent 2 (5-2), the load test agent 3 (5-3), and the load test agent 4 (5-4) , Simply referred to as load test agent (5).

In the load test control system (1), the load model creation unit (1-1) inputs the authentication system request log (8).
The load model creation unit (1-1) processes the input authentication system request log (8) to generate load model information (3-3).
The authentication system request log (8) is log data collected by each authentication server device (60) of the authentication system (6).
The authentication system request log (8) is, for example, the data illustrated in FIG. 19, and the HTTP request reception history in the authentication server device (60) is the request reception time, the URL (Uniform Resource Locator) targeted by each request, and Is shown by a pair.
Although not shown in FIG. 19, in the authentication system request log (8), each line may include address information of the client device that is the transmission source of the HTTP request and address information of the relay device.
Further, the “authentication screen”, “authentication request (I / D password)”, and “portal screen” shown in FIG. 19 are descriptions for explanation, and are described in the actual authentication system request log (8). It is not.
As shown in request type information (3-1) (FIG. 2) to be described later, each URL of the authentication system request log (8) is also an identifier for classifying an HTTP request, and corresponds to an example of a request classification identifier. To do.
The load model creation unit (1-1) totals the reception history of the authentication system request log (8) in units of request types every predetermined unit time (for example, 5 minutes), and the unit of request types every unit time. Thus, load model information (3-3) representing the number of requests received in the authentication server device (60) is generated.
The generated load model information (3-3) is held in the load test control information DB (3).
The load model information (3-3) is information illustrated in FIG.
Details of the load model information (3-3) will be described later.
The authentication system request log (8) corresponds to an example of log data, and the load model information (3-3) corresponds to an example of log aggregated data.
The load model creation unit (1-1) corresponds to an example of a log data input unit and a log aggregation unit.

In the present embodiment, it is assumed that a load test is performed on the authentication server device (60) that is actually operating and receiving an HTTP request from the client device.
For example, it is assumed that a load test is performed in order to verify whether the authentication server device (60) in which new software is installed operates as expected.
For this reason, in this embodiment, the authentication system request log (8) is acquired from the authentication server device (60).
However, the acquisition destination of the authentication system request log (8) may not be the test target authentication server device (60).
You may make it acquire an authentication system request log (8) from the other server apparatus in operation which operate | moves similarly to an authentication server apparatus (60).

The load parameter calculation unit (1-2) acquires the controller information (2-1) and the agent information (2-2) from the load tool information DB (2), and further loads from the load test control information DB (3). The model information (3-3) is acquired, and load parameter information (3-4) that is a test parameter of the load test is generated.
The controller information (2-1) is information illustrated in FIG. 5, and the agent information (2-2) is information illustrated in FIG.
Although details of the controller information (2-1) and the agent information (2-2) will be described later, the controller information (2-1) and the agent information (2-2) include a test tool (load test controller (4), load This is information indicating the HTTP request transmission performance of the test agent (5), and corresponds to an example of performance information.
The load parameter calculation unit (1-2) receives the number of requests received in units of request types per unit time indicated in the load model information (3-3), controller information (2-1), and agent information (2-2). The load parameter information (3-4) is generated based on the request transmission performance of each test tool shown in FIG.
The load parameter information (3-4) is information illustrated in FIG.
The details of the load parameter information (3-4) will be described later. As test parameters, the number of HTTP requests transmitted from each test tool to the authentication server device (60) and the transmission timing of the HTTP requests are set for each request type. This information is specified in units.
The generated load parameter information (3-4) is held in the load test control information DB (3).
The load parameter calculation unit (1-2) corresponds to an example of a test parameter designation unit.

  The load test execution unit (1-3) controls the load test controller (4) based on the parameters indicated in the load parameter information (3-4), and executes a load test on the authentication server device (60). .

The load tool information DB (2) stores controller information (2-1) and agent information (2-2).
The load tool information DB (2) corresponds to an example of a performance information storage unit.

The controller information (2-1) is information illustrated in FIG.
In the controller information (2-1), information of one load test controller (4) is described in one record.
In the “load test controller No.” column, the identification number of the load test controller (4) is described.
In the “controller host name” column, the name of the load test controller (4) is described.
In the “number of agents” column, the number of load test agents (5) that can be used by the load test controller (4) is described.
The column “maximum number of user executions” describes the maximum number of users (client devices) that the load test controller (4) can simulate using the load test agent (5).
The “maximum number of user executions” is the number of agents × the number of user executions per unit.
The number of user executions per unit depends on the performance of the host on which the agent operates.
Agent information (2-2) is information illustrated in FIG.
Also in the agent information (2-2), information of one load test agent (5) is described in one record.
In the column “load test controller No.”, the identification number of the load test controller (4) managing the load test agent (5) is described.
In the “host name” column, the name of the load test agent (5) is described.
In the “multi-IP” column, it is described whether or not the load test agent (5) can simulate a plurality of users (clients).
In the “number of IPs” column, the number of users (client devices) that can be simulated by the load test agent (5) is described.
In other words, the “number of IPs” is the number of IP addresses assigned to the host on which the agent operates.
In the “OS” column, the type of OS (Operating System) used by the load test agent (5) is described.
In the “multiplicity” column, the number of users (client devices) per second that can be simultaneously simulated by the load test agent (5) is described.
In the present embodiment, a predetermined number (for example, 200) of HTTP requests are transmitted per user (client apparatus).
Therefore, the “maximum number of user executions” in the controller information (2-1) and the “number of IPs” and “multiplicity” in the agent information (2-2) represent the transmission performance of the HTTP request in the test tool.
The controller information (2-1) and agent information (2-2) exist in the load tool information DB (2) before the load model creation unit (1-1) inputs the authentication system request log (8). doing.

  The load test control information DB (3) stores request type information (3-1), load requirement information (3-2), load model information (3-3), and load parameter information (3-4). .

The request type information (3-1) is information illustrated in FIG. 2, and is information for classifying what kind of request the HTTP request including each URL is.
In the “request type” column, the type of application related to the URL is shown.
In the example of FIG. 2, a “common” application, a “business” application, and an “authentication” application are shown.
The load model creation unit (1-1) collates the URL indicated in the input authentication system request log (8) with the request type information (3-1), and each HTTP request in the authentication system request log (8) It is possible to determine which request type (application) is targeted.
For example, when an HTTP request including the URL in the first line in FIG. 2 is described in the authentication system request log (8), the load model creation unit (1-1) determines that the HTTP request is a “common” application. It can be determined that the request is for execution of.
The request type information (3-1) exists in the load test control information DB (3) before the load model creation unit (1-1) inputs the authentication system request log (8).

The load requirement information (3-2) describes the number of HTTP requests, the number of used users, and the number of used terminals (number of used IP addresses).
The number of HTTP requests is the number of HTTP requests per second when a peak load is continuously generated.
Further, the number of users used is the number of users simulated by the load test.
Illustration of the load requirement information (3-2) is omitted.
The load requirement information (3-2) is also present in the load test control information DB (3) before the load model creating unit (1-1) inputs the authentication system request log (8).

The load model information (3-3) is information generated by the load model creation unit (1-1) and is information illustrated in FIG.
In the “model name” column, a value that uniquely determines the type of the load model is described.
In the “time (minutes)” column, the unit time of the test is described.
In the case of “model name: PEAK”, 1 hour (00-60) is a unit time, and in “model name: REAL”, 5 minutes (00-05 etc.) is a unit time. The number of HTTP requests per second transmitted to the authentication server device (60) per unit time is described in the column.
“Authentication (%)”, “Common (%)”, and “Business (%)” correspond to “Request type” in the request type information (3-1) (FIG. 2), and “HTTP count / second”. The breakdown of the number of requests shown in FIG.
For example, in the second line of FIG. 3, among 100 “HTTP counts / second”, “authentication” accounts for 5%, “common” accounts for 90%, and “business” accounts for 5%. Has been.

“Model name: PEAK” is a load model that continuously flows a peak load.
That is, this is a load test model in which 5000 HTTP requests per second are transmitted to the authentication server device (60) for 1 hour (00-60 minutes).
Of the 5000 HTTP requests per second, 0.3% is an HTTP request for “authentication”, 70% is an HTTP request for “common”, and 29.7% is an HTTP request for “business”. Is specified.
“Model name: REAL” is an actual load model.
That is, 100 HTTP requests per second are sent to the authentication server device (60) for the first 5 minutes, 500 HTTP requests per second are sent to the authentication server device (60) for the next 5 minutes, and 5 This is a load test model in which HTTP requests corresponding to “HTTP count / second” are transmitted to the authentication server device (60) every minute.
For the first 5 minutes, 5% of the 100 HTTP requests per second are HTTP requests for “authentication”, 90% are HTTP requests for “common”, and 5% are HTTP requests for “business”. For the next 5 minutes, 3% of 500 HTTP requests per second are HTTP requests for “authentication”, 85% are HTTP requests for “common”, and 12% are HTTP requests for “business”, Thereafter, it is specified to follow the ratio of “authentication (%)”, “common (%)”, and “business (%)” every 5 minutes.
For “model name: REAL”, the load model creation unit (1-1) analyzes the reception history indicated in the authentication system request log (8) every unit time (5 minutes), and the number of requests received per unit time. And records of the load model information (3-3) are generated.
In FIG. 3, the total number of received requests in the authentication server device (60) is described in the “HTTP count / second” column, and the breakdown of the total number of received requests for each request type is shown as a percentage. Can be said to indicate the number of requests received in the authentication server device (60) for each request type.
In the following, a load test based on “model name: REAL” will be mainly described.

The load parameter information (3-4) is information generated by the load parameter calculation unit (1-2), and is information illustrated in FIG.
“Scenario No” and “branch number” are keys for uniquely defining a record.
The plurality of records in which the common “scenario No” is set are generated from the records of the common unit time in the load model information (3-3) (FIG. 3).
The four records in which “scenario No. S1” is set are generated from, for example, the record (model name: REAL, time (minutes): 00-05) on the second line of the load model information (3-3). ing.
In the “load test controller No.” column, the identification number of the load test controller (4) targeted by each record is described.
In the example of FIG. 4, it is assumed that a load test controller (4) is installed.
In the “user execution interval” column, an interval (unit: millisecond) for executing a user process in the load test agent (5) is described.
That is, the “user execution interval” is an interval from when the load test agent (5) starts request transmission of the i-th user (client device) to when it starts request transmission of the (i + 1) -th user. , The transmission timing of the HTTP request is defined.
In the “user execution number” column, the number of users (client devices) simulated by the load test controller (4) in the corresponding unit time is described.
As described above, since the number of HTTP requests transmitted by one user is determined, the number of HTTP requests transmitted within a unit time is defined by the “user execution number”.
The column “Agent List” lists the identifiers (host names) of the load test agents (5) that send HTTP requests to the authentication server device (60) under the load test controller (4).
In the present embodiment, it is assumed that a load test controller (4) that controls transmission of an HTTP request is determined for each request type.
For example, the transmission of the HTTP request classified into the request type “common” is controlled by the “ctrlhost01” and “ctrlhost02” in FIG. 5 and the transmission of the HTTP request classified into the request type “business”. It is assumed that sharing of HTTP requests classified as “ctrlhost03” and request type “authentication” is determined in advance for each request type, such as “ctrlhost04”.
For this reason, the number of HTTP requests that are classified into the request type “common” (“number of user executions”) and the transmission are included in the first-line record that is targeted for “ctrlhost01” (load test controller No: 1). Timing (“user execution interval”) is described.
Similarly, in the second and subsequent records, the number of transmissions of HTTP requests of the corresponding request type (“user execution number”) and the transmission timing (“user execution interval”) are described.

In FIG. 1, a range surrounded by a broken line, that is, a load model creation unit (1-1), a load parameter calculation unit (1-2), and a load tool information DB (2) correspond to an example of a test apparatus.
Hereinafter, when referring to this test apparatus, it is referred to as “test apparatus 100”.
In FIG. 1, the load model creation unit (1-1), the load parameter calculation unit (1-2), and the load tool information DB (2) that configure the test apparatus 100 are included in the load test execution unit (1-3). The load test control information DB (3) and the load test controller (4) are mounted on the same computer, but the load model creation unit (1-1) and the load parameter calculation unit (1-2) are shown. The load tool information DB (2), the load test execution unit (1-3), the load test control information DB (3), and the load test controller (4) are mounted on different computers and communicate with each other. Thus, the following processing may be performed.

Next, the operation will be described.
First, the load model generation operation by the load model creation unit (1-1) will be described (FIG. 7).
In FIG. 7, the load model creation unit (1-1) analyzes the URL indicated in the authentication system request log (8), classifies the HTTP request into request types, and authenticates the request types in units of unit time. The number of requests received in the server device (60) is totaled.
Then, the load model creation unit (1-1) generates load model information (3-3) (FIG. 3) indicating the number of requests received in the authentication server device (60) in units of request types every unit time. ing

The load model creation unit (1-1) collects in advance the authentication system request log (8) based on the load model from all the authentication server devices (60) on the authentication system (6) (S1). .
Next, the load model creation unit (1-1) stores the data of the request type information (3-1) (FIG. 2) on the memory (S2).
Next, the load model creation unit (1-1) reads the authentication system request logs (8) one by one (S3).
That is, the authentication system request log (8) of one authentication server device (60) is read from the authentication system request logs (8) of the plurality of authentication server devices (60).
Next, the load model creation unit (1-1) sets a starting time (for example, 8:00) and a time interval (for example, 5 minutes) for aggregation as a parameter for generating the load model as a parameter file (in FIG. 1). (S4).
In the parameter file, for example, parameters are described in a format of “start time = 08: 0” and “time interval = 5”.
Next, the load model creation unit (1-1) substitutes the starting time + time interval for the counting time (S5).
Next, the load model creation unit (1-1) reads request logs one by one (S6).
The load model creation unit (1-1) compares the aggregation time with the request log time (S7), and if the request log time is earlier than the aggregation time, the process proceeds to S9.
On the other hand, if the request log time is later than the total time, the time interval is added to the total time (S8), and the data of the total table in the memory is recorded in the load model information (3-3) (S8-1). Then, the process proceeds to S10.
The tabulation table is a table for tabulating the HTTP request reception count and the request type ratio for each unit time in order to generate each record of the load model information (3-3).
In the aggregation table, since the number of HTTP request receptions per unit time (5 minutes) is aggregated, the load model creation unit (1-1) is configured according to the format of the load model information (3-3). The above HTTP request reception number is divided by 300 (seconds) to be converted into an HTTP reception number per second and described in the load model information (3-3).

  In S9, the load model creation unit (1-1) determines the request type by comparing the URL of the request log read in S6 with the request type information (3-1), and adds the total request to the total table on the memory. Add the number and the request type ratio.

In S10, the load model creation unit (1-1) confirms whether or not processing has been performed up to the last line of the request log. If the processing has been performed up to the last line, the process proceeds to S11. Returning to S6, S6 to S10 are repeated.
Further, the load model creation unit (1-1) confirms whether the processing of all the files in the authentication system request log (8) has been completed (S11), and ends the operation if it has been completed.

  Next, the load parameter calculation unit (1-2) generates load parameter information (3-4) from the load model information (3-3), and the load test execution unit (1-3) receives the load parameter information (3- The operation for performing the test based on 4) will be described (FIG. 8).

First, the load parameter calculation unit (1-2) designates a model to be calculated (here, “REAL” for a real model) (S13).
Further, the load parameter calculation unit (1-2) reads the controller information (2-1) and the agent information (2-2) of the load tool information DB (2) as basic information (S14).
Next, the load parameter calculation unit (1-2) reads the records of the load model information (3-3) one record at a time (S15).

Next, the load parameter calculation unit (1-2) calculates the required number of controllers from the number of HTTP requests described in the record read in S15 and the maximum number of user executions for each controller (S16).
This process is performed for each request type.
That is, “HTTP count / second” described in the record read in S15 is multiplied by a percentage for each request type (such as “common (%)”) to obtain “HTTP count / second” for each request type and the request type. Is compared with the maximum number of user executions (FIG. 5) of the load test controller (4) corresponding to.
For example, if “HTTP number / second” is within the range of the maximum number of user executions of one load test agent (5), the number of necessary controllers is one.
In addition, when the “HTTP count / second” cannot be covered by the maximum number of user executions of one load test agent (5), the remaining number of “HTTP count / second” is the second load test agent (5). If it is within the range of the maximum number of user executions, two controllers are required.
In this way, the load parameter calculation unit (1-2) calculates the required number of controllers for each request type.

Next, the load parameter calculation unit (1-2) calculates the number of execution users per controller per second by “number of requests ÷ number of required controllers” (S17).
This process is also performed for each request type.
That is, the “number of HTTPs / second” for each request type obtained in S16 is divided by the “necessary number of controllers” for the request type obtained in S16 to obtain the number of execution users per controller per second. .

Next, the load parameter calculation unit (1-2) calculates the necessary time per test as “(number of requests per test) × (number of execution users per controller per second) ÷ (number of requests)”. (S18).
This process is also performed for each request type.
The “number of requests per test” in the above formula is specified in advance, and is, for example, 200.
“The number of execution users per controller per second” in the above equation is the value obtained in S17.
The “number of requests” in the above equation is “number of HTTPs / second” for each request type obtained in S16.

Next, the load parameter calculation unit (1-2) calculates the execution interval of the user by “(required time per test) ÷ (multiplicity per agent)” (S19).
This process is performed for each load test controller (4).
The “required time per test” in the above equation is the value obtained in S18.
The “multiplicity per agent” in the above equation is an average value of the “multiplicity” values in the agent information (2-2) (FIG. 6).
For example, in the calculation for “ctrlhost01” (load test controller No: 1), the average multiplicity of “host001”, “host002”, “host003”, etc., which are the load test agents (5) under “ctrlhost01”. .

Next, the load parameter calculation unit (1-2) writes the calculated parameter in the load parameter information (3-4) for each load test controller (4) (S20).
Specifically, the value of “user execution interval” calculated in S19 is stored in the “user execution interval” column of the load parameter information (3-4), “execution per controller per second calculated in S17”. The value of “number of users” is written in the “number of executed users” column of the load parameter information (3-4).
Further, the host name of the load test agent (5) controlled by the load test controller (4) is extracted from the agent information (2-2) of FIG. 6, and the “agent list” of the load parameter information (3-4) is extracted. Write in the field.

  Next, the load parameter calculation unit (1-2) checks whether or not all records of the load model information (3-3) have been processed (S21). If all records have been processed, the process proceeds to S22. If there is an unprocessed record, the process returns to S15, and S15 to S21 are repeated for the next record (next unit time).

Next, the load test execution unit (1-3) converts the load parameter information (3-4) into a scenario for each load test controller (4) of the load test tool.
Specifically, the load test execution unit (1-3) reads the record of the load parameter information (3-4) (S22).
Next, the load test execution unit (1-3) calculates the activation delay time from the activation time, and assigns the value of “user execution interval” of the load parameter information (3-4) to each load test controller (4), “ The values of “user execution count” and “agent list” are written as load test execution scenarios (S23).
For example, for “ctrlhost01” (load test controller No: 1), the value (150) of “user execution interval” on the first line of the load parameter information (3-4) (FIG. 4), “number of user executions” Value (1400), “agent list” value (host001,...), “User execution interval” value (200), “user execution count” value (1000), “agent list” on the fifth line ”(Host 001,...) And the like are written.
Thereafter, the load test execution unit (1-3) checks whether or not all the records of the load parameter information (3-4) have been processed (S24). If all the records have been processed, the process proceeds to S25. If there are unprocessed records, the process returns to S22.
If all records of the load parameter information (3-4) have been processed, the load test execution unit (1-3) instructs each load test controller (4) to execute the load test (S25).
Then, the load test execution unit (1-3) waits for completion of the load test (S26), and ends the operation when the test is completed.
In the load test, an HTTP request describing each URL in FIG. 9 is transmitted from each load test agent (5).
An IP address is simulated in accordance with the number of IPs and the number of users set when transmitting an HTTP request.
Further, the “authentication screen”, “authentication request (I / D password)”, and “portal screen” shown in FIG. 9 are descriptions for explanation, and such descriptions are made in an actual load test. Do not mean.

As described above, according to the present embodiment, since load models are automatically generated and load parameters are automatically calculated, the load test execution period can be shortened.
In addition, since the calculation results can be recorded, it is possible to shorten the parameter calculation for similar load requirements and to define a load model for each pattern to which the load is applied. .

As described above, in the present embodiment,
Load parameter calculation tool for automatically calculating load tool execution parameters by combining the generated load model and load tool configuration information based on the log of the real environment authentication system, A load test control method including a load test execution unit for controlling and executing a load tool has been described.

Embodiment 2. FIG.
In the first embodiment described above, a model for applying an HTTP request load on the authentication system is generated from all logs in the real environment. In this case, an embodiment in which a load model is generated from a log of one authentication server device will be described.
That is, in the present embodiment, the load model creation unit (1-1) reads the load model information (3-3) from the authentication system request log (8) of all the authentication server devices (60) in the authentication system (6). ), But based on the authentication system request log (8) of the representative authentication server device (60), the estimated number of received HTTP requests in all the authentication server devices (60) is derived and derived. Load model information (3-3) is generated from the estimated value.

The system configuration according to the present embodiment is the same as that shown in FIG.
The load balancer (62) shown in FIG. 1 manages the ratio of allocating HTTP requests to the authentication server devices (60-1) (60-2) (60-3) in the load balance definition table shown in FIG. An HTTP request is allocated to each authentication server device (60-1) (60-2) (60-3), and the load on the authentication server device is equalized.
In the load distribution definition table shown in FIG. 10, it is assumed that all ratios are defined to be 1 when integrated.

FIG. 11 is a diagram showing a flow of operations according to the present embodiment.
Hereinafter, differences from the first embodiment will be described.

The load model creation unit (1-1) determines a representative authentication server device (60) that reads the authentication system request log (8) in advance, and records a load distribution definition table (FIG. 10).
Then, the load model creation unit (1-1) inputs the authentication system request log (8) of the representative authentication server device (60), and the input authentication system request log (8) as in the first embodiment. The total number of requests is counted for each unit time, the ratio for each request type is also totaled, and the total result is written in the total table.
When recording the number of requests from the aggregation table in the load model information (3-3), the load model creation unit (1-1) divides the number of requests on the aggregation table by the distribution ratio in FIG. Information is recorded in (3-3) (S8-2).
For example, if the representative authentication server device is the authentication server device 1 of FIG. 10, the number of requests in the aggregation table is divided by “0.3” and the estimated number of requests received in all the authentication server devices (60). calculate.
Then, the estimated value is recorded in the load model information (3-3).
The ratio for each request type is recorded in the load model information (3-3) with the value in the aggregation table.
Processes other than S8-2 are the same as those shown in FIG.

  As described above, according to the present embodiment, when a load model is generated, it is possible to generate a load model from a log of one authentication server device, thereby further reducing the time.

  As described above, in the present embodiment, the load test control method that enables creation of a load model from the log of one authentication server has been described.

Embodiment 3 FIG.
In Embodiment 1 described above, if a load as expected is not applied after the load test is performed, it is necessary to manually adjust the load.
In the present embodiment, on the other hand, an embodiment in which a load model is adjusted using a log of an authentication server device at the time of a load test trial is shown.

FIG. 12 is a system configuration diagram according to the third embodiment.
In FIG. 12, compared with FIG. 1, a load model feedback unit (1-4) and a feedback DB (9) are added as elements of the load test control system (1).
Further, log data regarding reception of an HTTP request of the authentication server device (60) at the time of the load test trial is input to the load model feedback unit (1-4) as a load test trial time authentication system request log (80).
The authentication system request log (8) shows the HTTP request reception history during normal operation, while the load test trial authentication system request log (80) shows the HTTP request reception history during the load test trial.
The format of the authentication system request log (80) at the time of load test trial is the same as that of the authentication system request log (8), for example, as shown in FIG.
The load model feedback unit (1-4) corresponds to an example of a feedback log data input unit, a feedback log aggregation unit, and a log aggregation data change unit.
In this embodiment, the load model creation unit (1-1), the load parameter calculation unit (1-2), the load tool information DB (2), and the load model feedback unit (1-4) are examples of test devices. It corresponds to.

In the feedback DB (9), feedback load model information (9-1) and feedback adjustment policy information (9-2) are stored.
The table configuration of the feedback load model information (9-1) is the same as that of the load model information (3-3) (FIG. 3).
The table configuration of the feedback adjustment policy information (9-2) is as shown in FIG.
The load model feedback unit (1-4) determines whether the difference condition of the feedback adjustment policy information (9-2) is satisfied for each unit time and for each request type, and when the difference condition is satisfied, The corresponding contents of the load model information (3-3) are changed according to the application policy.
The first line of the feedback adjustment policy information (9-2) shows that the value of “HTTP count / second” defined in the load model information (3-3) is obtained from the authentication system request log (80) at the time of load test trial. The difference condition is that it is larger than 1.1 times “HTTP count / second” defined in the aggregated feedback load model information (9-1).
That is, the number of HTTP requests actually transmitted to the authentication server device (60) in the load test was 10% or more less than the “HTTP count / second” defined in the load model information (3-3). Is the difference condition.
When this difference condition is satisfied, new load model information (1.5 times the value of “HTTP count / second” defined in the current load model information (3-3) is defined ( 3-3) is the application policy.
The third line of the feedback adjustment policy information (9-2) includes the value of “operation (%)” defined in the load model information (3-3), and the load test trial authentication system request log (80 The difference condition is that the value of “business (%)” defined in the feedback load model information (9-1) compiled from () does not match.
When this difference condition is satisfied, the same value as the “common (%)” value and the “business (%)” value defined in the feedback load model information (9-1) is defined. An application policy is to generate new load model information (3-3).

Next, an operation flow in the present embodiment is shown.
The processes from load model generation (FIG. 7) to load parameter calculation (FIG. 8) and load test execution (FIG. 8) are the same as those in the first embodiment.
FIG. 14 is a flow of the load model feedback unit (1-4).
The feedback load model information (9-1) is generated except that the input information is a load test trial authentication system request log (80) that is a log of the authentication system (6) at the time of the load test trial. This is the same as FIG.
Therefore, the description starts from comparing the difference between the feedback load model information (9-1) and the load model information (3-3).

The load model feedback unit (1-4) reads the feedback adjustment policy information (9-2) into the memory (S27), and initializes the comparison time (S28).
The load model feedback unit (1-4) reads the record of the load model information (3-3) at the corresponding time (S29), and reads the record of the feedback load model information (9-1) at the corresponding time (S30). ).
Next, the load model feedback unit (1-4) compares the contents of both records (S31). If there is a difference, the process proceeds to S32, and if there is no difference, the process proceeds to S35.
When there is a difference, the load model feedback unit (1-4) extracts the application policy by matching the difference with the difference condition of the feedback adjustment policy information (9-2) (S32).
That is, if there is a difference condition that matches the extracted difference, the load model feedback unit (1-4) adopts an application policy corresponding to the difference condition.
Then, the load model feedback unit (1-4) applies the application policy extracted in S32 to the value of the original load model information (3-3) and recalculates (S33).
Then, the load model feedback unit (1-4) reflects the recalculated value in the load model information (3-3) (S34).

When there is no difference in S32 or after updating the load model information (3-3) in S34, the load model feedback unit (1-4) adds a time interval to the comparison time (S35).
Further, the load model feedback unit (1-4) checks whether or not all data comparison processing has been completed (S36), and if completed, ends the operation.
If not completed, S29 to S35 are repeated.

Thereafter, the load test execution unit (1-3) performs a load test using the new load model information (3-3) in the same procedure as in the first embodiment.
By repeating the load test trial and the load test feedback, the load parameters that meet the requirements are converged.
For the feedback load model information (9-1) generated from the authentication test request log (80) at the second and subsequent load test trials, the difference from the original load model information (3-3) is extracted. Alternatively, a difference from the changed load model information (3-3) may be extracted.

FIG. 15 shows an overview of the feedback adjustment processing of the present embodiment.
FIG. 15A shows a state in which the value of “HTTP count / second” per unit time of the load model information (3-3) generated based on the authentication system request log (8) is graphed.
FIG. 15B is a graph of the value of “HTTP count / second” per unit time of the feedback load model information (9-1) generated based on the authentication system request log (80) at the time of the load test trial. Indicates the state.
FIG. 15C shows the “HTTP count / second” after the difference between the load model information (3-3) and the feedback load model information (9-1) is adjusted by the load model feedback unit (1-4). The state that the value was graphed is shown.
That is, FIG. 15C is a graph of the value of “HTTP number / second” obtained by recalculation in S33 of FIG.
As shown in FIG. 15 (c), in S33 of FIG. 14, the request for “HTTP count / second” described in the initial load model information (3-3) is made by adjusting larger than the actual difference. It is transmitted to the authentication server device (60).

  As described above, according to the present embodiment, the load model can be automatically adjusted when the load test execution result based on the generated load model is different from the load model. The effect of shortening the test time can be obtained.

  As described above, in the present embodiment, the load test control method that feeds back the test result of the load test to the load model has been described.

Embodiment 4 FIG.
You may combine the above Embodiment 2 and Embodiment 3.
As compared with the second and third embodiments, the effect of reducing the load test execution time can be obtained.

Embodiment 5 FIG.
In the third embodiment described above, the load test parameter that meets the load requirement is calculated by repeating the feedback. However, it is possible that the load model is not easily converged.
Therefore, in the present embodiment, an embodiment is shown in which the feedback adjustment policy information to be applied is changed between the first time and the second time, and the number of feedbacks is completed by two times.

The system configuration according to the present embodiment is the same as FIG.
In this embodiment, a label column is added as one of the keys to the feedback load model information (9-1), and the number of “trials” and “adjustments” and the load model are recorded (FIG. 16).
“Trial” means execution of a load test. In the record in which “trial” is set in FIG. 16, a value obtained by aggregating the authentication system request log (80) at the time of load test is described. Has been.
“Adjustment” means the setting of a new parameter after the load test. In the record in which “Adjustment” is set in FIG. 16, the value obtained by the recalculation in S33 of FIG. 14 is described. Yes.
In the feedback adjustment policy information (9-2) according to the present embodiment, information on the number of trials is also added to the difference condition (FIG. 17).
The first line in FIG. 17 shows feedback load model information (9-1) obtained by aggregating the first load test trial authentication system request log (80) and original load model information (3-3). The difference between is specified.
On the other hand, the second line in FIG. 17 shows feedback load model information (9-1) obtained by aggregating the authentication system request log (80) at the second load test trial and original load model information (3-3). ) Is specified.
Thus, in the present embodiment, the load model feedback unit (1-4) receives the first load test trial authentication system request log (80) and the second load test trial authentication system request log. The application policy is changed when (80) is input.

The operation flow of the load model feedback section (1-4) follows FIG. 14 as in the third embodiment.
This embodiment is different from Embodiment 3 only in that the difference conditions and application policies used in S32 and S33 are the same as those in FIG.

FIG. 18 shows the relationship among the load model, trial results, and adjustment results.
In FIG. 18, the load model is the load model of the original load model information (3-3).
The trial result (first time) is 1 generated from the first load test trial authentication system request log (80) output after the load test is performed based on the original load model information (3-3). It is a load model of the feedback feedback model information (9-1) for the second time.
Further, the adjustment result (first time) is obtained by adjusting the difference between the original load model information (3-3) and the first feedback load model information (9-1), and the changed load model information (3-3). ) Load model.
The trial result (second time) was generated from the second load test trial authentication system request log (80) output after the load test was performed based on the changed load model information (3-3). It is a load model of the second feedback load model information (9-1).
The adjustment result (second time) is obtained by adjusting the difference between the original load model information (3-3) and the second feedback load model information (9-1), and further changing the load model information (3-3). ) Load model.

Note that, in the above, different difference conditions and application policies are used when the first load test trial authentication system request log (80) is input and when the second load test trial authentication system request log (80) is input. However, the difference condition and the application policy may be changed at any timing.
In other words, if the number of feedback is not limited to two, n (n is an integer of 1 or more) load test trial authentication system request log (80) input (n + m) (m is an integer of 1 or more) Different difference conditions and application policies may be used depending on the input of the authentication system request log (80) at the time of the load test attempt.

  As described above, according to the present embodiment, it is possible to generate an appropriate load model in a short time by adjusting the feedback adjustment policy information, and the effect of shortening the load test time can be obtained.

  As described above, in the present embodiment, the load control method has been described in which the adjustment of the load model is completed with the maximum number of feedback times of the test result of the load test being two.

Embodiment 6 FIG.
You may combine the above Embodiment 2 and Embodiment 5. FIG.
The effect of shortening the load test execution time can be obtained as compared with the second and fifth embodiments.

Finally, a hardware configuration example of the test apparatus (100) shown in the first to fifth embodiments will be described.
FIG. 20 is a diagram illustrating an example of hardware resources of the test apparatus (100) illustrated in the first to fifth embodiments.
Note that the configuration of FIG. 20 is merely an example of the hardware configuration of the test apparatus (100), and the hardware configuration of the test apparatus (100) is not limited to the configuration illustrated in FIG. There may be.

20, the test apparatus (100) includes a CPU 911 (also referred to as a central processing unit, a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, and a processor) that executes a program.
The CPU 911 is connected to, for example, a ROM (Read Only Memory) 913, a RAM (Random Access Memory) 914, a communication board 915, a display device 901, a keyboard 902, a mouse 903, and a magnetic disk device 920 via a bus 912. Control hardware devices.
Further, the CPU 911 may be connected to an FDD 904 (Flexible Disk Drive), a compact disk device 905 (CDD), a printer device 906, and a scanner device 907. Further, instead of the magnetic disk device 920, a storage device such as an SSD (Solid State Drive), an optical disk device, or a memory card (registered trademark) read / write device may be used.
The RAM 914 is an example of a volatile memory. The storage media of the ROM 913, the FDD 904, the CDD 905, and the magnetic disk device 920 are an example of a nonvolatile memory. These are examples of the storage device.
The “load tool information DB (2)”, “load test control information DB (3)”, and “feedback DB (9)” described in the first to fifth embodiments are realized by the RAM 914, the magnetic disk device 920, and the like. .
A communication board 915, a keyboard 902, a mouse 903, a scanner device 907, and the like are examples of input devices.
The communication board 915, the display device 901, the printer device 906, and the like are examples of output devices.

The communication board 915 is connected to the network.
For example, the communication board 915 is connected to a LAN (local area network), the Internet, a WAN (wide area network), a SAN (storage area network), and the like.

The magnetic disk device 920 stores an operating system 921 (OS), a window system 922, a program group 923, and a file group 924.
The programs in the program group 923 are executed by the CPU 911 using the operating system 921 and the window system 922.

The RAM 914 temporarily stores at least part of the operating system 921 program and application programs to be executed by the CPU 911.
The RAM 914 stores various data necessary for processing by the CPU 911.

The ROM 913 stores a BIOS (Basic Input Output System) program, and the magnetic disk device 920 stores a boot program.
When the test apparatus (100) is activated, the BIOS program in the ROM 913 and the boot program in the magnetic disk device 920 are executed, and the operating system 921 is activated by the BIOS program and the boot program.

  The program group 923 stores a program for executing the function described as “˜unit” in the description of the first to fifth embodiments. The program is read and executed by the CPU 911.

In the file group 924, in the description of the first to fifth embodiments, “determination of”, “calculation of”, “comparison of”, “aggregation of”, “generation of”, “designation of” ”,“ Change of ”,“ update of ”,“ setting of ”,“ registration of ”,“ selection of ”,“ input of ”,“ output of ”, etc. Information, data, signal values, and variable values indicating the results are stored as files on a storage medium such as a disk or memory.
The encryption key / decryption key, random number value, and parameter may be stored as a file in a storage medium such as a disk or memory.
The “˜file” and “˜database” are stored in a storage medium such as a disk or a memory.
Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 911 via a read / write circuit.
The read information, data, signal value, variable value, and parameter are used for CPU operations such as extraction, search, reference, comparison, calculation, calculation, processing, editing, output, printing, and display.
Information, data, signal values, variable values, and parameters are stored in the main memory, registers, cache memory, and buffers during the CPU operations of extraction, search, reference, comparison, calculation, processing, editing, output, printing, and display. It is temporarily stored in a memory or the like.
The arrows in the flowcharts described in the first to fifth embodiments mainly indicate input / output of data and signals.
Data and signal values are recorded on a storage medium such as a memory of the RAM 914, a flexible disk of the FDD 904, a compact disk of the CDD 905, a magnetic disk of the magnetic disk device 920, other optical disks, a Blu-ray (registered trademark) disk, and a DVD.
Data and signals are transmitted online via a bus 912, signal lines, cables, or other transmission media.

In addition, what is described as “˜unit” in the description of the first to fifth embodiments may be “˜circuit”, “˜device”, “˜device”, and “˜step”, It may be “˜procedure” or “˜processing”.
That is, the “test method” according to the present invention can be realized by the steps, procedures, and processes shown in the flowcharts described in the first to fifth embodiments.
Further, what is described as “˜unit” may be realized by firmware stored in the ROM 913.
Alternatively, it may be implemented only by software, or only by hardware such as elements, devices, substrates, and wirings, by a combination of software and hardware, or by a combination of firmware.
Firmware and software are stored as programs in a storage medium such as a magnetic disk, a flexible disk, an optical disk, a compact disk, a Blu-ray (registered trademark) disk, and a DVD.
The program is read by the CPU 911 and executed by the CPU 911.
That is, the program causes the computer to function as “to part” in the first to fifth embodiments. Alternatively, the computer executes the procedure and method of “to part” in the first to fifth embodiments.

As described above, the test apparatus (100) shown in the first to fifth embodiments includes a CPU as a processing device, a memory as a storage device, a magnetic disk, a keyboard as an input device, a mouse, a communication board, and a display device as an output device, A computer including a communication board and the like.
Then, as described above, the functions indicated as “˜units” are realized using these processing devices, storage devices, input devices, and output devices.

  DESCRIPTION OF SYMBOLS 1 Load test control system, 1-1 Load model creation part, 1-2 Load parameter calculation part, 1-3 Load test execution part, 1-4 Load model feedback part, 2 Load tool information DB, 2-1 Controller information, 2-2 Agent information, 3 Load test control information DB, 3-1 Request type information, 3-2 Load requirement information, 3-3 Load model information, 3-4 Load parameter information, 4 Load test controller, 5 Load test agent , 6 authentication system, 7 business system, 8 authentication system request log, 9 feedback DB, 9-1 feedback load model information, 9-2 feedback adjustment policy information, 60 authentication server device, 61 authentication repository, 62 load distribution device, 80 Authentication system for load test trials Request log, 100 test equipment.

Claims (10)

A test apparatus for testing the test target server apparatus by transmitting a plurality of requests to the test target server apparatus from a plurality of test tools each emulating a client apparatus,
A performance information storage unit that stores performance information indicating the request transmission performance of each test tool;
Collected by an active server device in operation that receives a plurality of requests from a client device, the request reception history in the active server device is an identifier for classifying the request, and a request reception time, A log data input unit for inputting log data indicated by a pair of
Each request classification identifier indicated in the log data is analyzed and classified into one of a plurality of request types, and the number of received requests in the active server device is totaled in units of request types every predetermined unit time. A log aggregating unit for generating log aggregating data indicating the number of requests received in the active server device in units of request types per unit time;
Based on the number of requests received per request type per unit time indicated in the log aggregation data and the request transmission performance of each test tool indicated in the performance information, each test tool is the test target server device as a test parameter. A test parameter specification unit that specifies the number of requests to be sent to and the request transmission timing in units of request types per unit time ,
Input the feedback log data in which the reception history in the test target server device of the request transmitted from each test tool according to the test parameter specified by the test parameter specifying unit is indicated by the pair of the request classification identifier and the reception time of the request A feedback log data input unit,
Analyzing each request classification identifier shown in the feedback log data and classifying it into one of a plurality of request types, totaling the number of requests received in the test target server device in units of request types per unit time, A feedback log aggregation unit that generates feedback log aggregation data indicating the number of requests received in the test target server device in units of request types per unit time;
The number of received requests indicated in the feedback log aggregated data is compared with the number of received requests indicated in the log aggregated data used to specify the test parameters in units of request types for each unit time, and the comparison result And a log aggregated data change unit for changing the number of received log aggregated data requests,
The test parameter designating unit is
New test parameters based on the number of requests received per request type indicated in the log aggregated data after the change by the log aggregated data changing unit and the request transmission performance of each test tool indicated in the performance information A test apparatus characterized by specifying . The test parameter designating unit is
The number of requests transmitted and the request transmission timing are specified for each test tool so that requests corresponding to the number of requests received indicated in the log aggregated data are transmitted for all request types in each unit time. The test apparatus according to claim 1. The feedback log data input unit includes:
When a new test parameter is specified by the test parameter specifying unit, and a request is transmitted from each test tool to the test target server device according to the new test parameter, feedback log data is input,
The feedback log aggregation unit
Every time feedback log data is input by the feedback log data input unit, the feedback log aggregated data is generated,
The log aggregation data changing unit
Each time feedback log aggregated data is generated by the feedback log aggregator, the number of received requests indicated in the generated feedback log aggregated data and the number of received requests indicated in any past log aggregated data are expressed in units. Compare each request type in units of request type, and based on the comparison result, change the number of received requests for any log aggregated data in the past,
The test parameter designating unit is
Each time the log aggregated data is changed by the log aggregated data changing unit, the number of requests received per request type per unit time indicated in the log aggregated data after the change and the request of each test tool indicated in the performance information based on the transmission performance testing device according to claim 1, characterized in that designating a new test parameters. The log aggregation data changing unit
When inputting feedback log data n (n is an integer of 1 or more), the number of received log aggregated data requests is changed according to the first criterion,
The number of received log aggregated data requests is changed according to a second criterion different from the first criterion when (n + m) (m is an integer of 1 or more) feedback log data is input. 3. The test apparatus according to 3 . Multiple requests from a plurality of test tools to emulate each client device, by sending a plurality of test server running which receives a plurality of requests from the client device, tests of the plurality of test server A test device for performing
A performance information storage unit that stores performance information indicating the request transmission performance of each test tool;
Are collected by the plurality of test server, log data reception history of the request in the plurality of test server apparatus, indicated by the pair of the identifier and a request classification identifier and the reception time of the request to classify the request Log data input part to input,
Each request classification identifier shown in the log data is analyzed and classified into one of a plurality of request types, and the number of received requests in the plurality of test target server devices in units of request types every predetermined unit time. A log aggregating unit that aggregates and generates log aggregated data indicating the number of requests received in the plurality of test target server devices in units of request types per unit time;
Based on the number of requests received per request type per unit time indicated in the log aggregated data and the request transmission performance of each test tool indicated in the performance information, each test tool has the plurality of test targets as test parameters. A test apparatus comprising: a test parameter designating unit that designates the number of requests to be transmitted to a server apparatus and the request transmission timing in units of request types per unit time. The test parameter designating unit is
Testing apparatus according to claim 1 or 5, characterized in specifying the test parameters of a load test for testing the target server device. A test method using a computer for testing a test target server device by sending a plurality of requests to a test target server device from a plurality of test tools each emulating a client device,
A performance information reading step in which the computer reads performance information indicating the request transmission performance of each test tool from a predetermined storage area;
Collected by an active server device in operation that receives a plurality of requests from a client device, the request reception history in the active server device is an identifier for classifying the request, and a request reception time, Log data input step in which the computer inputs log data indicated by a pair of
The computer analyzes each request classification identifier indicated in the log data and classifies it into one of a plurality of request types, and receives a request in the active server device in units of request types every predetermined unit time. A log aggregation step for generating log aggregation data indicating the number of requests received in the active server device in units of request types per unit time;
Based on the number of requests received per request type per unit time indicated in the log aggregated data and the request transmission performance of each test tool indicated in the performance information, the computer uses each test tool as a test parameter. A first test parameter specifying step for specifying the number of requests to be transmitted to the test target server device and the transmission timing of the request in units of request types for each unit time ;
The reception history in the test target server device of the request transmitted from each test tool according to the test parameter specified in the first test parameter specifying step by the computer is represented by a pair of request classification identifier and request reception time. A feedback log data input step for inputting the displayed feedback log data;
The computer analyzes each request classification identifier indicated in the feedback log data and classifies it into one of a plurality of request types, and the number of requests received in the test target server device in units of request types per unit time A feedback log aggregation step for generating feedback log aggregation data indicating the number of requests received in the test target server device in units of request types per unit time;
The computer compares the number of received requests indicated in the feedback log aggregated data with the number of received requests indicated in the log aggregated data used to specify the test parameters in units of request types per unit time. And, based on the comparison result, a log aggregated data changing step for changing the number of requests received for the log aggregated data,
The computer is based on the number of requests received per unit time indicated in the log aggregated data after the change by the log aggregated data change step, and the request transmission performance of each test tool indicated in the performance information, And a second test parameter designating step for designating a new test parameter . Multiple requests from a plurality of test tools to emulate each client device, by sending a plurality of test server running which receives a plurality of requests from the client device, tests of the plurality of test server A test method using a computer,
A performance information reading step in which the computer reads performance information indicating the request transmission performance of each test tool from a predetermined storage area;
Are collected by the plurality of test server, log data reception history of the request in the plurality of test server apparatus, indicated by the pair of the identifier and a request classification identifier and the reception time of the request to classify the request Log data input step input by the computer,
The computer analyzes each request classification identifier indicated in the log data and classifies the request classification identifier into one of a plurality of request types, and in the plurality of test target server devices in units of request types every predetermined unit time. A log aggregation step for counting the number of received requests, and generating log aggregation data indicating the number of request receptions in the plurality of test target server devices in units of request types per unit time;
Based on the number of requests received per request type per unit time indicated in the log aggregated data and the request transmission performance of each test tool indicated in the performance information, the computer uses each test tool as a test parameter. A test method comprising: a test parameter specifying step for specifying the number of requests to be transmitted to a plurality of test target server devices and the request transmission timing in units of request types for each unit time. A computer for testing the test target server device by sending a plurality of requests to the test target server device from a plurality of test tools each emulating a client device,
A performance information reading step of reading performance information indicating the request transmission performance of each test tool from a predetermined storage area;
Collected by an active server device in operation that receives a plurality of requests from a client device, the request reception history in the active server device is an identifier for classifying the request, and a request reception time, A log data input step for inputting log data indicated by a pair of
Each request classification identifier indicated in the log data is analyzed and classified into one of a plurality of request types, and the number of received requests in the active server device is totaled in units of request types every predetermined unit time. Log aggregation step for generating log aggregation data indicating the number of requests received in the active server device in units of request types per unit time;
Based on the number of requests received per request type per unit time indicated in the log aggregation data and the request transmission performance of each test tool indicated in the performance information, each test tool is the test target server device as a test parameter. A first test parameter designating step for designating the number of requests to be transmitted and the transmission timing of the request in units of request types per unit time ;
A feedback log in which a reception history in the test target server device of a request transmitted from each test tool according to the test parameter specified in the first test parameter specifying step is indicated by a pair of a request classification identifier and a request reception time. A feedback log data input step for inputting data;
Analyzing each request classification identifier shown in the feedback log data and classifying it into one of a plurality of request types, totaling the number of requests received in the test target server device in units of request types per unit time, A feedback log aggregation step for generating feedback log aggregation data indicating the number of requests received in the test target server device in units of request types per unit time;
The number of received requests indicated in the feedback log aggregated data is compared with the number of received requests indicated in the log aggregated data used to specify the test parameters in units of request types for each unit time, and the comparison result Log aggregated data change step for changing the number of log aggregated data requests received,
Based on the number of requests received per request type indicated in the log aggregated data after the change in the log aggregated data change step and the request transmission performance of each test tool indicated in the performance information, a new test parameter And a second test parameter designating step for designating a program. Multiple requests from a plurality of test tools to emulate each client device, by sending a plurality of test server running which receives a plurality of requests from the client device, tests of the plurality of test server On the computer
A performance information reading step of reading performance information indicating the request transmission performance of each test tool from a predetermined storage area;
Are collected by the plurality of test server, log data reception history of the request in the plurality of test server apparatus, indicated by the pair of the identifier and a request classification identifier and the reception time of the request to classify the request Log data input step to input,
Each request classification identifier shown in the log data is analyzed and classified into one of a plurality of request types, and the number of received requests in the plurality of test target server devices in units of request types every predetermined unit time. A log aggregating step that aggregates and generates log aggregating data indicating the number of requests received in the plurality of test target server devices in units of request types per unit time;
Based on the number of requests received per request type per unit time indicated in the log aggregated data and the request transmission performance of each test tool indicated in the performance information, each test tool has the plurality of test targets as test parameters. A program for executing a test parameter specifying step for specifying the number of requests to be transmitted to a server device and the request transmission timing in units of request types per unit time.

Images