Concurrent stress testing method and apparatus, electronic device, and storage medium

Abstract

This invention proposes a concurrent stress testing method, apparatus, electronic device, and storage medium. The method involves creating a browser instance management script, a user behavior script, and a concurrent testing main script in the project root directory. The user behavior script reflects the complete operational behavior of a single user accessing the target web application. The browser instance management script is executed to call the browser automation control library and create multiple isolated browser instances. The concurrent testing main script is executed to call each browser instance and cause all browser instances to concurrently execute the user behavior script on the target web application, simulating multiple users accessing the target web application simultaneously. The concurrent test execution results are then obtained, significantly reducing deployment barriers and maintenance costs, and achieving lightweight, reproducible, and easily traceable web application stability verification.

Description

Technical Field

[0001] This invention relates to the field of web application performance testing technology, and more specifically, to a concurrent stress testing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of internet technology, web applications have become an indispensable part of daily life for businesses and individuals. To ensure the stability and performance of web applications under high concurrency, concurrent stress testing has become crucial. Concurrent stress testing helps developers and operations personnel understand how web applications perform when accessed by a large number of users simultaneously, thereby enabling them to promptly identify and resolve potential performance bottlenecks and stability issues.

[0003] Traditional concurrent stress testing methods typically rely on dedicated stress testing tools, such as Apache JMeter and LoadRunner. While these tools are powerful, they often require specialized learning and configuration, making it difficult to verify the stability and responsiveness of web applications under high-concurrency scenarios in a low-cost and rapid manner. Summary of the Invention

[0004] In view of this, the object of the present invention is to provide a concurrent stress testing method, apparatus, electronic device and computer-readable storage medium.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of the present invention are as follows: In a first aspect, the present invention provides a concurrent stress testing method applied to an electronic device, the electronic device being configured with a script execution environment and a browser automation control library, the method comprising: Create a browser instance management script, a user behavior script, and a concurrency test main script in the project root directory. The user behavior script reflects the complete operation behavior of a single user when accessing the target web application. The browser instance management script is executed, and the browser automation control library is invoked to create multiple isolated browser instances; The concurrency test main script is executed, which calls each browser instance and causes all browser instances to concurrently execute the user behavior script on the target web application to simulate multiple users accessing the target web application at the same time, and obtains the concurrency test execution results.

[0006] In an optional implementation, the step of calling the browser automation control library to create multiple isolated browser instances includes: The browser automation control library is invoked to create multiple initial browser instances; Configure each of the initial browser instances to run in headless mode; Each initial browser instance configured to run in headless mode is assigned an independent user data storage path, resulting in multiple browser instances with completely isolated session state, cache, and cookies.

[0007] In an optional implementation, the step of having all browser instances concurrently execute the user behavior script on the target web application to simulate multiple users accessing the target web application simultaneously includes: Drive each browser instance to access the login page of the target web application; Drive each browser instance to dynamically generate username and password parameters and input them into the form controls on the login page; Drive each browser instance to click the login button on the login page and wait for the HTTP response from the login interface of the target web application to complete; Drive each browser instance to access the form page of the target web application, dynamically generate form content and input it; Drive each browser instance to click the submit button on the form page and wait for the HTTP response from the form submission interface of the target web application to complete.

[0008] In an optional implementation, the step of obtaining the concurrent test execution results includes: Based on the execution status of each browser instance, the number of successfully executed instances, the number of failed execution instances, and the access time of each browser instance are counted as the execution result of the concurrency test.

[0009] In an optional implementation, the access time of the browser instance includes the response time of the login interface of the target web application, the response time of the form submission interface of the target web application, and the total time of the complete operation.

[0010] In an optional implementation, the electronic device is further configured with a network service execution framework. Prior to the step of creating the browser instance management script, user behavior script, and concurrent test main script in the project root directory, the method further includes: Enable the network service execution framework and build the target web application.

[0011] Secondly, the present invention provides a concurrent stress testing device applied to an electronic device, the electronic device being configured with a script execution environment and a browser automation control library, the device comprising: Create a module to build a browser instance management script, a user behavior script, and a concurrent test main script in the project root directory. The user behavior script reflects the complete operation behavior of a single user when accessing the target web application. The testing module is used to execute the browser instance management script, call the browser automation control library, create multiple isolated browser instances, execute the concurrency test main script, call each browser instance and make all browser instances concurrently execute the user behavior script on the target web application to simulate multiple users accessing the target web application at the same time, and obtain the concurrency test execution results.

