Method for automatic generation and execution of stress test scripts

Abstract

The application provides a method for automatic generation and execution of a stress test script. By constructing an automatic generation and execution closed loop from command line network request instructions to executable stress test scripts, the core problem of low efficiency and error-prone manual conversion and configuration is solved. The scheme first intelligently analyzes and standardizes the instruction text modeling, converts manual interpretation into machine-processed structured request model; then combined with stress configuration, dynamically synthesizes test logic structure conforming to test tool specifications; can also intelligently analyze the parameter dependence between interfaces, automatically complete the parameter transmission configuration in the script; finally realize one-key generation, automatic execution and report recovery of the test script. The scheme converts the originally cumbersome professional manual operation into an efficient and accurate automated process, significantly reducing the technical threshold and time cost of stress testing, and improving the reliability and consistency of the test activity.

Description

Technical Field

[0001] This application relates to the field of software engineering, and in particular to a method for automatically generating and executing stress test scripts. Background Technology

[0002] In the field of software system development and testing, stress testing is a crucial step in evaluating system performance, stability, and reliability. Currently, development or testing engineers typically use command-line interface network request commands (such as cURL commands) as the standard method to obtain interface request information. However, stress testing tools require test plan files in a specific format to execute tests. Therefore, in practice, engineers must manually convert the easily accessible and debuggable cURL commands into complex JMX format test scripts with numerous configuration options.

[0003] However, this conversion process is not only cumbersome and time-consuming, but also prone to omissions or errors when manually filling in various network parameters (such as request headers, message bodies, authentication tokens, etc.). In addition, existing script writing environments and stress test execution environments are usually isolated from each other, lacking an end-to-end automated closed loop from instruction parsing and script generation to test execution and result collection, resulting in low overall efficiency of stress testing and difficulty in ensuring the accuracy and consistency of test scenario construction.

[0004] Therefore, there is an urgent need for an automatic generation and execution method for stress test scripts that can automatically and accurately convert command-line request instructions into executable stress test scripts and complete automated testing processes, so as to improve the efficiency and effectiveness of stress testing. Summary of the Invention

[0005] The purpose of this application is to address at least one of the aforementioned technical deficiencies, particularly the insufficient efficiency and effectiveness of stress testing in the prior art.

[0006] Firstly, this application provides a method for automatically generating and executing stress test scripts, the method comprising:

[0007] Retrieve the command-line network request instruction text;

[0008] The command-line network request instruction text is parsed and processed to extract network request feature information and generate a request model;

[0009] Obtain the preset stress test configuration information;

[0010] Based on the request model and the stress test configuration information, a test plan file in a preset format is constructed and generated;

[0011] The test plan file is executed automatically to complete the stress test process.

[0012] As an optional implementation, the step of parsing the command-line network request instruction text, extracting network request feature information, and generating a request model includes:

[0013] The command-line network request instruction text is preprocessed to be normalized;

[0014] Identify and separate network request feature information from the preprocessed command-line network request instruction text;

[0015] The network request feature information includes a request method field, a Uniform Resource Locator field, a request header information set, and a request message body field.

[0016] Based on the network request characteristic information, a standardized request model with a preset structure is constructed.

[0017] As an optional implementation, the stress test configuration information includes the total number of virtual users and the user startup time configuration;

[0018] The process of constructing and generating a pre-defined test plan file based on the request model and stress test configuration information includes:

[0019] Based on the total number of virtual users and the user startup time configuration, generate configuration nodes;

[0020] Based on the request model, create a corresponding request action node, and configure the corresponding test component information in the request action node;

[0021] Based on the configuration node and the request action node, a test logic structure is constructed, and a test plan file in a preset format is generated.

[0022] As an optional implementation, the method further includes:

[0023] Based on the test plan file, determine the parameter dependencies between upstream and downstream interfaces;

[0024] Based on the parameter dependencies, in the test logic structure, a post-extractor is inserted into the preceding request action node, and static fields are replaced with dynamic placeholders in the following request action node.

[0025] As an optional implementation, determining the parameter dependencies between upstream and downstream interfaces based on the test plan file includes:

[0026] Based on each request action node in the test plan file, determine the upstream action nodes that have interface associations and the downstream action nodes corresponding to each upstream action node;

[0027] The parameter dependency relationship is determined based on the semantic and logical association between the network request feature information of the downstream action node and the network request feature information of the corresponding upstream action node.

[0028] As an optional implementation, the automatic execution of the test plan file to complete the stress test process includes:

[0029] The test plan file is scheduled to the stress test engine in the background, and the stress test engine is controlled to load and execute the test plan file.

[0030] During the execution of the test plan file, stress is applied to replay the traffic, and performance metrics data generated by the stress test engine during operation are collected.

[0031] The performance index data is aggregated and processed to generate a structured test result report.

[0032] Secondly, this application provides an apparatus for automatically generating and executing stress test scripts, the apparatus comprising:

[0033] The processing module is used to obtain the command-line network request instruction text;

[0034] The processing module is also used to parse the command line network request instruction text, extract network request feature information, and generate a request model;

[0035] The processing module is also used to obtain preset stress test configuration information;

