Simulation multi-user test method and electronic equipment thereof

Abstract

The embodiment of the invention provides a simulation multi-user test method and device, and the method comprises the steps: loading at least one piece of user information through a preset user data pool; after a login request of the at least one piece of user information is obtained, configuring corresponding user test data; establishing at least one test scene based on a preset test requirement and at least one piece of user test data; and performing a simulation test through the at least one test scene to obtain a simulation test result. User information is loaded through a preset user data pool, test data is dynamically configured after login, a test scene is built based on a preset test requirement, a simulation test is executed to obtain a test result, multi-user concurrent operation is simulated, data consistency and performance stability of a system in a high-load environment are ensured, abnormal conditions are effectively recognized, and the system performance is improved. And the test efficiency and the coverage rate are improved.

Description

Technical Field

[0001] The present invention relates to the field of intelligent testing, and in particular to a simulated multi-user testing method, device, system, electronic equipment and storage medium thereof. Background Art

[0002] During the testing process of high-concurrency business systems, especially scenarios involving large-scale user behavior simulation, such as user login, business operations, and data interaction, traditional testing methods often find it difficult to restore the actual usage environment. Manual testing is also inefficient and cannot achieve concurrent operations. Interface script testing will have problems such as context fragmentation, cumbersome parameter configuration, and limited coverage. At the same time, existing testing tools lack the ability to dynamically manage user behavior links, making it difficult to track and verify user status, business processes, and system resource usage throughout the entire process.

[0003] Therefore, existing testing methods have the problems of being unable to support and conduct dynamic management of user data, automatic construction of testing processes, configurable scenarios, and traceable results. Summary of the Invention

[0004] The embodiment of the present invention provides a simulated multi-user testing method to solve the problems of existing testing methods that cannot support and perform dynamic management of user data, automatic construction of test processes, configurable scenarios, and traceable results.

[0005] In a first aspect, an embodiment of the present invention provides a method for simulating multi-user testing, the method comprising the following steps: Load at least one user information through the preset user data pool; After obtaining a login request for the at least one user information, configuring corresponding user test data; Building at least one test scenario based on preset test requirements and at least one of the user test data; A simulation test is performed through at least one of the test scenarios to obtain a simulation test result.

[0006] Optionally, the step of loading at least one user information from a preset user data pool includes: Determine the size of the test dataset; Based on the size of the test data set, obtaining user information of corresponding size capacity from a preset user data pool; Based on the user information, a unique session identifier is assigned accordingly; Based on the unique session identifier, user information in the preset user data pool is loaded.

[0007] Optionally, after obtaining the login request of the at least one user information, configuring corresponding user test data, the method further includes: After confirming the login request of the user information, extracting the maintenance information in the user information; Storing the maintenance information in a session variable and detecting the state of the session variable in real time; Based on the state of the session variable, a request state of the current login request is determined.

[0008] Optionally, after obtaining the login request of the at least one user information, configuring corresponding user test data includes: Determining characteristic information of the corresponding user based on the login request; Based on the feature information, determining feature test data under at least one corresponding feature in the test library; Based on the feature test data under the at least one corresponding feature, corresponding user test data is configured.

[0009] Optionally, the step of establishing at least one test scenario based on the preset test requirements and at least one of the user test data includes: Based on the preset test requirements, determine the test parameters and business scenarios to be extracted; Based on the test parameters and the business scenario, determining a target user in at least one of the user test data; Based on the user test data corresponding to the target user, the business scenario is constructed to obtain at least one test scenario.

[0010] Optionally, the user test data corresponding to the target user is constructed in the business scenario to obtain at least one test scenario, and the method further includes: Analyze abnormal behavior of user test data corresponding to the target user in a business scenario to obtain abnormal behavior data; Based on the abnormal behavior data, the constructed test scenario is tested to obtain an abnormal test result of abnormal event injection; Based on the abnormal test results, an optimization strategy for the test scenario is determined.

[0011] Optionally, performing a simulation test on at least one of the test scenarios to obtain a simulation test result includes: Loading at least one of the test scenarios and initializing test data; During the test, real-time detection of interface data, database memory data, and server resource data; Calculating test results based on the interface data, database memory data, and server resource data; Generate a visual test report based on the test results.

[0012] In a second aspect, an embodiment of the present invention further provides a simulated multi-user testing device, the simulated multi-user testing device comprising: A first loading module is used to load at least one user information through a preset user data pool; A first configuration module is configured to configure corresponding user test data after obtaining a login request of the at least one user information; A first building module, configured to build at least one test scenario based on preset test requirements and at least one user test data; The first acquisition module is used to perform a simulation test through at least one of the test scenarios to obtain a simulation test result.

