Performance test method and device
By using containerization technology and visual low-code orchestration components, the problem of low efficiency in existing performance testing is solved, enabling efficient and low-cost performance testing, expanding test coverage and reducing costs.
Patent Information
- Application Number
- CN202512033558.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-24
AI Technical Summary
Existing performance testing workflows are inefficient, require a lot of manual operation, are difficult to standardize and normalize, and existing tools cannot meet the needs of complex testing scenarios.
Multiple load testing engine images are built based on containerization technology. Load testing scenarios are converted into various types of scripts through a load testing script parser. Multi-dimensional data is aggregated in a unified manner using a message queue, and test results are displayed in real time on the system front end. Visual low-code orchestration components are used to replace traditional script writing.
It enables efficient and low-cost performance testing, reduces personnel input and resource maintenance costs, expands test coverage, and improves test efficiency and automation.
Smart Images
Figure CN121924035A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of Internet technology, and in particular relates to a performance testing method and apparatus. Background Technology
[0002] With the rapid development of the internet, network concurrency has increased, and internet applications have become increasingly complex, such as distributed architectures, microservices, and cloud-native technologies. This makes server-side performance testing more complex and urgent. Therefore, routine performance testing is necessary, integrating it into the daily work of software development to ensure the overall quality and stability of the product and provide data support for further optimization. Furthermore, as application services become more complex, the design of test scenarios also becomes more intricate. Existing codeless load testing engines (such as JMeter and LoadRunner) cannot meet diverse load testing needs, requiring more granular code-based load testing engines (such as Locust and K6) to enrich the design capabilities of load testing scenarios.
[0003] The existing performance testing workflow mainly includes: writing debugging scripts offline, applying for a stress tester, starting performance stress testing, manually recording and collecting test data, and saving test data locally. The testing process requires a lot of manual operation, consumes a lot of human resources, is inefficient, and the process is difficult to standardize and normalize.
[0004] There is currently no effective solution to the above problems. Summary of the Invention
[0005] The purpose of this application is to provide a performance testing method and apparatus that can achieve efficient and low-cost performance testing.
[0006] This application provides a performance testing method and apparatus implemented as follows:
[0007] A performance testing method, comprising:
[0008] Based on containerization technology, images are built for multiple load testing tools and their execution environments to create multiple load testing engine images.
[0009] Select a compression engine as the target load testing engine image from multiple load testing engine images;
[0010] Obtain pre-programmed load testing scenarios;
[0011] Based on the target load testing engine image, the load testing scenario is converted into various types of load testing scripts through a load testing script parser.
[0012] Obtain multi-dimensional stress test data;
[0013] Based on message queues, discrete, distributed, and multi-dimensional load testing data is uniformly aggregated into the backend application of the load testing platform. The load testing scripts are executed to perform real-time processing and calculation for testing, and the test results are displayed in real-time on the system frontend.
[0014] In one implementation, images are built for multiple load testing tools and their execution environments based on containerization technology to create multiple load testing engines, including:
[0015] Obtain the base image of the operating system and install the necessary toolchain, which includes at least one of the following: an HTTP request client, a compression program, a decompression program, and a Chinese language pack;
[0016] The base image of the operating system and the necessary toolchain are used to build an operating system image;
[0017] On top of the constructed operating system image, the execution environment for the load testing tool is built, serving as the execution environment image;
[0018] Based on the constructed execution environment image, install the load testing tools and their required dependencies, as well as the platform load testing result collector, to obtain a load testing engine image that can be called.
[0019] In one implementation, test scenarios are orchestrated, including:
[0020] Obtain the load testing scenario;
[0021] Add a load test transaction to the orchestration page of the load test scenario;
[0022] Edit load testing requests within a load testing transaction, and use pre- and post-parameter extractors to extract and associate context parameters from multiple requests;
[0023] Select the load testing engine, configure the number of load testing nodes, and the number of concurrent users per node based on the load testing request.
[0024] In one implementation, test scenarios are orchestrated, including:
[0025] The process of writing daily performance test scripts and designing scenarios for users is abstracted into four process control components: data file import, test transaction definition, test request definition, and stress scenario orchestration.
[0026] Design interface protocol definition components and logic control component libraries for each of the four process components. The logic control component library includes: pre-processing component, post-processing component, and assertion component.
[0027] In one implementation, based on the target load testing engine, the load testing scenario is converted into various types of load testing scripts using a load testing script parser, including:
[0028] Retrieve the pre-sealed code libraries associated with the process control component, interface definition component, and logic control component, which correspond to multiple load testing engines;
[0029] The component code corresponding to the target load testing engine is obtained by matching the code library.
[0030] Based on the pre-arranged load testing scenarios, the component code corresponding to the target load testing engine is called, and the code is concatenated in the order of the scenario arrangement to generate the load testing script.
[0031] In one implementation, test result data is displayed in real time at the system front end, including:
[0032] Collect test result data;
[0033] The test results data are displayed in real time on the system front end.
[0034] In one implementation, test result data is collected, including:
[0035] During the execution of the load testing script, the result acquisition SDK in the target load testing engine image is called;
[0036] The load test data is synchronized to the message queue responsible for collecting test data through the result collection SDK. The load test data includes at least one of the following: transaction start time, transaction end time, transaction request message, transaction response message, and transaction response code.
[0037] The test data parser consumes data from the message queue in real time to obtain test results data for each task.
[0038] The number of transactions per second and the average response time are calculated in real time based on the test results data.
[0039] A performance testing device, comprising:
[0040] The build module is used to build images for multiple load testing tools and their execution environments based on containerization technology, so as to build multiple load testing engine images;
[0041] The selection module is used to select a compression engine as the target load testing engine image from multiple load testing engine images;
[0042] The first acquisition module is used to acquire pre-arranged load testing scenarios;
[0043] The conversion module is used to convert the load testing scenario into various types of load testing scripts based on the target load testing engine image through a load testing script parser.
[0044] The second acquisition module is used to acquire multi-dimensional stress test data;
[0045] The testing module is used to aggregate discrete, distributed, multi-dimensional load testing data into the backend application of the load testing platform based on message queues. The load testing scripts are executed to perform real-time processing and calculation for testing, and the test results are displayed in real-time on the system frontend.
[0046] An electronic device includes a processor and a memory for storing processor-executable instructions, wherein the processor, when executing the instructions, implements the steps of the method described above.
[0047] A computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.
[0048] The performance testing method and apparatus provided in this application construct images for multiple load testing tools and their execution environments based on containerization technology, thereby creating multiple load testing engine images. A compression engine is selected as the target load testing engine image from these images. A pre-arranged load testing scenario is obtained. Based on the target load testing engine image, the load testing scenario is converted into various types of load testing scripts using a load testing script parser. Multi-dimensional load testing data is obtained. Based on a message queue, the discrete, distributed, multi-dimensional load testing data is uniformly aggregated into the backend application of the load testing platform. The load testing scripts are executed for real-time processing and calculation for testing, and the test results are displayed in real-time on the system frontend. In the example above, the multi-engine compatible distributed performance platform implementation scheme and system replace the script coding work in the existing performance testing process with a visual, low-code performance testing orchestration component, solving the problem that testers need to set up development environments and have coding skills. Furthermore, through multi-engine script code parsing and generation, execution image construction, and the support of cloud-native platform capabilities, users have a wider range of load testing tools to choose from and the ability to quickly build distributed load testing clusters. This reduces the personnel investment and resource maintenance costs of performance testing and expands the coverage of performance testing. Attached Figure Description
[0049] 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 recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0050] Figure 1 This is a flowchart of one embodiment of the performance testing method provided in this application;
[0051] Figure 2 This is a schematic diagram of the performance testing module provided in this application;
[0052] Figure 3 This is a hardware structure block diagram of an electronic device for a performance testing method provided in this application;
[0053] Figure 4 This is a schematic diagram of the module structure of one embodiment of the performance testing device provided in this application. Detailed Implementation
[0054] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in 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 should fall within the scope of protection of this application.
[0055] It should be noted that the information and data related to users involved in the embodiments of this specification are all information and data authorized by the user or fully authorized by the relevant parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with relevant laws, regulations, and standards, and necessary confidentiality measures have been taken. They do not violate public order and good morals, and corresponding operation entry points are provided for users or relevant parties to choose to authorize or refuse.
[0056] It should also be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the solution.
[0057] Figure 1This is a flowchart of one embodiment of the performance testing method provided in this application. Although this application provides method operation steps or apparatus structures as shown in the following embodiments or figures, more or fewer operation steps or module units may be included in the method or apparatus based on conventional or non-inventive effort. In steps or structures where there is no logically necessary causal relationship, the execution order of these steps or the module structure of the apparatus is not limited to the execution order or module structure described in the embodiments and figures of this application. When the method or module structure is applied in actual devices or terminal products, it can be executed sequentially or in parallel according to the method or module structure shown in the embodiments or figures (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed processing environment).
[0058] Specifically, such as Figure 1 As shown, the performance testing method described above may include the following steps:
[0059] Step 101: Based on containerization technology, build images for multiple load testing tools and their execution environments to obtain multiple load testing engine images;
[0060] Specifically, based on containerization technology, images are built for multiple load testing tools and their execution environments to create multiple load testing engines, which may include:
[0061] S1: Obtain the base image of the operating system and install the necessary toolchain, which includes at least one of the following: an HTTP request client, a compression program, a decompression program, and a Chinese language pack;
[0062] S2: Construct the operating system image from the base image of the operating system and the necessary toolchain;
[0063] S3: On top of the constructed operating system image, build the execution environment of the load testing tool as the execution environment image;
[0064] S4: Based on the constructed execution environment image, install the load testing tool and the dependency packages required by the load testing tool, as well as the platform load testing result collector, to obtain a load testing engine image that can be called.
[0065] Step 102: Select a compression engine from multiple load testing engine images as the target load testing engine image;
[0066] Step 103: Obtain the pre-programmed load testing scenario;
[0067] The test scenario can be orchestrated as follows: obtain the load test scenario; add a load test transaction on the orchestration page of the load test scenario; edit the load test request under the load test transaction, and use the pre- and post-parameter extractors to extract and associate context parameters of multiple requests; select the load test engine, configure the number of load test nodes and the number of concurrent users per node according to the load test request.
[0068] Step 104: Based on the target load testing engine image, the load testing scenario is converted into various types of load testing scripts using a load testing script parser;
[0069] Step 105: Obtain multi-dimensional stress test data;
[0070] Step 106: Based on the message queue, the discrete, distributed, multi-dimensional load testing data is uniformly aggregated into the backend application of the load testing platform. The load testing script is executed to perform real-time processing and calculation for testing, and the test results data are displayed in real-time on the system front end.
[0071] In the example above, the multi-engine compatible distributed performance platform solution and system replaces the script coding work in the existing performance testing process with a visual, low-code performance test orchestration component, solving the problem of testers needing to set up development environments and have coding skills. Furthermore, through multi-engine script code parsing and generation, execution image construction, and the support of cloud-native platform capabilities, users have a wider variety of load testing tools to choose from and the ability to quickly build distributed load testing clusters. This reduces the personnel and resource maintenance costs of performance testing and expands the coverage of performance testing.
[0072] When implementing this, the orchestration of test scenarios can include:
[0073] S1: The process of writing daily performance test scripts and designing scenarios for users is abstracted into four process control components. The four process control components are: data file import, test transaction definition, test request definition, and stress scenario orchestration.
[0074] S2: Design interface protocol definition components and logic control component libraries for each component in the four process components. The logic control component library includes: pre-processing component, post-processing component, and assertion component.
[0075] Accordingly, based on the target load testing engine, the load testing scenario is converted into various types of load testing scripts through a load testing script parser, which may include:
[0076] S1: Retrieve the pre-sealed code library associated with the process control component, interface definition component, and logic control component, which corresponds to multiple load testing engines;
[0077] S2: Match the component code corresponding to the target load testing engine from the code library;
[0078] S3: Based on the pre-arranged load testing scenario, call the component code corresponding to the target load testing engine, and concatenate the code according to the order of the scenario arrangement to generate the load testing script.
[0079] To achieve visualized test result display, enabling testers to clearly understand the test results, test result data can be displayed in real time on the system front end. Specifically, test result data can be collected and displayed in real time on the system front end.
[0080] Specifically, collecting test result data may include:
[0081] S1: During the execution of the load testing script, the result acquisition SDK in the target load testing engine image is called;
[0082] S2: Synchronize the load test data to the message queue responsible for collecting test data through the result collection SDK. The load test data includes at least one of the following: transaction start time, transaction end time, transaction request message, transaction response message, and transaction response code.
[0083] S3: Consume data from the message queue in real time through the test data parser to obtain test result data for each task;
[0084] S4: Calculate the number of transactions per second and the average response time in real time based on the test results data.
[0085] The above method will be described below with reference to a specific embodiment. However, it should be noted that this specific embodiment is only for better illustration of this application and does not constitute an improper limitation of this application.
[0086] This example provides a performance testing platform system based on a distributed architecture. The system includes: a performance testing scenario front-end orchestration component (load-test element), a performance testing service back-end (performance-test), a multi-engine script parser (script-parser), a load-test engine (load-test engine), a test data collection back-end listener (ciblistener), and a test data parser (result collector), wherein:
[0087] The load-test element abstracts the process of writing daily performance test scripts and designing scenarios into a data file, encompassing four main workflows: test transaction definition, test request definition, and stress scenario orchestration. It also includes a component library with interface protocol definition components, pre-processing components, post-processing components, assertion components, and more, enabling users to orchestrate performance scenarios on a web page using a unified standard and input. Furthermore, it utilizes containerization technology to pre-build images containing load testing tools and their execution environment.
[0088] performance-test is used for front-end and back-end interactions such as project management, user management, load testing scenario management, and test report management in load testing systems.
[0089] script-parser is used to convert user-choreographed performance test scenarios into performance test scripts according to the syntax of different load testing engine scripts;
[0090] ciblistener is a complete set of SDK components developed by this system for different load testing tools. It supports load testing scripts to call this component after completing the load test to send the load test results back to the test data parser.
[0091] The result collector is used to receive and parse test data, and is responsible for receiving, calculating, and storing the test data.
[0092] For the aforementioned performance testing platform system based on a distributed architecture, such as Figure 2 The diagram illustrates the modules involved in performance testing. Users can edit these modules on a web frontend, which connects to a performance automation platform system. This platform system includes: project permission management, script orchestration testing, test case management, test execution and automation, resource pool node management, test report management, data storage, and monitoring and alerting. The performance automation platform system obtains test resources from the test resource pool through test data computation nodes to perform performance testing.
[0093] In other words, the solution and system, implemented through a multi-engine compatible distributed performance platform, replaces the script coding work in the existing performance testing process with visual, low-code performance test orchestration components, solving the problems of testers needing to set up development environments and have coding skills. Furthermore, through multi-engine script code parsing and generation, execution image construction, and the support of cloud-native platform capabilities, users have access to a wider variety of load testing tools and the ability to quickly build distributed load testing clusters, thereby reducing personnel and resource maintenance costs for performance testing and expanding the scope of performance testing.
[0094] Specifically, for the aforementioned performance testing platform system based on a distributed architecture, this example also provides a performance testing method, which may include the following steps:
[0095] Step 1: Build a load testing engine: Build images for different load testing tools and their execution environments based on containerization technology.
[0096] In implementation, the construction process of the load testing engine may include:
[0097] S1: Prepare an operating system base image (e.g., CentOS 7) and install the necessary toolchain (e.g., HTTP request client, compression and decompression program, Chinese language pack), and build the base image and the necessary toolchain into an operating system image;
[0098] S2: On top of the built operating system image, build the execution environment of the load testing tool. The execution environment of the installation tool (e.g., JDK 8, JDK 11, Python 2, Python 3, Go, etc.) is built into the execution environment image.
[0099] S3: Based on the built execution environment image, further install the load testing tools and their required dependency packages, platform load testing result collectors, etc., to build a load testing engine image that can be called (e.g., JMeter 5.4 image, locust image, K6 image, etc.).
[0100] Step 2: Arrange test scenarios:
[0101] Existing performance test scripts typically require offline editing and specialized tools and languages. In this example, a web-based low-code script editing interface was designed. Based on performance, the process of writing daily performance test scripts and designing scenarios is abstracted into four major process components: data file import, test transaction definition, test request definition, and stress scenario orchestration. Accompanying components include interface protocol definition components, as well as logic control component libraries such as pre-processing components, post-processing components, and assertion components. This allows users to orchestrate performance scenarios on a web page with unified specifications and inputs.
[0102] When implementing this, the orchestration of test scenarios can include:
[0103] S1: Testers create a new load testing scenario;
[0104] S2: Add a load test transaction on the load test scenario orchestration page;
[0105] S3: Edit load test requests under load test transactions. This system supports requests for various interface protocols such as HTTP, TCP, and Dubbo.
[0106] S4: Under load testing transactions, use pre- and post-parameter extractors to extract and associate context parameters for multiple requests;
[0107] S5: Stress configuration, including: load testing engine selection, load testing node count configuration, and single-node concurrent user count configuration. Users can choose a platform-customized load testing engine based on their actual load testing needs;
[0108] S6: Allows for additional advanced customization options, such as configuration file splitting and whether to retain JTL.
[0109] Step 3: Convert to obtain the load testing script:
[0110] In this example, a multi-protocol compatible load testing script parser is used to convert the load testing scenario into various types of load testing scripts based on the load testing engine selected by the user.
[0111] During implementation, the resulting load testing script may include:
[0112] S1: For the component libraries such as process control components, interface definition components and logic control components defined in step 2, Teng uses load testing tools to pre-block the code libraries of multiple engines that can correspond one-to-one with the component libraries, according to the script rules or code syntax rules corresponding to the components.
[0113] S2: The script-parser calls the code snippets of the corresponding components of the load testing engine according to the user-arranged scenario flow and load testing engine configuration, and concatenates the code in the order of scenario arrangement to complete the generation of the actual load testing script.
[0114] Step 4: Schedule stress nodes: Combining cloud-native technology architecture and platform, quickly create stress testing node containers and dynamically scale them up and down for different stress testing engines.
[0115] Step 5: Collect load test results: Based on the message queue, the discrete and distributed load test data is uniformly aggregated to the backend application of the load test platform for real-time processing and calculation, and the test result data is displayed in real-time on the front end of the system.
[0116] When implementing this, the collected stress test results may include:
[0117] S1: The load testing engine image in step 1 contains the result collection SDKs corresponding to each load testing engine tool.
[0118] S2: During the execution of each load testing tool script, the test data collection SDK is invoked in real time to synchronize the load testing results to the message queue responsible for collecting test data. The test data may include: transaction start time, transaction end time, transaction request message, transaction response message, transaction response code, etc.
[0119] S3: The result collector module of the load testing platform consumes data from the message queue in real time, obtains load testing data for each task, and then calculates the number of transactions per second, average response time, etc. in real time based on the load testing data.
[0120] Step 6: Automated execution, that is, automated execution, which enables unattended automated execution and rapid response to alarms.
[0121] The methods and embodiments provided in the above-described embodiments of this application can be executed in a mobile terminal, computer terminal, or similar computing device. Taking operation on an electronic device as an example... Figure 3 This is a hardware structure block diagram of an electronic device for a performance testing method provided in this application. (See diagram for example.) Figure 3 As shown, the electronic device 10 may include one or more (only one is shown in the figure) processors 02 (processors 02 may include, but are not limited to, processing devices such as microprocessors (MCUs) or programmable logic devices (FPGAs), a memory 04 for storing data, and a transmission module 06 for communication functions. Those skilled in the art will understand that... Figure 3 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, electronic device 10 may also include... Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown.
[0122] The memory 04 can be used to store software programs and modules of application software, such as the program instructions / modules corresponding to the performance testing method in this embodiment. The processor 02 executes various functional applications and data processing by running the software programs and modules stored in the memory 04, thereby implementing the aforementioned application performance testing method. The memory 04 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 04 may further include memory remotely located relative to the processor 02, and these remote memories can be connected to the electronic device 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0123] The transmission module 06 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 10. In one example, the transmission module 06 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 06 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.
[0124] At the software level, the aforementioned performance testing device can, as follows: Figure 4 As shown, it includes:
[0125] Module 401 is used to build images for multiple load testing tools and their execution environments based on containerization technology, so as to build multiple load testing engine images.
[0126] Select module 402 is used to select a compression engine as the target load testing engine image from multiple load testing engine images;
[0127] The first acquisition module 403 is used to acquire pre-arranged stress test scenarios;
[0128] The conversion module 404 is used to convert the load testing scenario into various types of load testing scripts according to the target load testing engine image through a load testing script parser.
[0129] The second acquisition module 405 is used to acquire multi-dimensional stress test data;
[0130] Test module 406 is used to aggregate discrete, distributed, multi-dimensional load testing data into the backend application of the load testing platform based on message queues. The load testing scripts are executed to perform real-time processing and calculation for testing, and the test results are displayed in real-time on the system front end.
[0131] In one implementation, the building module 401 specifically obtains the base image of the operating system and installs the necessary toolchain, wherein the necessary toolchain includes at least one of the following: an HTTP request client, a compression program, a decompression program, and a Chinese language pack; the base image of the operating system and the necessary toolchain are used to build an operating system image; on the built operating system image, an execution environment for the load testing tool is built as an execution environment image; based on the built execution environment image, the load testing tool and its required dependency packages and a platform load testing result collector are installed to obtain a callable load testing engine image.
[0132] In one implementation, orchestrating a test scenario may include: acquiring a load testing scenario; adding a load testing transaction to the orchestration page of the load testing scenario; editing load testing requests under the load testing transaction, and using a pre- and post-parameter extractor to extract and associate context parameters for multiple requests; selecting a load testing engine, configuring the number of load testing nodes, and the number of concurrent users per node according to the load testing request.
[0133] In one implementation, orchestrating test scenarios may include: abstracting the process of writing user daily performance test scripts and designing scenarios into four process control components, wherein the four process control components are: data file import, test transaction definition, test request definition, and stress scenario orchestration; and designing interface protocol definition components and logic control component libraries for each of the four process components, wherein the logic control component library includes: pre-processing components, post-processing components, and assertion components.
[0134] In one implementation, the conversion module 404 may specifically retrieve a pre-sealed code library associated with the process control component, interface definition component, and logic control component, which corresponds to multiple load testing engines; from the code library, match the component code corresponding to the target load testing engine; according to the pre-arranged load testing scenario, call the component code corresponding to the target load testing engine, and concatenate the code according to the order of the scenario arrangement to generate a load testing script.
[0135] In one implementation, displaying test result data in real time at the system front end may include: collecting test result data; and displaying the test result data in real time at the system front end.
[0136] In one implementation, collecting test result data may include: during the execution of the load testing script, calling the result collection SDK in the target load testing engine image; synchronizing the load testing data to the message queue responsible for collecting test data through the result collection SDK, wherein the load testing data includes at least one of the following: transaction start time, transaction end time, transaction request message, transaction response message, and transaction response code; consuming the data in the message queue in real time through a test data parser to obtain the test result data for each task; and calculating the number of transactions per second and the average response time during the transaction process in real time based on the test result data.
[0137] This application also provides a specific implementation of an electronic device capable of implementing all steps of the performance testing method in the above embodiments. The electronic device specifically includes: a processor, a memory, a communication interface, and a bus; wherein the processor, memory, and communication interface communicate with each other via the bus; the processor is used to call a computer program in the memory, and when the processor executes the computer program, it implements all steps of the performance testing method in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:
[0138] Step 1: Based on containerization technology, build images for multiple load testing tools and their execution environments to obtain multiple load testing engine images;
[0139] Step 2: Select a compression engine from multiple load testing engine images as the target load testing engine image;
[0140] Step 3: Obtain the pre-programmed load testing scenario;
[0141] Step 4: Based on the target load testing engine image, the load testing scenario is converted into various types of load testing scripts using a load testing script parser;
[0142] Step 5: Obtain multi-dimensional stress test data;
[0143] Step 6: Based on the message queue, the discrete, distributed, multi-dimensional load testing data is uniformly aggregated into the backend application of the load testing platform. The load testing script is executed to perform real-time processing and calculation for testing, and the test results data are displayed in real-time on the system front end.
[0144] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the performance testing method in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the performance testing method in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:
[0145] Step 1: Based on containerization technology, build images for multiple load testing tools and their execution environments to obtain multiple load testing engine images;
[0146] Step 2: Select a compression engine from multiple load testing engine images as the target load testing engine image;
[0147] Step 3: Obtain the pre-programmed load testing scenario;
[0148] Step 4: Based on the target load testing engine image, the load testing scenario is converted into various types of load testing scripts using a load testing script parser;
[0149] Step 5: Obtain multi-dimensional stress test data;
[0150] Step 6: Based on the message queue, the discrete, distributed, multi-dimensional load testing data is uniformly aggregated into the backend application of the load testing platform. The load testing script is executed to perform real-time processing and calculation for testing, and the test results data are displayed in real-time on the system front end.
[0151] As described above, the embodiments of this application implement a solution and system using a multi-engine compatible distributed performance platform. This system replaces the script coding work in existing performance testing processes with a visual, low-code performance test orchestration component, solving the problems of testers needing to set up development environments and possess coding skills. Furthermore, through multi-engine script code parsing and generation, execution image construction, and the support of cloud-native platform capabilities, users have access to a wider variety of load testing tools and the ability to quickly build distributed load testing clusters. This reduces personnel investment and resource maintenance costs for performance testing and expands the coverage of performance testing.
[0152] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, hardware + program embodiments are relatively simple in description because they are fundamentally similar to method embodiments; relevant parts can be referred to the descriptions in the method embodiments.
[0153] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.
[0154] While this application provides the method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual device or client product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).
[0155] While this specification provides method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, 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, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.
[0156] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing the embodiments of this specification, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.
[0157] Those skilled in the art will also know that, besides implementing the controller using purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the controller function as logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers (PLCs), and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the devices within it used to implement various functions can also be considered structures within that hardware component. Alternatively, the devices used to implement various functions can be considered as both software modules implementing the method and structures within a hardware component.
[0158] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0159] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of computer program products implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0160] The embodiments described in this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. The embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.
[0161] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments in this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.
[0162] The above description is merely an embodiment of the embodiments in this specification and is not intended to limit the embodiments of this specification. For those skilled in the art, various modifications and variations can be made to the embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the embodiments of this specification should be included within the scope of the claims of the embodiments of this specification.
Claims
1. A performance testing method, characterized in that, The method includes: Based on containerization technology, images are built for multiple load testing tools and their execution environments to create multiple load testing engine images. Select a compression engine as the target load testing engine image from multiple load testing engine images; Obtain pre-programmed load testing scenarios; Based on the target load testing engine image, the load testing scenario is converted into various types of load testing scripts through a load testing script parser. Obtain multi-dimensional stress test data; Based on message queues, discrete, distributed, and multi-dimensional load testing data is uniformly aggregated into the backend application of the load testing platform. The load testing scripts are executed to perform real-time processing and calculation for testing, and the test results are displayed in real-time on the system frontend.
2. The method according to claim 1, characterized in that, Based on containerization technology, images are built for multiple load testing tools and their execution environments to create multiple load testing engines, including: Obtain the base image of the operating system and install the necessary toolchain, which includes at least one of the following: an HTTP request client, a compression program, a decompression program, and a Chinese language pack; The base image of the operating system and the necessary toolchain are used to build an operating system image; On top of the constructed operating system image, the execution environment for the load testing tool is built, serving as the execution environment image; Based on the constructed execution environment image, install the load testing tools and their required dependencies, as well as the platform load testing result collector, to obtain a load testing engine image that can be called.
3. The method according to claim 1, characterized in that, Arrange test scenarios, including: Obtain the load testing scenario; Add a load test transaction to the orchestration page of the load test scenario; Edit load test requests within a load test transaction, and use pre- and post-parameter extractors to extract and associate context parameters from multiple requests; Select the load testing engine, configure the number of load testing nodes, and the number of concurrent users per node based on the load testing request.
4. The method according to claim 1, characterized in that, Arrange test scenarios, including: The process of writing daily performance test scripts and designing scenarios for users is abstracted into four process control components: data file import, test transaction definition, test request definition, and stress scenario orchestration. Design interface protocol definition components and logic control component libraries for each of the four process components. The logic control component library includes: pre-processing component, post-processing component, and assertion component.
5. The method according to claim 4, characterized in that, Based on the target load testing engine, the load testing scenario is converted into various types of load testing scripts through a load testing script parser, including: Retrieve the pre-sealed code libraries associated with the process control component, interface definition component, and logic control component, which correspond to multiple load testing engines; The component code corresponding to the target load testing engine is obtained by matching the code library. Based on the pre-arranged load testing scenarios, the component code corresponding to the target load testing engine is called, and the code is concatenated in the order of the scenario arrangement to generate the load testing script.
6. The method according to claim 1, characterized in that, The system front-end displays test results data in real time, including: Collect test result data; The test results data are displayed in real time on the system front end.
7. The method according to claim 6, characterized in that, Collect test result data, including: During the execution of the load testing script, the result acquisition SDK in the target load testing engine image is called; The load test data is synchronized to the message queue responsible for collecting test data through the result collection SDK. The load test data includes at least one of the following: transaction start time, transaction end time, transaction request message, transaction response message, and transaction response code. The test data parser consumes data from the message queue in real time to obtain test results data for each task. The number of transactions per second and the average response time are calculated in real time based on the test results data.
8. A performance testing device, characterized in that, include: The build module is used to build images for multiple load testing tools and their execution environments based on containerization technology, so as to build multiple load testing engine images; The selection module is used to select a compression engine as the target load testing engine image from multiple load testing engine images; The first acquisition module is used to acquire pre-arranged load testing scenarios; The conversion module is used to convert the load testing scenario into various types of load testing scripts based on the target load testing engine image through a load testing script parser. The second acquisition module is used to acquire multi-dimensional stress test data; The testing module is used to aggregate discrete, distributed, multi-dimensional load testing data into the backend application of the load testing platform based on message queues. The load testing scripts are executed to perform real-time processing and calculation for testing, and the test results are displayed in real-time on the system frontend.
9. An electronic device comprising a processor and a memory for storing processor-executable instructions, characterized in that, When the processor executes the instructions, it implements the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.