[0036] The processing module is also used to construct and generate a test plan file in a preset form based on the request model and the stress test configuration information;

[0037] The processing module is also used to automatically execute the test plan file to complete the stress test process.

[0038] As an optional implementation, the specific method by which the processing module parses the command-line network request instruction text, extracts network request feature information, and generates a request model includes:

[0039] The command-line network request instruction text is preprocessed to be normalized;

[0040] Identify and separate network request feature information from the preprocessed command-line network request instruction text;

[0041] The network request feature information includes a request method field, a Uniform Resource Locator field, a request header information set, and a request message body field.

[0042] Based on the network request characteristic information, a standardized request model with a preset structure is constructed.

[0043] Thirdly, this application provides a computer device including one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method described in the first aspect.

[0044] Fourthly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method described in the first aspect.

[0045] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0046] Based on any of the above embodiments, the method provided in this application solves the core problems of low efficiency and error-proneness of manual conversion and configuration by constructing an automated generation and execution closed loop from command-line network request instructions to executable stress test scripts. The solution first performs intelligent parsing and standardized modeling of the instruction text, transforming manual interpretation into a machine-processable structured request model; then, combined with stress configuration, it dynamically synthesizes a test logic structure that conforms to the testing tool specifications; it can also intelligently analyze parameter dependencies between interfaces and automatically complete parameter passing configuration in the script; finally, it achieves one-click generation, automatic execution, and report collection of test scripts. This solution transforms the originally tedious and professional manual operation into an efficient and accurate automated process, significantly reducing the technical threshold and time cost of stress testing, and improving the reliability and consistency of testing activities. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 A flowchart illustrating an embodiment of the method for automatically generating and executing stress test scripts provided in this application;

[0049] Figure 2 A schematic diagram of the process architecture based on a real-world application scenario for the automatic generation and execution method of stress test scripts provided in one embodiment of this application;

[0050] Figure 3This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0051] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0052] In the field of software system development and testing, stress testing is a crucial step in evaluating system performance, stability, and reliability. Currently, development or testing engineers typically use command-line interface network request commands (such as cURL commands) as the standard method to obtain interface request information. However, stress testing tools require test plan files in a specific format to execute tests. Therefore, in practice, engineers must manually convert the easily accessible and debuggable cURL commands into complex JMX format test scripts with numerous configuration options.

[0053] However, this conversion process is not only cumbersome and time-consuming, but also prone to omissions or errors when manually filling in various network parameters (such as request headers, message bodies, authentication tokens, etc.). In addition, existing script writing environments and stress test execution environments are usually isolated from each other, lacking an end-to-end automated closed loop from instruction parsing and script generation to test execution and result collection, resulting in low overall efficiency of stress testing and difficulty in ensuring the accuracy and consistency of test scenario construction.

[0054] Therefore, there is an urgent need for an automatic generation and execution method for stress test scripts that can automatically and accurately convert command-line request instructions into executable stress test scripts and complete automated testing processes, so as to improve the efficiency and effectiveness of stress testing.

[0055] In summary, the technical concept of this application lies in providing an efficient and accurate method for generating and executing automated stress test scripts. Its technical effectiveness stems from a systematic innovation of the traditional manual process. In existing technologies, engineers need to manually parse command-line network request instructions and fill in various network parameters item by item in the testing tool to construct the test script. This process is lengthy and prone to configuration errors or omissions due to human negligence. It is particularly difficult to handle parameter dependencies between multiple interfaces, and the script generation and test execution environments are isolated from each other. This solution effectively overcomes the above-mentioned shortcomings through a complete technical closed loop of instruction parsing, model conversion, logic construction, and automatic execution. Specifically, the solution first standardizes and extracts features from unstructured command-line instruction text, accurately converting it into a structured request model, eliminating errors from manual interpretation. Second, based on user-preset stress test configuration information, the request model is combined with the configuration information to automatically assemble a test logic structure containing configuration nodes and request action nodes, generating a standardized test plan file that can be directly executed, thus achieving automated and standardized construction of test scenarios. Furthermore, the solution analyzes the semantic and logical relationships between different request action nodes in the test plan, intelligently determines parameter dependencies, and automatically inserts post-extractors in pre-nodes and replaces dynamic placeholders in post-nodes, solving key challenges in script writing for complex scenarios. Finally, the solution achieves automatic background scheduling of test plan files, stress application, performance data collection, and structured report generation, forming an end-to-end automated test pipeline. In summary, this solution transforms stress testing from a task highly dependent on manual operation and expertise into an efficient, reliable, and repeatable automated process, significantly improving test efficiency, accuracy, and consistency.

[0056] The methods provided in this application will be described in detail below based on the corresponding implementation methods in some practical application scenarios.

[0057] Figure 1 A flowchart illustrating an embodiment of the method for automatically generating and executing stress test scripts provided in this application is shown below. Figure 1 As shown, this application provides a method for automatically generating and executing stress test scripts, the method comprising:

[0058] S101. Obtain the command line network request instruction text;

[0059] S102. Parse the command line network request instruction text, extract network request feature information and generate a request model;

[0060] S103. Obtain the preset stress test configuration information;

[0061] S104. Based on the request model and the stress test configuration information, construct and generate a test plan file in a preset format;