[0012] In an optional implementation, the testing device is specifically used to call the browser automation control library to create multiple initial browser instances; configure each initial browser instance to a headless running mode; allocate an independent user data storage path to each initial browser instance configured to run in headless mode, thereby obtaining multiple browser instances with completely isolated session state, cache, and cookies.

[0013] Thirdly, the present invention provides an electronic device including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor can execute the machine-executable instructions to implement the concurrent stress testing method described in any of the foregoing embodiments.

[0014] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the concurrent stress testing method as described in any of the foregoing embodiments.

[0015] The concurrent stress testing method, apparatus, electronic device, and storage medium provided in this invention establish a browser instance management script, a user behavior script, and a concurrent test main script in the project root directory. The user behavior script reflects the complete operational behavior of a single user accessing the target web application. The browser instance management script is executed to call the browser automation control library and create multiple isolated browser instances. The concurrent test main script is executed to call each browser instance and make all browser instances concurrently execute the user behavior script on the target web application to simulate multiple users accessing the target web application at the same time and obtain the concurrent test execution results. Because this invention builds a flat, clearly defined browser instance management script, user behavior script, and concurrent testing main script in the project root directory, and creates multiple isolated browser instances based on the browser automation control library, it achieves high-fidelity concurrent simulation of real user end-to-end interaction behavior. This improves the authenticity and attributability of stress test results, overcoming the performance blind spots caused by the inability of traditional protocol-level tools to cover front-end logic, and avoiding the state pollution problem caused by multiple users sharing session context. At the same time, the scripts have zero subdirectory dependencies, require no middleware installation, and can be started in a single script environment, significantly reducing deployment threshold and operation and maintenance costs. It can quickly carry out lightweight, reproducible, and easily traceable web application stability verification with dozens of concurrent levels.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This figure shows a schematic block diagram of an electronic device provided by an embodiment of the present invention; Figure 2 A flowchart illustrating a concurrent stress testing method provided by an embodiment of the present invention is shown; Figure 3 The diagram shows a code example of a browser instance management script provided in an embodiment of the present invention. Figure 4 The diagram shows a code example of a user behavior script provided in an embodiment of the present invention. Figure 5 The diagram shows a code example of a concurrent test main script provided by an embodiment of the present invention. Figure 6 The diagram shows a code example of a network service execution framework provided by an embodiment of the present invention. Figure 7 A functional block diagram of a concurrent stress testing device provided in an embodiment of the present invention is shown.

[0019] Icons: 100 - Electronic device; 110 - Memory; 120 - Processor; 130 - Communication module; 200 - Concurrent stress testing device; 201 - Creation module; 202 - Test module. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0022] It should be noted that 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 limitation, 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.

[0023] In the field of web application performance testing, mainstream stress testing tools (such as Apache JMeter and Gatling) generally adopt a protocol-layer-based HTTP request simulation mechanism. Their core logic involves constructing and batch-sending standardized HTTP request packets (such as GET / POST), simulating concurrent access by multiple users through thread pools or coroutines, and then statistically analyzing metrics such as response time, throughput, and error rate. While these tools possess high concurrency throughput and good scalability, they have inherent shortcomings in terms of behavioral realism and front-end environment fidelity. First, tools like JMeter do not load HTML, parse CSS, or execute JavaScript, thus completely ignoring crucial behaviors in SPAs (Single Page Applications) such as dynamically rendering the DOM, managing route state, and handling asynchronous data binding by front-end frameworks (like React and Vue). For example, after the login API returns a successful response, the front-end may need to wait several seconds to complete token persistence, asynchronous loading of the permission menu, and route navigation. However, JMeter only considers the HTTP response as the operation completed, resulting in a severely distorted "login timeout" measurement that fails to expose typical user experience bottlenecks such as first-screen latency and blank screen timeouts caused by front-end script execution blocking.