[0013] In a third aspect, an embodiment of the present invention provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the simulated multi-user testing method provided in the embodiment of the present invention are implemented.

[0014] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program implements the steps of the simulated multi-user testing method provided in the embodiment of the invention.

[0015] In an embodiment of the present invention, at least one user's information is loaded through a preset user data pool; after obtaining a login request for the at least one user's information, corresponding user test data is configured; based on the preset test requirements and the at least one user's test data, at least one test scenario is built; a simulation test is performed through the at least one test scenario to obtain a simulation test result. User information is loaded through a preset user data pool, test data is dynamically configured after login, a test scenario is built based on the preset test requirements, and a simulation test is performed to obtain test results. This simulates concurrent operations of multiple users, ensures data consistency and performance stability of the system under high load, effectively identifies abnormal situations, and improves test efficiency and coverage. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0017] Figure 1 This is a flow chart of a method for simulating multi-user testing provided by an embodiment of the present invention; Figure 2 is a structural diagram of another simulated multi-user testing device provided in an embodiment of the present invention; Figure 3 It is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0018] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0019] like Figure 1 As shown, Figure 1 1 is a flow chart of a method for simulating multi-user testing provided by an embodiment of the present invention, the method for simulating multi-user testing comprising the steps of: 101. Load at least one user information through a preset user data pool.

[0020] In an embodiment of the present invention, the above-mentioned simulated multi-user testing method can be applied to a simulated multi-user testing platform. The above-mentioned simulated multi-user testing platform has functions such as test data processing, test data transmission and reception, and test data memory storage, and can be constructed based on a server or a server cluster. The above-mentioned server or server cluster can be an electronic device with test data processing capabilities.

[0021] The above-mentioned preset user data pool can refer to a set of structured data sets prepared in advance before the test is executed to simulate user behavior. This data pool is usually used to support the automated testing system to simulate and manage user identity, permissions, behavior, etc. in multi-user scenarios.

[0022] Specifically, the above-mentioned preset user data pool may include but is not limited to user ID, password, user type, region, account information, login status and dynamic fields such as Token. It can be understood that dynamic fields such as Token can be generated and updated in real time during the test process.

[0023] It is understandable that the above preset user data pool can be directly referenced as parameter input through automated testing tools (such as JMeter, Postman, Selenium scripts, etc.). During the test, each thread / virtual user reads a row of user data from the data pool, dynamically binds it to the request, and automatically maintains the user login status and Token lifecycle based on the request session management.

[0024] The above-mentioned user information may include but is not limited to the balance, points, test behavior actions, etc. of the corresponding user account. The user information can be configured according to the specific test requirements and test environment, and stored in the above-mentioned preset user data pool in advance. It can also be matched to see whether the corresponding configured user information exists in the above-mentioned preset user data pool. If so, it can be called directly.

[0025] 102. After obtaining a login request of at least one user information, configure corresponding user test data.

[0026] In an embodiment of the present invention, the login request can be an HTTP request initiated to simulate a user login operation, typically including parameters such as a username and password. The response then returns user identity credentials, such as a token or cookie, for authentication purposes in subsequent operations. Specifically, dynamic login can be achieved by parameterizing the login request in JMeter and extracting the token from the response using a regular expression.

[0027] The above configuration can be a process of automatically binding key information (such as Token, user ID) with the user's subsequent test process after receiving the login response, and dynamically selecting the test path and parameters according to the user's attributes. It can be understood that the configuration process can run through multiple testing links such as interface parameter injection, process control, and exception simulation.

[0028] The above-mentioned user test data may refer to a personalized test data set corresponding to each simulated user, which may include but is not limited to: billing information, payment information, geographic location, balance, operation permissions, product orders, etc. Specifically, the above-mentioned user test data can be imported from a CSV file or generated at runtime and bound to the user identity and test target for use.

[0029] In one possible embodiment, after receiving the test response, the simulated multi-user testing platform matches the user in the preset user pool. If no match is found, the test data is automatically configured for the test user. For example, the token extracted from the response is dynamically bound to the user's subsequent requests to maintain the login state; billing data (such as bill ID, amount, payment method, etc.) for simulating payment behavior is allocated to the user and associated with the user information through the bills.csv file; whether failure scenarios (such as insufficient balance and token expiration) need to be simulated is marked according to the user type and test objectives (such as whether to participate in abnormal testing); all user test data is injected into the test request at runtime.

