Simulating multi-user login test method and device, storage medium and program product
By constructing test commands and real-time monitoring methods, the system's multi-user concurrent login performance is automatically evaluated, solving the problem of difficulty in simulating device information in traditional methods and achieving efficient and accurate test results.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING TOPSEC NETWORK SECURITY TECH
- Filing Date
- 2024-11-26
- Publication Date
- 2026-07-14
Smart Images
Figure CN119484371B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of system testing technology, and in particular to a method, apparatus, storage medium, and program product for simulating multi-user login testing. Background Technology
[0002] Zero Trust is a cybersecurity strategy where enterprises do not automatically trust any internal or external users, devices, or applications; all access requests undergo rigorous verification before authorization. In a test environment, it's necessary to simulate scenarios where multiple users simultaneously log into the client. This scenario is typically used to verify the system's concurrency handling capabilities and security. To simulate real user login requests, each user request must contain specific device information (such as IP address, MAC address, system information, etc.) to verify the user's identity and the device's legitimacy. Traditional API testing methods usually focus on simulating API requests and responses, but in this scenario, it's difficult to easily obtain and simulate each user's device information, making effective simulation and verification of the test scenario impossible. Summary of the Invention
[0003] In view of this, the present disclosure provides a method, apparatus, storage medium, and program product for simulating multi-user login testing, which can simulate concurrent login by executing and updating test commands, and automatically test the multi-user concurrent login performance of the tested terminal.
[0004] In a first aspect, the embodiments of this disclosure provide a method for simulating multi-user login testing, employing the following technical solution:
[0005] On the test side, construct a test command and configure the test command with the test terminal identifier, username prefix, number start value and number of logins;
[0006] The i-th round of testing is initiated by executing the test command, where the initial value of i is 1;
[0007] In the i-th round of testing, the authentication login request of the user is simulated based on the username prefix, the starting value of the number and the number of logins, and the authentication login request is sent to the tested terminal based on the tested terminal identifier;
[0008] Real-time monitoring of whether the number of concurrent users on the tested end is increasing;
[0009] If not, obtain the maximum number of concurrent users and use it as the concurrent authentication login capacity of the tested terminal, then end the test;
[0010] If so, obtain the test information, update the test command based on the test information, and execute the new test command, i=i+1.
[0011] Optionally, the step of simulating a user's authentication login request based on the username prefix, the starting value of the number, and the number of logins includes:
[0012] Based on the aforementioned starting number value, the current number K is generated, K=k0. i + k, k0 i Let k be the starting value of the number in the i-th round of testing, and k is initially 0.
[0013] Combine the username prefix and the current number to form the current username;
[0014] Generate the current IP address and current MAC address based on the starting values of the IP address and MAC address;
[0015] Get current system information;
[0016] Based on the current username, the current IP address, the current MAC address, and the current system information, simulate the user's authentication login request, k=k+1;
[0017] When the result of k-1 is less than the number of logins, a new authentication login request is simulated.
[0018] Optionally, the real-time monitoring of whether the number of concurrent users on the tested end is increasing includes:
[0019] Real-time acquisition of the number of concurrent users and sampling time on the tested device;
[0020] A graph is constructed based on the real-time acquired number of concurrent users and sampling time;
[0021] Obtain the instantaneous slope of the curve;
[0022] If the instantaneous slope is positive, then the number of concurrent users on the tested end is determined to be in an increasing state.
[0023] If the instantaneous slope is not positive, then the number of concurrent users on the tested end is determined to be constant.
[0024] Optionally, the simulated multi-user login test method further includes:
[0025] Determine whether the device under test is being used for the first time;
[0026] If so, obtain the device type of the tested terminal, and collect the concurrent authentication login capacity of multiple devices of the same type based on the device type;
[0027] The average value of the concurrent authentication login capacity of multiple devices of the same type is used as the initial value of the number of logins;
[0028] If not, obtain the number of CPU cores of the tested terminal, as well as the average utilization of each CPU core and the average time for request processing in historical login operations.
[0029] The initial value of the number of logins is obtained based on the number of CPU cores, the average utilization rate, and the average time.
[0030] Optionally, the initial value of the number of logins is calculated using the following formula:
[0031]
[0032] Where C1 is the initial number of logins; n is the sequence number of the CPU core, 1≤n≤N; N is the number of CPU cores; u n t represents the average utilization of the nth CPU core. n This represents the average time for processing a request on the nth CPU core.
[0033] Optionally, the test information includes the total time of the i-th round of testing, the current number of concurrent users on the tested end, the request failure rate, and the throughput;
[0034] The predicted number of logins for the next round of testing is obtained based on the curve.
[0035] Based on the total time of the i-th round of testing, the current number of concurrent users on the tested end, the request failure rate, the throughput, and the predicted number of logins, obtain the new number of logins;
[0036] Update the starting value of the login ID based on the new number of logins;
[0037] Update the test command based on the new number of logins and the new starting value of the ID.
[0038] Optionally, the formula for calculating the new number of logins is as follows:
[0039] C i+1 =(Y c - y1)×T i ×(1-S i ) / L;
[0040] In the formula, C i+1 Y represents the new number of logins. c To predict the number of logins; y1 is the current concurrent user count on the tested device; T i S represents the total time of the i-th round of testing; i Let L be the cumulative request failure rate at the end of the i-th round of testing. The request failure rate will be continuously updated as the test iterations proceed; L is the throughput.
[0041] Secondly, this disclosure also provides a simulated multi-user login testing system, which adopts the following technical solution:
[0042] The command building module is used to build test commands on the test side and configure the test command with the test terminal identifier, username prefix, number start value and number of logins;
[0043] The command execution module is used to initiate the i-th round of testing by executing the test command, where the initial value of i is 1;
[0044] The request simulation module is used to simulate the user's authentication login request based on the username prefix, the starting value of the number and the number of logins in the i-th round of testing, and to send the authentication login request to the tested end based on the tested end identifier.
[0045] The status monitoring module is used to monitor in real time whether the number of concurrent users on the tested end is increasing; if not, the capacity acquisition module is executed; if so, the command update module is executed.
[0046] The capacity acquisition module is used to obtain the maximum number of concurrent users and use it as the concurrent authentication login capacity of the tested terminal, and then end the test;
[0047] The command update module is used to obtain test information, update the test command based on the test information, and execute the new test command, i=i+1.
[0048] Thirdly, this disclosure also provides a computer device, which adopts the following technical solution:
[0049] The computer device includes:
[0050] At least one processor; and,
[0051] A memory communicatively connected to the at least one processor; wherein,
[0052] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform any of the simulated multi-user login test methods described above.
[0053] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing computer instructions for causing a computer to execute any of the simulated multi-user login test methods described above.
[0054] Fifthly, embodiments of this disclosure also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of any of the methods described above.
[0055] The simulated multi-user login testing method provided in this disclosure can accurately assess the concurrent authentication login capacity of the tested terminal by gradually increasing the login requests of concurrent users. This capacity is the maximum number of concurrent users the system can stably handle, helping to identify performance bottlenecks under different loads. This is particularly helpful when testing the capabilities of a zero-trust SDP multi-user login client, assisting development teams in making more informed decisions during system design and deployment. When the number of concurrent users on the tested terminal stops increasing, the testing method automatically stops and records the current maximum number of concurrent users, thus avoiding over-testing and unnecessary resource consumption. If the number of concurrent users continues to increase, the testing method dynamically updates the test commands and continues to the next round of testing (i.e., round i+1) to further explore the system's limits. The entire testing process is automated by building and executing test commands, reducing errors and time consumption from manual operations and improving testing efficiency. Real-time monitoring of changes in the number of concurrent users on the tested terminal allows for timely detection of system performance trends, facilitating rapid updates to test commands. By configuring username prefixes and starting numbers, a large number of simulated users can be flexibly generated, suitable for testing needs of different scales and types. This flexible configuration strategy for test commands can be adjusted according to specific test objectives and requirements, increasing the applicability and scalability of the test methods.
[0056] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0057] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0058] Figure 1 A flowchart illustrating the simulated multi-user login testing method provided in this embodiment of the disclosure;
[0059] Figure 2 A flowchart illustrating the authentication login request simulation method provided in this embodiment of the disclosure;
[0060] Figure 3 A flowchart illustrating the growth state determination method provided in this embodiment of the disclosure;
[0061] Figure 4 A flowchart illustrating the method for setting the initial number of logins provided in this embodiment of the disclosure;
[0062] Figure 5 A flowchart illustrating the test command update method provided in this embodiment of the disclosure;
[0063] Figure 6 This is a schematic diagram of a simulated multi-user login test system provided in an embodiment of the present disclosure.
[0064] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. Detailed Implementation
[0065] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.
[0066] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.
[0067] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.
[0068] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The drawings only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.
[0069] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that these aspects can be practiced without these specific details.
[0070] Reference Figure 1 This disclosure provides a method for simulating multi-user login testing, including the following steps:
[0071] S1: Build test commands on the test side and configure the test terminal identifier, username prefix, number start value and number of logins to the test commands;
[0072] S2: Initiate the i-th round of testing by executing the test command, where the initial value of i is 1;
[0073] S3: In the i-th round of testing, simulate the user's authentication login request based on the username prefix, the starting value of the number, and the number of logins, and send the authentication login request to the tested end based on the tested end identifier;
[0074] S4: Monitor in real time whether the number of concurrent users on the tested end is increasing; if not, proceed to S5; if yes, proceed to S6.
[0075] S5: Obtain the maximum number of concurrent users and use it as the concurrent authentication login capacity of the tested terminal, then end the test;
[0076] S6: Obtain test information, update the test command based on the test information, i=i+1, return to S2, and execute the new test command.
[0077] This disclosed method for simulating multi-user login testing accurately assesses the concurrent authentication login capacity of the tested system by gradually increasing the login requests from concurrent users. This capacity determines the maximum number of concurrent users the system can stably handle, helping to identify performance bottlenecks under different loads. This is particularly beneficial when testing the capabilities of zero-trust SDP multi-user login clients, assisting development teams in making more informed decisions during system design and deployment. The testing method automatically stops and records the current maximum concurrent user count when the number of concurrent users on the tested system stops increasing, thus avoiding overtesting and unnecessary resource consumption. If the number of concurrent users continues to increase, the testing method dynamically updates the test commands and continues to the next round of testing (i.e., round i+1) to further explore the system's limits. The entire testing process is automated by building and executing test commands, reducing errors and time consumption from manual operations and improving testing efficiency. Real-time monitoring of changes in the number of concurrent users on the tested system allows for timely detection of system performance trends, facilitating rapid updates to test commands. By configuring username prefixes and starting numbers, a large number of simulated users can be flexibly generated, suitable for testing needs of different scales and types. This flexible configuration strategy for test commands can be adjusted according to specific test objectives and requirements, increasing the applicability and scalability of the test methods.
[0078] In summary, this simulated multi-user login testing method, through automation, dynamic adjustment, and real-time monitoring, can efficiently and accurately evaluate the system's performance and capacity in concurrent authentication login scenarios, providing strong support for system optimization and expansion.
[0079] In S1, the test client can be a personal computer (PC). Test commands are constructed on the test client, and command parameters are configured for these commands. Command parameters include the test program identifier, tester identifier, tested terminal identifier, username prefix, starting number value, and number of logins. The test program identifier is the unique identifier of the test program to be invoked; the tester identifier is the unique identifier of the tester initiating the test command; the tested terminal identifier is the IP address of the tested terminal, which can be a TopSDP (Top Security Device Protocol) controller, therefore, the tested terminal identifier can also be called the controller IP; a large number of pre-registered usernames are preset, each including a username prefix and a number. The username prefix is a fixed part of the username used to identify the user's group or category, and the starting number value is the starting value of the number part of the username, usually set to an integer; the number of logins refers to the total number of simulated user logins in the i-th round of testing, where i represents the number of test iterations, and the initial value of i is 1.
[0080] In S2, the testing tool (simulated test client) is a large collection of software or scripts containing multiple test programs. Users navigate to the directory where the testing tool is located via the command-line interface, enter the directory, and run the testing tool directly from the command line, sending test commands. Once the testing tool receives a test command, it calls the corresponding test program based on the test program identifier in the command to execute the test command, thus beginning the i-th round of testing.
[0081] In S3, during the i-th round of testing, the test program simulates user authentication login requests based on username prefix, starting number value, and number of logins, and sends multiple authentication login requests to the tested terminal based on the tested terminal identifier.
[0082] Reference Figure 2 The flowchart illustrating the authentication login request simulation method shows the following steps for simulating a user's authentication login request based on the username prefix, the starting value of the ID, and the number of logins:
[0083] S31: Generate the current number K based on the initial number value, K=k0 i + k, k0 i Let k be the starting value of the number in the i-th round of testing, and k is initially 0.
[0084] S32: Combine the username prefix and the current number to form the current username;
[0085] S33: Generate the current IP address and current MAC address based on the starting values of the IP address and MAC address;
[0086] S34: Obtain current system information;
[0087] S35: Based on the current username, current IP address, current MAC address, and current system information, simulate the user's authentication login request, k=k+1;
[0088] S36: Determine if the result of k-1 is less than the number of logins; if yes, return to S31 and simulate a new authentication login request; if no, execute S37.
[0089] S37: Awaiting the next round of iteration testing.
[0090] In S31, k is reset to 0 at the beginning of each test round.
[0091] In S32, the current number is added to the username prefix to form the complete username, and the username generated at this time is the current username.
[0092] In S33, the current IP address is represented as P, where P = P0 + k, and P0 is the starting value of the IP address. Note that it is necessary to check whether the last bit (fourth bit) of P has reached the upper limit (e.g., 255); if so, add 1 to the second to last bit (third bit) of P and reset the last bit to the lower limit (e.g., 1); if not, simply add 1 to the last bit of P.
[0093] The current MAC address is represented as M, where M = M0 + k, and M0 is the starting value of the MAC address. Note that it is necessary to check whether the last bit (sixth bit) of M has reached the upper limit (e.g., FF); if so, add 1 to the second to last bit (fifth bit) of M and reset the last bit to the lower limit (e.g., 00); if not, simply add 1 to the last bit of M.
[0094] In S34, the current system information can be determined in three ways: First, a preset set of system information can be used as the current system information, representing the system environment to be simulated. Second, different system information is iteratively extracted from a preset information database to cover various possible system environments. Third, the current system information can be generated directly based on real-time performance data. This method can dynamically adjust the system configuration based on real-time performance data to more accurately simulate the actual operating environment. The current system information includes system version, IMEI information, device serial number, etc.
[0095] In S35, the current username, current IP address, current MAC address, and current system information are constructed into a device information entity (i.e., stdev). stdev calls the internally defined login() function to simulate a user's authentication login request. It then initiates authentication login requests to the corresponding client under test (DUT) using the DUT's identifier. The total number of requests is determined by the set number of login attempts. Since the time interval between each request is very short, and some requests are even sent in parallel, it can be considered as a series of authentication login requests being continuously initiated in each round of testing. Upon receiving the authentication login request, the DUT executes the authentication process and returns the authentication result. If authentication is successful, the DUT provides an authentication token and other relevant information; if authentication fails, it returns the corresponding error code and reason for failure. This process ensures comprehensive testing and verification of the DUT's authentication mechanism.
[0096] In S36-S37, calculate the result of k-1. If the result is less than the number of logins, continue to repeat the above steps to simulate a new authentication login request. If the result is equal to the number of logins, wait for the next round of iteration test (i.e., the i+1th round of test).
[0097] In S4, refer to Figure 3 The flowchart illustrating the growth status determination method demonstrates how to monitor the concurrent user count on the tested device in real time to determine if it is in a growth state. This includes the following steps:
[0098] S41: Real-time acquisition of the number of concurrent users and sampling time on the tested end;
[0099] S42: Construct a graph based on the real-time acquired number of concurrent users and sampling time;
[0100] S43: Get the instantaneous slope of the curve;
[0101] S44: Determine if the instantaneous slope is positive; if yes, proceed to S45; if no, proceed to S46.
[0102] S45: Determine that the number of concurrent users on the tested end is in an increasing state;
[0103] S46: Determine that the number of concurrent users on the tested end is constant.
[0104] In S41-S42, concurrent users refer to the number of online users on the tested device, and sampling time refers to the specific time when the concurrent user count is collected. To visually demonstrate this dynamic change, an xoy coordinate system is constructed, where the x-axis represents the sampling time and the y-axis represents the concurrent user count. The coordinate points (x, y) are determined by the real-time collected concurrent user count and the corresponding sampling time. Connecting these coordinate points sequentially forms a curve. As time progresses and data collection continues, the curve will continuously update, reflecting the trend of concurrent user count changes over time.
[0105] Note that the token is usually valid for 8 hours, which is enough to support the completion of the entire test project. Therefore, during the overall test project process, no users will go offline, and correspondingly, the number of concurrent users on the tested side will not decrease.
[0106] In S43, whenever the number of concurrent users on the tested end is updated, the real-time slope of the curve is immediately obtained. The formula for calculating the real-time slope is as follows:
[0107] m = (y1 - y2) / (x1 - x2)
[0108] In the formula, y1 is the latest number of concurrent users of the tested terminal, that is, the current number of concurrent users of the tested terminal; y2 is the number of concurrent users of the tested terminal in the last collection; x1 is the sampling time of y1; and x2 is the sampling time of y2.
[0109] In S44-S46, if the instantaneous slope is positive, it indicates that the number of concurrent users on the tested end is in an increasing state, meaning that the tested end has not yet reached its limit for handling online users, and further exploration of the tested end's capacity is still needed. If the instantaneous slope is not positive, it indicates that the number of concurrent users on the tested end is in a constant state, meaning that the tested end has reached its limit for handling online users.
[0110] In S5, when the number of concurrent users on the tested end is constant, the maximum number of concurrent users obtained during the test (i.e., the number of concurrent users on the tested end collected in the last round) is obtained and used as the concurrent authentication login capacity of the tested end, then the test ends and the simulated authentication login request is stopped.
[0111] Furthermore, since device information entities need to be prepared before making an authentication login request, if the initial number of logins far exceeds the concurrent authentication login capacity of the tested device, the preparation work for many device information entities will become redundant. Conversely, if the initial number of logins is far lower than the concurrent authentication login capacity of the tested device, the overall test completion time will be extended, thus affecting test efficiency. Therefore, the simulated multi-user login test method disclosed herein also includes: specifically adjusting the initial value of the number of logins according to the device details of the tested device to ensure the efficiency and accuracy of the test. Such adjustments help optimize resource utilization and ensure the reliability of test results. Specifically, refer to... Figure 4 The flowchart illustrating the method for setting the initial number of logins shows the following steps for obtaining the initial number of logins:
[0112] S7: Determine if the device under test is being used for the first time; if yes, proceed to S8; otherwise, proceed to S10.
[0113] S8: Obtain the device type of the tested terminal, and collect the concurrent authentication login capacity of multiple devices of the same type based on the device type;
[0114] S9: Use the average value of the concurrent authentication login capacity of multiple devices of the same type as the initial value for the number of logins;
[0115] S10: Obtain the number of CPU cores on the tested device, as well as the average utilization of each CPU core and the average time for request processing in historical login operations;
[0116] S11: Obtain the initial value of the number of logins based on the number of CPU cores, average utilization, and average time.
[0117] In the above, whether the tested device is using it for the first time refers to whether it has already undergone user authentication and login before the test. If it has not undergone user authentication and login, it is considered to be using it for the first time. The concurrent authentication and login capacity of the tested device is evaluated by collecting data from multiple devices of the same type as the tested device, and the initial value of the number of logins is set based on this. If the tested device has undergone user authentication and login, it is considered not to be using it for the first time. The initial value of the number of logins is calculated by using the number of CPU cores of the tested device, the average utilization of each CPU core in historical login operations, and the average time for request processing (i.e., the average time for CPU cores to process authentication and login requests). The calculation formula is as follows:
[0118]
[0119] In the formula, C1 is the initial value of the number of logins, and the prototype of C1 is C i C i This represents the number of logins in the i-th test round, but the initial value of the login count was set in the 1st test round, so i is 1 at this time; n is the CPU core sequence number, 1≤n≤N; N is the number of CPU cores; u n t represents the average utilization of the nth CPU core. n This represents the average time for processing a request on the nth CPU core.
[0120] In S6, refer to Figure 5 The flowchart illustrating the test command update method, in one specific implementation, involves obtaining test information, updating the command parameters in the test command based on the test information, and executing the new test command, including the following steps:
[0121] S61: Test information includes the total time of the i-th round of testing, the current number of concurrent users on the tested end, the request failure rate, and the throughput;
[0122] S62: Obtain the predicted number of logins for the next round of testing based on the curve graph;
[0123] S63: Based on the total time of the i-th round of testing, the current number of concurrent users on the tested end, the request failure rate, the throughput, and the predicted number of logins, obtain the new number of logins;
[0124] S64: Update the starting value of the login ID based on the new number of logins;
[0125] S65: Update test commands based on the new number of logins and the new starting value of the ID.
[0126] In S61, test information is obtained, including the total time of the i-th test round, the current number of concurrent users on the tested end, the request failure rate, and the throughput. The current number of concurrent users on the tested end refers to the number of concurrent users monitored on the tested end after the end of this test round; the request failure rate is equal to the ratio between the total number of failed requests in each test round and the total number of logins in each test round; and the throughput refers to the number of requests successfully processed by the tested end per unit time.
[0127] In S62, mathematical methods such as multinomial regression or logistic regression are used to obtain the predicted number of logins for the next round of testing based on a curve graph.
[0128] In S63, the formula for calculating the new number of logins is as follows:
[0129] C i+1 =(Y c - y1)×T i ×(1-S i ) / L;
[0130] In the formula, C i+1 Y represents the new number of logins. c To predict the number of logins; T i S represents the total time of the i-th round of testing; i Let L be the cumulative request failure rate at the end of the i-th round of testing. The request failure rate will be continuously updated as the test iterations proceed; L is the throughput.
[0131] In S64, the new starting value for numbering is k0. i+1 = k0 i + C i .
[0132] In S65, the original login count and the original starting number of the ID are replaced by the new login count and the new starting number of the ID, respectively, to update the test command, execute the new test command, i=i+1, and initiate a new round of testing.
[0133] By using the above approach, the number of requests initiated in the next test can be adjusted based on the test details, minimizing the number of test iterations, saving test server resources, and ensuring high test efficiency.
[0134] In another specific implementation, the test information includes CPU utilization, memory utilization, and concurrent user login rate on the test server. The concurrent user login rate is calculated based on the number of logged-in users (login_users) and the test execution time. When all three conditions are met—CPU utilization and memory utilization exceeding a preset utilization threshold (e.g., 80%), and the concurrent user login rate falling below a preset rate threshold—C... i+1= C i -R, where R is a preset integer, for example, R=20; when any of the above three conditions is not met, C i+1 = C i .
[0135] This solution takes into account the device capacity of the testing end, ensuring that it does not put too much pressure on the resources of the testing end while issuing more authentication login requests and reducing testing time.
[0136] In each round of testing, multiple processes are pre-started and wait for the device information entity to complete its preparation before immediately sending authentication login requests. To reduce the load on the testing end and conserve process resources, all processes are shut down after each round of testing is completed. If a next round of testing is needed, the processes will be restarted. Alternatively, if the number of new logins is less than a preset threshold, a shutdown ratio is determined based on the number of new logins and the preset threshold, and a corresponding number of processes are shut down accordingly. This process helps optimize resource usage and ensures the efficiency of the testing process. The shutdown ratio refers to the number of processes that need to be shut down, and the formula for calculating the shutdown ratio is as follows:
[0137] G = (g - C) i+1 ) / g
[0138] In the formula, G is the closing ratio; g is the preset number threshold.
[0139] This disclosure also provides a specific example:
[0140] Navigate to the directory containing the testing tool via the command-line interface (cmd), and then enter the test command `TestClient.exe 10.7.107.174 pjh 100 10 50`. Press Enter to execute the command. This command will start a background process, using 100 users with usernames from pjh50 to pjh149 to concurrently log in to the SDP controller at IP address 10.7.107.174. After this round of testing is completed, the testing tool will decide whether to continue to the next round or stop the test based on the test information. If a specific trigger condition is met, the testing tool will continue to execute the command `TestClient.exe 10.7.107.174 pjh 80 10 150` for the next round of testing, this time updating the login count to 150. This process will repeat until the conditions for stopping the test are met. Finally, check the output of the testing tool to obtain the maximum number of concurrent users supported by the SDP system.
[0141] In summary, this solution automatically generates complete login information using a test tool that simulates multiple user clients. It can efficiently and automatically test the multi-user concurrent login performance of zero-trust SDP clients, avoiding the cumbersome operation, troublesome device information acquisition, and limitations of single-user login in traditional methods. It significantly saves testing time, improves testing efficiency, and can accurately evaluate the user login concurrency performance of zero-trust systems.
[0142] Reference Figure 6 This disclosure provides a simulated multi-user login testing system, including:
[0143] Command building module 101 is used to build test commands on the test side and configure the test command with the test terminal identifier, username prefix, number starting value and number of logins;
[0144] Command execution module 102 is used to initiate the i-th round of testing by executing test commands, where the initial value of i is 1;
[0145] The request simulation module 103 is used to simulate the user's authentication login request based on the username prefix, the starting value of the number and the number of logins in the i-th round of testing, and to send the authentication login request to the tested end based on the tested end identifier.
[0146] The status monitoring module 104 is used to monitor in real time whether the number of concurrent users on the tested end is increasing; if not, the capacity acquisition module is executed; if so, the command update module is executed.
[0147] The capacity acquisition module 105 is used to obtain the maximum number of concurrent users and use it as the concurrent authentication login capacity of the tested terminal, and then the test ends.
[0148] Command update module 106 is used to obtain test information, update test commands based on test information, and execute new test commands, i=i+1.
[0149] The various variations and specific examples of the simulated multi-user login test method provided above are also applicable to the simulated multi-user login test system provided in this disclosure. Through the foregoing detailed description of the simulated multi-user login test method, those skilled in the art can clearly understand the implementation method of the simulated multi-user login test system. For the sake of brevity, they will not be described in detail here.
[0150] A computer device according to embodiments of the present disclosure includes a memory and a processor. The memory is used to store non-transitory computer-readable instructions. Specifically, the memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, flash memory, etc.
[0151] The processor may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the computer device to perform desired functions. In one embodiment of this disclosure, the processor is used to execute computer-readable instructions stored in the memory, causing the computer device to perform all or part of the steps of the simulated multi-user login test method described in the foregoing embodiments of this disclosure.
[0152] Those skilled in the art will understand that, in order to solve the technical problem of how to achieve a good user experience, this embodiment may also include well-known structures such as communication buses and interfaces, and these well-known structures should also be included within the protection scope of this disclosure.
[0153] like Figure 7 This is a schematic diagram of a computer device provided for an embodiment of the present disclosure. It illustrates a structural schematic diagram suitable for implementing the computer device in the embodiments of the present disclosure. Figure 7 The computer device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.
[0154] like Figure 7 As shown, a computer device may include a processor (such as a central processing unit, graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) or programs loaded from storage devices into random access memory (RAM). The RAM also stores various programs and data required for the operation of the computer device. The processor, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.
[0155] Typically, the following devices can be connected to the I / O interface: input devices, such as sensors or visual information acquisition devices; output devices, such as displays; storage devices, such as magnetic tapes or hard drives; and communication devices. Communication devices allow the computer device to communicate wirelessly or wiredly with other devices (such as edge computing devices) to exchange data. Although Figure 7A computer apparatus with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or included alternatively.
[0156] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processor, all or part of the steps of the simulated multi-user login testing method of embodiments of this disclosure are performed.
[0157] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.
[0158] A computer-readable storage medium according to embodiments of the present disclosure stores non-transitory computer-readable instructions. When these non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the simulated multi-user login test methods described in the foregoing embodiments of the present disclosure are performed.
[0159] The aforementioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or portable hard drive), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).
[0160] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.
[0161] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.
[0162] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.
[0163] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.
[0164] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.
[0165] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.
[0166] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.
[0167] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.
Claims
1. A method for simulating multi-user login testing, characterized in that, include: On the test side, construct a test command and configure the test command with the test terminal identifier, username prefix, number start value and number of logins; The i-th round of testing is initiated by executing the test command, where the initial value of i is 1; In the i-th round of testing, the authentication login request of the user is simulated based on the username prefix, the starting value of the number and the number of logins, and the authentication login request is sent to the tested terminal based on the tested terminal identifier; Real-time monitoring of whether the number of concurrent users on the tested end is increasing; If not, obtain the maximum number of concurrent users and use it as the concurrent authentication login capacity of the tested terminal, then end the test; If so, obtain the test information, update the test command based on the test information, and execute the new test command, i=i+1; The method further includes: Determine whether the device under test is being used for the first time; If so, obtain the device type of the tested terminal, and collect the concurrent authentication login capacity of multiple devices of the same type based on the device type; The average value of the concurrent authentication login capacity of multiple devices of the same type is used as the initial value of the number of logins; If not, obtain the number of CPU cores of the tested terminal, as well as the average utilization of each CPU core and the average time for request processing in historical login operations. The initial value of the number of logins is obtained based on the number of CPU cores, the average utilization rate, and the average time.
2. The method for simulating multi-user login testing according to claim 1, characterized in that, The simulated user authentication login request based on the username prefix, the starting value of the number, and the number of logins includes: Based on the aforementioned starting number value, the current number K is generated, K=k0. i + k, k0 i Let k be the starting value of the number in the i-th round of testing, and k is initially 0. Combine the username prefix and the current number to form the current username; Generate the current IP address and current MAC address based on the starting values of the IP address and MAC address; Get current system information; Based on the current username, the current IP address, the current MAC address, and the current system information, simulate the user's authentication login request, k=k+1; When the result of k-1 is less than the number of logins, a new authentication login request is simulated.
3. The simulated multi-user login testing method according to claim 1, characterized in that, The real-time monitoring of whether the number of concurrent users on the tested end is increasing includes: Real-time acquisition of the number of concurrent users and sampling time on the tested device; A graph is constructed based on the real-time acquired number of concurrent users and sampling time; Obtain the instantaneous slope of the curve; If the instantaneous slope is positive, then the number of concurrent users on the tested end is determined to be in an increasing state. If the instantaneous slope is not positive, then the number of concurrent users on the tested end is determined to be constant.
4. The simulated multi-user login testing method according to claim 3, characterized in that, The test information includes the total time of the i-th round of testing, the current number of concurrent users on the tested end, the request failure rate, and the throughput; The predicted number of logins for the next round of testing is obtained based on the curve. Based on the total time of the i-th round of testing, the current number of concurrent users on the tested end, the request failure rate, the throughput, and the predicted number of logins, obtain the new number of logins; Update the starting value of the login ID based on the new number of logins; Update the test command based on the new number of logins and the new starting value of the ID.
5. A computer device, characterized in that, The computer device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the simulated multi-user login test method according to any one of claims 1-4.
6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the simulated multi-user login test method as described in any one of claims 1-4.
7. A computer program product comprising computer instructions, characterized in that, When executed by a processor, the computer instructions implement the steps of the method according to any one of claims 1-4.