A pressure testing system, method, storage medium and electronic device

Abstract

The application discloses a pressure test system, method, storage medium and electronic equipment, wherein the pressure test system comprises a configuration parser, a parameter generator, a test behavior configurator and a test executor. The configuration parser is used for receiving a test configuration file and parsing the test configuration file to obtain test process information. The parameter generator is used for reading a parameter generation strategy in the test process information and generating test parameters based on the parameter generation strategy. The test behavior configurator is used for initializing a test behavior based on the test behavior information and the test parameters. The test executor is used for initializing based on the test execution information and the multiplexed test behavior, and executing a test task based on the test execution information and the multiplexed test behavior, and outputting a test result. Without writing pressure test codes, the difficulty and workload of pressure test are reduced, and the pressure test process is simplified.

Description

Technical Field

[0001] The present invention relates to the field of pressure testing technology, and in particular to a pressure testing system, method, storage medium and electronic device. Background Technology

[0002] With the continuous development of computer technology, applications include more and more services, and the interface protocols used in these applications are also increasing. Currently, there are many mature stress testing tools available.

[0003] However, in the process of realizing this invention, the inventors discovered that the prior art has at least the following technical problems: Current stress testing tools require the operator to write the relevant test code, which is difficult for operators who are not familiar with coding. At the same time, the additional coding required for testing increases the workload. Summary of the Invention

[0004] This invention provides a stress testing system, method, storage medium, and electronic device to achieve stress testing without coding.

[0005] In a first aspect, embodiments of the present invention provide a stress testing system, comprising:

[0006] Configure a parser to receive the test configuration file and parse it to obtain test process information;

[0007] A parameter generator is used to read the parameter generation strategy from the test process information and generate test parameters based on the parameter generation strategy.

[0008] A test behavior configurator, connected to the parameter generator, is used to read test behavior information from the test process information and reuse test parameters generated by the parameter generator, and initialize test behavior based on the test behavior information and the test parameters;

[0009] The test executor, connected to the test behavior configurator, is used to read the test execution information in the test process information and reuse the test behavior of the test behavior configurator, initialize based on the test execution information and the reused test behavior, execute test tasks on the reused test behavior based on the test execution information, and output test results.

[0010] Secondly, embodiments of the present invention also provide a stress testing method, comprising:

[0011] The configuration parser receives the test configuration file and parses it to obtain test process information.

[0012] The parameter generator reads the parameter generation strategy from the test process information and generates test parameters based on the parameter generation strategy.

[0013] The test behavior is initialized based on the test behavior information read from the test process information by the test behavior configurator and the test parameters generated by the parameter generator.

[0014] The test executor reads the test execution information from the test process information and reuses the test behavior from the test behavior configurator. It initializes based on the test execution information and the reused test behavior, executes test tasks on the reused test behavior based on the test execution information, and outputs test results.

[0015] Thirdly, embodiments of the present invention also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the stress testing method provided in any embodiment of the present invention.

[0016] Fourthly, embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the stress testing method provided in any embodiment of the present invention.

[0017] The technical solution provided by this invention sets a configuration file, which includes the test process information required during the stress test of the target object. The configuration parser parses the configuration file to obtain the test process information. Based on the parsed test process information, the parameter generator, test behavior configurator, and test executor are initialized to obtain a stress test system capable of stress testing the target object. The system performs stress testing on the target object and obtains the test results. There is no need to write stress test code, which reduces the difficulty and workload of stress testing and simplifies the stress testing process. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of a pressure testing system provided in Embodiment 1 of the present invention;

[0019] Figure 2 This is a schematic diagram of the structure of a pressure testing system provided in Embodiment 2 of the present invention;

[0020] Figure 3 This is a schematic diagram of another pressure testing system provided in Embodiment 2 of the present invention;

[0021] Figure 4 This is a schematic flowchart of a pressure testing method provided in Embodiment 3 of the present invention;

[0022] Figure 5 This is a flowchart illustrating another pressure testing method provided in Embodiment 3 of the present invention;

[0023] Figure 6 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

[0024] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0025] Example 1

[0026] Figure 1 This is a schematic diagram of a pressure testing system provided in Embodiment 1 of the present invention. The device includes:

[0027] Configure parser 110 to receive test configuration files and parse them to obtain test process information;

[0028] The parameter generator 120 is used to read the parameter generation strategy in the test process information and generate test parameters based on the parameter generation strategy.

[0029] Test behavior configurator 130, connected to the parameter generator, is used to read test behavior information from the test process information, reuse test parameters generated by the parameter generator, and initialize test behavior based on the test behavior information and the test parameters;

[0030] Test executor 140, connected to the test behavior configurator, is used to read test execution information from the test process information and reuse the test behavior of the test behavior configurator, initialize based on the test execution information and the reused test behavior, execute test tasks on the reused test behavior based on the test execution information, and output test results.

[0031] In this embodiment, the configuration parser 110 receives an externally input configuration file. This configuration file can be directly imported, written in code, or generated through a configuration information collection page. The configuration information collection page may include information identifiers to be input and corresponding information input controls. The page collects user input information about the testing process of the target test object through the information input controls, and converts the collected test process information into a configuration file in a preset format. This configuration file is used to perform stress testing on the target object. The target object can be one or more services within an application. For example, the target object may include, but is not limited to, payment services and contract services within the application.

[0032] Configuration files can be named based on target objects, facilitating retrieval and management of configuration files based on target objects. Configuration files can be edited, allowing for updates based on the stress testing requirements of each target object. By maintaining configuration files for each target object, these files can be invoked during stress testing to perform stress tests on the target object, eliminating the need to write stress test code, thus reducing the difficulty and workload of stress testing and simplifying the stress testing process.