[0024] Second, although existing tools support Cookie Manager script injection to simulate sessions, their session state is essentially still running within the same JVM process, relying on memory variables or lightweight context passing. This leads to problems such as cookie obfuscation, CSRF token reuse, and local storage pollution under high concurrency, and cannot truly reflect the resource competition and state conflicts generated when multiple users operate in parallel in independent browser environments.

[0025] Third, existing tools atomicate testing into "request-response" pairs. Once a request fails, the current thread is terminated or marked as an error, making it impossible to distinguish whether the failure is due to network jitter, server-side anomalies, or front-end interaction logic failures (such as triggering a click before a button is ready). At the same time, single-thread anomalies often cause thread pool avalanches or statistical biases, making it difficult to support long-term, large-scale stability stress testing.

[0026] Therefore, in order to overcome the shortcomings of the prior art, the present invention provides a concurrent stress testing method, apparatus, electronic device and storage medium, which will be described in detail below.

[0027] Please refer to Figure 1 This is a block diagram of an electronic device 100. The electronic device 100 includes a memory 110, a processor 120, and a communication module 130. The memory 110, processor 120, and communication module 130 are electrically connected to each other directly or indirectly to realize data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0028] The memory 110 is used to store programs or data. The memory 110 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0029] The processor 120 is used to read / write data or programs stored in the memory 110 and to perform corresponding functions.

[0030] The communication module 130 is used to establish a communication connection between the electronic device 100 and other communication terminals through the network, and to send and receive data through the network.

[0031] It should be understood that, Figure 1 The structure shown is only a schematic diagram of the electronic device 100. The electronic device 100 may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown. Figure 1 The components shown can be implemented using hardware, software, or a combination thereof.

[0032] Please refer to Figure 2 The concurrent stress testing method provided in this embodiment of the invention includes steps S101 to S103.

[0033] S101. Create a browser instance management script, a user behavior script, and a main concurrent test script in the project root directory.

[0034] The electronic device is equipped with a script execution environment and a browser automation control library. The user behavior script reflects the complete operational behavior of a single user when accessing the target web application.

[0035] In this embodiment of the invention, the electronic device (e.g., a development / testing computer equipped with an Intel i7 processor, 16GB of memory, and running Ubuntu 22.04) is pre-installed with the Node.js runtime environment and Puppeteer is installed as a browser automation control library via the npm package manager. Optionally, Express is also installed as a web service execution framework.

[0036] Subsequently, three independent JavaScript script files are created in the project root directory (e.g., / home / user / stress-test / ), without introducing any subdirectory levels, to reduce deployment complexity and path dependency risks: (1) browserManager.js: A browser instance management script used to uniformly create, configure, and destroy Puppeteer browser instances. Its implementation code can be found in [reference]. Figure 3 ; (2) userAction.js: User behavior script, which encapsulates the complete end-to-end operation process when a single user accesses the target web application, including page navigation, dynamic parameter injection, DOM element interaction, interface response waiting and performance data collection. Its implementation code can be found in [reference]. Figure 4 ; (3) stressTest.js: The main script for concurrent testing. As the entry point for method execution, it is responsible for parsing the concurrency parameter input by the user, coordinating the calls of various scripts, aggregating test results, and persisting the output. Its implementation code can be found in [reference]. Figure 5 .

[0037] Based on this flat script structure, you can start N concurrent user tests simply by executing the command `node stressTest.js --users N` in the project root directory, without the need to build an additional toolchain or configuration center.

[0038] S102 executes the browser instance management script, calls the browser automation control library, and creates multiple isolated browser instances.

[0039] In a possible implementation, the process of "calling the browser automation control library to create multiple isolated browser instances" could be as follows: call the browser automation control library to create multiple initial browser instances; configure each initial browser instance to run in headless mode; allocate an independent user data storage path to each initial browser instance configured to run in headless mode, resulting in multiple browser instances with completely isolated session state, cache, and cookies.

[0040] For example, embodiments of the present invention perform as follows Figure 3 The browserManager.js script shown calls the puppeteer.launch() interface provided by Puppeteer to create N initial browser instances (N is the set number of concurrent users).