[0062] S105. Automatically execute the test plan file to complete the stress test process.

[0063] Figure 2 The flowchart illustrating the process architecture based on a real-world application scenario for the automatic generation and execution method of stress test scripts provided in one embodiment of this application is shown below. Figure 2 The following provides a detailed description of the overall process of this application, and its specific implementation can also be found in the relevant implementation methods.

[0064] In practical application scenarios, the technical backbone of this application can be understood as a closed loop of "cURL input → JMX parsing and generation → automated execution".

[0065] cURL structured parsing:

[0066] Capture one or more raw Bash cURL command texts entered by the user;

[0067] Extract and strip features from fields such as request path (URL), request headers, request body, and request method;

[0068] Transform text instructions into standardized request entity models;

[0069] Dynamic assembly of JMX logic trees:

[0070] Read the set concurrency target (such as thread count configuration, Ramp-Up period);

[0071] Serialize the request entity model into a node tree (AST) in JMeter XML format.

[0072] Automatically mount necessary test components (such as HTTP Header Manager and HTTP Request Sampler);

[0073] Automatic correlation of upstream and downstream parameters:

[0074] Determine the parameter dependencies between multiple interfaces in the upstream and downstream processes;

[0075] Automatically insert post-extractors (such as JSON Extractor) and dynamic placeholders for downstream variables into the JMX tree to replace static fields;

[0076] Automated concurrent execution and recycling:

[0077] The system silently mounts and executes the generated .jmx load test file via the background without requiring any configuration.

[0078] The automatic scheduling engine applies pressure to replay traffic and simultaneously collects the aggregated monitoring data;

[0079] Specifically, this application provides a method for automatically generating and executing stress test scripts. Its core lies in building an end-to-end automated pipeline from obtaining raw instructions to completing the stress test. First, it obtains the command-line network request command text. This can be standardized network request command text obtained by engineers when debugging interfaces, such as command-line strings copied from browser developer tools for sending network requests. This text is the raw data source for all subsequent automated processing. It can be obtained by the user pasting input through a graphical interface, or by the system automatically reading it from a specified file or network interface.

[0080] Next, the system parses the acquired command-line network request text. The purpose of this parsing is to understand this unstructured text instruction and precisely extract all the essential elements necessary to constitute a complete network request. This process is not simply string truncation; it requires understanding the command's syntactic structure and distinguishing between the command itself, parameter options, Uniform Resource Locator (URL), request headers, and the request message body. Through parsing, the system transforms a human-friendly but machine-unprocessable text into a set of structured and explicit network request feature information, and generates an internally defined, standardized request model based on this information. This request model is an abstract and data-driven representation of the network request, laying the data foundation for subsequent automated construction.

[0081] Next, the system needs to obtain the preset stress test configuration information. This configuration information defines the execution strategy of the stress test, such as the total number of virtual users, the time it takes for these virtual users to gradually start and complete, the number of loops, and the think time. This information is usually preset by the testers according to the test objectives and can be input into the system through configuration files, databases, or graphical configuration interfaces. After obtaining the request model and stress test configuration information, the system enters the build and generation phase. In this phase, based on the aforementioned structured request model and stress test configuration information, the system dynamically assembles and generates a preset test plan file that meets the requirements of a specific stress test tool. This file is essentially a script or project file that can be directly recognized and executed by the stress test engine. The build process is equivalent to an "assembly" process. The system instantiates the request model into specific request elements in the test tool and creates corresponding logic control elements such as concurrency control and timers according to the configuration information. Finally, these elements are organized into a complete test plan structure according to the test logic and serialized into a file in the target format.

[0082] Finally, the entire stress testing process is completed through the automated execution of the test plan file. After the test plan file is generated, there is no need for manual opening of the stress testing tool, loading of the file, and starting of the test. The system can automatically schedule the file to the stress testing engine in the background, control the engine to load the file, apply pressure according to the logic defined in the file, and send back traffic to simulate the behavior of a large number of users accessing the system under test. Throughout the execution process, the system synchronously collects various performance indicator data generated by the stress testing engine, such as response time, throughput, and error rate. After the test is completed, the system aggregates, analyzes, and processes these collected raw performance indicator data, and finally generates a well-structured and complete test result report. The entire process seamlessly connects the previously separate manual steps of script writing, environment configuration, test execution, and report generation, achieving full automation.

[0083] The method provided in this embodiment acquires command-line network request instruction text, automates its parsing to extract network request feature information and generate a request model. This model, combined with preset stress test configuration information, automatically constructs and generates an executable test plan file, which is then automatically executed to complete the entire stress test process. This method constructs a complete automated closed loop, transforming the tedious and error-prone process of manually interpreting command-line instructions, configuring network parameters in the testing tool, and starting the test into a standardized process automatically completed by the system. This not only significantly reduces the time and effort required for manual intervention but also eliminates omissions or errors that may result from manual configuration through procedural operation, thereby greatly improving the overall efficiency of stress test construction, execution accuracy, and process reliability.

[0084] As an optional implementation, the step of parsing the command-line network request instruction text, extracting network request feature information, and generating a request model includes:

[0085] The command-line network request instruction text is preprocessed to be normalized;