[0033] The configuration parser 110 parses the received configuration file to obtain the test process information in the configuration file. The test process information may include information required for different stages of stress testing the target object.

[0034] The parameter generator 120, test behavior configurator 130, and test executor 140 can listen to the test process information parsed by the configuration parser 110 after the configuration parser 110 starts, and perform information configuration based on the listened test process information, that is, perform initialization, and have the function of stress testing the target object through initialization.

[0035] The test process information is set according to the test requirements of the target object, and may include, but is not limited to, the stress test mode, parameter generation strategy, test behavior, and execution method of the test behavior.

[0036] The technical solution provided in this embodiment sets a configuration file, which includes the test process information required during the stress test of the target object. The configuration parser parses the configuration file to obtain the test process information. Based on the parsed test process information, the parameter generator, test behavior configurator, and test executor are initialized to obtain a stress test system capable of stress testing the target object. The system performs stress testing on the target object and obtains the test results. There is no need to write stress test code, which reduces the difficulty and workload of stress testing and simplifies the stress testing process.

[0037] The parameter generator 120, connected to the configuration parser 110, is used to read the parameter generation strategy in the test process information and generate test parameters based on the parameter generation strategy. In this embodiment, the test parameters generated by the parameter generator 120 can be parameter values ​​in the stress test request. The parameter values ​​in the stress test request can be determined according to the needs of the stress test. For example, in a stress test based on the Thrift interface communication method, the parameter values ​​of the stress test request can be Thrift interface parameter values. In a stress test based on JMS (Java Message Service) and Kafka communication methods, the parameter values ​​of the stress test request can be the message body of the message partition. In a stress test based on Redis communication methods, the parameter values ​​of the stress test request can be key-value pairs in Redis.

[0038] The parameter values ​​in the aforementioned stress test request can be composed of at least one basic parameter value. Correspondingly, for the different parameter value requirements, the test process information is configured with a parameter generation strategy. This strategy includes preset type parameter values ​​and parameter objects. The preset type parameter values ​​are basic parameter values, such as, but not limited to, fixed or random strings, positive numbers, floating-point numbers, boolean values, and date types. The parameter object is composed of at least one level of basic parameter values. For example, a parameter object can include multiple child node parameters, and any child node parameter can include a next-level child node parameter. The parameter object in the aforementioned parameter generation strategy can include parameter types (e.g., basic parameter values ​​or parameter objects) at each level of nodes, as well as parameter attributes (the data type of the basic parameter values).

[0039] The parameter generator 120 includes a simple parameter generator and a complex parameter generator. The simple parameter generator generates parameter values ​​of the corresponding type based on the parameter value's type. The complex parameter generator reuses at least one simple parameter generator and / or at least one complex parameter generator to generate parameter objects. By setting the parameter generator, corresponding parameters can be automatically generated through a parameter generation strategy, eliminating the need for manual configuration by the user. This improves parameter setting efficiency and reduces the difficulty of parameter setting by eliminating the need to establish relationships between different parameters during the coding process. It also reduces the probability of stress test failures due to parameter setting errors.

[0040] The test behavior configurator 130 is connected to the configuration parser 110 and the parameter generator 120 respectively. It is used to read the test behavior information in the test process information and reuse the test parameters generated by the parameter generator to initialize the test behavior based on the test behavior information and test parameters.

[0041] The test behavior information may include, but is not limited to, the interface type used in the stress test and the interface attributes set. Different test behaviors correspond to different test behavior information. By reading the test behavior information and the test parameters generated by the parameter reuse generator, the test behavior configurator 130 is initialized to configure the test behaviors.

[0042] In this embodiment, the test behavior configurator includes test behavior configuration units for multiple protocols. Each test behavior configuration unit can configure different test behaviors, and these units may include, but are not limited to, Thrift configuration units, JMS configuration units, Kafka configuration units, and Redis configuration units. Accordingly, for Thrift interface test behaviors, the test behavior information may include the IP address of the Thrift service under test, the port number of the Thrift service under test, the fully qualified Java class name of the RPC client call interface generated by Thrift, and the method name in the RPC interface to be tested; for JMS or Kafka test behaviors, the test behavior information may include the provider of the message and the message body generation strategy; for Redis test behaviors, the test behavior information may include the Redis server address where the test data is to be written, the Redis server port number where the test data is to be written, and the test data to be written to Redis, etc.

[0043] In some embodiments, the configuration file may contain test behavior information including one or more test behaviors for testing multiple test behaviors. Optionally, the test behavior configurator may also include an extension interface, through which new test behavior configuration units can be added to improve the compatibility and applicability of stress testing.

[0044] Test executor 140 is connected to configuration parser 110 and test behavior configurator 130 respectively. It is used to read test execution information in test process information and reuse test behavior from test behavior configurator. It initializes based on test execution information and reused test behavior, executes test tasks on reused test behavior based on test execution information, and outputs test results.

[0045] The test execution information includes at least one of the following: the number of threads for the test behavior, the number of tests per thread, and the test time. By initializing the test executor 140 with the test execution information and setting the test behavior onto the test executor 140 using reused test execution information, the test executor 140 is equipped with the function of performing stress tests on the target object. After the test executor 140 completes initialization and the test behavior configuration, the stress test task is executed, the test results are obtained, and the stress test on the target object is completed. The test results may include, but are not limited to, request latency, execution count, and error count.

[0046] Based on the above embodiments, the stress testing system further includes a result statistician 150, which is connected to the test executor 140, receives the test results output by the test executor, and generates a test report based on the test metrics in the test results. The result statistician 150 may also be connected to a configuration parser 110. The test process information parsed by the configuration parser 110 may include a test result statistical strategy. This strategy may include the types of metrics to be statistically analyzed, such as TPS (Transactions Per Second), QPS (Queries per Second), error rate, and latency, corresponding to maximum, minimum, and average values, respectively.