[0030] The simulated multi-user testing platform mentioned above dynamically manages user sessions and test parameters, improving test automation and authenticity. It is particularly suitable for system scenarios such as e-commerce, finance, and payment that are sensitive to high-concurrency operations among multiple users.

[0031] 103. Based on preset test requirements and at least one user test data, build at least one test scenario.

[0032] In an embodiment of the present invention, the above-mentioned construction can be to automatically construct a test path for simulating business operation processes based on the above-mentioned user test data and preset test objectives, including operation sequence, parameter injection, state control and other behaviors. Specifically, the construction behavior can be driven by the test engine, covering request organization, data binding, condition judgment and other links, used to reproduce the real user behavior link, and support dynamic path branches (such as success path and abnormal path).

[0033] The above-mentioned test scenarios may refer to a series of user operation behavior sets generated by the above-mentioned simulated multi-user testing platform based on user identity characteristics, business logic and test objectives, which are used to simulate specific functions or processes. For example, typical test scenarios include "login → order → payment", "payment → refund", "login → payment failure → retry", etc. It should be noted that each test scenario has clear goals, input parameters and expected verification points, which are used to comprehensively test functional correctness and stability, and support comprehensive coverage of positive processes and abnormal processes.

[0034] In a possible embodiment, after receiving the preset test objective of "simulating multiple users simultaneously participating in the purchase of limited-edition products during a major promotion to verify the system's order processing capabilities and capital flow accuracy under high concurrency, with specific requirements including: simulating 3,000 users logging in, placing orders, and paying, 20% of whom need to initiate refund operations after payment is completed, to test the system's responsiveness in terms of transaction rollback and data consistency", the simulated multi-user testing platform reads a preset user data pool (such as user_accounts.csv) to load user test data, including user account number, payment method, account balance, geographic location, whether to trigger a refund (refund_flag), etc. After loading is completed, the simulated multi-user testing platform dynamically determines the test path that the user should execute based on the user's characteristics and preset requirements.

[0035] More specifically, it can be divided into the following steps: For regular users, build a "login → order → payment" scenario; For the thread set as the refund user, build the "login → order → payment → delayed refund" scenario; For users with insufficient balance or expired tokens, an abnormal path is injected to verify the system's fault tolerance and interception mechanism.

[0036] Dynamically fill in request parameters (product ID, payment amount, token, etc.) based on each user's test path, generate the corresponding HTTP request link, and continuously track the interface response status, database write results, and log output of each operation. This can maintain the behavioral stability and data consistency of test data and test scenarios in high-concurrency test scenarios.

[0037] 104. Perform a simulation test through at least one test scenario to obtain a simulation test result.

[0038] In an embodiment of the present invention, the above-mentioned simulation test can be performed in a preset test environment by using automated means to execute specific business processes on the system through virtual users, simulating the behavioral operations of real users to verify the system's responsiveness, business logic correctness and fault tolerance under specific loads or functional paths. It should be noted that the above-mentioned simulation test can cover normal processes, boundary scenarios and abnormal paths, and is suitable for various scenarios such as functional testing, performance testing, and security testing.

[0039] The above-mentioned simulation test results may refer to the data set output by the system after the simulation test is executed to evaluate the completion of the test objectives, including interface response status, business data consistency, whether exception handling is effective, system performance indicators, whether the log behavior meets expectations, etc. It can be understood that the above-mentioned simulation test results can be used to determine whether the online requirements are met under the current conditions, whether there are performance bottlenecks or business defects, and are an important part of the test verification closed loop.

[0040] In a possible embodiment, the simulated multi-user test platform loads 500 virtual users based on the user data pool, configures corresponding billing test data for each user, and performs simulation testing based on the following test scenarios: Conventional payment process scenario: User login → Bill submission → Payment completed; Abnormal scenarios: Inject invalid tokens, payment timeouts, illegal parameters, etc. during the bill submission process to test the system's fault tolerance mechanism.

[0041] After the test is started, the simulated multi-user test platform executes the above test scenarios concurrently through automation tools (such as JMeter). Each user thread initiates an HTTP request to the server according to its test path, simulating the user's operation behavior in real use, including identity authentication, billing data submission, payment interface call, session state maintenance, etc.

[0042] After the simulation test is completed, the simulated multi-user test platform collects and analyzes the execution results of each test thread according to the preset verification mechanism to obtain a set of structured simulation test results, including but not limited to: Interface success rate statistics (e.g. bill submission interface success rate ≥ 99%); Data consistency check results (e.g., whether the number of bills in the database is 500 x 10); Exception path capture status (e.g., whether the invalid token is successfully intercepted); Performance indicators (such as average response time, concurrent processing capabilities, and resource utilization); The log tracks the matching situation (for example, there are no duplicate records of trade_no in the log).