[0041] To ensure resource efficiency and operational stability, each initial browser instance is configured in headless mode (headless: 'new') with the following key startup parameters: "--no-sandbox" (bypasses Chrome sandbox restrictions to adapt to containerized or restricted permission environments), "--disable-gpu" (disables GPU acceleration to reduce VRAM usage), and "--disable-dev-shm-usage" (avoids crashes caused by insufficient space in / dev / shm).

[0042] A unique user data storage path (userDataDir) is dynamically allocated for each browser instance. The browserManager.js script creates an independent subdirectory ( / tmp / puppeteer- / user_i / ) for the i-th browser instance under a temporary directory (such as / tmp / puppeteer- / ), and passes this path as the userDataDir option to plugineteer.launch(). This method ensures that each browser instance has completely independent Cookie Jar, local storage, cache database (Cache API), IndexedDB, and certificate storage, fundamentally eliminating session state pollution, token reuse, or cache hit interference between multiple users, thus realistically simulating the scenario where N physical users each use an independent browser to access the same web application.

[0043] Understandably, this embodiment of the invention, by optimizing the startup parameters such as "--no-sandbox", "--disable-gpu", and "-disable-dev-shm-usage" in headless mode (headless: 'new'), and dynamically allocating a unique and isolated user data directory (userDataDir) for each browser instance, significantly reduces the CPU, memory, and GPU resource consumption under single-machine resource constraints. This allows ordinary development machines (such as PCs with 16GB of memory) to stably support 20–50 concurrent user tests, breaking through the hardware bottleneck of traditional GUI browser clusters. Furthermore, it achieves physical isolation of Cookie, localStorage, IndexedDB, cache, and certificates at the operating system file system level, completely eliminating the risk of cross-contamination of multi-user sessions and token reuse, ensuring that the test scenario closely resembles real multi-terminal concurrent access.

[0044] S103, execute the main script for concurrent testing, call each browser instance and make all browser instances concurrently execute the user behavior script on the target web application to simulate multiple users accessing the target web application at the same time and obtain the execution results of the concurrent test.

[0045] In a possible implementation, the process of "using each browser instance and having all browser instances concurrently execute user behavior scripts on the target web application to simulate multiple users accessing the target web application simultaneously" could be: Drive each browser instance to access the login page of the target web application; Drive each browser instance to dynamically generate username and password parameters and input them into the form controls on the login page; Drive each browser instance to click the login button on the login page and wait for the HTTP response from the login interface of the target web application to complete; Drive each browser instance to access the form page of the target web application, dynamically generate form content and input it; Drive each browser instance to click the submit button on the form page and wait for the HTTP response from the target web application's form submission interface to complete.

[0046] Furthermore, the process of "obtaining the concurrent test execution results" can be achieved by calculating the number of successfully executed instances, the number of failed execution instances, and the access time of each browser instance based on the execution status of each browser instance, as the concurrent test execution results.

[0047] The access time of the browser instance includes the response time of the login interface of the target web application, the response time of the form submission interface of the target web application, and the total time of the complete operation.

[0048] In other words, by executing such Figure 5 The `stressTest.js` script shown loads the N browser instances created in S102 and creates an independent page for each instance (browser.newPage()). Then, it concurrently (e.g., triggered in parallel via `Promise.all()`) executes the following on each page: Figure 4 The userAction.js script shown is an example. The userAction.js script contains the following ordered sequence of operations: (1) Call page.goto('https: / / target-app.com / login') to navigate to the login page of the target web application; (2) Generate dynamic login credentials: The username format is test_user_${Date.now()}_${Math.random().toString(36).substr(2,9)}, and the password is fixed as Password! (or read from the environment variable), and is injected into the corresponding form control through page.type() or page.fill(); (3) Call page.click('#login-btn') to trigger login, and then execute page.waitForResponse('https: / / target-app.com / api / v1 / auth / login',{timeout:10000}) to wait precisely for the login interface to return an HTTP 200 response. Record the response.headers['x-response-time'] or response.timing().responseEnd-response.timing().requestStart of this request as the response time of the login interface; (d) Navigate to the form page (page.goto('https: / / target-app.com / form')), dynamically generate form content (such as random strings, timestamps, simulated business IDs), fill it in, and click the submit button; (e) Similarly, use page.waitForResponse() to listen to the form submission interface and get the response time of the form submission interface; (f) Collect page-level performance markers using page.evaluate(()=>performance.now()) and calculate the total time taken for the entire operation from page loading to form submission completion.