[0047] The results statistician 150 processes the received test results using a test results statistics strategy and outputs a test report.

[0048] The technical solution provided in this embodiment sets up a test executor, a test behavior configurator, and a parameter generator. These components read test execution information, test behavior information, and parameter generation strategies from the test process information, initialize them accordingly, configure test behaviors using test parameters generated by the parameter generator, and write the test behaviors into the test executor, thus forming a test executor with stress testing capabilities to execute stress testing tasks. By configuring the test executor, test behavior configurator, and parameter generator using test process information parsed from the configuration file, no test code needs to be written, simplifying the stress testing process and reducing its difficulty.

[0049] Example 2

[0050] Figure 2This is a schematic diagram of a pressure testing system provided in Embodiment 2 of the present invention. It is an optimization based on the above embodiments. Optionally, the pressure testing system further includes a piling service simulator. The parameter generator is also used to generate piling service parameters according to the read parameter generation strategy. The piling service simulator, connected to the parameter generator, is used to read piling service information from the test process information, reuse the piling service parameters generated by the parameter generator, initialize based on the piling service information and the piling service parameters, execute a piling service simulation task, and output the piling service simulation results.

[0051] Accordingly, the stress testing system includes:

[0052] Configure parser 110 to receive test configuration files and parse them to obtain test process information.

[0053] The parameter generator 120 is used to read the parameter generation strategy from the test process information and generate test parameters based on the parameter generation strategy.

[0054] The test behavior configurator 130, connected to the parameter generator 120, is used to read test behavior information from the test process information, reuse test parameters generated by the parameter generator 120, initialize test behavior based on the test behavior information and test parameters, and generate stubbing service parameters according to the read parameter generation strategy.

[0055] Test executor 140, connected to test behavior configurator 130, is used to read test execution information from test process information and reuse test behaviors from test behavior configurator 130, initialize based on test execution information and reused test behaviors, execute test tasks on reused test behaviors based on test execution information, and output test results.

[0056] The piling service simulator 160 is connected to the configuration parser 110 and the parameter generator 120 respectively. It is used to read the piling service information in the test process information and reuse the piling service parameters generated by the parameter generator 120. It is initialized based on the piling service information and piling service parameters, and executes the piling service simulation task to output the piling service simulation results.

[0057] In microservice architectures across systems or applications, services depend on each other to jointly achieve the overall functionality of the system. For services with dependencies, the front-end service needs to obtain resources from the back-end service before it can return correctly. Therefore, the performance of the front-end service is affected by the performance of the back-end service, increasing the difficulty of stress testing a single microservice. In this embodiment, a stubbing service simulator 160 is set up to simulate the services that the target object depends on, avoiding interference from dependent services to the front-end service, and enabling stress testing of a single microservice without interference from other dependent services.

[0058] Optionally, the test process information includes test mode attributes, which include a piling service mode identifier and a normal mode identifier. The piling service mode identifier is used to trigger the test executor to execute the test task, and the normal mode identifier is used to trigger the piling service simulator to execute the piling service simulation. The test executor 140 and the piling service simulator 160 read the test process information and identify the test mode attributes. The test executor 140 starts the stress test when the identified test mode attribute is the normal mode identifier, and the piling service simulator 160 starts the piling service when the identified test mode attribute is the piling service mode identifier.

[0059] The parameter generator 120 generates piling service parameters according to the read parameter generation strategy. These piling service parameters can be the return value of the piling service. The return value of the piling service can be a basic data value or a parameter object, and can be generated according to the parameter generation strategy. The piling service simulator 160 can reuse the piling service parameters generated in the parameter generator 120 to initialize the piling service simulator 160, generate a piling service simulator with piling service functions, execute the piling service task, and obtain the piling service result.

[0060] The piling service simulator 160 includes a piling service simulation unit with at least one interface. This piling service simulation unit may include, but is not limited to, a piling service simulation unit with an HTTP interface and a piling service simulation unit with a Thrift interface, used to simulate piling functions for the HTTP interface and the Thrift interface, respectively. Optionally, the piling service simulator 160 may also include an extension interface for adding new piling service simulation units, improving the applicability and compatibility of the piling service.

[0061] Each piling service simulation unit is used to execute the piling service simulation task of the corresponding interface based on the piling service information and the piling service parameters generated by the reuse parameter generator, so as to realize piling services for different interface types.

[0062] The results analyzer 150 is connected to both the test executor 140 and the stubbing service simulator 160, receiving test results and stubbing service simulation results. Based on the test metrics in the test and stubbing service simulation results, it generates a test report. The stress test performed by the test executor 140 is based on the return values ​​of actual dependent services. The test results include the actual return values ​​of each dependent service and their corresponding timestamps. The stubbing service simulation results generated by the stubbing service simulator 160 include the theoretical return values ​​and their corresponding timestamps. The results analyzer 150 compares the stubbing service simulation results with the test results to determine whether dependent services have a negative impact on the current object being stress tested, thus eliminating interference from dependent services and achieving single-object testing of the target object.

[0063] The technical solution provided in this embodiment simulates at least one dependent service of the target object to be tested by setting up a stubbing service simulator, thereby avoiding interference from dependent services to the front-end service and realizing stress testing of a single microservice without interference from other dependent services.

[0064] Based on the above embodiments, a preferred example of a stress testing system is also provided, for example, see [link to example]. Figure 3 , Figure 3 This is a schematic diagram of another stress testing system provided in Embodiment 2 of the present invention. The stress testing system includes a configuration parser (ConfigParser), a test executor (TestExecutor), a test behavior configurator (TestBehave), a parameter generator (ParamGenerator), a stubbing service simulator (ServerMocker), and a result statistics module (StatisticModule).