[0043] The above simulation test results are written into log files and databases and used to generate the final performance analysis report.

[0044] In an embodiment of the present invention, at least one user's information is loaded through a preset user data pool; after obtaining a login request for at least one user's information, corresponding user test data is configured; based on the preset test requirements and the at least one user's test data, at least one test scenario is built; and a simulation test is performed through the at least one test scenario to obtain a simulation test result. User information is loaded through a preset user data pool, test data is dynamically configured after login, a test scenario is built based on the preset test requirements, and a simulation test is performed to obtain test results. This simulates concurrent operations of multiple users, ensures data consistency and performance stability of the system under high load environments, effectively identifies abnormal situations, and improves test efficiency and coverage.

[0045] Optionally, in the step of loading at least one user information through a preset user data pool, the size of the test data set can also be determined; based on the size of the test data set, user information of corresponding size capacity is obtained in the preset user data pool; based on the user information, a unique session identifier is allocated; and based on the unique session identifier, the user information in the preset user data pool is loaded.

[0046] In embodiments of the present invention, the aforementioned test dataset size may refer to the user data load capacity or the number of concurrent test threads that the system can support, determined dynamically before test execution based on the current operating environment's resource conditions (including but not limited to memory capacity, CPU load, thread pool configuration, etc.). It will be appreciated that the aforementioned test dataset size can be adjusted dynamically based on load or set to a specific number based on test requirements after evaluating them.

[0047] The above-mentioned corresponding size capacity may refer to the equal number of user data entries extracted from the preset user data pool according to the determined test data set size, that is, the number of rows or records matched by capacity from the user data resource. Therefore, the corresponding size capacity may also be set according to the specified number of test requirements after evaluating the test requirements.

[0048] In one possible embodiment, the simulated multi-user testing platform calculates the maximum test dataset size it can currently handle based on the memory resource status detected in the current operating environment (e.g., maximum heap size, remaining available memory, etc.). For example, if each user thread occupies approximately X MB of memory, the system dynamically sets the maximum number of concurrent threads to N based on the total memory and occupancy model. It then loads N user data from a pre-set user data pool. This prevents memory overflows caused by overly large test scales and improves test stability and robustness.

[0049] The above-mentioned unique session identifier can be an independent identifier generated for each virtual user, used to distinguish different user sessions and prevent session confusion. Generally speaking, the above-mentioned unique session identifier usually exists in the form of a string or hash value, binds the operation context of the user, and runs through the entire test process.

[0050] In another possible embodiment, the above-mentioned simulated multi-user test platform reads and injects user information from a preset user data pool into the test engine, enabling each thread to obtain its exclusive user identity and data configuration, and then execute a complete test behavior chain.

[0051] Optionally, in the step of configuring corresponding user test data after obtaining a login request for at least one user information, it further includes extracting the maintenance information in the user information after determining the login request for the user information; storing the maintenance information in the session variable and detecting the status of the session variable in real time; determining the request status of the current login request based on the status of the session variable.

[0052] In the embodiment of the present invention, the above-mentioned maintenance information can refer to status data related to the validity of the current user session, usually including: Token, Session ID, Token validity period / expiration time, user role permission level, device identifier / IP information, etc., which are information data used to maintain the integrity of a user's behavior chain during the test process, and can avoid problems such as session drift and cross-user pollution.

[0053] Generally speaking, through interface testing tools such as JSON, during the process of returning the user login request, the request information can be extracted to obtain the corresponding maintenance information.

[0054] The status of the above-mentioned session variable can refer to the current status of the maintenance information recorded in the context of each user thread, such as whether the Token has expired, whether the device has been tampered with, whether the permissions have changed, etc. During the request login detection process, these status values can be checked regularly or before an operation to determine whether the session is still valid. For example: token_valid = true indicates that the session is normal; expire_at < now() indicates that the Token has expired; device_id != expected_device indicates that the user login environment is abnormal.

[0055] The above-mentioned request status can be the executability or validity of the user's current request judged based on the current session variable status.

[0056] In a possible embodiment, after the above-mentioned simulated multi-user test platform obtains a login request for a certain user through the user data pool in the test thread, it extracts the maintenance information in the user information, including but not limited to: auth_token (authentication token) returned by login; Session expiration timestamp (expire_at); User level information (such as permission identification, user type, etc.); Current login device information (such as device_id, IP address, etc.).