[0049] Throughout the concurrent execution process, the operation of each page is wrapped in an independent try / catch block: if a user fails in step (c) or (e) due to network timeout, element not ready, or interface exception, the error is captured and recorded as the failure status of that instance, but will not interrupt the execution flow of other instances, thereby ensuring the robustness and statistical validity of the overall test.

[0050] Finally, stressTest.js aggregates the execution results of all N browser instances and generates structured statistics, including the total number of successful instances, the total number of failed instances, the login time for each browser instance, the form submission time, and the total time, and saves the complete dataset as a JSON file.

[0051] Optionally, the execution results of N browser instances may also include the average total execution time of the browser instances.

[0052] After obtaining the results of the concurrent test execution, a summary is output to the terminal in real time.

[0053] Understandably, the embodiments of the present invention achieve closed-loop stress verification of the entire stack of a web application (network layer, rendering layer, JavaScript execution layer, and business interface layer) by concurrently driving each browser page to execute user behavior scripts covering navigation, dynamic parameter injection, real DOM interaction, precise interface-level response waiting (page.waitForResponse()), and end-to-end performance marking (performance.now()) in a multi-browser instance isolation environment.

[0054] By dynamically generating usernames (including timestamps and random factors) and accurately capturing the millisecond-level response time of the login / submission interface and the total time of the complete operation, the system effectively avoids duplicate test data and distorted metrics, allowing performance bottlenecks to be accurately located at specific stages such as front-end loading, JS execution delay, or back-end interface response.

[0055] Each page operation is nested in an independent try / catch exception handling block. Single user failures (such as element not ready, timeout, network jitter) are only recorded locally without interrupting the global concurrent process, thereby improving the stability and statistical effectiveness of large-scale load testing.

[0056] The dual output of structured JSON result files and real-time terminal summaries supports both automated analysis (such as time-consuming calculations and failure root cause clustering) and meets the needs of rapid manual review, enhancing the efficiency and reliability of problem discovery, localization, and verification in high-concurrency scenarios of web applications.

[0057] Optionally, the electronic device is also equipped with a network service execution framework. Before the steps of creating the browser instance management script, user behavior script and concurrent test main script in the project root directory, the concurrent stress test method provided in this embodiment of the invention further includes the step of: enabling the network service execution framework and building the target web application.

[0058] In this embodiment of the invention, before step S101, the electronic device can enable the Express framework to build a lightweight target web application for local closed-loop verification. For example, Figure 6 As shown, a RESTful service that simulates login and form submission is set up.

[0059] The API response logic of the Express service has a built-in controllable delay, which makes it easy to reproduce front-end waiting bottlenecks. This allows the embodiments of the present invention to be connected to real production environments and to be used for offline stress testing without external dependencies, significantly improving test agility and repeatability.

[0060] Understandably, the embodiments of the present invention utilize a lightweight network service execution framework (such as Express) to quickly build a target web application with complete business logic (login authentication, form submission) and controllable response behavior locally before test execution. This constructs a completely autonomous, environmentally closed, and behaviorally adjustable end-to-end verification loop, thus eliminating the need to rely on external test environments or production systems. Developers / testers can start the service under test that conforms to real interaction characteristics on any offline device in seconds, significantly shortening the test preparation cycle and supporting high-frequency automated load testing in CI / CD pipelines.

[0061] Meanwhile, by programmatically controlling key behaviors such as API response time, error codes, and token generation strategies, performance bottleneck scenarios such as "front-end white screen timeout due to slow back-end response" and "session creation blocking under high concurrency" can be accurately reproduced. This elevates stress testing from a simple "traffic impact" to a "problem-driven" in-depth verification, thereby effectively supporting engineering practices such as performance tuning, capacity planning, and stability hardening.