[0065] The ConfigParser is used to parse configuration files, configuring the system's working state through XML files and defining XML Schema files to constrain each XML element and its attributes. This configuration file allows configuration of test task parameter generation strategies, test behaviors, how to execute test behaviors, whether to perform stubbing services, and how to perform test result statistics, among other functions.

[0066] There are settings between the configuration parsers <tester>element, <tester>The `<test>` element is the root element in the entire configuration file. It is used to define a test instance, and all other XML elements contained in the configuration file are child elements of this element. <tester>The element has an optional enumeration type attribute 'mode', which specifies whether the system operates in normal mode (value 'TESTER') or stub service mode (value 'MOCK_SERVER').

[0067] The ParamGenerator is used to generate parameter values ​​in stress test requests or return values ​​from stubbing services. The parameter generator can be configured in a configuration file using a simple parameter value generator. <simplevalue>and complex parameter value generator <objectvalue>Two elements are configured to generate different types of parameter values ​​and return values. Among them, <simplevalue>The element generates parameter values ​​of fixed or random string, integer, floating-point, boolean, and date types. These simple parameter values ​​can be used to further construct subsequent Thrift interface parameter values, message bodies for message services, and key names or value keys in Redis, etc. <simplevalue>The element has the following attributes: the optional attribute `id` is used to uniquely identify a parameter value generator and to reference the parameter generator in other elements; the required attribute `type` is an enumeration type used to define the type of the parameter value, with possible values ​​of `string`, `int`, `long`, `float`, `double`, `boolean`, and `date`, where the `date` type specifies that the parameter value is a time string; the required attribute `mode` is an enumeration type used to define how the parameter value is generated, with possible values ​​of `const`, `length`, and `range`, used to specify that the parameter value is generated as a fixed value, a random value of a specified length, or a random value within a specified range, respectively. When the `type` attribute is `string`, the `mode` attribute can only be set to `fix` or `length`. The optional `format` attribute, valid when the `type` attribute is `date`, specifies the format of the generated time string, using the Java standard time string format definition, with a default format of "yyyy-MM-ddHH:mm:ss". The optional `value` attribute, valid when the `mode` attribute is `const`, specifies a fixed value for the generated parameter; it is optional and defaults to "0". The optional `length` attribute, valid when the `mode` attribute is `length`, specifies the length of the generated random parameter. The optional `min` attribute, valid when `mode` is `range`, specifies the minimum value of the generated random parameter. The optional `max` attribute, valid when `mode` is `range`, specifies the maximum value of the generated random parameter. An optional `ref` attribute is used to reference a defined global variable. <simplevalue>Elements. The configuration file can be configured with... <simplevalue>Elements or the range of parameters used to generate random parameters, etc.

[0068] <objectvalue>The element is a top-level parameter generator that can directly generate complex parameter objects for Thrift interfaces, MapMessage parameters for message services, or JSON string parameters. <objectvalue>The element has the following attributes: the optional attribute `id` is used to uniquely identify a parameter value generator and to reference the parameter generator in other elements; the optional attribute `class` is used to specify the fully qualified Java class name of the parameter object; and the optional attribute `ref` is used to reference other global classes. <objectvalue>element.

[0069] Optional, <objectvalue>Elements can be defined in multiple ways <property>The child element is used to configure the generation strategy of a field value in the parameter object. <property>Child elements can have the following attributes: a required attribute `name`, used to specify the name of the field to be set; an optional attribute `value`, used to specify a constant value for the corresponding field; and an optional attribute `valueRef`, used to reference a global value. <simplevalue>element or <obejectvalue>The element is the generated parameter value for the specified field.

[0070] <property>Child elements support the use of <list> 、 <set>and <map>The child element defines an attribute value generator for the field values ​​of a collection type. <list>and <set>The following child elements can be defined: <simplevalue>The child element directly defines a simple parameter value generator. <objectvalue>Child element: Directly define a Thrift parameter object generator. <map>Elements need to be passed <entry>The child element adds a collection element to it. <entry>The child element needs to be passed through <key>and <value>Add key-value pairs to child elements. <key>and <value>The child elements below are with <list>and <set>The elements are the same. <list>element, <set>Elements and <map>Elements can also be directly used as <objectvalue>The child element is used to directly generate a Java collection type object value.

[0071] The TestBehave module is used to define the operations performed during a test, including specifying the interface type used in the test, setting interface properties, and test parameters. This module is only available when... <tester>The element's `mode` attribute is set to `TESTER`, meaning the test instance only takes effect when it's running in normal mode. This module... <testbehave>Elements are configured, and multiple elements can be defined in a single configuration file. <testbehave>element.

[0072] <testbehave>An element has an id attribute, which is used to uniquely identify a single element. <testbehave>The element and its definition can be referenced in other elements. <testbehave>An element has one and only one child element, which can be configured as one of the following child elements: <thrift>element, <messages>Elements and <redis>element.

[0073] in, <thrift>The `<test>` element is used to define test behavior based on the Thrift interface. <thrift>The element can be configured with the following required attributes: host attribute, which specifies the IP address of the Thrift service being tested; port attribute, which specifies the port number of the Thrift service being tested; class attribute, which specifies the fully qualified Java class name of the RPC client calling interface generated by Thrift; and method attribute, which specifies the method name in the RPC interface to be tested.

[0074] Optional, <thrift>Multiple elements can be defined under an element. <param> The child element is used to configure how the parameters of the RPC interface method under test are generated. <param> The order of the child elements is the same as the order in which the parameters are defined in the method under test. Each <param> The child element has an optional ref attribute, which is used to reference globally defined elements. <simplevalue>element or <objectvalue>This element allows you to configure the strategy for generating parameter values. In addition, you can also... <param> Defining a dedicated element directly under a child element <simplevalue>child element or <objectvalue>Sub-elements.