[0057] These maintenance information can be used to keep the session state continuously valid, namely the so-called maintenance information.

[0058] The simulated multi-user testing platform stores this information in the user's session variables, creating a separate context (Session Map) for each user thread and continuously monitoring the state of these variables. For example, the simulated multi-user testing platform uses timers or assertions to detect token expiration, permissions changes, device replacement, and other issues in real time.

[0059] In subsequent request phases, such as submitting a bill, initiating a payment, or before initiating a refund, the simulated multi-user testing platform will dynamically determine the request status of the current login request based on the status of the current session variables. Specifically, it may include: Normal status: The session is valid, the token is not expired, and the request is allowed; Expired status: The token has expired and you need to log in again; Abnormal status: Device changes or permission downgrades are detected, triggering interception or additional verification; Empty state: The session variable does not exist or is uninitialized, marking it as an invalid request.

[0060] The above steps simulate the surface path of user behavior and further restore the complex session management and request judgment logic, thereby supporting automatic test branches and robustness assessment under abnormal conditions.

[0061] Optionally, after obtaining a login request for at least one user information, the step of configuring corresponding user test data also includes determining feature information of the corresponding user based on the login request; based on the feature information, determining feature test data under at least one corresponding feature in the test library; and configuring corresponding user test data based on the feature test data under at least one corresponding feature.

[0062] In an embodiment of the present invention, the above-mentioned feature information may include a set of information that directly or indirectly reflects the user's identity characteristics or business attributes in the user login request, such as user role, level, region, channel source, authentication status, etc. It can be understood that the above-mentioned feature information can be the basis for matching personalized test data, which can be obtained from request parameters, response fields or database mapping.

[0063] The above-mentioned feature test data can refer to structured data templates or instance data corresponding to a certain type of user characteristics in the test library, which is used to support the simulation of the real business path of this type of user in the system. For example, a simulated bill of "payment failure" is configured for "unbound card users"; reimbursement data containing multiple invoice fields is configured for "corporate users"; and an empty data set with no historical records is configured for "newly registered users".

[0064] In a possible embodiment, the simulated multi-user testing platform can bind the matched feature test data to the session context of a specific user so that subsequent operations (such as API calls and page interactions) are performed based on the data.

[0065] Optionally, in the step of building at least one test scenario based on preset test requirements and at least one user test data, it also includes determining the test parameters and business scenarios to be extracted based on the preset test requirements; determining the target user in at least one user test data based on the test parameters and business scenarios; and constructing in the business scenario based on the user test data corresponding to the target user to obtain at least one test scenario.

[0066] In an embodiment of the present invention, the above-mentioned preset test requirements may refer to a set of information such as test objectives, coverage, user types, functional points, data requirements, etc., which are pre-defined by the tester or the system before the test task is started. It can be understood that the above-mentioned preset test requirements serve as the input basis for the automated construction of the test process, and are used to guide the entire process of test parameters, user screening and scenario configuration.

[0067] The above test parameters can be key fields or data points used to screen users or match process conditions when building test scenarios. They are usually extracted from user test data, such as account balance, usage frequency, discount status, order quantity, etc., and are the basis for building differentiated paths.

[0068] The above business scenarios can be a set of operation paths that simulate a certain type of function or process in an actual system. They usually have clear business objectives, operation sequences, and input and output definitions, and are used to restore the typical user behavior path. For example: user places an order → successfully pays → initiates a refund; user places an order → payment fails → retry succeeds.

[0069] The target user mentioned above can refer to specific user entities within the user testing dataset that meet certain test objectives based on test parameters and business scenario conditions, and are then selected to participate in the personalized testing process. The target user screening process may involve steps such as condition judgment, feature matching, and policy filtering. For example, target users may meet the "first-time ordering user" condition; or target users may meet the "multiple refund records" condition. It is understood that target users can be user data that meets multiple or a single test objective.

[0070] In a possible embodiment, after receiving the preset test requirements, the above-mentioned simulated multi-user testing platform extracts users with corresponding test parameters from the preset user pool, configures the corresponding business scenarios, and screens out target users with specific behavioral characteristics based on the configured content. According to the screened target users and corresponding business scenarios, they are injected into the test execution engine, and the target users and context parameters are bound to perform the full-process simulation operation, which is finally used to verify the test results.

