Pressure testing method, device and system and computer readable storage medium
The base64 encoding request body is decoded, JSON parameterized and quadratic encoding process through custom plug-ins, which solves the problem of great impact on the performance of the Beanshell processor and achieves efficient performance testing and resource conservation.
Patent Information
- Application Number
- CN202510619093.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-14
- Publication Date
- 2025-08-26
AI Technical Summary
When using a Beanshell processor to process base64 encoding, although encoding processing can be implemented, it has a great impact on performance and consumes suppressor resources.
The base64 encoding request body is decoded, JSON parameterized and secondary encoding processed through custom plug-ins to improve performance testing efficiency and reduce resource consumption.
It improves performance testing capabilities, saves compressor resource consumption, enhances testing flexibility and accuracy, and reduces CPU and memory usage.
Smart Images

Figure CN120540951A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a stress testing method, device, system, and computer-readable storage medium. Background Art
[0002] Currently, when JMeter performs stress testing, the base64-encoded parameter content is processed by the preprocessor BeanShell in most cases. Although using the preprocessor BeanShell to perform performance testing can achieve fast processing, it has a significant impact on performance and consumes stress testing machine resources. Summary of the Invention
[0003] The embodiments of the present application provide a stress testing method, device, system and computer-readable storage medium, which can solve the technical problem mentioned in the above background technology that the existing technology uses a beanshell processor to process base64 encoding. Although it can process base64 encoding, it has a great impact on performance.
[0004] In a first aspect, an embodiment of the present application provides a stress testing method, comprising the following steps:
[0005] The tested end receives the current HTTP request sent by the test front end, and obtains the encoded request body of the current HTTP request; wherein the encoded request body is encrypted base64 encoded data;
[0006] The tested end calls a custom plug-in to decode, parameterize and re-encode the encoded request body in sequence, obtain a target request body after re-encoding, and perform stress testing on the target request body.
[0007] In one embodiment, before the step of the tested end receiving the current HTTP request sent by the test front end, the method further includes:
[0008] The test front end debugs the original HTTP request according to the interface document, encodes the request body in the original HTTP request according to the interface document, and obtains an encoded request body containing base64 encoded data that meets the interface requirements;
[0009] The test front end transmits the current HTTP request including the encoding request sphere to the tested end.
[0010] In one embodiment, the tested end calls a custom plug-in to sequentially decode, parameterize, and re-encode the encoded request body to obtain a target request body after re-encoding, and performs a stress test on the target request body, including:
[0011] The tested end configures the target request body into a performance testing tool, and references the custom plug-in in the performance testing tool to sequentially decode, parameterize, and re-encode the request body to obtain a target request body after re-encoding;
[0012] A stress test is performed on the target request body to obtain a test result.
[0013] In one embodiment, performing a stress test on the target request body to obtain a test result includes:
[0014] Performing a stress test on the target request body to evaluate the performance of the interface when processing the target request body in base64 encoding format;
[0015] and / or
[0016] Simulate multiple users to send HTTP requests containing the target request body concurrently to test the performance of the interface under high concurrency conditions.
[0017] In one embodiment, after the step of performing a stress test on the target request body and obtaining the test result, the following step is also included:
[0018] Based on the test results, the performance of the interface under different loads is analyzed to determine the performance bottleneck.
[0019] In one embodiment, the custom plug-in includes a base64 decoding function, a parameterized processing function, and a base64 encoding function;
[0020] The calling custom plug-in sequentially decodes, parameterizes, and re-encodes the encoded request body to obtain a target request body after secondary base64 encoding, including:
[0021] Calling the base64 decoding function to decode the encoded request to obtain decoded data;
[0022] Performing JSON parameterization processing on the decoded data using a parameterization processing function to generate JSON format parameters that meet the requirements;
[0023] The base64 secondary encoding function is called to encode the JSON format parameters again to obtain the target request body after secondary base64 encoding.
[0024] In a second aspect, the present application further proposes a pressure testing device, comprising:
[0025] A receiving module, configured to receive a current HTTP request and obtain an encoded request body of the current HTTP request; wherein the encoded request body is encrypted base64 encoded data;
[0026] The test module is used to call a custom plug-in to decode, parameterize and re-encode the encoded request body in sequence, obtain the target request body after re-encoding, and perform stress testing on the target request body.
[0027] In the third aspect, the present application also proposes a testing system, which includes a tested end and a testing front end; the tested end and the testing front end are both deployed on a first terminal device; the first terminal device includes a memory, a processor, and a computer program stored on the memory and runnable on the processor; when the computer program is executed by the processor, the steps of the stress testing method described in the first aspect above are implemented.
[0028] In a fourth aspect, the present application further proposes a test system, comprising a tested terminal and a test front end; the tested terminal is deployed on a first terminal device; the test front end is deployed on a second terminal device;
[0029] The first terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor; when the computer program is executed by the processor, the steps of the stress testing method described above are implemented.
[0030] In a fifth aspect, the present application further proposes a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the stress testing method described in the first aspect above are implemented.
[0031] The beneficial effects of the present application are as follows: first, the tested end receives the current HTTP request sent by the test front end, and obtains the encoded request body of the current HTTP request; the encoded request body is encrypted base64 encoded data; then the tested end calls a custom plug-in to decode, JSON parameterize and re-encode the encoded request body in sequence, obtain the target request body after re-encoding, and perform stress testing on the target request body, thereby improving performance testing capabilities and saving stress testing machine resource consumption. BRIEF DESCRIPTION OF THE DRAWINGS
[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0033] Figure 1 This is a flow chart of a pressure testing method provided in an embodiment of the present application;
[0034] Figure 2 This is a flow chart of another pressure testing method provided in an embodiment of the present application;
[0035] Figure 3 This is a schematic diagram of the relevant process of running a custom plug-in to sequentially decode, parameterize, and re-encode an encoded request body, as provided in an embodiment of the present application;
[0036] Figure 4 Schematic diagram of a pressure testing device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0037] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.
[0038] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.
[0039] It will also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.
[0040] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.
[0041] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.
[0042] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.
[0043] In a first aspect, an embodiment of the present application provides a stress testing method, comprising the following steps:
[0044] Step S01: The test front end debugs the original HTTP request according to the interface document, encodes the request body in the original HTTP request according to the interface document, and obtains an encoded request body containing encrypted base64 encoded data that meets the interface requirements;
[0045] Generally speaking, interface documentation is typically written by the system or team providing the interface service. It details the interface's functionality, input parameters, output results, and usage instructions. Interface documentation refers to the interface documentation for the target service or application under test, specifically the interface to be tested or invoked. The test frontend can be an application or computer device that provides the input interface for testers.
[0046] It's understandable that encoding the request body in Base64 format is done to ensure data security during transmission (for example, to prevent data tampering or theft) or to meet the requirements of certain protocols or interfaces. In performance testing, processing Base64-encoded request bodies is a critical task in test scripts to ensure that the test accurately simulates the actual request process.
[0047] Step S02: the test front end sends the current HTTP request containing the coded sphere to the tested end;
[0048] The original HTTP request is initiated by the tester or an automated test script (such as a test script written using JMeter). For example, the test front-end can write a test script based on the interface documentation, simulate the behavior of the user or client, and send HTTP requests to the target service under test to verify the functionality and performance of the interface.
[0049] Step S10: The tested end receives the current HTTP request and obtains the encoded request body of the current HTTP request;
[0050] It's understood that the encoded request body is the data portion of the target service being tested that the test frontend sends to the client under test. In some cases, the request body is encoded in Base64 format for secure transmission or to meet specific protocol requirements. Therefore, the "Base64-encoded request body" is the result of Base64 encoding the request body portion of the "original HTTP request."
[0051] Conversion process: Before sending an HTTP request, the client may encode the original request body data (such as JSON, XML, etc.) into Base64 format and then send it as part of the request body to the server. After receiving the request, the server needs to decode the Base64-encoded request body to obtain the original request body data.
[0052] Step S20: The tested end calls the custom plug-in to decode, parameterize and re-encode the encoded request body in sequence, obtain the target request body after re-encoding, and perform stress testing on the target request body.
[0053] In a specific implementation, the tested end configures the target request body into a performance testing tool, and references a custom plug-in in the performance testing tool to sequentially decode, parameterize, and re-encode the request body to obtain the target request body after re-encoding;
[0054] A performance test is performed on the target request body to evaluate the performance of the interface when processing the target request body in base64 encoding format.
[0055] In a specific implementation, the performance testing tool may use a stress testing tool developed based on Java, such as Jmeter, for performing stress testing on the software.
[0056] It is understandable that in the embodiment of the present application, the tester can pre-write a custom plug-in JsonTest.jar, which includes a base64 decoding function, a parameterized processing function, and a base64 secondary encoding function. The step S20 specifically includes:
[0057] Sub-step S21: calling the base64 decoding function to decode the encoded request to obtain decoded data;
[0058] Sub-step S22: using a parameterization processing function to perform JSON parameterization processing on the decoded data to generate JSON format parameters that meet the requirements;
[0059] Sub-step S23: calling the base64 secondary encoding function to re-encode the JSON format parameters to obtain the target request body after secondary base64 encoding.
[0060] In a specific implementation, the base64 decoding function is the base64.decode() method; the parameterized processing function is the uuid4() method; the base64 secondary encoding function is the base64.encodeAsString() method;
[0061] In the specific implementation, the base64-encoded request body is decoded by calling the base64.decode() method to obtain the decoded data; the decoded data is parameterized by JSON using the uuid4() method to generate JSON format parameters that meet the requirements; the base64.encodeAsString() method is called to encode the decoded data again to form a new base64-encoded request body (i.e., the target request body).
[0062] It is understandable that the purpose of the custom plug-in is to implement base64 decoding, JSON parameterization processing, and re-encoding functions to improve the efficiency and script quality of the performance testing tool Jmeter when processing base64 encoded requests. The development of the custom plug-in involves the use of the Java programming language, including calling base64 decoding and encoding methods, and implementing the logic of JSON parameterization processing. Among them, the embodiment of the present application calls the parameterization processing function, performs JSON parameterization processing on the decoded data, and generates JSON format parameters that meet the requirements. Its technical effect is:
[0063] (1) Improved test flexibility and efficiency: The JSON parameterization processing of this embodiment allows dynamic changes to request parameters during performance testing without manually modifying the script or request body. This is very useful for tests that need to simulate multiple user scenarios or test different data inputs. Through parameterization, testers can more easily manage test data, improving test flexibility and efficiency.
[0064] (2) Helps simulate real user behavior: In practical applications, the data input by users is often diverse. This embodiment uses JSON parameterization to simulate different data submitted by different users, thereby more realistically simulating user behavior and improving the accuracy and reliability of the test.
[0065] (3) Facilitates automated testing: In automated testing, the parameterized processing of this embodiment can make the test script more versatile and reusable. By modifying the parameter values, different test cases can be quickly generated without having to write a separate script for each test case.
[0066] Furthermore, the tested end in the embodiment of the present application uses a custom plug-in, which has stronger scalability and lower compression machine resource consumption when processing Base64 encoded requests compared to the traditional Beanshell processor. The main effects include:
[0067] First, the first technical effect is greater scalability:
[0068] (1) Custom Logic Implementation: Custom plug-ins allow testers to write specific logic code based on specific needs, such as Base64 decoding, JSON parameterization, and Base64 encoding. This logic can be highly customized to meet the testing needs of different scenarios. In contrast, although Beanshell also supports scripting, its flexibility and functional depth are limited by the characteristics and expressiveness of the scripting language.
[0069] (2) Modular design: Custom plug-ins typically adopt a modular design, allowing each functional module to be independently developed and tested, facilitating subsequent functional expansion and maintenance. This design approach makes it easier to add new features or modify existing features when new requirements arise, without affecting the normal operation of other parts.
[0070] (3) Integration capabilities: Custom plug-ins can be more easily integrated with other tools or systems, such as performance testing tools like JMeter. By providing standard interfaces or APIs, plug-ins can seamlessly connect with other components, enabling data sharing and interaction, thereby improving the efficiency and accuracy of the entire testing process.
[0071] Secondly, the second technical effect is that the suppressor consumes less resources:
[0072] (1) Performance Optimization: Custom plug-ins typically use more efficient algorithms and data structures to implement specific functions, such as Base64 encoding and decoding. These optimizations can significantly reduce CPU and memory usage, thereby reducing the resource consumption of the compression machine. In contrast, the Beanshell processor may be less efficient when processing complex logic, resulting in higher resource consumption.
[0073] (2) Reduced intermediate steps: The custom plug-in can complete Base64 decoding, JSON parameterization, and Base64 encoding in a single step, reducing the number of intermediate steps and data processing times. This direct processing method can reduce memory usage and CPU load, and improve processing efficiency.
[0074] (3) Resource reuse: The custom plug-in can consider resource reuse and sharing during design and implementation, such as using a thread pool to manage concurrent requests and reduce the overhead of thread creation and destruction. This resource reuse strategy can further reduce the resource consumption of the compression machine.
[0075] In summary, the tested end runs the custom plug-in provided in the embodiment of the present application to decode, parameterize and re-encode the encoded request body in sequence, obtain the target request body after re-encoding, and perform stress testing on the target request body. Because the custom plug-in provides highly customized logic implementation, modular design, powerful integration capabilities and performance optimization, it has stronger scalability and lower compression machine resource consumption when processing Base64 encoded requests compared to traditional Beanshell processors.
[0076] In a second aspect, an embodiment of the present application provides a test system, the test system comprising a tested terminal A and a test front end B;
[0077] In some embodiments, the tested end A and the test front-end B can both be deployed on a first terminal device; for example, the tester uses a computer device to perform software stress testing, the test front-end B is the test front-end software installed on the computer device, and the tested end A is the application software to be tested installed on the computer device; the tester enters the configured interface document by opening the front-end input interface of the test front-end software, and the test front-end software can encode the request body in the original HTTP request according to the interface document to obtain an encoded request body containing base64 encoded data that meets the interface requirements; then the test front-end B transmits the current HTTP request containing the encoded request body to the tested end to perform software stress testing on the application software to be tested.
[0078] In other embodiments, the tested end A is deployed on the server to be tested; the test front-end B is deployed on the first terminal device; for example, the tester uses a computer device to perform software stress testing, the test front-end B is the test front-end software installed on the computer device, and the tested end A is the application service to be tested installed on the server to be tested; the tester enters the configured interface document by opening the front-end input interface of the test front-end software, and the test front-end software can encode the request body in the original HTTP request according to the interface document to obtain an encoded request body containing base64 encoded data that meets the interface requirements; then the test front-end B transmits the current HTTP request containing the encoded request body to the application service to be tested on the server to be tested, so as to perform software stress testing on the application service to be tested.
[0079] like Figure 4 As shown, the embodiment of the present application further provides a pressure testing device, comprising:
[0080] Receiving module A1, used to receive the current HTTP request and obtain the encoded request body of the current HTTP request; wherein the encoded request body is encrypted base64 encoded data;
[0081] Test module A2 is configured to call a custom plug-in to sequentially decode, parameterize, and re-encode the encoded request body, obtaining a target request body after re-encoding, and then perform a stress test on the target request body. It should be noted that the stress testing device can be a virtual appliance in a computer device, such as software specifically designed for testing, deployed in the computer device and run by the computer device's processor. The device can also be an integrated circuit chip.
[0082] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the above-mentioned various method embodiments can be implemented.
[0083] An embodiment of the present application provides a computer program product. When the computer program product is run on a mobile terminal, the mobile terminal can implement the steps in the above-mentioned various method embodiments when executing the computer program product.
[0084] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the process in the above-mentioned embodiment method by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the camera / terminal device, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk. In some instances, the computer-readable medium cannot be an electric carrier signal or a telecommunication signal.
[0085] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.
[0086] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0087] In the embodiments provided in this application, it should be understood that the disclosed devices / network equipment and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are merely illustrative. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0088] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.
[0089] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.
Claims
1. A stress testing method, characterized in that: The following steps are involved: The tested end receives the current HTTP request sent by the test front end, and obtains the encoded request body of the current HTTP request; wherein the encoded request body is encrypted base64 encoded data; The tested end calls a custom plug-in to decode, parameterize and re-encode the encoded request body in sequence, obtain a target request body after re-encoding, and perform stress testing on the target request body.
2. The testing method according to claim 1, wherein: Before the step of the tested end receiving the current HTTP request sent by the test front end, the method further includes: The test front end debugs the original HTTP request according to the interface document, encodes the request body in the original HTTP request according to the interface document, and obtains an encoded request body containing base64 encoded data that meets the interface requirements; The test front end transmits the current HTTP request including the encoding request sphere to the tested end.
3. The testing method according to claim 2, wherein: The tested end calls a custom plug-in to decode, parameterize, and re-encode the encoded request body in sequence to obtain a target request body after re-encoding, and performs a stress test on the target request body, including: The tested end configures the target request body into a performance testing tool, and references the custom plug-in in the performance testing tool to sequentially decode, parameterize, and re-encode the request body to obtain a target request body after re-encoding; A stress test is performed on the target request body to obtain a test result.
4. The testing method according to claim 3, wherein: The performing a stress test on the target request body to obtain a test result includes: Performing a stress test on the target request body to evaluate the performance of the interface when processing the target request body in base64 encoding format; and / or Simulate multiple users to send HTTP requests containing the target request body concurrently to test the performance of the interface under high concurrency conditions.
5. The testing method according to claim 3, wherein: After the step of performing a stress test on the target request body and obtaining the test result, the following steps are also included: Based on the test results, the performance of the interface under different loads is analyzed to determine the performance bottleneck.
6. The testing method according to any one of claims 1 to 5, wherein: The custom plug-in includes a base64 decoding function, a parameterized processing function, and a base64 encoding function; The calling custom plug-in sequentially decodes, parameterizes, and re-encodes the encoded request body to obtain a target request body after secondary base64 encoding, including: Calling the base64 decoding function to decode the encoded request to obtain decoded data; Performing JSON parameterization processing on the decoded data using a parameterization processing function to generate JSON format parameters that meet the requirements; The base64 secondary encoding function is called to encode the JSON format parameters again to obtain the target request body after secondary base64 encoding.
7. A pressure testing device, characterized in that: include: A receiving module, configured to receive a current HTTP request and obtain an encoded request body of the current HTTP request; wherein the encoded request body is encrypted base64 encoded data; The test module is used to call a custom plug-in to decode, parameterize and re-encode the encoded request body in sequence, obtain the target request body after re-encoding, and perform stress testing on the target request body.
8. A testing system, characterized in that: The test system includes a tested end and a test front end; the tested end and the test front end are both deployed on a first terminal device; the first terminal device includes a memory, a processor, and a computer program stored on the memory and runnable on the processor; when the computer program is executed by the processor, the steps of the stress testing method as described in any one of claims 1 to 6 are implemented.
9. A testing system, characterized in that: The test system includes a tested terminal and a test front end; the tested terminal is deployed on a first terminal device; the test front end is deployed on a second terminal device; The first terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor; when the computer program is executed by the processor, the steps of the stress testing method according to any one of claims 1, 3 to 6 are implemented.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the stress testing method according to any one of claims 1 to 6.