[0075] <messages>The `<meta>` element is used to configure test behavior based on a message service and can be configured with the following attributes: `provider` attribute, which specifies the message provider; in this example, it can support ACTIVEMQ and KAFKA providers; `type` attribute, only valid when `provider` is ACTIVEMQ, specifies the message type, with possible values: `TEXT`, `MAP`, and `BYTE`, used to configure test behavior to produce `TextMessage`, `MapMessage`, and `ByteMessage` respectively; `brokers` attribute, used to connect to the message server URL; if `provider` is KAFKA, this attribute value is a string in the format `host:port`, and multiple addresses are separated by commas; `destination` attribute, used for the name of the JMS queue or topic used by the service under test, or the name of the Kafka topic; `isPersistent` attribute, only valid when `provider` is ACTIVEMQ, is a boolean type and specifies whether to use persistent messaging; `isQueue` attribute, only valid when `provider` is ACTIVEMQ, is a boolean type and specifies whether the message destination type is Queue or Topic.

[0076] Optional, <messages>One or more elements can be defined under an element. <message>The child element is used to define the strategy for generating the message body. If a... <messages>The element defines multiple <message>If the child element is executed, then each time the test behavior is executed, it will be performed according to each child element. <message>The messages are sent sequentially according to the order in which the child elements are defined. <message>Element properties and <messages>Same, if <messages>and <message>If elements define the same attribute, then <message>The attribute value in the element will override the attribute value with the same name in its parent element.

[0077] <message>The following child elements can also be defined under an element: <header>Child elements and child elements. Among them, <header>The child element is only valid when the provider attribute is ACTIVEMQ, and is used to configure the message headers for sending messages. <header>The child element configuration has the following attributes: The required attribute `name` specifies the message header to be set. For example, setting the `name` attribute to "correlationId" will call the JMS `setJMSCorrelationId(longcorrelationId)` method to set it; the optional attribute `ref` is used to reference globally defined headers. <simplevalue>The `<header>` element is used to set the value of the message header. The optional `value` attribute specifies that the value of a message header is a constant. <header>You can also define a proprietary element directly under the element. <simplevalue>element. <property>Element attributes and child elements <header>The elements are the same; when the provider attribute is ACTIVEMQ, the... <header>The `<message>` element is used to configure the attribute values ​​for sending messages; the system will reference these values ​​based on the `ref` attribute. <simplevalue>The `type` attribute of an element calls the JMS `set[type]Property(String name, [type] value)` method to set the message's property value. When the `provider` attribute is `KAFKA`, this... <header>The `<producer>` element contains attributes used to configure Kafka producers.

[0078] The child element, used to configure the message body content, has a ref attribute for referencing globally defined elements. <simplevalue>element or <map>Elements, or you can define proprietary ones directly under the element. <simplevalue>child element or <map>Child element. When <message>When the type attribute of the element is MAP, the <body child> element can only reference or define <map>The element, when its type attribute is TEXT or BYTE, or its provider attribute is KAFKA, <map>The object defined by the element will be converted into a JSON string.

[0079] <redis>The `<test>` element is used to configure Redis-based test behavior. <redis>The element can be configured with the following attributes: the host attribute, which specifies the address of the Redis server where the test data is to be written; and the port attribute, which specifies the port number of the Redis server where the test data is to be written.

[0080] Optional, <redis>Multiple elements can be defined under an element. <data>child element, <data>The sub-element is used to specify the test data to be written to Redis. <data>The child element has the following attributes: `host` attribute, which specifies the Redis server address where the test data will be written; if set, it will override the corresponding attribute value in the parent element, otherwise it will inherit the value from the parent element; `port` attribute, which specifies the Redis server port number where the test data will be written; if set, it will override the corresponding attribute value in the parent element, otherwise it will inherit the value from the parent element; `type` attribute, an enumeration type, specifies the data structure type in Redis where the test data will be stored. Possible values ​​are: `STRING`, `LIST`, `SET`, and `HASH`. When `type` is `STRING`, the test behavior will write the corresponding value to the specified key in Redis; when `type` is `LIST` or `SET`, the test behavior will add the specified value to the specified list or set structure in Redis; when `type` is `HASH`, the test behavior will add the specified field and field value to the specified hash structure in Redis; `key` attribute, which specifies the name of the Redis key used to store the test data as a constant; and `keyRef` attribute, which references a global key. <simplevalue>The `<key>` element generates a name for the Redis key used to store data; the `value` attribute specifies that the data value is a constant, but this attribute is invalid when the `type` attribute is set to `HASH`; the `valueRef` attribute specifies that the test data value is derived from a global variable. <simplevalue>This property is invalid when the type attribute value is HASH.

[0081] Optional, <data>The following three optional child elements can also be defined under a child element: child elements <key>sub-elements <field>Wako elements <value>Among them, child elements <key>This is used to specify the name of the Redis key for storing test data. It has two optional attributes: `value` and `ref`, which are used to specify the key name as a constant and a reference to a global key, respectively. <simplevalue>Alternatively, you can define proprietary features directly under this element. <simplevalue>Element; child element <field>This is only valid when the `type` attribute is `HASH`, and is used to specify the name of a field in a key of type `HASH`. The attributes and child elements of this element are related to... <key>Same elements; child elements <value>: Used to specify how to generate test data values; the attributes of this element and its child elements are related to... <key>The elements are the same.

[0082] The test executor is used to configure the execution plan for stress tests, including one or more of the following: the number of threads executing the test behavior, the number of times each thread executes the test, and the test time. It is also responsible for executing the tests and reporting the test results to the statistics module. The test executor only... <tester>The element's `mode` attribute is set to `TESTER`, meaning the test instance only takes effect when operating in normal mode. This test executor... <testexecutor>Element configuration is used; a configuration file can define multiple elements. <testexecutor>element.