[0071] Optionally, in the step of constructing in a business scenario based on the user test data corresponding to the target user to obtain at least one test scenario, it also includes parsing the abnormal behavior of the user test data corresponding to the target user in the business scenario to obtain abnormal behavior data; based on the abnormal behavior data, testing the constructed test scenario to obtain abnormal test results of abnormal event injection; based on the abnormal test results, determining the optimization strategy of the test scenario.

[0072] In an embodiment of the present invention, the above-mentioned abnormal behavior data may refer to structured description information of potential violations or unreasonable operational behaviors parsed from the target user's test data and business scenario logic, which is used to identify boundary conditions, error paths or illegal operations that need to be simulated for testing.

[0073] The above-mentioned injection refers to the intentional insertion of abnormal data or behavior into the normal test path during the test process to verify the system's ability to handle abnormal input. This includes data tampering, state distortion, process interruption, etc. Specifically, the injection process can occur in multiple dimensions such as interface parameters, request headers, database status, and token status.

[0074] The above-mentioned abnormal test results can be the recording results of interface behavior, system response, data status, log output, etc. during the test process after the abnormal event is injected, which is used to evaluate the system's abnormal handling capabilities and robustness, such as interception success rate, type of returned error code, whether the degradation / retry mechanism is triggered, resource consumption status and other result prompts.

[0075] The above-mentioned optimization strategy may refer to an improvement plan for system functions, logic, resource configuration or abnormal response mechanism proposed based on the analysis of abnormal test results, which is used to improve system stability, availability and security, such as adding abnormal input whitelist verification, adjusting thread pool strategy, enhancing token validity verification, etc.

[0076] In a possible embodiment, the simulated multi-user testing platform analyzes possible abnormal behaviors of target users in a specified business scenario, for example: The account balance is insufficient but a transfer request is still initiated; Users with low credit ratings apply for large loans; Users suddenly switch devices or IP addresses during high-frequency trading; The user's requested operation does not match their permissions (for example, a normal user accesses the administrator interface).

[0077] By identifying and matching the current behavior with the corresponding historical behavior, when it is identified as abnormal behavior data, it indicates the behavioral characteristics and parameter combinations that may trigger the system fault tolerance logic, interception mechanism or abnormal branch in a certain business process. The above-mentioned simulated multi-user test platform will inject abnormal events based on the above-mentioned abnormal behavior data on the basis of the constructed normal test scenario, that is, artificially write abnormal parameters into the key requests in the test path. Subsequently, the test platform executes the abnormal scenario test, records the system's response status at each injection point, abnormal capture status, interface error code, log output and other information to form a structured abnormal test result. The above-mentioned abnormal test results are analyzed to generate optimization strategies for targeted test scenarios, such as adding input verification logic for a certain type of exception, adding current limiting processing to a certain interface, adjusting the access permission model for a certain type of user, enhancing the log link and alarm prompt mechanism, and other means.

[0078] Optionally, in the step of performing simulation testing through at least one test scenario and obtaining simulation test results, it also includes loading at least one test scenario and initializing test data; during the test process, real-time detection of interface data, database memory data and server resource data; calculating test results based on interface data, database memory data and server resource data; and generating a visual test report based on the test results.

[0079] In an embodiment of the present invention, the simulated multi-user testing platform loads at least one test scenario according to preset test requirements, for example, simulating the complete business process of "login → query bill → online payment → download invoice".

[0080] To ensure a consistent operating environment for each test thread, the platform initializes test data for each thread or virtual user session, including binding user identity (Token, session_id), injecting billing data (such as bill number, amount, and status), writing the initial database status (such as balance and limit), clearing the log cache, and resetting statistical indicators.

[0081] During the formal test operation, the above-mentioned simulated multi-user test platform can detect the following three core data sources in real time: interface data: including request duration, response code, return body content, etc.; database / memory data: such as whether the bill is written successfully, whether the balance is deducted correctly, whether the transaction is rolled back, etc.; server resource data: including CPU usage, memory usage, thread pool status, I / O, etc.

[0082] The above data is dynamically collected and recorded, and the test performance is evaluated based on the collected multi-dimensional data, and the test results are calculated, including but not limited to: interface success rate = number of successful requests / total number of requests, average response time = ∑ response time / number of requests, data consistency check = whether there is a write failure, amount discrepancy, etc., system resource load = whether there is resource excess or thread blocking, etc.

[0083] Based on the calculation results, the above-mentioned simulated multi-user test platform further generates a structured visual test report, which covers: business process coverage statistics, performance charts of each interface (success rate, response time curve), database consistency verification conclusions, system resource usage trend charts, key exception log tracking and other data.