[0086] Identify and separate network request feature information from the preprocessed command-line network request instruction text;

[0087] The network request feature information includes a request method field, a Uniform Resource Locator field, a request header information set, and a request message body field.

[0088] Based on the network request characteristic information, a standardized request model with a preset structure is constructed.

[0089] This implementation provides a conversion process from raw command-line text to a standardized request model. First, the command-line network request instruction text undergoes normalization preprocessing. Since user-inputted or copied instruction text from different sources may have inconsistent formatting, such as extra spaces, line breaks, mismatched quotation marks, or comments that are useless for parsing, the purpose of normalization preprocessing is to clean and standardize this raw text, making it conform to a uniform parsing format.

[0090] For example, the system can remove leading and trailing whitespace characters from text, compress multiple consecutive spaces into a single space, merge strings that should belong to the same part but are broken due to line breaks, and check and fix possible quotation mark pairing errors to ensure the accuracy and robustness of subsequent parsing.

[0091] Next, network request feature information is identified and separated from the preprocessed text. This process is the core of parsing and requires designing a corresponding parser based on the syntax rules of command-line network request instructions (such as the widely used curl command). The parser scans the preprocessed text word by word, identifies command keywords and parameter option identifiers, and extracts the parameter values ​​that follow. Specifically, the system needs to identify and separate the following key information: first, the request method field, such as the standard method name corresponding to operations like fetch, submit, update, and delete; second, the Uniform Resource Locator field, i.e., the target network address of the request; third, the request header information set, which is usually a set of key-value pairs containing information such as content type, authentication token, and user agent; and fourth, the request message body field, i.e., the main data content carried by the request, which may be form data, JSON, or XML strings, etc.

[0092] Finally, based on the extracted network request feature information, the system constructs a standardized request model with a pre-defined structure. This model is a data object or structure created in memory, with a predefined structure containing attribute fields that correspond one-to-one with the aforementioned feature information. For example, the model might contain attributes such as "method" (string type, storing the request method), "url" (string type, storing the Uniform Resource Locator), "headers" (dictionary or mapping type, storing request header key-value pairs), and "body" (string or byte stream type, storing the request message body). The construction process involves assigning the parsed feature information to the corresponding attributes of the model. Through this step, an unstructured text instruction is accurately transformed into a clearly structured and attribute-defined data object—the standardized request model—providing accurate and reliable input data for subsequent automated test script construction.

[0093] This implementation preprocesses the command-line network request text to standardize and unify the format of the input commands, laying the foundation for accurate subsequent parsing. The system then automatically identifies and separates core network request features from the preprocessed text, including the request method field, Uniform Resource Locator (URL) field, request header information set, and request message body field. The standardized request model built upon this structured information provides a precise and consistent data foundation for subsequent automated script generation. This process achieves a precise conversion from unstructured text commands to a structured data model, replacing the inefficient method of manually reading and understanding commands, ensuring the completeness and accuracy of feature extraction, and thus guaranteeing that the final generated test script accurately reflects the original network request intent.

[0094] As an optional implementation, the stress test configuration information includes the total number of virtual users and the user startup time configuration;

[0095] The process of constructing and generating a pre-defined test plan file based on the request model and stress test configuration information includes:

[0096] Based on the total number of virtual users and the user startup time configuration, generate configuration nodes;

[0097] Based on the request model, create a corresponding request action node, and configure the corresponding test component information in the request action node;

[0098] Based on the configuration node and the request action node, a test logic structure is constructed, and a test plan file in a preset format is generated.

[0099] This implementation further refines the specific process of constructing a test plan file based on the request model and stress test configuration information, transforming abstract logical construction into the creation and assembly of specific nodes. Firstly, the most crucial aspect of the stress test configuration information is the configuration of the total number of virtual users (e.g., thread count) and user startup time (e.g., ramp-up period). The total number of virtual users defines the number of concurrent users to be simulated during the stress test, while the user startup time configuration defines the time frame within which all virtual users must start up, thus affecting the rate at which the system can withstand increasing stress.

[0100] After reading these configurations, the system generates one or more configuration nodes. In a tree-structured or hierarchical test plan file, configuration nodes typically correspond to components that control the test concurrency logic. For example, in a typical stress testing tool project structure, this configuration node might correspond to a "thread group" element. The system sets the thread count attribute of this thread group based on the total number of virtual users and its startup cycle attribute based on the user startup time configuration. This node, as the top-level container for the test logic, defines the basic strategy for applying stress.

[0101] Next, the system creates corresponding request action nodes based on the standardized request model. Each request model corresponds to an independent network request operation and is therefore instantiated as a request action node, such as an "HTTP Request Sampler" node. Simultaneously, the system configures the corresponding test component information within the node. Specifically, the system maps each field in the request model to the corresponding attribute of the request action node. For example, the request method field is filled into the method attribute, the Uniform Resource Locator (URL) field into the path attribute, each key-value pair in the request header information set is created as an independent "HTTP Header Manager" sub-component and attached to the request action node, and the request message body field is filled into the request body data attribute. In this way, a complete, independently sendable network request unit is constructed.