[0062] Compared with the prior art, the embodiments of the present invention have the following beneficial effects: (1) By building a browser instance management script, user behavior script and concurrency test main script with a flat structure and clear responsibilities in the root directory of the project, and creating multiple isolated browser instances based on the browser automation control library, high-fidelity concurrency simulation of real user end-to-end interaction behavior is achieved, thereby improving the authenticity and attributability of stress test results. This not only overcomes the performance blind spot caused by the inability of traditional protocol-level tools to cover the front-end logic, but also avoids the state pollution problem caused by multiple users sharing session context.

[0063] (2) The script has zero subdirectory dependency, no middleware installation required, and can be started with a single script environment, which greatly reduces the deployment threshold and operation and maintenance costs. It can quickly carry out lightweight, reproducible and traceable Web application stability verification with dozens of concurrent levels.

[0064] (3) By optimizing the startup parameters such as "--no-sandbox", "--disable-gpu", and "-disable-dev-shm-usage" in headless mode (headless: 'new'), and dynamically allocating a unique and isolated user data directory (userDataDir) for each browser instance, the CPU, memory and GPU resource consumption is significantly reduced under single-machine resource constraints, so that ordinary development machines (such as 16GB memory PCs) can stably support 20-50 concurrent user tests, breaking through the hardware bottleneck of traditional GUI browser clusters.

[0065] (4) Implement physical isolation of Cookie, localStorage, IndexedDB, cache and certificate at the operating system file system level to completely eliminate the risk of cross-contamination of multi-user sessions and token reuse, and ensure that the test scenario is highly close to real multi-terminal concurrent access.

[0066] (5) By concurrently driving each browser page to fully execute user behavior scripts covering navigation, dynamic parameter injection, real DOM interaction, precise interface-level response waiting (page.waitForResponse()) and end-to-end performance marking (performance.now()) in a multi-browser instance isolation environment, closed-loop pressure verification of the entire Web application chain (network layer, rendering layer, JavaScript execution layer, business interface layer) is achieved.

[0067] (6) By dynamically generating usernames (including timestamps and random factors), accurately capturing the millisecond-level response time of the login / submission interface and the total time of the complete operation, the duplication of test data and the distortion of indicators are effectively avoided, and the performance bottleneck can be accurately located to specific links such as front-end loading, JS execution delay or back-end interface response.

[0068] (7) Each page operation is nested in an independent try / catch exception handling block. Single user failure (such as element not ready, timeout, network jitter) is only recorded locally without interrupting the global concurrent process, thereby improving the stability and statistical effectiveness of large-scale load testing.

[0069] (8) The dual output of structured JSON result files and real-time terminal summaries supports both automated analysis (such as time-consuming calculations and failure root cause clustering) and meets the needs of rapid manual review, enhancing the efficiency and credibility of problem discovery, location and verification in high-concurrency scenarios of Web applications.

[0070] (9) By using a lightweight network service execution framework (such as Express) to quickly build a target web application with complete business logic (login authentication, form submission) and controllable response behavior locally before test execution, a completely autonomous, closed-environment, and adjustable end-to-end verification loop is constructed. This eliminates the need to rely on external test environments or production systems. Developers / testers can start the tested service with real interaction characteristics on any offline device in seconds, greatly shortening the test preparation cycle and supporting high-frequency automated load testing in CI / CD pipelines.

[0071] (10) By programmatically controlling key behaviors such as API response time, error codes, and token generation strategies, performance bottleneck scenarios such as “front-end white screen timeout due to slow back-end response” and “session creation blocking under high concurrency” can be accurately reproduced, making stress testing go from simple “traffic impact” to “problem-driven” in-depth verification, thereby effectively supporting engineering practices such as performance tuning, capacity planning and stability reinforcement.

[0072] To perform the corresponding steps in the above embodiments and various possible methods, an implementation of the concurrent stress testing device 200 is given below. Further, please refer to... Figure 7 , Figure 7 This is a functional block diagram of a concurrent stress testing device 200 provided in an embodiment of the present invention. It should be noted that the basic principle and technical effects of the concurrent stress testing device 200 provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. The concurrent stress testing device 200 includes: Create module 201 to create browser instance management scripts, user behavior scripts, and concurrent test main scripts in the project root directory. The user behavior scripts reflect the complete operational behavior of a single user when accessing the target web application.