[0083] <testexecutor>The `<executor>` element is used to configure the execution plan for the test executor module to perform stress tests. <testexecutor>The element configuration has the following attributes: the `threadNumber` attribute, which specifies the number of threads used by the test executor, allowing control over concurrency; the `executeNumber` attribute, which specifies the number of times each test thread executes the test behavior; and the `behaveRef` attribute, which references a global... <testbehave>The `<test>` element, whose attribute is used to configure the test behavior to be executed by the executor. Optional, <testexecutor>Elements can also be directly in <testexecutor>Defining proprietary elements directly under an element <testbehave>The `<test>` element is used to configure the test behavior that the executor will perform.

[0084] The test result statistics tool summarizes the test results reported by each thread in the test executor, including request latency, execution count, and error count. It then calculates the maximum, minimum, and average TPS, QPS, error rate, and latency metrics for the current test. This test result statistics tool... <statisticmodule>Configure the elements. <statisticmodule>The `<test>` element is used to configure the test report generation strategy for the test result statistician. <statisticmodule>The element has the following attributes: the boolean attribute doTPS, which configures whether to count TPS; the boolean attribute doQPS, which configures whether to count QPS; the boolean attribute doErrorRate, which configures whether to count error rate; and the boolean attribute doDelay, which configures whether to count latency.

[0085] ServerMocker, a staking service simulator, is used to simulate the behavior of backend services using HTTP or Thrift interfaces, responding to requests from the module under test and quickly returning specified result values. This staking service simulator is only available in... <tester>The element's `mode` attribute is set to `SERVER_MOCKER`, meaning this only takes effect when the test instance is running in stubbing service mode. This stubbing service simulator... <servermocker>Configure the elements. <servermocker>The element defines the following child elements <httpmocker>The child element is used to configure the stubbing functionality of the HTTP interface. <thriftmocker>The child element is used to configure the stubbing function of the Thrift interface.

[0086] <httpmocker>The child element is used to configure a service stub module that provides backend service simulation functionality via an HTTP interface. <httpmocker>The child element can be configured to return a specified value based on the HTTP request URL received from the service under test. <httpmocker>The child element has the following attributes: The required attribute `urlPrefix` defines the URL prefix for the HttpMock service provided by the test instance. For example, if the value of the `urlPrefix` attribute is configured as "mymocker", then the test instance will only provide mock service for HTTP requests with the URL "http: / / *:* / mymocker / **". The optional attribute `port` defines the port number on which the current Mocker provides the HTTP service.

[0087] Optional, <httpmocker>Multiple child elements can be defined <urlmapping>The child element is used to configure the return of a specified result for a specific URL. <urlmapping>The following two child elements must be defined under the child element: <pattern>The child element is used to specify a regular expression to configure a particular URL suffix. <result>Sub-elements are used to specify the criteria for successful matches. <pattern>A URL that specifies a pattern returns a specific value. <result>The child element has an optional `ref` attribute, which is used to reference the global reference. <simplevalue>child element or <objectvalue>Child elements can also define proprietary elements directly within that element. <simplevalue>child element or <objectvalue>Child elements. (Through) <objectvalue>The return value generated by the child element will be converted into a JSON string.

[0088] The staking service simulator can provide an implementation class of a server-side interface generated by the Thrift framework through Java dynamic proxy technology, thereby enabling the function of returning specified values ​​to specific Thrift interface requests. The above functionality provides... <thriftmocker>Child element configuration, <thriftmocker>The child element has the following attributes: The required attribute `port` specifies the port number on which the current mocker provides Thrift services; the required attribute `class` specifies the Java interface name of the server-side interface generated by the Thrift framework; the optional attribute `serverMode` specifies the working mode of the Thrift stubbing service server, with possible values ​​of `THREAD_POOL` and `SELECTOR`; the optional attribute `maxThreadNum`, which is valid when `serverMode` is `THREAD_POOL`, specifies the maximum number of threads started by the Thrift service server; and the optional attribute `minThreadNum`, which is valid when `serverMode` is `THREAD_POOL`, specifies the minimum number of threads started by the Thrift service server.

[0089] Optional, <thriftmocker>Multiple child elements can be defined <method>The sub-element is used to configure the return values ​​of various interface methods of each Thrift service. <method>The child element has the following attributes: a required attribute `name`, used to specify the name of a particular interface method in the Thrift interface; and an optional attribute `resultRef`, used to reference a globally defined... <simplevalue>or <objectvalue>The `<name>` element specifies the return value of the interface method specified by the `name` attribute.

[0090] Optional, <method>Defining proprietary elements directly under child elements <simgplevalue>child element or <objectvalue>The child element is configured to return the corresponding value for the specified interface method.

[0091] Example 3

[0092] Figure 4 This is a flowchart illustrating a stress testing method provided in an embodiment of the present invention. This embodiment is applicable to stress testing microservices without the need for coding. The method can be executed by the stress testing system provided in this embodiment of the present invention, and specifically includes the following steps:

[0093] S210. Receive the test configuration file based on the configuration parser, and parse the test configuration file to obtain test process information.

[0094] S220. Read the parameter generation strategy from the test process information based on the parameter generator, and generate test parameters based on the parameter generation strategy.

[0095] S230. Based on the test behavior configurator, read the test behavior information from the test process information and reuse the test parameters generated by the parameter generator, and initialize the test behavior based on the test behavior information and the test parameters.

[0096] S240. Based on the test execution information read from the test process information by the test executor, and the test behavior of the test behavior configurator is reused, the test execution information and the reused test behavior are initialized, and the test task is executed on the reused test behavior based on the test execution information, and the test result is output.