[0102] Finally, the system constructs the test logic structure based on the configuration nodes and request action nodes, and generates a pre-defined test plan file. The process of constructing the logical structure allows request action nodes to be treated as child nodes, mounted or nested under previously created configuration nodes, forming a parent-child or subordinate relationship of "configuration node - request action node". This structure reflects the test logic of "executing specific network requests under a specific concurrency strategy". After assembly, the system transforms this in-memory, tree-like logical structure model into a pre-defined file format that can be directly read and executed by the stress testing engine, such as a test plan file format based on Extensible Markup Language. This file contains complete concurrency configuration and request details, and can be directly loaded and executed by stress testing tools.

[0103] This implementation automatically generates corresponding configuration nodes by reading preset stress test configuration information such as the total number of virtual users and user startup time. Simultaneously, based on the aforementioned request model, it automatically creates corresponding request action nodes and configures necessary test component information. Finally, by logically assembling the configuration nodes and request action nodes, a test plan file in a preset format is generated. This process automates the assembly of test logic and stress strategies. Users only need to provide basic concurrency and time configurations, and the system can automatically complete the structured construction of the test scenario, avoiding the tedious manual addition and configuration of thread groups, samplers, and other components, ensuring the speed of test plan construction and the consistency of configuration.

[0104] As an optional implementation, the method further includes:

[0105] Based on the test plan file, determine the parameter dependencies between upstream and downstream interfaces;

[0106] Based on the parameter dependencies, in the test logic structure, a post-extractor is inserted into the preceding request action node, and static fields are replaced with dynamic placeholders in the following request action node.

[0107] This implementation adds intelligent identification and automated configuration capabilities for parameter dependencies between interfaces, building upon the existing test plan file. This is crucial for simulating real, stateful business scenarios. When the test plan file contains multiple request action nodes, the interface calls represented by these nodes may have data dependencies. For example, an interface response for "user login" might return an authentication token, and the subsequent interface for "query user information" needs to use this token in the request header for authentication. Traditionally, when writing scripts manually, engineers need to manually write code to extract the token from the login response and set it as a variable for use in subsequent requests. This implementation aims to automate this tedious and error-prone process.

[0108] First, based on the generated test plan file, the system determines the parameter dependencies between upstream and downstream interfaces represented by different request action nodes. This process can be achieved by analyzing the semantics and logical relationships of the interfaces. For example, the system can analyze the path patterns of Uniform Resource Locators, the names and values ​​of parameters in the request message body, or perform matching based on a preset business rule base. Determining dependencies means identifying which upstream request's return value needs to be used by which downstream request's parameter. Once the parameter dependencies are determined, the system automatically configures the corresponding dependencies in the test logic structure.

[0109] Specifically, for upstream request action nodes identified as data providers, i.e., pre-request action nodes, the system automatically inserts a post-extractor component under them. The function of this post-extractor is to extract specific data values ​​from its response content (such as response body or response header) according to predetermined rules (such as extracting from JSON based on key names or using regular expression matching) after the request is completed, and store the value in a named variable.

[0110] Next, for downstream request nodes that rely on this data, the system locates the static fields in their network request feature information that need to reference this data. For example, it finds a static field in the request header information set or a parameter value in the request message body fields. Then, the system replaces these static fields, which were originally fixed values, with dynamic placeholders that reference the aforementioned named variables.

[0111] When the test is actually executed, the stress testing engine first executes the pre-request to extract variable values, and then automatically replaces the dynamic placeholders with the actual variable values ​​when executing the post-request. In this way, the system automatically implements the cross-interface parameter passing logic configuration, enabling the test script to realistically simulate business chains with data flow, greatly improving the automation and accuracy of building test scripts for complex scenarios.

[0112] This implementation method, based on the generated test plan file, further automatically analyzes and determines the parameter dependencies between upstream and downstream interfaces. According to the identified dependencies, the system can automatically insert a post-extractor into the pre-request action node in the test logic structure to capture specific data in the response; and in the post-request action node, it intelligently replaces the originally static fields with dynamic placeholders referencing the upstream extraction results. This mechanism automatically implements the logical configuration of parameter passing between interfaces, solving the problem of needing to manually write code or configure rules to associate interface data when simulating continuous business scenarios. It greatly simplifies the construction process of test scripts for complex scenarios, improving the intelligence of the scripts and the realism of the scenario simulation.

[0113] As an optional implementation, determining the parameter dependencies between upstream and downstream interfaces based on the test plan file includes:

[0114] Based on each request action node in the test plan file, determine the upstream action nodes that have interface associations and the downstream action nodes corresponding to each upstream action node;

[0115] The parameter dependency relationship is determined based on the semantic and logical association between the network request feature information of the downstream action node and the network request feature information of the corresponding upstream action node.

[0116] This implementation details a method for determining parameter dependencies and provides an analysis and judgment mechanism based on the semantic and logical associations of network request feature information. First, it analyzes each request action node in the test plan file to determine which request action nodes have interface associations, i.e., identifying potential upstream action nodes and their corresponding downstream action nodes.

[0117] This initial determination of association can be based on various heuristic rules. For example, the order in which nodes are added in the test plan or the preset execution order can be used to determine the sequence. Alternatively, the node names and comments can be analyzed to see if they contain keywords indicating the business sequence. Furthermore, requests with hierarchical or inheritance relationships on the Uniform Resource Locator (URL) path can be identified.