[0073] Test module 202 is used to execute browser instance management scripts, call browser automation control libraries, create multiple isolated browser instances, execute the concurrency test main script, call each browser instance and make all browser instances concurrently execute user behavior scripts on the target web application to simulate multiple users accessing the target web application at the same time and obtain the concurrency test execution results.

[0074] Optionally, the testing device is specifically used to call the browser automation control library to create multiple initial browser instances; configure each initial browser instance to run in headless mode; allocate an independent user data storage path to each initial browser instance configured to run in headless mode, thereby obtaining multiple browser instances with completely isolated session state, cache, and cookies.

[0075] Optionally, the above modules can be stored in the form of software or firmware. Figure 1 The memory 110 shown is either stored in or embedded in the operating system (OS) of the electronic device 100, and can be used by... Figure 1 The processor 120 executes the program. Meanwhile, the data and program code required to execute the above modules can be stored in the memory 110.

[0076] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0077] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0078] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0079] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A concurrent stress testing method, characterized in that, Applied to electronic devices equipped with a script execution environment and a browser automation control library, the method includes: Create a browser instance management script, a user behavior script, and a concurrency test main script in the project root directory. The user behavior script reflects the complete operation behavior of a single user when accessing the target web application. The browser instance management script is executed, and the browser automation control library is invoked to create multiple isolated browser instances; The concurrency test main script is executed, which calls each browser instance and causes all browser instances to concurrently execute the user behavior script on the target web application to simulate multiple users accessing the target web application at the same time, and obtains the concurrency test execution results.

2. The concurrent stress testing method as described in claim 1, characterized in that, The steps of calling the browser automation control library to create multiple isolated browser instances include: The browser automation control library is invoked to create multiple initial browser instances; Configure each of the initial browser instances to run in headless mode; Each initial browser instance configured to run in headless mode is assigned an independent user data storage path, resulting in multiple browser instances with completely isolated session state, cache, and cookies.

3. The concurrent stress testing method as described in claim 1, characterized in that, The step of having all browser instances concurrently execute the user behavior script on the target web application to simulate multiple users accessing the target web application simultaneously includes: Drive each browser instance to access the login page of the target web application; Drive each browser instance to dynamically generate username and password parameters and input them into the form controls on the login page; Drive each browser instance to click the login button on the login page and wait for the HTTP response from the login interface of the target web application to complete; Drive each browser instance to access the form page of the target web application, dynamically generate form content and input it; Drive each browser instance to click the submit button on the form page and wait for the HTTP response from the form submission interface of the target web application to complete.

4. The concurrent stress testing method as described in claim 3, characterized in that, The steps for obtaining the concurrent test execution results include: Based on the execution status of each browser instance, the number of successfully executed instances, the number of failed execution instances, and the access time of each browser instance are counted as the execution result of the concurrency test.

5. The concurrent stress testing method as described in claim 4, characterized in that, The access time of the browser instance includes the response time of the login interface of the target web application, the response time of the form submission interface of the target web application, and the total time of the complete operation.

6. The concurrent stress testing method as described in claim 1, characterized in that, The electronic device is also configured with a network service execution framework. Before the step of creating the browser instance management script, user behavior script, and concurrent test main script in the project root directory, the method further includes: Enable the network service execution framework and build the target web application.

7. A concurrent stress testing device, characterized in that, Applied to electronic devices, the electronic devices being configured with a script execution environment and a browser automation control library, the device includes: Create a module to build a browser instance management script, a user behavior script, and a concurrent test main script in the project root directory. The user behavior script reflects the complete operation behavior of a single user when accessing the target web application. The testing module is used to execute the browser instance management script, call the browser automation control library, create multiple isolated browser instances, execute the concurrency test main script, call each browser instance and make all browser instances concurrently execute the user behavior script on the target web application to simulate multiple users accessing the target web application at the same time, and obtain the concurrency test execution results.

8. The concurrent stress testing device as described in claim 7, characterized in that, The testing device is specifically used to call the browser automation control library to create multiple initial browser instances; configure each initial browser instance to run in headless mode; allocate an independent user data storage path to each initial browser instance configured in headless mode, thereby obtaining multiple browser instances with completely isolated session state, cache, and cookies.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the concurrent stress testing method according to any one of claims 1-6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the concurrent stress testing method as described in any one of claims 1-6.

Images