[0084] Test reports can be exported to PDF or HTML format for testers to review.

[0085] like Figure 2 As shown, an embodiment of the present invention further provides a simulated multi-user testing device 200, which includes: A first loading module 201 is configured to load at least one user information from a preset user data pool; A first configuration module 202 is configured to configure corresponding user test data after obtaining a login request of the at least one user information; A first building module 203 is configured to build at least one test scenario based on a preset test requirement and at least one user test data; The first acquisition module 204 is configured to perform a simulation test through at least one of the test scenarios to obtain a simulation test result.

[0086] Optionally, the first loading module 201 includes: The first determination submodule is used to determine the size of the test data set; A first acquisition submodule is configured to acquire user information of a corresponding size and capacity from a preset user data pool based on the size of the test data set; A first allocation submodule, configured to allocate a unique session identifier based on the user information; The first loading submodule is configured to load user information from the preset user data pool based on the unique session identifier.

[0087] Optionally, the above device further includes: A first extraction module is used to extract maintenance information from the user information after confirming the login request of the user information; a first detection module, configured to store the maintenance information in a session variable and detect a state of the session variable in real time; The first session module is configured to determine a request status of a current login request based on a status of the session variable.

[0088] Optionally, the first configuration module 202 includes: A second determining submodule, configured to determine characteristic information of a corresponding user based on the login request; A third determining submodule is configured to determine, based on the feature information, feature test data corresponding to at least one feature in the test library; The first configuration submodule is configured to configure corresponding user test data based on the feature test data under the at least one corresponding feature.

[0089] Optionally, the first building module 203 further includes: The fourth determination submodule is used to determine the test parameters and business scenarios to be extracted based on the preset test requirements; a fifth determining submodule, configured to determine a target user from at least one of the user test data based on the test parameters and the business scenario; The sixth determination submodule is configured to construct, based on the user test data corresponding to the target user, the business scenario to obtain at least one test scenario.

[0090] Optionally, the above device further includes: An analysis module is used to analyze abnormal behavior of the user test data corresponding to the target user in the business scenario to obtain abnormal behavior data; A construction module is used to test the constructed test scenario based on the abnormal behavior data to obtain an abnormal test result of abnormal event injection; The optimization module is used to determine an optimization strategy for the test scenario based on the abnormal test result.

[0091] Optionally, the first obtaining module 204 includes: An initialization submodule, configured to load at least one of the test scenarios and initialize test data; The test detection submodule is used to detect interface data, database memory data and server resource data in real time during the test process; A calculation submodule, configured to calculate test results based on the interface data, database memory data, and server resource data; The generating submodule is used to generate a visual test report according to the test results.

[0092] like Figure 3 As shown, an embodiment of the present invention further provides an electronic device 300, including a processor, and the processor can execute any one of the above-mentioned simulated multi-user testing methods.

[0093] Specifically, the system includes a processor 301, a memory 302, and a computer program for executing a simulated multi-user test method stored in the memory 302 and capable of running on the processor 301, wherein: The processor 301 runs the computer program for simulating the multi-user testing method stored in the memory 302 and performs the following steps: Load at least one user information through the preset user data pool; After obtaining a login request for the at least one user information, configuring corresponding user test data; Building at least one test scenario based on preset test requirements and at least one of the user test data; A simulation test is performed through at least one of the test scenarios to obtain a simulation test result.

[0094] Optionally, the processor 301 executes the step of loading at least one user information through a preset user data pool, including: Determine the size of the test dataset; Based on the size of the test data set, obtaining user information of corresponding size capacity from a preset user data pool; Based on the user information, a unique session identifier is assigned accordingly; Based on the unique session identifier, user information in the preset user data pool is loaded.

[0095] Optionally, the processor 301 configures corresponding user test data after executing the login request for obtaining the at least one user information, and the method further includes: After confirming the login request of the user information, extracting the maintenance information in the user information; Storing the maintenance information in a session variable and detecting the state of the session variable in real time; Based on the state of the session variable, a request state of the current login request is determined.

[0096] Optionally, the processor 301 configures corresponding user test data after executing the login request for obtaining the at least one user information, including: Determining characteristic information of the corresponding user based on the login request; Based on the feature information, determining feature test data under at least one corresponding feature in the test library; Based on the feature test data under the at least one corresponding feature, corresponding user test data is configured.

[0097] Optionally, the processor 301 executes the step of building at least one test scenario based on the preset test requirements and at least one of the user test data, including: Based on the preset test requirements, determine the test parameters and business scenarios to be extracted; Based on the test parameters and the business scenario, determining a target user in at least one of the user test data; Based on the user test data corresponding to the target user, the business scenario is constructed to obtain at least one test scenario.