[0118] After identifying potentially related node pairs, the system ultimately determines whether a specific parameter dependency exists based on the semantic and logical associations between the network request feature information of downstream action nodes and their corresponding upstream action nodes. Semantic association analysis focuses on the meaning expressed by the request itself. For example, the Uniform Resource Locator (URL) of a downstream request might contain a path parameter whose value resembles an identifier, while the response body of the upstream request happens to contain an identifier field with the same name; or, the request header information set of a downstream request might require a field named "Token-A," while the response header or body of an upstream request might contain a field named "token." The system can discover such semantic correspondences through fuzzy matching of field names, keyword matching, and other methods. Logical association analysis goes further, focusing on the relationship between data generation and consumption. The system can simulate execution or statically analyze the response format of upstream requests and check whether field values ​​in the request feature information of downstream requests conform to the syntax pattern of "variable references." Furthermore, the system can maintain a library of common parameter passing patterns, such as "the login interface returns a token, used for the Authorization header of subsequent requests." When an upstream interface is detected to match the "login" mode and the downstream request header requires an "Authorization" field, the dependency relationship can be logically inferred even if the field names are not exactly the same. By comprehensively evaluating semantic matching and logical rationality, the system can intelligently determine reliable parameter dependencies, thereby providing an accurate basis for subsequent automated configuration, reducing misjudgments, and improving the intelligence level of dependency identification.

[0119] This implementation details the logic for determining parameter dependencies. By analyzing each request action node in the test plan file, the system can automatically identify upstream action nodes and their corresponding downstream action nodes that have interface associations. Furthermore, by comparing the semantic and logical relationships between the network request feature information of these upstream and downstream nodes, the system intelligently determines whether parameter dependencies exist. This automated analysis based on semantics and logic reduces reliance on explicitly declared dependencies by the user, enabling the system to more intelligently understand test intent and automatically construct test logic that conforms to the actual business call chain, further enhancing the accuracy and applicability of automated script generation.

[0120] As an optional implementation, the automatic execution of the test plan file to complete the stress test process includes:

[0121] The test plan file is scheduled to the stress test engine in the background, and the stress test engine is controlled to load and execute the test plan file.

[0122] During the execution of the test plan file, stress is applied to replay the traffic, and performance metrics data generated by the stress test engine during operation are collected.

[0123] The performance index data is aggregated and processed to generate a structured test result report.

[0124] This implementation details the specific steps for automatically executing a test plan file to complete a stress test process, achieving a fully automated closed loop from script generation to result output. First, the generated test plan file is scheduled to the stress test engine in the background. The system, through a programmatic interface or command-line call, passes the path of the test plan file, generated in the aforementioned steps and conforming to a specific format, to a pre-integrated or specified stress test engine. The scheduling process occurs silently in the background, without requiring a graphical user interface, achieving automated deployment without manual intervention. The system then controls the stress test engine to load and execute the test plan file. This means that the system not only starts the engine process but also controls the engine to read the specified test plan file through application programming interface commands or scripts, and begins executing the stress test according to the test logic defined in the file.

[0125] During the execution of the test plan, the system control engine applies pressure to replay traffic. Specifically, the stress test engine creates a corresponding number of virtual user threads based on the total number of virtual users and startup time defined in the test plan. These threads continuously send network requests defined by the request action nodes to the system under test according to set logic (such as think time and loop count), thereby simulating a high-concurrency access scenario of real users and applying pressure to the system under test. Simultaneously, the system collects performance metrics data generated by the stress test engine during its operation. When replaying traffic, the stress test engine records raw data such as the response status, latency, and throughput of each request in real time. The system collects this scattered performance metrics data in real time by listening to the engine's data output interface, reading temporary log files generated by the engine, or through integrated monitoring plugins, and then temporarily stores or forwards it to the centralized processing module.

[0126] Finally, the system aggregates and processes the collected performance metrics data, generating a structured test result report. Aggregation processing may include data cleaning (outlier removal), grouping and summarizing by time window or transaction name, and calculating key metrics such as average response time, quantile response time, throughput, and error rate. After processing, the system organizes these results into a clear test report in a structured format (such as a Hypertext Markup Language webpage, Portable Document Format, or Extensible Markup Language file). The report typically includes a test overview, a summary of key performance metrics, a response time distribution chart, a throughput trend chart, and error statistics. Through this series of automated steps, this implementation integrates test execution, monitoring, and report generation into a coherent process, eliminating the need for manual test execution, data collection, and organization, significantly improving the efficiency of stress test execution and the consistency of results.

[0127] This implementation achieves a closed loop of automated execution and result management for test plan files. The system automatically schedules the generated test plan file to the stress testing engine in the background and controls its loading and execution, eliminating the need for manual startup of the testing tools by the user. During execution, stress is automatically applied and traffic is replayed to simulate real load, while simultaneously collecting various performance metrics data generated by the engine during runtime. Finally, these scattered performance metrics data are automatically aggregated and processed to generate a structured test result report. This process liberates test execution and result collection from manual operation, achieving true one-click testing. It not only improves the efficiency of test execution but also ensures the comprehensiveness of performance data collection and the standardization of report generation, facilitating rapid performance analysis and decision-making.