[0097] Optionally, the parameter generator includes a simple parameter generator and a complex parameter generator, and the parameter generation strategy includes parameter values ​​of preset types and parameter objects.

[0098] Optionally, the simple parameter generator is used to generate parameter values ​​of the corresponding type based on the type of the parameter value; the complex parameter generator is used to reuse at least one simple parameter generator and / or at least one complex parameter generator to generate the parameter object.

[0099] Optionally, the test behavior configurator includes test behavior configuration units for multiple protocols.

[0100] Optionally, the test execution information includes at least one of the following: the number of threads for the test behavior, the number of tests, and the test time.

[0101] Optionally, the above methods also include:

[0102] The parameter generator generates piling service parameters based on the read parameter generation strategy;

[0103] The system reads the piling service information from the test process information based on the piling service simulator, and reuses the piling service parameters generated by the parameter generator. It initializes the system based on the piling service information and the piling service parameters, executes the piling service simulation task, and outputs the piling service simulation results.

[0104] Optionally, the piling service simulator includes a piling service simulation unit with at least one interface;

[0105] The process of reading piling service information from the test process information using a piling service simulator, reusing piling service parameters generated by the parameter generator, initializing based on the piling service information and the piling service parameters, and executing a piling service simulation task includes:

[0106] Each of the piling service simulation units executes the piling service simulation task of the corresponding interface based on the piling service information and the piling service parameters generated by the parameter generator.

[0107] Optionally, the test process information includes test mode attributes, which include a piling service mode identifier and a normal mode identifier. The piling service mode identifier is used to trigger the test executor to execute the test task, and the normal mode identifier is used to trigger the piling service simulator to execute the piling service simulation.

[0108] Optionally, the method further includes:

[0109] The result statistician receives the test results output by the test executor and generates a test report based on the test indicators in the test results.

[0110] Alternatively, the test results and the piling service simulation results are received by the result statistician, and a test report is generated based on the test indicators in the test results and the piling service simulation results.

[0111] The technical solution of this embodiment sets a configuration file, which includes the test process information required during the stress test of the target object. The configuration parser parses the configuration file to obtain the test process information. Based on the parsed test process information, the parameter generator, test behavior configurator and test executor are initialized to obtain a stress test system that can perform stress tests on the target object. The system performs stress tests on the target object and obtains the test results. There is no need to write stress test code, which reduces the difficulty and workload of stress testing and simplifies the stress testing process.

[0112] A preferred example of a stress testing method is also provided based on the above embodiments. See [link to example]. Figure 5 , Figure 5 This is a flowchart illustrating another stress testing method provided in Embodiment 3 of the present invention. The method includes: obtaining a configuration file and parsing it to obtain test process information; initializing a parameter generator based on the parameter generation strategy in the test process information to generate test parameters; determining whether the test mode attribute in the test process information is a staking mode identifier (ServerMocker); if so, initializing a staking service simulator based on the staking service parameters in the test process information, configuring the parameter generator for the staking service simulator by reusing the parameter generator, executing the staking service task, and obtaining the staking service result; if the test mode attribute is not a staking mode identifier (i.e., a normal test mode), initializing test behavior based on the test behavior information in the test process information, configuring a parameter generator for the test behavior, further initializing a test executor based on the test execution information in the test process information, configuring the test behavior on the executor, executing the stress test task, obtaining the test result, and the result statistics module statistically analyzing the running results based on the test result and the staking service result to obtain a test report.

[0113] Example 4

[0114] Figure 6 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. Figure 6 A block diagram is shown of an electronic device 12 suitable for implementing embodiments of the present invention. Figure 6 The electronic device 12 shown is merely an example and should not be construed as limiting the functionality or scope of the embodiments of the present invention. Device 12 is typically an electronic device that performs image classification functions.

[0115] like Figure 6 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors 16, a storage device 28, and a bus 18 connecting different system components (including the storage device 28 and the processor 16).

[0116] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0117] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0118] Storage device 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 6 Not shown; usually referred to as "hard drive"). Although Figure 6 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disc drive for reading and writing to a removable non-volatile optical disc (e.g., a compact disc-read-only memory (CD-ROM), a digital video disc-read-only memory (DVD-ROM), or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. Storage device 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0119] A program 36 having a set (at least one) of program modules 26 may be stored in, for example, a storage device 28. Such program modules 26 include, but are not limited to, an operating system, one or more applications, other program modules, and program data. Each or some combination of these examples may include an implementation of a gateway environment. Program modules 26 typically perform the functions and / or methods described in the embodiments of the present invention.

[0120] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, camera, display 24, etc.), and with one or more devices that enable a user to interact with electronic device 12, and / or with any device that enables electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more gateways (e.g., Local Area Network (LAN), Wide Area Network (WAN) and / or public gateways, such as the Internet) via gateway adapter 20. As shown, gateway adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Arrays of Independent Disks (RAID) systems, tape drives, and data backup storage systems.

[0121] The processor 16 executes various functional applications and data processing by running programs stored in the storage device 28, such as implementing the stress testing method provided in the above embodiments of the present invention.

[0122] Example 5

[0123] Embodiment 5 of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the stress testing method provided in the embodiments of the present invention.

[0124] Of course, the computer program stored on the computer-readable storage medium provided in the embodiments of the present invention is not limited to the method operation described above, and can also execute the stress testing method provided in any embodiment of the present invention.

[0125] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0126] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable source code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device.