[0098] Optionally, the processor 301 further executes the user test data corresponding to the target user, constructs in the business scenario, and obtains at least one test scenario. The method further includes: Analyze abnormal behavior of user test data corresponding to the target user in a business scenario to obtain abnormal behavior data; Based on the abnormal behavior data, the constructed test scenario is tested to obtain an abnormal test result of abnormal event injection; Based on the abnormal test results, an optimization strategy for the test scenario is determined.

[0099] Optionally, the processor 301 further performs the simulation test through at least one of the test scenarios to obtain a simulation test result, including: Loading at least one of the test scenarios and initializing test data; During the test, real-time detection of interface data, database memory data, and server resource data; Calculating test results based on the interface data, database memory data, and server resource data; Generate a visual test report based on the test results.

[0100] An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the computer program implements the various processes of the simulated multi-user testing method or the application-side simulated multi-user testing method provided in the embodiment of the present invention, and can achieve the same technical effect. To avoid repetition, it will not be described here.

[0101] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by a computer program that instructs related hardware to perform the process, and can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0102] The above disclosure is merely a preferred embodiment of the present invention and certainly cannot be used to limit the scope of the present invention. Therefore, equivalent changes made according to the claims of the present invention are still within the scope of the present invention.

Claims

1. A simulated multi-user testing method, characterized in that: include: Load at least one user information through the preset user data pool; After obtaining a login request for the at least one user information, configuring corresponding user test data; Building at least one test scenario based on preset test requirements and at least one of the user test data; A simulation test is performed through at least one of the test scenarios to obtain a simulation test result.

2. The simulated multi-user testing method according to claim 1, wherein: The step of loading at least one user information through a preset user data pool includes: Determine the size of the test dataset; Based on the size of the test data set, obtaining user information of corresponding size capacity from a preset user data pool; Based on the user information, a unique session identifier is assigned accordingly; Based on the unique session identifier, user information in the preset user data pool is loaded.

3. The simulated multi-user testing method according to claim 1, wherein: After obtaining the login request of the at least one user information, configuring corresponding user test data, the method further includes: After confirming the login request of the user information, extracting the maintenance information in the user information; Storing the maintenance information in a session variable and detecting the state of the session variable in real time; Based on the state of the session variable, a request state of the current login request is determined.

4. The simulated multi-user testing method according to claim 1, wherein: After obtaining the login request of the at least one user information, configuring corresponding user test data includes: Determining characteristic information of the corresponding user based on the login request; Based on the feature information, determining feature test data under at least one corresponding feature in the test library; Based on the feature test data under the at least one corresponding feature, corresponding user test data is configured.

5. The simulated multi-user testing method according to claim 4, wherein: The step of establishing at least one test scenario based on the preset test requirements and at least one of the user test data includes: Based on the preset test requirements, determine the test parameters and business scenarios to be extracted; Based on the test parameters and the business scenario, determining a target user in at least one of the user test data; Based on the user test data corresponding to the target user, the business scenario is constructed to obtain at least one test scenario.

6. The simulated multi-user testing method according to claim 5, wherein: The user test data corresponding to the target user is constructed in the business scenario to obtain at least one test scenario, and the method further includes: Analyze abnormal behavior of user test data corresponding to the target user in a business scenario to obtain abnormal behavior data; Based on the abnormal behavior data, the constructed test scenario is tested to obtain an abnormal test result of abnormal event injection; Based on the abnormal test results, an optimization strategy for the test scenario is determined.

7. The simulated multi-user testing method according to claim 1, wherein: The performing of a simulation test through at least one of the test scenarios to obtain a simulation test result includes: Loading at least one of the test scenarios and initializing test data; During the test, real-time detection of interface data, database memory data, and server resource data; Calculating test results based on the interface data, database memory data, and server resource data; Generate a visual test report based on the test results.

8. A simulated multi-user test device, characterized in that: include: A first loading module is used to load at least one user information through a preset user data pool; A first configuration module is configured to configure corresponding user test data after obtaining a login request of the at least one user information; A first building module, configured to build at least one test scenario based on preset test requirements and at least one user test data; The first acquisition module is used to perform a simulation test through at least one of the test scenarios to obtain a simulation test result.

9. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the simulated multi-user testing method according to any one of claims 1 to 7 when executing the computer program.

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 simulated multi-user testing method according to any one of claims 1 to 7.

Images