[0128] This application also provides an apparatus for automatically generating and executing stress test scripts, the apparatus comprising:

[0129] The processing module is used to obtain the command-line network request instruction text;

[0130] The processing module is also used to parse the command line network request instruction text, extract network request feature information, and generate a request model;

[0131] The processing module is also used to obtain preset stress test configuration information;

[0132] The processing module is also used to construct and generate a test plan file in a preset form based on the request model and the stress test configuration information;

[0133] The processing module is also used to automatically execute the test plan file to complete the stress test process.

[0134] The method provided in this embodiment acquires command-line network request instruction text, automates its parsing to extract network request feature information and generate a request model. This model, combined with preset stress test configuration information, automatically constructs and generates an executable test plan file, which is then automatically executed to complete the entire stress test process. This method constructs a complete automated closed loop, transforming the tedious and error-prone process of manually interpreting command-line instructions, configuring network parameters in the testing tool, and starting the test into a standardized process automatically completed by the system. This not only significantly reduces the time and effort required for manual intervention but also eliminates omissions or errors that may result from manual configuration through procedural operation, thereby greatly improving the overall efficiency of stress test construction, execution accuracy, and process reliability.

[0135] As an optional implementation, the specific method by which the processing module parses the command-line network request instruction text, extracts network request feature information, and generates a request model includes:

[0136] The command-line network request instruction text is preprocessed to be normalized;

[0137] Identify and separate network request feature information from the preprocessed command-line network request instruction text;

[0138] The network request feature information includes a request method field, a Uniform Resource Locator field, a request header information set, and a request message body field.

[0139] Based on the network request characteristic information, a standardized request model with a preset structure is constructed.

[0140] This implementation preprocesses the command-line network request text to standardize and unify the format of the input commands, laying the foundation for accurate subsequent parsing. The system then automatically identifies and separates core network request features from the preprocessed text, including the request method field, Uniform Resource Locator (URL) field, request header information set, and request message body field. The standardized request model built upon this structured information provides a precise and consistent data foundation for subsequent automated script generation. This process achieves a precise conversion from unstructured text commands to a structured data model, replacing the inefficient method of manually reading and understanding commands, ensuring the completeness and accuracy of feature extraction, and thus guaranteeing that the final generated test script accurately reflects the original network request intent.

[0141] As an optional implementation, the stress test configuration information includes the total number of virtual users and the user startup time configuration;

[0142] The specific methods by which the processing module constructs and generates a pre-defined test plan file based on the request model and stress test configuration information include:

[0143] Based on the total number of virtual users and the user startup time configuration, generate configuration nodes;

[0144] Based on the request model, create a corresponding request action node, and configure the corresponding test component information in the request action node;

[0145] Based on the configuration node and the request action node, a test logic structure is constructed, and a test plan file in a preset format is generated.

[0146] This implementation automatically generates corresponding configuration nodes by reading preset stress test configuration information such as the total number of virtual users and user startup time. Simultaneously, based on the aforementioned request model, it automatically creates corresponding request action nodes and configures necessary test component information. Finally, by logically assembling the configuration nodes and request action nodes, a test plan file in a preset format is generated. This process automates the assembly of test logic and stress strategies. Users only need to provide basic concurrency and time configurations, and the system can automatically complete the structured construction of the test scenario, avoiding the tedious manual addition and configuration of thread groups, samplers, and other components, ensuring the speed of test plan construction and the consistency of configuration.

[0147] As an optional implementation, the processing module is further configured to:

[0148] Based on the test plan file, determine the parameter dependencies between upstream and downstream interfaces;

[0149] Based on the parameter dependencies, in the test logic structure, a post-extractor is inserted into the preceding request action node, and static fields are replaced with dynamic placeholders in the following request action node.

[0150] This implementation method, based on the generated test plan file, further automatically analyzes and determines the parameter dependencies between upstream and downstream interfaces. According to the identified dependencies, the system can automatically insert a post-extractor into the pre-request action node in the test logic structure to capture specific data in the response; and in the post-request action node, it intelligently replaces the originally static fields with dynamic placeholders referencing the upstream extraction results. This mechanism automatically implements the logical configuration of parameter passing between interfaces, solving the problem of needing to manually write code or configure rules to associate interface data when simulating continuous business scenarios. It greatly simplifies the construction process of test scripts for complex scenarios, improving the intelligence of the scripts and the realism of the scenario simulation.

[0151] As an optional implementation, the processing module determines the specific method of parameter dependency relationships between upstream and downstream interfaces based on the test plan file, including:

[0152] Based on each request action node in the test plan file, determine the upstream action nodes that have interface associations and the downstream action nodes corresponding to each upstream action node;

[0153] The parameter dependency relationship is determined based on the semantic and logical association between the network request feature information of the downstream action node and the network request feature information of the corresponding upstream action node.