[0127] Source code contained on a computer-readable medium may be transmitted on any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0128] Computer source code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The source code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of gateway—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0129] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.< / objectvalue> < / simgplevalue> < / method> < / objectvalue> < / simplevalue> < / method> < / method> < / thriftmocker> < / thriftmocker> < / thriftmocker> < / objectvalue> < / objectvalue> < / simplevalue> < / objectvalue> < / simplevalue> < / result> < / pattern> < / result> < / pattern> < / urlmapping> < / urlmapping> < / httpmocker> < / httpmocker> < / httpmocker> < / httpmocker> < / thriftmocker> < / httpmocker> < / servermocker> < / servermocker> < / tester> < / statisticmodule> < / statisticmodule> < / statisticmodule> < / testbehave> < / testexecutor> < / testexecutor> < / testbehave> < / testexecutor> < / testexecutor> < / testexecutor> < / testexecutor> < / tester> < / key> < / value> < / key> < / field> < / simplevalue> < / simplevalue> < / key> < / value> < / field> < / key> < / data> < / simplevalue> < / simplevalue> < / data> < / data> < / data> < / redis> < / redis> < / redis> < / map> < / map> < / message> < / map> < / simplevalue> < / map> < / simplevalue> < / header> < / simplevalue> < / header> < / header> < / property> < / simplevalue> < / header> < / simplevalue> < / header> < / header> < / header> < / message> < / message> < / message> < / messages> < / messages> < / message> < / message> < / message> < / messages> < / message> < / messages> < / messages> < / objectvalue> < / simplevalue> < / objectvalue> < / simplevalue> < / thrift> < / thrift> < / thrift> < / redis> < / messages> < / thrift> < / testbehave> < / testbehave> < / testbehave> < / testbehave> < / testbehave> < / tester> < / objectvalue> < / map> < / set> < / list> < / set> < / list> < / value> < / key> < / value> < / key> < / entry> < / entry> < / map> < / objectvalue> < / simplevalue> < / set> < / list> < / map> < / set> < / list> < / property> < / obejectvalue> < / simplevalue> < / property> < / property> < / objectvalue> < / objectvalue> < / objectvalue> < / objectvalue> < / simplevalue> < / simplevalue> < / simplevalue> < / simplevalue> < / objectvalue> < / simplevalue> < / tester> < / tester> < / tester>

Claims

1. A pressure testing system, characterized in that, include: Configure a parser to receive the test configuration file and parse it to obtain test process information; The test process information includes parameter generation strategy, test behavior information, and test execution information; The parameter generation strategy includes parameter values ​​of preset types and parameter objects; A parameter generator is used to read the parameter generation strategy from the test process information and generate test parameters based on the parameter generation strategy. The test parameters include the parameter values ​​in the stress test request; A test behavior configurator, connected to the parameter generator, is used to read test behavior information from the test process information and reuse test parameters generated by the parameter generator, and initialize test behavior based on the test behavior information and the test parameters; The test executor, connected to the test behavior configurator, is used to read the test execution information in the test process information and reuse the test behavior of the test behavior configurator, initialize based on the test execution information and the reused test behavior, execute test tasks on the reused test behavior based on the test execution information, and output test results.

2. The pressure testing system according to claim 1, characterized in that, The parameter generator includes a simple parameter generator and a complex parameter generator, wherein the simple parameter generator is used to generate parameter values ​​of the corresponding type based on the type of the parameter value; The complex parameter generator is used to reuse at least one simple parameter generator and / or at least one complex parameter generator to generate the parameter object.

3. The pressure testing system according to claim 1, characterized in that, The test behavior configurator includes test behavior configuration units for multiple protocols.

4. The pressure testing system according to claim 1, characterized in that, The test execution information includes at least one of the following: the number of threads used in the test, the number of tests, and the test time.

5. The pressure testing system according to claim 1, characterized in that, The pressure testing system also includes a piling service simulator; The parameter generator is also used to generate piling service parameters based on the read parameter generation strategy; The piling service simulator is connected to the parameter generator and is used to read piling service information from the test process information, reuse piling service parameters generated by the parameter generator, initialize based on the piling service information and the piling service parameters, execute the piling service simulation task, and output the piling service simulation results.

6. The pressure testing system according to claim 5, characterized in that, The piling service simulator includes a piling service simulation unit with at least one interface; Each of the piling service simulation units is used to execute the piling service simulation task of the corresponding interface based on the piling service information and the piling service parameters generated by the parameter generator.

7. The pressure testing system according to claim 5, characterized in that, The test process information includes test mode attributes, which include a piling service mode identifier and a normal mode identifier. The piling service mode identifier is used to trigger the test executor to execute the test task, and the normal mode identifier is used to trigger the piling service simulator to execute the piling service simulation.

8. The pressure testing system according to claim 1 or 5, characterized in that, The stress testing system also includes a result statistician; The result statistician is connected to the test executor, receives the test results output by the test executor, and generates a test report based on the test indicators in the test results; or, The result statistician is connected to the test executor and the piling service simulator respectively, receives the test results and the piling service simulation results, and generates a test report based on the test indicators in the test results and the piling service simulation results.

9. A pressure testing method, characterized in that, include: The configuration parser receives the test configuration file and parses it to obtain test process information. The test process information includes parameter generation strategy, test behavior information, and test execution information; The parameter generation strategy includes parameter values ​​of preset types and parameter objects; The parameter generator reads the parameter generation strategy from the test process information and generates test parameters based on the parameter generation strategy. The test parameters include the parameter values ​​in the stress test request; The test behavior is initialized based on the test behavior information read from the test process information by the test behavior configurator and the test parameters generated by the parameter generator. The test executor reads the test execution information from the test process information and reuses the test behavior from the test behavior configurator. It initializes based on the test execution information and the reused test behavior, executes test tasks on the reused test behavior based on the test execution information, and outputs test results.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the stress testing method as described in claim 9.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the stress testing method as described in claim 9.

Images