[0154] This implementation details the logic for determining parameter dependencies. By analyzing each request action node in the test plan file, the system can automatically identify upstream action nodes and their corresponding downstream action nodes that have interface associations. Furthermore, by comparing the semantic and logical relationships between the network request feature information of these upstream and downstream nodes, the system intelligently determines whether parameter dependencies exist. This automated analysis based on semantics and logic reduces reliance on explicitly declared dependencies by the user, enabling the system to more intelligently understand test intent and automatically construct test logic that conforms to the actual business call chain, further enhancing the accuracy and applicability of automated script generation.

[0155] As an optional implementation, the specific method by which the processing module automatically executes the test plan file to complete the stress test process includes:

[0156] The test plan file is scheduled to the stress test engine in the background, and the stress test engine is controlled to load and execute the test plan file.

[0157] During the execution of the test plan file, stress is applied to replay the traffic, and performance metrics data generated by the stress test engine during operation are collected.

[0158] The performance index data is aggregated and processed to generate a structured test result report.

[0159] This implementation achieves a closed loop of automated execution and result management for test plan files. The system automatically schedules the generated test plan file to the stress testing engine in the background and controls its loading and execution, eliminating the need for manual startup of the testing tools by the user. During execution, stress is automatically applied and traffic is replayed to simulate real load, while simultaneously collecting various performance metrics data generated by the engine during runtime. Finally, these scattered performance metrics data are automatically aggregated and processed to generate a structured test result report. This process liberates test execution and result collection from manual operation, achieving true one-click testing. It not only improves the efficiency of test execution but also ensures the comprehensiveness of performance data collection and the standardization of report generation, facilitating rapid performance analysis and decision-making.

[0160] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, a processing module can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as program code in the device's memory, and its functions can be called and executed by a processing element. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0161] Indicatively, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 3The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the methods of any of the embodiments described above.

[0162] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0163] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0164] This application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method provided in any embodiment.

[0165] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0166] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0167] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for automatically generating and executing stress test scripts, characterized in that, The method includes: Retrieve the command-line network request instruction text; The command-line network request instruction text is parsed and processed to extract network request feature information and generate a request model; Obtain the preset stress test configuration information; Based on the request model and the stress test configuration information, a test plan file in a preset format is constructed and generated; The test plan file is executed automatically to complete the stress test process.

2. The method according to claim 1, characterized in that, The step of parsing the command-line network request instruction text, extracting network request feature information, and generating a request model includes: The command-line network request instruction text is preprocessed to be normalized; Identify and separate network request feature information from the preprocessed command-line network request instruction text; The network request feature information includes a request method field, a Uniform Resource Locator field, a request header information set, and a request message body field. Based on the network request characteristic information, a standardized request model with a preset structure is constructed.

3. The method according to claim 2, characterized in that, The stress test configuration information includes the total number of virtual users and the user startup time configuration; The process of constructing and generating a pre-defined test plan file based on the request model and stress test configuration information includes: Based on the total number of virtual users and the user startup time configuration, generate configuration nodes; Based on the request model, create a corresponding request action node, and configure the corresponding test component information in the request action node; Based on the configuration node and the request action node, a test logic structure is constructed, and a test plan file in a preset format is generated.

4. The method according to claim 3, characterized in that, The method further includes: Based on the test plan file, determine the parameter dependencies between upstream and downstream interfaces; Based on the parameter dependencies, in the test logic structure, a post-extractor is inserted into the preceding request action node, and static fields are replaced with dynamic placeholders in the following request action node.

5. The method according to claim 4, characterized in that, The step of determining the parameter dependencies between upstream and downstream interfaces based on the test plan file includes: Based on each request action node in the test plan file, determine the upstream action nodes that have interface associations and the downstream action nodes corresponding to each upstream action node; The parameter dependency relationship is determined based on the semantic and logical association between the network request feature information of the downstream action node and the network request feature information of the corresponding upstream action node.

6. The method according to any one of claims 1-5, characterized in that, The automatic execution of the test plan file to complete the stress test process includes: The test plan file is scheduled to the stress testing engine in the background, and the stress testing engine is controlled to load and execute the test plan file. During the execution of the test plan file, stress is applied to replay the traffic, and performance metrics data generated by the stress test engine during operation are collected. The performance index data is aggregated and processed to generate a structured test result report.

7. An automatic generation and execution device for stress test scripts, characterized in that, The device includes: The processing module is used to obtain the command-line network request instruction text; The processing module is also used to parse the command line network request instruction text, extract network request feature information, and generate a request model; The processing module is also used to obtain preset stress test configuration information; The processing module is also used to construct and generate a test plan file in a preset form based on the request model and the stress test configuration information; The processing module is also used to automatically execute the test plan file to complete the stress test process.

8. The apparatus according to claim 7, characterized in that, The specific methods by which the processing module parses and processes the command-line network request instruction text, extracts network request feature information, and generates a request model include: The command-line network request instruction text is preprocessed to be normalized; Identify and separate network request feature information from the preprocessed command-line network request instruction text; The network request feature information includes a request method field, a Uniform Resource Locator field, a request header information set, and a request message body field. Based on the network request characteristic information, a standardized request model with a preset structure is constructed.

9. A computer device, characterized in that, The method includes one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method as described in any one of claims 1-6.

10. A storage medium, characterized in that, The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method as described in any one of claims 1-6.

Images