Test method, device and equipment for electric vehicle battery replacement software and medium

Abstract

The embodiment of the invention discloses a testing method, device and equipment for electric vehicle battery replacement software and a medium. The testing method comprises the steps that all service scenes of the electric vehicle battery replacement software are determined, and testing performance targets of all the service scenes before the electric vehicle battery replacement software is online are determined; determining the number of test concurrent users of each service scene according to pre-acquired service data of each service scene; in a preset test platform, according to each business scene, a test target of each business scene and a test concurrent user number of each business scene, compiling a pressure test script, operating the pressure test script, and collecting test performance data of each business scene of the electric vehicle battery replacement software; and when the test performance data of each business scene of the electric vehicle battery replacement software accords with the corresponding test performance target, completing the test of the electric vehicle battery replacement software. According to the embodiment of the invention, stable on-line of the system is ensured by collecting and analyzing the test performance data, and beneficial effects can be provided for stable operation and good user experience of electric vehicle battery replacement software.

Description

[0001] This application claims priority based on the invention patent application filed with the China National Patent Office on December 29, 2023, with the application number 202311867333.X and the invention title "A Testing Method, Device, Equipment and Medium for an Electric Vehicle Battery Swapping Software". The entire text of the above-mentioned Chinese patent application is incorporated herein by reference. Technical Field

[0002] This specification relates to the technical field of new energy electric vehicle battery swapping, and particularly to a testing method, device, equipment and medium for an electric vehicle battery swapping software. Background Art

[0003] During the APP development process, testing is a crucial step. Currently, most APP testing mainly focuses on functional testing and compatibility testing, lacking stress testing for the core business scenarios of the system. Traditional stress testing methods mainly rely on manual simulation of user behavior and cannot accurately simulate the behavior and concurrency of real users. In addition, due to the limitations of manual testing, large-scale concurrent testing cannot be achieved, so the stability of the system in high-concurrency scenarios cannot be fully understood.

[0004] Currently in APP testing, due to the lack of applicable stress testing tools and methods, it is impossible to accurately estimate the performance of the system in high-concurrency situations. Conducting stress testing on the core business scenarios of the system before going live can effectively identify the performance bottlenecks and risk factors of the system, providing a basis for the stable launch of the system. Summary of the Invention

[0005] One or more embodiments of this specification provide a testing method, device, equipment and medium for an electric vehicle battery swapping software to solve the technical problems raised in the background art.

[0006] One or more embodiments of this specification adopt the following technical solutions:

[0007] A testing method for an electric vehicle battery swapping software provided by one or more embodiments of this specification includes:

[0008] Determine each business scenario of the electric vehicle battery swapping software and determine the test performance objectives of each business scenario before the electric vehicle battery swapping software goes live;

[0009] Determine the test concurrent user numbers of each business scenario according to the business data of each business scenario obtained in advance;

[0010] In a pre-set test platform, according to each business scenario, the test objectives of each business scenario and the test concurrent user numbers of each business scenario, write a stress test script and run the stress test script to collect the test performance data of each business scenario of the electric vehicle battery swapping software;

[0011] When the test performance data of each business scenario of the tram battery swapping software meet the corresponding test performance objectives, the test of the tram battery swapping software is completed.

[0012] By determining each business scenario of the tram battery swapping software and the test performance objectives before going live, the embodiments of this specification can clarify the performance requirements of the system under high concurrency, which can provide an accurate basis for the stable launch of the system and avoid problems of insufficient performance or over-optimization caused by the lack of objectives.

[0013] Moreover, by writing stress test scripts and running stress tests, the embodiments of this specification can simulate real high-concurrency scenarios, thereby effectively discovering the performance bottlenecks and potential risk factors of the system under high concurrency. This helps to identify and solve performance problems early, and plan and optimize the stability and scalability of the system in advance;

[0014] At the same time, by running stress test scripts, the embodiments of this specification can collect the test performance data of each business scenario of the tram battery swapping software, which can provide a detailed understanding of the performance of the system under high-concurrency load and provide data support for subsequent performance optimization and adjustment.

[0015] In addition, by confirming the stability and performance of the system according to the compliance of the test performance data and objectives, the embodiments of this specification help to ensure that the tram battery swapping software can operate normally in the face of high-concurrency load and has sufficient performance reserves, ensuring a good user experience and the availability of the system.

[0016] Furthermore, the test performance objectives include the test concurrent user number and the test performance metrics;

[0017] When the test performance data of each business scenario of the tram battery swapping software meet the corresponding test performance objectives, the completion of the test of the tram battery swapping software specifically includes:

[0018] Based on the test performance data of each business scenario of the tram battery swapping software, determine whether the test concurrent user number in each business scenario meets the corresponding test performance metrics to obtain a test result;

[0019] And / or, based on the test performance data of each business scenario of the tram battery swapping software, determine the upper limit concurrent user number that meets the corresponding test performance metrics in each business scenario.

[0020] It should be noted that the embodiments of this specification can accurately identify the performance bottlenecks and potential risk factors of the tram battery swapping software in high-concurrency scenarios, so as to perform necessary optimizations and adjustments before the software is officially launched. Conducting a comprehensive stress test before launch can ensure the stability of the system in a real high-concurrency environment and reduce failures and user complaints caused by system instability.

[0021] At the same time, the embodiments of this specification determine the test concurrent user number and test performance indicators, providing clear goals and standards for the test work, which helps the scientific management and evaluation of the test process.

[0022] Moreover, the embodiments of this specification determine whether the test concurrent user number in each business scenario meets the performance indicators based on the test data, which helps to make decisions based on data and ensure that the performance of the software in actual use meets expectations.

[0023] In addition, by determining the upper limit of the concurrent user number that meets the test performance indicators, the embodiments of this specification can help developers reasonably allocate resources, such as server configuration, network bandwidth, etc., to support a higher user access volume.

[0024] Furthermore, the method further includes:

[0025] Based on the test objectives of the business scenario and the test concurrent user number, determine the initial concurrent user number and initial operation data corresponding to the initial test stage, where the initial operation data includes at least one of operation duration, operation interval, loop interval, concurrent interval, user loading and decompression time.

[0026] It should be noted that determining the initial concurrent user number in the embodiments of this specification helps to set a reasonable test scale at the initial stage of the test, ensuring that the test can effectively cover the main business scenarios and avoiding waste of resources caused by over-testing.

[0027] At the same time, the initial operation data in the embodiments of this specification, such as operation duration, operation interval, loop interval, concurrent interval, etc., provides a benchmark for performance evaluation. These data help to compare performance changes in different scenarios during subsequent tests. Through the initial operation data, the configuration of test resources, such as server performance, network bandwidth, etc., can be optimized to ensure that it will not become a performance bottleneck during the test process.

[0028] Moreover, collecting operation data at the initial stage of the test in the embodiments of this specification helps to quickly locate the source of performance problems when they occur, because anomalies can be discovered based on the comparison of the initial data and the current data.

[0029] Moreover, the initial running data defined in the embodiments of this specification helps improve the testing efficiency because it allows the testing team to focus on key performance indicators during the testing process rather than conducting aimless extensive testing.

[0030] Moreover, by simulating the running data under different numbers of concurrent users, the embodiments of this specification can more realistically simulate the actual user usage scenarios, thereby evaluating the user experience of the software in actual use.

[0031] In addition, the initial running data of the embodiments of this specification can help predict potential risks of the system under high concurrency, such as system crashes, data loss, etc., so as to take preventive measures in advance.

[0032] Further, the method further includes:

[0033] Obtain a first test result, a first number of concurrent users, and first running data corresponding to the current test stage, where the current test stage includes an initial test stage and any test stage after the initial test stage;

[0034] When it is determined that the first test result meets the test objective, based on the first test result, the first number of concurrent users, the first running data, the test objective, and the test number of concurrent users, determine a second number of concurrent users and second running data corresponding to the next test stage.

[0035] It should be noted that by comparing the results of the first test stage, the embodiments of this specification can identify the performance bottlenecks and problems of the system under high concurrency, so as to optimize them specifically in the subsequent test stages. The first test result provides a basis for performance prediction for the subsequent tests, enabling the testing team to adjust the number of concurrent users according to the actual situation to more accurately simulate the real-world usage.

[0036] At the same time, based on the first running data, the embodiments of this specification can allocate test resources, such as servers, network bandwidth, etc., more reasonably to ensure the accuracy and efficiency of the tests. By analyzing the first test result, it is possible to avoid repeating the problems that have been discovered and solved in the previous stage in the subsequent test stages, thereby improving the testing efficiency.

[0037] Moreover, the problems discovered in the first test stage of the embodiments of this specification can be solved before the second test stage, thereby reducing the possibility of serious risks occurring in the higher concurrency test stages. If the first test result does not meet the expectations, the improvement direction can be clarified, such as optimizing database queries, increasing caches, adjusting server configurations, etc.

[0038] Moreover, by gradually increasing the number of concurrent users in the embodiments of this specification, the performance of the system under different loads can be more accurately evaluated, thereby conducting a cost-benefit analysis within a limited test budget. Determining the second number of concurrent users and the second running data is based on the premise of meeting the test objectives, which helps ensure the validity of the test results and verify whether the expected performance metrics are achieved.

[0039] In addition, by recording and updating the test results and running data in the embodiments of this specification, the test process can be made more transparent, facilitating communication and collaboration among team members. This test method helps to implement automated performance testing in the continuous integration and deployment process, ensuring effective performance feedback after each code submission or build.

[0040] Furthermore, the method further includes:

[0041] Execute the parallel test task for multiple business scenarios based on the number of concurrent users and running data corresponding to each business scenario in the same test stage, and obtain the test results for multiple business scenarios corresponding to each business scenario in the same test stage;

[0042] Based on the test results for multiple business scenarios, determine whether the test number of concurrent users for each business scenario meets the corresponding test performance metrics, and obtain the first test result;

[0043] Based on the test results for multiple business scenarios, determine the first upper limit number of concurrent users that meets the corresponding test performance metrics for each business scenario.

[0044] It should be noted that by parallel testing multiple business scenarios in the embodiments of this specification, the overall performance of the system during multi-task concurrent processing can be comprehensively evaluated, rather than evaluating a single scenario alone. And the number of concurrent users and performance metrics of each business scenario can be understood, which helps to optimize system resource allocation and ensure that critical business scenarios can also maintain good performance under high concurrency.

[0045] At the same time, in the parallel test of multiple business scenarios, in the embodiments of this specification, it is easier to identify system performance bottlenecks because resource competition and performance issues are more obvious when multiple scenarios are running simultaneously.

[0046] Moreover, the embodiments of this specification ensure that all business scenarios can meet the corresponding test performance metrics, which helps to ensure the consistency of the user experience when using different functions.

[0047] In addition, by determining the first upper limit number of concurrent users for each business scenario in the embodiments of this specification, the risks of the system under high concurrency can be pre-evaluated, and measures can be taken to prevent system crashes or service quality degradation.

[0048] Furthermore, the method further includes:

[0049] For each business scenario separately, based on the number of concurrent users and operation data corresponding to the business scenario during the test phase, perform a single business scenario test task to obtain the single business scenario test result corresponding to the business scenario;

[0050] Based on the single business scenario test results, determine whether the test concurrent user numbers in each business scenario meet the corresponding test performance indicators to obtain a first test result;

[0051] Based on the single business scenario test results, determine the first upper limit concurrent user numbers that meet the corresponding test performance indicators in each business scenario.

[0052] It should be noted that separately testing each business scenario in the embodiments of this specification can more precisely evaluate the performance of each function and avoid possible mutual interference in multi-scenario parallel testing. In separate testing, if there are performance problems, they can be quickly located to the specific business scenario, which is convenient for targeted debugging and optimization.

[0053] At the same time, by determining whether the test concurrent user numbers of each business scenario meet the performance indicators in the embodiments of this specification, it can be verified whether each business scenario meets the established performance standards.

[0054] Moreover, separate testing helps to identify the resource usage of each business scenario, so as to optimize the system resource configuration and ensure that key business scenarios are given priority in resource allocation.

[0055] And ensuring that each business scenario can meet the performance indicators under high concurrency helps to ensure the experience consistency of users when using different functions.

[0056] And separate testing can simplify the test process and improve the test efficiency, especially in the case of limited test resources.

[0057] In addition, separate testing can more clearly analyze the performance bottlenecks of each business scenario and provide specific directions for subsequent performance optimization work.

[0058] Furthermore, the business scenarios in the embodiments of this specification include at least one of the following: charging and swapping station scenario, accessing payment page scenario, personal information scenario, order list scenario, online refund scenario, shift handover scenario, and emergency charging scenario.

[0059] It should be noted that by conducting stress tests on the above-mentioned core business scenarios of the system in the embodiments of this specification, the performance of the system under high concurrency can be evaluated, thereby providing a basis for the stable online launch of the system. By analyzing the stress test results of the above-mentioned business scenarios, the load capacity and response time of the system in different scenarios can be determined, and then the system architecture and performance can be optimized to ensure the stable operation of the system after it is launched.

[0060] Meanwhile, by conducting stress tests on the above-mentioned business scenarios of the system in the embodiments of this specification, high concurrency situations can be simulated, thereby discovering possible performance bottlenecks that may occur when the system processes a large number of concurrent requests. For example, by simulating the scenario where a large number of users access the payment page simultaneously, it can be detected whether the system will experience performance degradation or crashes when processing a large number of payment requests.

[0061] Furthermore, the number of concurrent test users in the swapping station scenario in the embodiments of this specification includes at least one of the following:

[0062] The number of concurrent test users in the swapping station scenario is the number of users who simulate multiple users performing operations such as checking stations, viewing battery and queuing information, and navigation functions simultaneously;

[0063] The number of concurrent test users in the access payment page scenario is the number of users who simulate multiple users performing the payment operation process simultaneously;

[0064] The number of concurrent test users in the personal information scenario is the number of users who simulate multiple users accessing personal information or the settings page simultaneously;

[0065] The number of concurrent test users in the order list scenario is the number of users who simulate multiple users accessing the order list page and viewing recharge and consumption orders simultaneously;

[0066] The number of concurrent test users in the online refund scenario is the number of users who simulate multiple users performing online refund operations simultaneously;

[0067] The number of concurrent test users in the shift handover scenario is the number of users who simulate multiple users performing shift handover operations simultaneously;

[0068] The number of concurrent test users in the emergency charging scenario is the number of users who simulate multiple users performing emergency charging operations simultaneously.

[0069] It should be noted that by simulating the simultaneous functional operations of users in each scenario in the embodiments of this specification, the performance of the system when processing multiple users' simultaneous operations can be verified, thereby discovering possible performance bottlenecks.

[0070] Meanwhile, through stress testing of each business scenario in the embodiments of this specification, various abnormal situations and malicious attacks can be simulated, thereby discovering risk factors in the system. For example, in the shift handover scenario, by simulating multiple users performing shift handover operations simultaneously, it is possible to detect whether there are abnormal situations such as login conflicts or permission errors when the system processes multiple concurrent requests.

[0071] In addition, by analyzing the stress test results of each business scenario in the embodiments of this specification, the load capacity and response time of the system can be evaluated, providing a basis for the stable online launch of the system. For example, in the scenario of accessing the payment page, by simulating multiple users performing the payment operation process simultaneously, the performance of the system when processing multiple payment requests can be tested to determine whether the system can stably handle high-concurrency payment requests.

[0072] Furthermore, the stress test script in the embodiments of this specification is used to simulate the actual operations of the tram battery swapping software, including online data concurrency scenarios and driver user behavior concurrency scenarios.

[0073] It should be noted that by simulating the online data concurrency scenario through the stress test script in the embodiments of this specification, multiple users can be simulated to perform operations simultaneously, such as querying battery swapping stations, viewing battery and queuing information, etc., thereby evaluating the performance of the system under high concurrency. This can help discover potential performance bottlenecks when the system processes a large number of actual operations, such as performance issues in database queries, network transmissions, etc.

[0074] Meanwhile, by simulating the driver user behavior concurrency scenario through the stress test script in the embodiments of this specification, multiple driver users can be simulated to perform operations simultaneously, such as emergency charging and online refunds, etc., to evaluate the performance of the system under high concurrency. This can help discover potential performance issues when the system processes a large number of concurrent operations, such as performance bottlenecks in concurrent request processing, resource allocation, etc.

[0075] In summary, by performing stress testing on these two scenarios in the embodiments of this specification, the performance of the system under high concurrency can be more comprehensively evaluated, and potential performance bottlenecks and risk factors can also be discovered. This provides a basis for the stable online launch of the system, and corresponding optimizations and improvements can be made.

[0076] Furthermore, the test concurrent user numbers in the embodiments of this specification include the average online data concurrent user number and the peak online data concurrent user number in the online data concurrency scenario, as well as the average driver user behavior concurrent user number and the peak driver user behavior concurrent user number in the driver user behavior concurrency scenario.

[0077] It should be noted that by determining the average number of concurrent online data users and the peak number of concurrent online data users in the online data concurrency scenario, as well as the average number of concurrent driver user behavior users and the peak number of concurrent driver user behavior users in the driver user behavior concurrency scenario in the embodiments of this specification, the load capacity of the system under high concurrency can be evaluated, which helps to determine the maximum number of concurrent requests that the system can handle and the performance of the system under different load conditions.

[0078] At the same time, by determining the average number of concurrent users and the peak number of concurrent users in different scenarios in the embodiments of this specification, the load of the system under high concurrency can be simulated. This helps to discover possible performance bottlenecks when the system processes a large number of concurrent requests. By analyzing the results of the stress test, it can be determined whether there are performance problems in the system under high load, such as extended response time, system crashes, etc.

[0079] In addition, by simulating the concurrent user operations in different scenarios in the embodiments of this specification, the risk factors of the system can be discovered. For example, in the online data concurrency scenario, by simulating multiple users performing operations such as checking the replacement station, viewing the battery, and queuing information simultaneously, it can be discovered whether there are risk factors such as data consistency problems and resource competition when the system processes multiple concurrent requests.

[0080] In summary, by conducting stress tests on the core business scenarios of the system and determining the average number of concurrent users and the peak number of concurrent users in different scenarios in the embodiments of this specification, the load capacity of the system can be evaluated, performance bottlenecks and risk factors can be discovered, providing a basis for the stable online launch of the system, and corresponding optimizations and adjustments can be made.

[0081] Furthermore, the determination of the test performance objectives for each business scenario before the launch of the electric vehicle battery replacement software in the embodiments of this specification includes:

[0082] Continuously increase the number of concurrent processing transactions for each business scenario of the electric vehicle battery replacement software to obtain performance indicators for different numbers of concurrent processing transactions;

[0083] According to the performance indicators for different numbers of concurrent processing transactions, determine the test performance objectives for each business scenario before the launch of the electric vehicle battery replacement software.

[0084] It should be noted that by continuously increasing the number of concurrent processing transactions for each business scenario and according to the obtained performance indicators for different numbers of concurrent processing transactions in the embodiments of this specification, the test performance objectives for each business scenario before the launch of the electric vehicle battery replacement software can be determined. This helps to clarify the performance requirements of the system under different loads and serves as the basis and guidance for testing.

[0085] Meanwhile, in the embodiments of this specification, by continuously increasing the number of concurrently processed transactions and monitoring the performance metrics of the system, the load capacity of the system can be evaluated. By determining the performance of the system under different numbers of concurrently processed transactions, the maximum number of concurrent requests that the system can handle can be determined, thereby providing a basis for the load planning and design of the system.

[0086] In addition, in the embodiments of this specification, by continuously increasing the number of concurrently processed transactions and monitoring the performance metrics of the system, performance bottlenecks that may occur under different loads of the system can be discovered. By analyzing the test results, the performance of the system under different numbers of concurrently processed transactions can be determined, and possible performance bottlenecks can be found, such as extended response time and insufficient system resources.

[0087] In summary, by determining the test performance goals for each business scenario, continuously increasing the number of concurrently processed transactions, and monitoring the performance metrics of the system, the load capacity of the system can be evaluated, performance bottlenecks can be discovered, a basis for the stable online launch of the system can be provided, and corresponding optimizations and adjustments can be made.

[0088] Furthermore, the test performance goals in the embodiments of this specification include at least one test performance metric, and the test performance metric includes one or more of the number of transactions processed per second (TPS), the number of query requests per second (QPS), the error rate, CPU, and memory occupancy rate.

[0089] It should be noted that in the embodiments of this specification, by monitoring the number of transactions processed per second (TPS) and the number of query requests per second (QPS), the processing capacity of the system under high concurrency can be evaluated. These performance metrics can help determine the number of transactions and requests that the system can handle, thereby evaluating the performance of the system under actual usage conditions.

[0090] Meanwhile, in the embodiments of this specification, by monitoring the error rate, the stability of the system under high concurrency can be evaluated. A high error rate may indicate problems such as performance bottlenecks, insufficient resources, or program errors in the system, which need to be repaired and optimized in a timely manner.

[0091] In addition, in the embodiments of this specification, by monitoring the occupancy rates of CPU and memory, the resource consumption of the system under high concurrency can be evaluated. High CPU and memory occupancy rates may indicate problems such as insufficient resources and memory leaks in the system, which require performance optimization and resource management.

[0092] In summary, in the embodiments of this specification, by monitoring and analyzing these test performance metrics, performance bottlenecks and risk factors of the system can be discovered, a basis for the stable online launch of the system can be provided, and corresponding optimizations and adjustments can be made. At the same time, these performance metrics can also be used to formulate performance test plans and evaluate test results to ensure that the performance of the system under high concurrency meets expectations.

[0093] A test device for an electric vehicle battery swapping software provided by one or more embodiments of this specification, the device includes:

[0094] A scenario performance determination unit, which determines each service scenario of the electric vehicle battery swapping software and determines the test performance targets of each service scenario before the electric vehicle battery swapping software goes online;

[0095] A concurrency number determination unit, which determines the test concurrent user numbers of each service scenario according to the service data of each service scenario obtained in advance;

[0096] A test unit, in a pre-set test platform, writes a stress test script according to each service scenario, the test target of each service scenario and the test concurrent user numbers of each service scenario, runs the stress test script, and collects the test performance data of each service scenario of the electric vehicle battery swapping software;

[0097] A test determination unit, when the test performance data of each service scenario of the electric vehicle battery swapping software meets the corresponding test performance targets, completes the test of the electric vehicle battery swapping software.

[0098] A test device for an electric vehicle battery swapping software provided by one or more embodiments of this specification, includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and when the instructions are executed by the at least one processor, the at least one processor is enabled to: determine each service scenario of the electric vehicle battery swapping software and determine the test performance targets of each service scenario before the electric vehicle battery swapping software goes online; determine the test concurrent user numbers of each service scenario according to the service data of each service scenario obtained in advance; in a pre-set test platform, write a stress test script according to each service scenario, the test target of each service scenario and the test concurrent user numbers of each service scenario, run the stress test script, and collect the test performance data of each service scenario of the electric vehicle battery swapping software; when the test performance data of each service scenario of the electric vehicle battery swapping software meets the corresponding test performance targets, complete the test of the electric vehicle battery swapping software.

[0099] A non - volatile computer storage medium provided by one or more embodiments of this specification stores computer - executable instructions. When the computer - executable instructions are executed by a computer, they can achieve the following: determining each business scenario of the tram battery - swapping software, and determining the test performance goals of each business scenario before the tram battery - swapping software goes online; determining the test concurrent user numbers of each business scenario according to the business data of each business scenario obtained in advance; in a pre - set test platform, writing a stress - test script according to each business scenario, the test goals of each business scenario, and the test concurrent user numbers of each business scenario, and running the stress - test script to collect the test performance data of each business scenario of the tram battery - swapping software; when the test performance data of each business scenario of the tram battery - swapping software meets the corresponding test performance goals, completing the test of the tram battery - swapping software.

[0100] The above - mentioned at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0101] By determining each business scenario of the tram battery - swapping software and the test performance goals before going online, the embodiments of this specification can clarify the performance requirements of the system under high concurrency, which can provide an accurate basis for the stable online of the system and avoid problems such as insufficient performance or over - optimization caused by the lack of goals.

[0102] Moreover, by writing a stress - test script and running the stress - test, the embodiments of this specification can simulate real high - concurrency scenarios, thereby effectively discovering the performance bottlenecks and potential risk factors of the system under high concurrency. This helps to identify and solve performance problems early, and plan and optimize the stability and scalability of the system in advance;

[0103] At the same time, by running the stress - test script, the embodiments of this specification can collect the test performance data of each business scenario of the tram battery - swapping software, which can provide a detailed understanding of the performance of the system under high - concurrency load and provide data support for subsequent performance optimization and adjustment.

[0104] In addition, by confirming the stability and performance of the system according to the compliance of the test performance data and the goals, the embodiments of this specification help to ensure that the tram battery - swapping software can operate normally in the face of high - concurrency load, and has sufficient performance reserve to ensure a good user experience and the availability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0105] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings. In the drawings:

[0106] Figure 1 It is a schematic flowchart of a test method for an electric vehicle battery swapping software provided by one or more embodiments of this specification;

[0107] Figure 2 It is a schematic structural diagram of a test device for an electric vehicle battery swapping software provided by one or more embodiments of this specification;

[0108] Figure 3 It is a schematic structural diagram of a test device for an electric vehicle battery swapping software provided by one or more embodiments of this specification. Detailed implementation manners

[0109] The embodiments of this specification provide a test method, device, equipment and medium for an electric vehicle battery swapping software.

[0110] In order to enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only some embodiments of this specification, rather than all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

[0111] Figure 1 It is a schematic flowchart of a test method for an electric vehicle battery swapping software provided by one or more embodiments of this specification, and this process can be executed by a test system for the electric vehicle battery swapping software. Some input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

[0112] The method process steps of the embodiments of this specification are as follows:

[0113] S102. Determine each business scenario of the electric vehicle battery swapping software, and determine the test performance goals of each business scenario before the electric vehicle battery swapping software goes online.

[0114] In the embodiments of this specification, each business scenario includes a charging station query scenario, an access payment page scenario, a personal information scenario, an order list scenario, an online refund scenario, a shift handover scenario, and an emergency charging scenario.

[0115] It should be noted that by conducting stress tests on the above core business scenarios of the system, the embodiments of this specification can evaluate the performance of the system under high concurrency, thereby providing a basis for the stable online launch of the system. By analyzing the stress test results of the above business scenarios, the load capacity and response time of the system in different scenarios can be determined, and then the system architecture and performance can be optimized to ensure the stable operation of the system after it is launched.

[0116] At the same time, by conducting stress tests on the above business scenarios of the system, the embodiments of this specification can simulate high concurrency situations, thereby discovering potential performance bottlenecks that may occur when the system processes a large number of concurrent requests. For example, by simulating the scenario where a large number of users access the payment page simultaneously, it can be detected whether the system will experience performance degradation or crashes when processing a large number of payment requests.

[0117] The test performance objectives include at least one test performance metric, and the test performance metrics may include the number of transactions processed per second (TPS), the number of query requests per second (QPS), the error rate, CPU, and Memory occupancy rate.

[0118] It should be noted that by monitoring the number of transactions processed per second (TPS) and the number of query requests per second (QPS), the embodiments of this specification can evaluate the processing capacity of the system under high concurrency. These performance metrics can help determine the number of transactions and requests that the system can handle, thereby evaluating the performance of the system in actual usage scenarios.

[0119] At the same time, by monitoring the error rate, the embodiments of this specification can evaluate the stability of the system under high concurrency. A high error rate may indicate problems such as performance bottlenecks, insufficient resources, or program errors in the system, which need to be repaired and optimized in a timely manner.

[0120] In addition, by monitoring the occupancy rates of CPU and Memory, the embodiments of this specification can evaluate the resource consumption of the system under high concurrency. High CPU and Memory occupancy rates may indicate problems such as insufficient resources and memory leaks in the system, which require performance optimization and resource management.

[0121] In summary, by monitoring and analyzing these test performance metrics, the embodiments of this specification can discover the performance bottlenecks and risk factors of the system, provide a basis for the stable online launch of the system, and perform corresponding optimizations and adjustments. At the same time, these performance metrics can also be used to formulate performance test plans and evaluate test results to ensure that the performance of the system under high concurrency meets expectations.

[0122] For the above-mentioned determination of each business scenario of the electric vehicle battery swapping software and the determination of the test performance objectives of each business scenario before the launch of the electric vehicle battery swapping software, the specific implementation steps are as follows:

[0123] Determine each business scenario: According to the given scenario descriptions, clearly define each business scenario of the electric vehicle battery swapping software. For example: Check battery swapping stations, access payment pages, personal information, order lists, online refunds, shift handovers, and emergency charging.

[0124] Analyze the test performance goals for each business scenario: For each business scenario, determine the test performance goals.

[0125] Check battery swapping station scenario: In the check battery swapping station scenario, users can, according to their own needs, choose to query battery availability or view the queue situation at battery swapping stations. For this scenario, the following test performance goals can be determined:

[0126] TPS goal: Determine the number of transactions processed per second, that is, the number of requests to check battery swapping stations that can be processed per second. This includes requests for querying battery and queue information and requests for navigating to battery swapping stations.

[0127] QPS goal: Determine the number of query requests processed per second, that is, the number of requests to query information about battery swapping stations that can be processed per second.

[0128] Error rate goal: Determine the error rate threshold for interface requests, that is, the allowable error rate in operations related to checking battery swapping stations.

[0129] CPU and Memory occupancy rate goal: Determine the threshold of CPU and memory resources occupied by each operation related to checking battery swapping stations.

[0130] Access payment page scenario: In the access payment page scenario, when users select the function to access the payment page in the electric vehicle battery swapping software, the system will jump to the payment page interface, which may include the user's account information, balance information, and various recharge and payment options. For this scenario, the following test performance goals can be determined:

[0131] TPS goal: Determine the number of transactions processed per second, that is, the number of requests to access the payment page that can be processed per second. This includes requests for accessing the payment page and selecting packages.

[0132] QPS goal: Determine the number of query requests processed per second, that is, the number of requests to access the payment page that can be processed per second.

[0133] Error rate goal: Determine the error rate threshold for interface requests, that is, the allowable error rate in operations related to accessing the payment page.

[0134] CPU and Memory occupancy rate goal: Determine the threshold of CPU and memory resources occupied by each operation related to accessing the payment page.

[0135] Personal information scenario: In the personal information scenario, users can view and edit their personal information. For this scenario, the following test performance goals can be determined:

[0136] TPS target: Determine the number of transactions processed per second, i.e., the number of personal information query and edit operations that can be processed per second.

[0137] QPS target: Determine the number of query requests per second, i.e., the number of personal information query operations that can be processed per second.

[0138] Error rate target: Determine the error rate threshold for interface requests, i.e., the allowable error rate when querying and editing personal information.

[0139] CPU and Memory occupancy rate target: Determine the threshold of CPU and memory resources occupied by each query and edit operation.

[0140] Order list scenario: In the order list scenario, users can view the list of recharge and consumption orders. For this scenario, the following test performance targets can be determined:

[0141] TPS target: Determine the number of transactions processed per second, i.e., the number of order list query operations that can be processed per second.

[0142] QPS target: Determine the number of query requests per second, i.e., the number of order list query operations that can be processed per second.

[0143] Error rate target: Determine the error rate threshold for interface requests, i.e., the allowable error rate in order list query operations.

[0144] CPU and Memory occupancy rate target: Determine the threshold of CPU and memory resources occupied by each order list query operation.

[0145] Online refund scenario: In the online refund scenario, users can apply for a refund of an order. For this scenario, the following test performance targets can be determined:

[0146] TPS target: Determine the number of transactions processed per second, i.e., the number of refund application operations that can be processed per second.

[0147] QPS target: Determine the number of query requests per second, i.e., the number of refund application operations that can be processed per second.

[0148] Error rate target: Determine the error rate threshold for interface requests, i.e., the allowable error rate in refund application operations.

[0149] CPU and Memory occupancy rate target: Determine the threshold of CPU and memory resources occupied by each refund application operation.

[0150] Shift handover scenario: In the shift handover scenario, users can conduct work handover and data transfer between employees. To ensure the performance of this scenario, the following test performance objectives can be determined:

[0151] TPS objective: Determine the number of transactions processed per second, that is, the number of shift handover operations that can be processed per second.

[0152] QPS objective: Determine the number of query requests per second, that is, the number of shift handover operations that can be processed per second.

[0153] Error rate objective: Determine the error rate threshold for interface requests, that is, the allowable error rate in shift handover operations.

[0154] CPU and Memory occupancy rate objective: Determine the threshold of CPU and memory resources occupied by each shift handover operation.

[0155] Emergency power supply replenishment scenario: In the emergency power supply replenishment scenario, users can apply for emergency power supply replenishment services. To ensure the performance of this scenario, the following test performance objectives can be determined:

[0156] TPS objective: Determine the number of transactions processed per second, that is, the number of emergency power supply replenishment application operations that can be processed per second.

[0157] QPS objective: Determine the number of query requests per second, that is, the number of emergency power supply replenishment application operations that can be processed per second.

[0158] Error rate objective: Determine the error rate threshold for interface requests, that is, the allowable error rate in emergency power supply replenishment application operations.

[0159] CPU and Memory occupancy rate objective: Determine the threshold of CPU and memory resources occupied by each emergency power supply replenishment application operation.

[0160] It should be noted that the scenario of checking the swapping station can be the scenario of checking the swapping station - viewing the battery and queuing information of the swapping station - navigating to the swapping station, which specifically includes:

[0161] Checking the swapping station: The user opens the electric vehicle swapping software and enters the function of checking the swapping station. On the interface of checking the swapping station, the user can, according to their own needs, choose to query the battery availability or view the queuing situation of the swapping station.

[0162] Viewing the battery and queuing information of the swapping station: When the user selects to query the battery availability in the function of checking the swapping station, the system will display all the nearby swapping stations and show the available quantity of batteries in each swapping station. The user can choose a suitable swapping station according to information such as distance and battery quantity.

[0163] In addition, users can also choose to view the queuing situation at the battery swapping stations. The system will display the queuing situation of users in each current battery swapping station, including information such as the current number of people in the queue and the estimated queuing time.

[0164] Navigate to the battery swapping station: After the user selects a suitable battery swapping station, they can click the navigation button, and the system will call the navigation service to provide the user with a navigation route to guide the user to the selected battery swapping station.

[0165] It should be noted that the scenario of accessing the payment page can be the scenario of accessing the payment page - going to recharge - selecting a package - creating a payment order, which specifically includes:

[0166] Access the payment page: When the user selects the function of accessing the payment page in the electric vehicle battery swapping software, the system will jump to the payment page interface. The payment page usually contains the user's account information, balance information, and various recharge and payment options.

[0167] Go to recharge: The user selects the recharge function on the payment page and then selects the recharge amount or enters a custom recharge amount. After the user clicks to confirm, the system will perform the recharge operation and update the user's balance information.

[0168] Select a package: After the recharge is completed, the user can choose to purchase different packages. The packages usually contain information such as charging duration and charging fees. The user selects a suitable package according to their own needs.

[0169] Create a payment order: When the user selects a recharge package, the system will generate a corresponding payment order. The user needs to confirm the order information and choose which payment method to use for payment. After the user completes the payment, the system will complete the corresponding order processing, and the recharge amount will be added to the user's balance.

[0170] It should be noted that the personal information scenario can be the scenario of Mine - viewing personal information or settings, which specifically includes:

[0171] View personal information: The user can view their own personal information in the application, including name, age, gender, contact information, etc. This can help the user quickly understand their personal profile in the application and make necessary modifications or updates.

[0172] Set personal information: The user can set personal information in the application, such as changing the password, modifying notification settings, selecting preference settings, etc. In this way, the user can customize the functions and behaviors of the application according to their own needs and preferences.

[0173] View activity records: The application can record the user's activities, such as order history, browsing history, etc. The user can view these activity records in the personal information scenario to understand their behaviors and consumption situations in the application.

[0174] View account information: Users can view their own account information, such as account balance, points balance, membership level, etc. This can help users manage their accounts and understand their financial situation in the application.

[0175] Modify personal avatar: Users can choose to modify their personal avatars and upload or select appropriate avatar photos in the personal information scenario. This can enhance the user's personalized experience and make it easier for others to recognize the user in the application.

[0176] It should be noted that the order list scenario can be the scenario of entering the order list - viewing recharge and consumption orders, specifically including:

[0177] Enter the order list: Users can enter the order list page through entrances such as the navigation bar or sidebar. This scenario allows users to actively choose to view their order records and perform related operations through this page.

[0178] View recharge orders: On the order list page, users can view their recharge order records. These order records can include information such as recharge amount, recharge method, and recharge time. Users can understand their recharge situation and historical recharge records in the application by viewing recharge orders.

[0179] View consumption orders: On the order list page, users can view their consumption order records. These order records can include detailed information about the purchased goods or services, consumption amount, and consumption time. Users can understand their consumption situation and historical consumption records in the application by viewing consumption orders.

[0180] Perform order operations: On the order list page, users can perform some order-related operations, such as refund, cancel order, etc. Users can select specific orders and execute corresponding operations to meet their needs and requirements.

[0181] S104. Determine the test concurrent user numbers of each business scenario according to the business data of each pre-acquired business scenario.

[0182] In the embodiments of this specification, the test concurrent user numbers of the charging and swapping station scenario include at least one of the following:

[0183] The test concurrent user count for the charging and swapping station scenario is the number of users simulating multiple users simultaneously performing operations such as station checking, battery and queuing information viewing, and navigation function operations; the test concurrent user count for the access payment page scenario is the number of users simulating multiple users simultaneously performing the payment operation process; the test concurrent user count for the personal information scenario is the number of users simulating multiple users simultaneously accessing the personal information or settings page; the test concurrent user count for the order list scenario is the number of users simulating multiple users simultaneously accessing the order list page and viewing recharge and consumption orders; the test concurrent user count for the online refund scenario is the number of users simulating multiple users simultaneously performing online refund operations; the test concurrent user count for the shift handover scenario is the number of users simulating multiple users simultaneously performing shift handover operations; the test concurrent user count for the emergency charging scenario is the number of users simulating multiple users simultaneously performing emergency charging operations.

[0184] It should be noted that in the embodiments of this specification, the test concurrent user count for each business scenario is determined based on the pre-obtained business data of each business scenario. The number of concurrent users to be simulated for each business scenario is determined according to business requirements and system performance requirements.

[0185] For the charging and swapping station scenario, the number of concurrent users to be simulated can be determined first. Then, use a performance testing tool or an automated testing tool to create a script to simulate multiple users simultaneously performing operations such as station checking, battery and queuing information viewing, and navigation function operations. Execute and monitor these concurrent requests to evaluate the performance and stability of the system under high concurrency.

[0186] For the access payment page scenario, determine the number of concurrent users to be simulated according to the requirements. Then, use a performance testing tool or an automated testing tool to create a script to simulate multiple users simultaneously performing the payment operation process. Execute and monitor these concurrent requests to evaluate the payment performance and reliability of the system under high concurrency.

[0187] For the personal information scenario, after determining the number of concurrent users to be simulated, use a performance testing tool or an automated testing tool to create a script to simulate multiple users simultaneously accessing the personal information or settings page. Execute and monitor these concurrent requests to evaluate the performance and usability of the personal information function of the system under high concurrency.

[0188] For the order list scenario, determine the number of concurrent users to be simulated according to the requirements. Use a performance testing tool or an automated testing tool to create a script to simulate multiple users simultaneously accessing the order list page and viewing recharge and consumption orders. Execute and monitor these concurrent requests to evaluate the performance and accuracy of the order list function of the system under high concurrency.

[0189] For the online refund scenario, determine the number of concurrent users to be simulated according to the requirements. Use a performance testing tool or an automated testing tool to create a script to simulate multiple users performing online refund operations simultaneously. Execute and monitor these concurrent requests to evaluate the performance and reliability of the online refund function of the system under high concurrency.

[0190] For the shift handover scenario, after determining the number of concurrent users to be simulated, use a performance testing tool or an automated testing tool to create a script to simulate multiple users performing shift handover operations simultaneously. Execute and monitor these concurrent requests to evaluate the performance and feasibility of the shift handover function of the system under high concurrency.

[0191] For the emergency charging scenario, determine the number of concurrent users to be simulated according to the requirements. Use a performance testing tool or an automated testing tool to create a script to simulate multiple users performing emergency charging operations simultaneously. Execute and monitor these concurrent requests to evaluate the performance and reliability of the emergency charging function of the system under high concurrency.

[0192] Through the above steps, performance testing can be carried out on each business scenario by simulating multiple concurrent users to evaluate the concurrent processing ability, performance and reliability of the system. This can provide a reference basis for subsequent system optimization, capacity planning and performance tuning.

[0193] It should be noted that in the embodiments of this specification, by simulating the functional operations of users simultaneously in each scenario, the performance of the system when processing multiple users' simultaneous operations can be verified, so as to discover possible performance bottlenecks.

[0194] At the same time, in the embodiments of this specification, by conducting stress tests on each business scenario, various abnormal situations and malicious attacks can be simulated, so as to discover the risk factors of the system. For example, in the shift handover scenario, by simulating multiple users performing shift handover operations simultaneously, it can be detected whether there are abnormal situations such as login conflicts or permission errors when the system processes multiple concurrent requests.

[0195] In addition, in the embodiments of this specification, by analyzing the stress test results of each business scenario, the load capacity and response time of the system can be evaluated, providing a basis for the stable online of the system. For example, in the scenario of accessing the payment page, by simulating multiple users performing the payment operation process simultaneously, the performance of the system when processing multiple payment requests can be tested to determine whether the system can stably process high-concurrency payment requests.

[0196] S106, in the pre-set test platform, according to each business scenario, the test objectives of each business scenario and the test concurrent user numbers of each business scenario, write a stress test script, run the stress test script, and collect the test performance data of each business scenario of the tram battery swapping software.

[0197] In the embodiments of this specification, the stress test script can be used to simulate the actual operations of the tram battery swapping software, including online data concurrency scenarios and driver user behavior concurrency scenarios.

[0198] It should be noted that by simulating the online data concurrency scenario through the stress test script in the embodiments of this specification, it is possible to simulate multiple users operating simultaneously, such as querying battery swapping stations, viewing battery and queuing information, etc., so as to evaluate the performance of the system under high concurrency. This can help identify potential performance bottlenecks that may occur when the system processes a large number of actual operations, such as performance issues in database queries, network transmissions, etc.

[0199] At the same time, by simulating the driver user behavior concurrency scenario through the stress test script in the embodiments of this specification, it is possible to simulate multiple driver users operating simultaneously, such as emergency charging and online refund, etc., to evaluate the performance of the system under high concurrency. This can help identify potential performance issues that may occur when the system processes a large number of concurrent operations, such as performance bottlenecks in concurrent request processing, resource allocation, etc.

[0200] In summary, by conducting stress tests on these two scenarios in the embodiments of this specification, it is possible to more comprehensively evaluate the performance of the system under high concurrency, and at the same time, potential performance bottlenecks and risk factors can be identified. This provides a basis for the stable online launch of the system and corresponding optimizations and improvements can be made.

[0201] Furthermore, the test concurrent user numbers in the embodiments of this specification can include: the average online data concurrent user number and the peak online data concurrent user number in the online data concurrency scenario, as well as the average driver user behavior concurrent user number and the peak driver user behavior concurrent user number in the driver user behavior concurrency scenario.

[0202] It should be noted that by determining the average online data concurrent user number and the peak online data concurrent user number in the online data concurrency scenario, as well as the average driver user behavior concurrent user number and the peak driver user behavior concurrent user number in the driver user behavior concurrency scenario, the load capacity of the system under high concurrency can be evaluated. This helps to determine the maximum number of concurrent requests that the system can handle, as well as the performance of the system under different load conditions.

[0203] At the same time, by determining the average concurrent user number and the peak concurrent user number in different scenarios, the load of the system under high concurrency can be simulated. This helps to identify potential performance bottlenecks that may occur when the system processes a large number of concurrent requests. By analyzing the stress test results, it is possible to determine whether there are performance issues in the system under high load, such as extended response times, system crashes, etc.

[0204] In addition, the embodiments of this specification can discover the risk factors of the system by simulating concurrent user operations in different scenarios. For example, in the online data concurrency scenario, by simulating multiple users performing operations such as checking the swapping station, viewing battery information, and queuing information simultaneously, it can be discovered whether there are risk factors such as data consistency problems and resource competition when the system processes multiple concurrent requests.

[0205] In summary, the embodiments of this specification can evaluate the load capacity of the system, discover performance bottlenecks and risk factors, provide a basis for the stable online launch of the system, and perform corresponding optimizations and adjustments by conducting stress tests on the core business scenarios of the system, determining the average concurrent user number and peak concurrent user number in different scenarios.

[0206] It should be noted that for the above-mentioned writing and running of stress test scripts, the following specific content can be adopted:

[0207] In a pre-set test platform, write stress test scripts according to each business scenario, test objectives, and test concurrent user number. According to the actual operation process and business requirements of the tram battery swapping software, write stress test scripts that can simulate online data concurrency scenarios and driver user behavior concurrency scenarios.

[0208] For the online data concurrency scenario, determine the average online data concurrent user number and peak online data concurrent user number according to the requirements. Set parameters such as the concurrent user number in the stress test script so that it can simulate the corresponding number of online data concurrent users. The script can include operations such as simulating user login, viewing battery status, and searching for swapping stations.

[0209] For the driver user behavior concurrency scenario, determine the average driver user behavior concurrent user number and peak driver user behavior concurrent user number according to the requirements. Set parameters such as the concurrent user number in the stress test script so that it can simulate the corresponding number of driver user concurrent operations. The script can include operations such as simulating driver login, viewing task list, confirming tasks, and completing tasks.

[0210] When running the stress test script, relevant test environments and resources can be configured in the test platform, and the stress test script can be run for testing. The script will simulate multiple concurrent users performing operations in each business scenario, such as viewing battery status, searching for swapping stations, and confirming tasks.

[0211] Collect test performance data. During the stress test run, collect and record the test performance data of each business scenario, such as response time, throughput, error rate, etc. The test platform or performance testing tool usually provides monitoring and reporting functions for these data.

[0212] Analyze and evaluate the test results. Based on the collected performance data, analyze and evaluate the performance of each business scenario. Compare the actual performance with the test objectives, identify bottlenecks and problems, and propose corresponding optimization suggestions.

[0213] Through the above steps, stress test scripts can be written and run in a pre-set test platform, and the test performance data of each business scenario can be collected and analyzed. This will help evaluate the performance of the electric vehicle battery swapping software in each business scenario and provide optimization solutions and improvement suggestions.

[0214] S108. When the test performance data of each business scenario of the electric vehicle battery swapping software meets the corresponding test performance objectives, the test of the electric vehicle battery swapping software is completed.

[0215] In the embodiments of this specification, for the above content, the following specific content can be adopted:

[0216] Analyze the test performance data: Analyze and evaluate the test performance data collected in S106. Compare it with the test performance objectives in S102 to determine whether the objectives are met. If the test performance data meets the corresponding test performance objectives, it indicates that the electric vehicle battery swapping software has good performance in each business scenario.

[0217] Confirm the test results: According to the analysis results of the test performance data, confirm the test results of the electric vehicle battery swapping software. If the test performance data meets the corresponding test performance objectives, it means that the test of the electric vehicle battery swapping software has been completed.

[0218] Prepare a test report: Based on the test results and analysis, prepare a test report that details the compliance of the test performance data of each business scenario of the electric vehicle battery swapping software with the corresponding test performance objectives. The report can include descriptions of the test environment, test methods, statistics and analysis results of the test performance data, problems found in the test, test conclusions, and recommendations, etc.

[0219] Propose improvement suggestions: Based on the test results and analysis, propose improvement suggestions to help improve and optimize the performance of the electric vehicle battery swapping software. The improvement suggestions can include performance optimization solutions, resource adjustment suggestions, system configuration adjustment suggestions, etc.

[0220] Furthermore, when determining the test performance objectives of each business scenario before the electric vehicle battery swapping software goes live, the number of concurrent processing transactions of each business scenario of the electric vehicle battery swapping software can be continuously increased to obtain performance indicators for different numbers of concurrent processing transactions; then, based on the performance indicators for different numbers of concurrent processing transactions, determine the test performance objectives of each business scenario before the electric vehicle battery swapping software goes live.

[0221] It should be noted that the implementation steps for determining the test performance objectives of each business scenario before the electric vehicle battery swapping software goes live are as follows:

[0222] Initial test performance target setting: According to the expected usage scenarios and business requirements of the electric vehicle battery swapping software, initially set the test performance targets for each business scenario, including indicators such as response time, throughput, and number of concurrent users.

[0223] Increase the number of concurrent transaction processes: In the test environment, gradually increase the number of concurrent transaction processes for each business scenario of the electric vehicle battery swapping software. Different situations of the number of concurrent transaction processes can be simulated by gradually increasing the number of concurrent users, request frequency, or the number of parallel processing tasks, etc.

[0224] Collect performance indicators: For different situations of the number of concurrent transaction processes, collect and record the performance indicators of the electric vehicle battery swapping software, such as response time, throughput, resource utilization, etc. Performance testing tools or performance monitoring tools can be used to collect these indicators in real time.

[0225] Analyze performance indicators: Analyze the collected performance indicators and compare the performance performance under different numbers of concurrent transaction processes. Observe whether there are performance bottlenecks or system resource exhaustion situations, as well as the changing trend of performance indicators with the number of concurrent transaction processes.

[0226] Determine the final test performance target: According to the analysis results of the performance indicators under different numbers of concurrent transaction processes, determine the final test performance targets for each business scenario before the electric vehicle battery swapping software goes live. Determine appropriate indicators such as response time, throughput, and number of concurrent users according to the requirements of performance indicators and the expected user load.

[0227] Update the test plan and execution: According to the finally determined test performance targets, update the test plan and test scripts. Re-execute the performance test, simulate the number of concurrent transaction processes under the final target, and collect and record new test performance data.

[0228] Analyze the test results: According to the results of the re-executed performance test, verify whether the finally set test performance targets are achieved. Analyze and evaluate the results to ensure that the electric vehicle battery swapping software has the required performance in each business scenario before going live.

[0229] Through the above steps, the final test performance target can be determined by increasing the number of concurrent transaction processes and according to the performance and trend of performance indicators. This can ensure that the electric vehicle battery swapping software can meet the expected performance requirements in each business scenario before going live.

[0230] It should be noted that in the embodiments of this specification, by continuously increasing the number of concurrent processing transactions in each business scenario and based on the performance metrics obtained for different numbers of concurrent processing transactions, the test performance goals for each business scenario before the online launch of the tram battery swapping software can be determined. This helps to clarify the performance requirements of the system under different loads and serves as the basis and guidance for testing.

[0231] Meanwhile, in the embodiments of this specification, by continuously increasing the number of concurrent processing transactions and monitoring the performance metrics of the system, the load capacity of the system can be evaluated. By determining the performance of the system under different numbers of concurrent processing transactions, the maximum number of concurrent requests that the system can handle can be determined, thereby providing a basis for the load planning and design of the system.

[0232] In addition, in the embodiments of this specification, by continuously increasing the number of concurrent processing transactions and monitoring the performance metrics of the system, performance bottlenecks that may occur in the system under different loads can be discovered. By analyzing the test results, the performance of the system under different numbers of concurrent processing transactions can be determined, and possible performance bottlenecks can be found, such as extended response times and insufficient system resources.

[0233] In summary, by determining the test performance goals for each business scenario, continuously increasing the number of concurrent processing transactions, and monitoring the performance metrics of the system, the load capacity of the system can be evaluated, performance bottlenecks can be discovered, a basis for the stable online launch of the system can be provided, and corresponding optimizations and adjustments can be made.

[0234] Furthermore, the test performance goals include the number of concurrent users to be tested and test performance metrics; when the test performance data for each business scenario of the tram battery swapping software meets the corresponding test performance goals and the testing of the tram battery swapping software is completed, based on the test performance data for each business scenario of the tram battery swapping software, it can be determined whether the number of concurrent users to be tested in each business scenario meets the corresponding test performance metrics, and the test results can be obtained; and / or, based on the test performance data for each business scenario of the tram battery swapping software, the upper limit of the number of concurrent users that meets the corresponding test performance metrics in each business scenario can be determined.

[0235] It should be noted that regarding the above content, the following specific implementation solutions can be adopted:

[0236] 1. Determine the test performance goals and metrics

[0237] Define the test performance goals: According to the requirements and expected performance of the tram battery swapping software, set the test performance goals for each business scenario, including but not limited to the number of transactions processed per second (TPS), the number of query requests per second (QPS), the error rate, CPU, and memory occupancy rate, etc.

[0238] Determine the test performance metrics: Set specific metric values for each test performance goal.

[0239] 2. Design test cases

[0240] Identify business scenarios: List all business scenarios of the tram battery swapping software in detail, such as user registration, battery swapping request, payment process, etc.

[0241] Create test cases: Design test cases for each business scenario to ensure that all function points and performance metrics are covered.

[0242] 3. Prepare the test environment and tools

[0243] Set up the test environment: Simulate the real operating environment, including servers, networks, databases, etc.

[0244] Select test tools: Select appropriate performance test tools, such as JMeter, LoadRunner, etc.

[0245] 4. Execute the test tasks

[0246] Single business scenario test: For each business scenario, execute the test according to the set number of concurrent users and test performance metrics. Record the running data during the test, including response time, throughput, error rate, etc.

[0247] Multi-business scenario test: On the basis of the single business scenario test, simulate the situation of multiple business scenarios running in parallel. Also record the running data during the test.

[0248] 5. Analyze the test results

[0249] Evaluate the number of concurrent users in the test: Compare the actual test data with the test performance metrics to determine whether the number of concurrent users in the test meets the requirements. If not, analyze the reasons and adjust the number of concurrent users in the test or optimize the system performance.

[0250] Determine the upper limit of the number of concurrent users: By gradually increasing the number of concurrent users until the test performance metrics begin to decline, determine the upper limit of the number of concurrent users for each business scenario.

[0251] 6. Test report and optimization

[0252] Prepare the test report: Summarize the test results, including the number of concurrent users in the test, performance metrics, existing problems, etc.

[0253] Performance optimization: According to the test results, optimize the performance of the tram battery swapping software, such as code optimization, database index optimization, server resource adjustment, etc. Retest until all business scenarios meet the test performance metrics.

[0254] It should be noted that the embodiments of this specification can accurately identify the performance bottlenecks and potential risk factors of the tram battery swapping software under high concurrency, so as to perform necessary optimization and adjustment before the software is officially launched. Conducting a comprehensive stress test before launch can ensure the stability of the system in a real high-concurrency environment and reduce failures and user complaints caused by system instability.

[0255] Meanwhile, the embodiments of this specification determine the test concurrent user number and test performance indicators, providing clear goals and standards for the test work, which helps the scientific management and evaluation of the test process.

[0256] Moreover, the embodiments of this specification determine whether the test concurrent user number in each business scenario meets the performance indicators based on the test data, which helps to make decisions based on data and ensure that the performance of the software in actual use meets expectations.

[0257] In addition, the embodiments of this specification can help developers reasonably allocate resources, such as server configuration, network bandwidth, etc., to support a higher user access volume by determining the upper limit of the concurrent user number that meets the test performance indicators.

[0258] Furthermore, the method further includes: determining the initial concurrent user number and initial operation data corresponding to the initial test stage based on the test objectives of the business scenario and the test concurrent user number, where the initial operation data includes at least one of operation duration, operation interval, loop interval, concurrent interval, user loading and decompression time.

[0259] It should be noted that for the above content, the following specific implementation solutions can be adopted:

[0260] 1. Determine the test objectives of the business scenario

[0261] Analyze business requirements: Analyze in detail the functional requirements, performance requirements, and user experience requirements of each business scenario.

[0262] Set test objectives: According to the business requirements, set the test objectives for each business scenario, such as TPS (Transactions Per Second), QPS (Queries Per Second), error rate, CPU and Memory occupancy rate, etc.

[0263] 2. Design the test plan

[0264] Determine the test stage: Divide different test stages according to the complexity and importance of the business scenario.

[0265] Formulate the test plan: Formulate a specific test plan for each test stage, including test methods, tools, and expected results.

[0266] 3. Determine the test concurrent user number

[0267] Refer to historical data: If possible, refer to the historical test data of similar systems to determine the initial number of concurrent users.

[0268] 4. Collect initial running data

[0269] Select key metrics: Based on the test objectives, select at least one of the running duration, operation interval, loop interval, concurrency interval, user load, and decompression time as the key metrics for the initial running data.

[0270] Design a monitoring plan: Use performance testing tools (such as JMeter, LoadRunner, etc.) to simulate user behavior and monitor key metrics. Ensure that the monitoring tool can capture the required running data.

[0271] 5. Execute the test

[0272] Set up the test environment: Ensure that the test environment is as consistent as possible with the production environment, including hardware, software, and network configurations.

[0273] Execute the test: According to the test plan, execute the test using the simulated user load. Record the running data of the key metrics during the test.

[0274] It should be noted that determining the initial number of concurrent users in the embodiments of this specification helps to set a reasonable test scale at the initial stage of the test, ensure that the test can effectively cover the main business scenarios, and avoid waste of resources caused by overtesting.

[0275] At the same time, the initial running data in the embodiments of this specification, such as running duration, operation interval, loop interval, concurrency interval, etc., provides a benchmark for performance evaluation. These data help to compare the performance changes in different scenarios during subsequent tests. Through the initial running data, the configuration of test resources, such as server performance, network bandwidth, etc., can be optimized to ensure that it will not become a performance bottleneck during the test.

[0276] Moreover, collecting running data at the initial stage of the test in the embodiments of this specification helps to quickly locate the source of problems when performance problems occur, because anomalies can be found based on the comparison between the initial data and the current data.

[0277] Moreover, the clear initial running data in the embodiments of this specification helps to improve test efficiency because it allows the test team to focus on key performance metrics during the test instead of conducting aimless extensive tests.

[0278] Moreover, by simulating the running data under different numbers of concurrent users in the embodiments of this specification, the actual user usage scenario can be more realistically simulated, thereby evaluating the user experience of the software in actual use.

[0279] In addition, the initial operation data of the embodiments of this specification can help predict potential risks of the system under high concurrency, such as system crashes, data loss, etc., so as to take preventive measures in advance.

[0280] Further, the method further includes: obtaining a first test result, a first number of concurrent users, and first operation data corresponding to the current test phase, where the current test phase includes an initial test phase and any test phase after the initial test phase; and when it is determined that the first test result meets the test target, determining a second number of concurrent users and second operation data corresponding to the next test phase based on the first test result, the first number of concurrent users, the first operation data, the test target, and the test number of concurrent users.

[0281] It should be noted that regarding the above content, the following specific implementation solutions can be adopted:

[0282] 1. Obtain the first test result, the first number of concurrent users, and the first operation data of the current test phase

[0283] Collect data: Use a performance testing tool (such as JMeter, LoadRunner, etc.) to conduct tests in the current test phase. Record the key data during the test, including the first test result (such as response time, throughput, error rate, etc.), the first number of concurrent users, and the first operation data (such as running duration, operation interval, loop interval, concurrent interval, user loading and decompression time, etc.).

[0284] 2. Analyze the first test result

[0285] Evaluate the test target: Evaluate whether the first test result meets the expectation according to the test target.

[0286] Verify the performance metrics: Confirm whether the first number of concurrent users and the first operation data are within the acceptable performance metric range.

[0287] 3. Determine the number of concurrent users and operation data for the next test phase

[0288] Determine the target: Set the target number of concurrent users and performance metrics for the next test phase according to the business requirements and the performance testing target.

[0289] Formulate a strategy: If the first test result meets the test target, consider increasing the number of concurrent users to test the scalability and stability of the system. If the first test result is already close to the performance bottleneck, it may be necessary to maintain the current number of concurrent users and focus on testing other performance metrics or performing system optimization.

[0290] 4. Design the next test phase

[0291] Plan the test scenario: Based on the first test results, plan the test scenario for the next test phase, including any abnormal situations or stress tests that may need to be simulated.

[0292] Adjust the number of concurrent users for testing: If the goal is to increase the number of concurrent users, start with a small range and gradually increase the number of concurrent users, recording the running data each time after the increase. Ensure that the test tool can evenly distribute the load to each test node to avoid local overloading.

[0293] 5. Execute the next test phase

[0294] Execute the test: Execute the test for the next test phase according to the designed test plan.

[0295] Monitor the running data: Continuously monitor the key running data during the test, including response time, throughput, resource usage, etc.

[0296] 6. Analyze the running data of the next test phase

[0297] Compare the running data: Compare the running data of the next test phase with the running data of the first test phase.

[0298] Evaluate the performance improvement: Analyze whether the increase in the number of concurrent users has brought about a performance improvement.

[0299] 7. Determine the second running data

[0300] Record the second running data: Record the detailed running data of the next test phase.

[0301] Adjust the test target: If the running data of the second test phase does not meet the expectations, it may be necessary to adjust the test target or test strategy.

[0302] It should be noted that through comparison with the results of the first test phase in the embodiments of this specification, the performance bottlenecks and problems of the system under high concurrency can be identified, so as to optimize them specifically in the subsequent test phases. The first test results provide a basis for performance prediction in the subsequent tests, enabling the test team to adjust the number of concurrent users according to the actual situation to more accurately simulate the real-world usage.

[0303] Meanwhile, based on the first running data in the embodiments of this specification, test resources such as servers and network bandwidth can be more reasonably allocated to ensure the accuracy and efficiency of the test. By analyzing the first test results, it is possible to avoid repeating the problems that have been discovered and solved in the previous test phases in the subsequent test phases, thereby improving the test efficiency.

[0304] Moreover, the problems discovered in the first test phase of this specification embodiment can be resolved before the second test phase, thereby reducing the likelihood of serious risks occurring in the higher concurrency test phase. If the first test result does not meet the expectations, the improvement direction can be clarified, such as optimizing database queries, increasing caches, adjusting server configurations, etc.

[0305] Moreover, by gradually increasing the number of concurrent users in the embodiments of this specification, the performance of the system under different loads can be more accurately evaluated, thereby conducting a cost-benefit analysis within a limited test budget. Determining the second number of concurrent users and the second set of running data is based on the premise of meeting the test objectives, which helps ensure the validity of the test results and verify whether the expected performance metrics are achieved.

[0306] In addition, by recording and updating the test results and running data in the embodiments of this specification, the test process can be made more transparent, facilitating communication and collaboration among team members. This test method helps achieve automated performance testing in the continuous integration and deployment process, ensuring effective performance feedback after each code submission or build.

[0307] Furthermore, the method further includes: based on the number of concurrent users and the running data corresponding to each business scenario in the same test phase, performing a multi-business scenario parallel test task to obtain the multi-business scenario test results corresponding to each business scenario in the same test phase; based on the multi-business scenario test results, determining whether the test concurrent user numbers for each business scenario meet the corresponding test performance metrics to obtain a first test result; based on the multi-business scenario test results, determining the first upper limit number of concurrent users that meet the corresponding test performance metrics for each business scenario.

[0308] It should be noted that regarding the above content, the following specific implementation solutions can be adopted:

[0309] 1. Preparation

[0310] Define business scenarios: Clearly define all business scenarios in the tram battery swapping software, such as user login, battery swapping request, payment processing, etc.

[0311] Determine test performance metrics: Set test performance metrics for each business scenario, such as response time, throughput, error rate, etc.

[0312] Prepare the test environment: Set up a test environment similar to the production environment, including servers, databases, networks, etc.

[0313] 2. Determine the number of concurrent users

[0314] Evaluate system load: According to the system design and technical specifications, evaluate the maximum number of concurrent users that the system can withstand.

[0315] Set the initial number of concurrent users: Select a reasonable initial number of concurrent users and usually increase it gradually from low to high.

[0316] 3. Execute parallel tests for multiple business scenarios

[0317] Design test scripts: Design test scripts for each business scenario to simulate real user behavior.

[0318] Configure test tools: Use performance testing tools (such as JMeter, LoadRunner, etc.) to configure test scripts to ensure that multiple business scenarios can be executed in parallel.

[0319] Set test parameters: Set test parameters for each business scenario, including the number of concurrent users, running duration, number of loops, etc.

[0320] Execute the test: Start the test tool and begin parallel testing of multiple business scenarios.

[0321] 4. Collect and record operation data

[0322] Monitor operation data: During the test, monitor key performance indicators in real time, such as response time, throughput, resource utilization, etc.

[0323] Record operation data: Record the data collected during the test, including the operation data of each business scenario.

[0324] 5. Analyze the test results of multiple business scenarios

[0325] Compare performance indicators: Compare the performance indicators of each business scenario in the parallel test of multiple business scenarios with the set test performance indicators.

[0326] Evaluate the number of concurrent users: Determine whether the current number of concurrent users meets the test performance indicators of each business scenario.

[0327] 6. Determine the first test result

[0328] Determine the number of concurrent users that meet the conditions: If the performance indicators of all business scenarios are within the acceptable range, the current number of concurrent users meets the test target and the first test result is obtained.

[0329] Record the first test result: Record the first test result in detail, including the number of concurrent users that meet the conditions and the corresponding performance indicators.

[0330] 7. Determine the first upper limit of the number of concurrent users

[0331] Gradually increase the number of concurrent users: If the current number of concurrent users is already close to the performance bottleneck, gradually increase the number of concurrent users.

[0332] Monitor performance changes: As the number of concurrent users increases, monitor the changes in performance metrics until the performance starts to decline.

[0333] Determine the upper limit of concurrent users: When the performance metrics start to decline, record the number of concurrent users at this time as the first upper limit of concurrent users.

[0334] It should be noted that in the embodiments of this specification, by parallelly testing multiple business scenarios, the overall performance of the system in multi-task concurrent processing can be comprehensively evaluated, rather than evaluating a single scenario alone. And the number of concurrent users and performance metrics of each business scenario can be understood, which helps to optimize the system resource allocation and ensure that key business scenarios can also maintain good performance under high concurrency.

[0335] At the same time, in the parallel test of multi-business scenarios, the embodiments of this specification can more easily identify the system performance bottleneck, because when multiple scenarios run simultaneously, resource competition and performance problems are more obvious.

[0336] Moreover, the embodiments of this specification ensure that all business scenarios can meet the corresponding test performance metrics, which helps to ensure the experience consistency of users when using different functions.

[0337] In addition, by determining the first upper limit of concurrent users for each business scenario, the embodiments of this specification can pre-evaluate the risks of the system under high concurrency and take measures to prevent the system from crashing or the service quality from degrading.

[0338] Furthermore, the method further includes: For each business scenario separately, based on the number of concurrent users and running data corresponding to the business scenario in the test phase, execute a single-business-scenario test task to obtain the single-business-scenario test result corresponding to the business scenario; Based on the single-business-scenario test result, determine whether the test concurrent users in each business scenario meet the corresponding test performance metrics to obtain a first test result; Based on the single-business-scenario test result, determine the first upper limit of concurrent users that meet the corresponding test performance metrics in each business scenario.

[0339] It should be noted that for the above content, the following specific implementation solutions can be adopted:

[0340] 1. Preparation stage

[0341] Business scenario identification: Clearly define all business scenarios that need to be tested, such as user registration, order submission, payment processing, etc.

[0342] Performance metric setting: Set specific performance metrics for each business scenario, such as response time, throughput, error rate, resource utilization rate, etc.

[0343] Test environment setup: Ensure that the test environment is similar to the production environment, including hardware configuration, software version, network conditions, etc.

[0344] 2. Design of single-business scenario test tasks

[0345] Test script writing: Write detailed test scripts for each business scenario to ensure that the scripts can simulate the behavior of real users.

[0346] Test parameter configuration: Configure the parameters of test tools (such as JMeter, LoadRunner, etc.), including the number of concurrent users, running duration, number of loops, etc.

[0347] 3. Execute single-business scenario tests

[0348] Initial concurrent user number setting: Select a reasonable initial concurrent user number, usually starting from a relatively low level and increasing gradually.

[0349] Test execution: Use the test tool to execute single-business scenario tests and monitor the key performance indicators during the test process.

[0350] Data recording: Record the running data of each business scenario during the test, including response time, throughput, error rate, etc.

[0351] 4. Analyze the results of single-business scenario tests

[0352] Performance indicator evaluation: Compare the test results of each business scenario with the set performance indicators to evaluate whether the requirements are met.

[0353] Analysis of abnormal situations: For business scenarios that do not meet the performance indicators, analyze the reasons, which may be due to system bottlenecks, code defects, or configuration problems.

[0354] 5. Determine the first test result

[0355] Concurrent user number evaluation: Based on the results of single-business scenario tests, determine whether the test concurrent user number under each business scenario meets the performance indicators.

[0356] Record the first test result: Record the concurrent user number that meets the performance indicators as the first test result.

[0357] 6. Determine the first upper limit of concurrent user number

[0358] Gradually increase the concurrent user number: On the basis of meeting the performance indicators, gradually increase the concurrent user number to test the maximum bearing capacity of the system.

[0359] Monitor performance changes: As the concurrent user number increases, continuously monitor the performance indicators and observe when the system performance begins to decline.

[0360] Determine the upper limit of concurrent users: When the performance metrics start to decline, record the concurrent user count at this time as the first upper limit of concurrent users that meets the performance metrics.

[0361] It should be noted that in the embodiments of this specification, testing each business scenario separately can more accurately evaluate the performance of each function and avoid possible mutual interference in the multi-scenario parallel testing. In the separate testing, if there are performance issues, it is possible to quickly locate the specific business scenario, which is convenient for targeted debugging and optimization.

[0362] At the same time, in the embodiments of this specification, by determining whether the tested concurrent user count of each business scenario meets the performance metrics, it is possible to verify whether each business scenario meets the established performance standards.

[0363] Moreover, separate testing helps to identify the resource usage of each business scenario, thereby optimizing the system resource configuration and ensuring that key business scenarios are given priority in resource allocation.

[0364] And ensuring that each business scenario can meet the performance metrics under high concurrency helps to ensure the consistency of the user experience when using different functions.

[0365] And separate testing can simplify the testing process and improve testing efficiency, especially in the case of limited testing resources.

[0366] In addition, separate testing can more clearly analyze the performance bottlenecks of each business scenario, providing a specific direction for subsequent performance optimization work.

[0367] It should be noted that the implementation method of the performance testing of the tram battery swapping software in the embodiments of this specification is as follows:

[0368] 1. Online data analysis:

[0369] (1) Calculation of the online data concurrency. The possible average number of concurrent business users is: C = nL / T = 59 * 25 / 60 ≈ 24.58, and the peak value of the concurrent user count: C^ = C + 3 * (square root of C) ≈ 29.56;

[0370] (2) Calculation of the concurrent volume of driver user behavior. For example, for 50,000 vehicles, if the average customer logs in to the APP to swap the battery twice per vehicle, assuming the concentrated time is 12 hours and the peak value is 3 - 5 times the normal state, that is, the maximum concurrent number = (50000 * 2 / (12 * 60 * 60)) * 5 ≈ 11.57;

[0371] (3) Planning within 2 years. For example, it is planned to add another 50,000 vehicles by the end of the year and plan to add 100,000 vehicles. According to the above two calculation methods, the possible peak concurrent numbers after 2 years are 118.24 and 46.28 respectively.

[0372] 2. Test Objectives:

[0373] TPS reaches 100, QPS reaches 300, error rate is 0%, CPU and Memory occupancy rates are below 80%, and the test runs continuously for more than 5 minutes.

[0374] 3. Test Function Scope:

[0375] Scenario 1: Logged in or not - Find a station - View battery and queuing information of the battery swapping station - Navigate to the battery swapping station;

[0376] The number of concurrent users is gradually pressure - tested from 20, 50, 100, 200, 300, 500... The scenario runs for 5 minutes until the system reaches the performance bottleneck. One request calls 8 back - end interfaces to test the TPS value, response time, etc.;

[0377] Scenario 2: Logged in - Access the payment page - Go to recharge - Select a package - Create a payment order;

[0378] The number of concurrent users is gradually pressure - tested from 20, 50, 100, 200, 300, 400... The scenario runs for 5 minutes until the system reaches the performance bottleneck. One request calls 8 back - end interfaces, parameterizes 10,000 users, and loops to fetch data when the data is insufficient;

[0379] Scenario 3: Logged in - My - View personal information or settings, etc.;

[0380] The number of concurrent users is gradually pressure - tested from 20, 50, 100, 200, 300, 400... The scenario runs for 5 minutes until the system reaches the performance bottleneck. One request calls 7 back - end interfaces, parameterizes 10,000 users, and loops to fetch data when the data is insufficient;

[0381] Scenario 4: Logged in - Enter the order list - View recharge and consumption orders;

[0382] The number of concurrent users is gradually pressure - tested from 20, 50, 100, 200, 300, 400... The scenario runs for 5 minutes until the system reaches the performance bottleneck. One request calls 8 back - end interfaces, parameterizes 10,000 users, and loops to fetch data when the data is insufficient;

[0383] Scenario 5: Online refund;

[0384] The number of concurrent users is gradually pressure - tested from 50, 100, 200, 300, 400... The scenario runs for 2 minutes until the system reaches the performance bottleneck. One request calls 6 back - end interfaces, uses the universal verification code 9999, does not send SMS verification codes separately, and tests the TPS value, response time, etc.;

[0385] Scenario 6: Shift handover;

[0386] The number of concurrent users is gradually stress - tested from 50, 100, 200, 300, 400... The operation scenario lasts for 2 minutes until the system reaches the performance bottleneck. Each request calls 6 back - end interfaces, parameterizes 10,000 users, and loops to retrieve data when the data is insufficient.

[0387] Scenario 7: Emergency power replenishment;

[0388] The number of concurrent users is gradually stress - tested from 50, 100, 200, 300, 400.. The operation scenario lasts for 2 minutes until the system reaches the performance bottleneck. Each request calls 6 back - end interfaces, parameterizes 10,000 users, and loops to retrieve data when the data is insufficient.

[0389] 4. Test press: A Linux system environment can be used as the test press to run the stress - testing scripts / scenarios based on JMeter.

[0390] 5. Test benchmark:

[0391] (1) Analyze and extract typical transactions and business processes based on business data

[0392] (2) Frequently used by users in operations

[0393] (3) Greatly affect the system performance

[0394] (4) The performance test pressure conforms to the actual transaction occurrence ratio of the business system

[0395] (5) Try to simulate the actual business when setting up the execution scenario. The running duration, operation interval, loop interval, concurrent interval, user loading, and decompression time are judged and set according to the benchmark test results.

[0396] 6. Test strategy: Continuously increase the number of concurrent transactions processed by the system, increase the system load until the system reaches the performance bottleneck, and calculate the number of transaction requests that the system can support, so as to fully understand the pressure situation of the core business scenario link of the APP.

[0397] 7. Test results and tuning: Analyze the results of each business scenario, and conduct targeted performance tuning for those that do not meet the expected pressure targets.

[0398] 8. Test conclusion: Summarize the maximum number of concurrent users that each business scenario link of this period's performance test can support and risk analysis, and use this as the basis for going live to ensure the stable operation of the new version of the APP after going live.

[0399] It should be noted that by analyzing and extracting the online pressure model and business processes in the embodiments of this specification, the concurrent user numbers that the current system can support can be more clearly understood, and optimization can be carried out for those that do not meet the expected goals, so as to ensure the stable operation of the battery swapping system in both the current and future developments.

[0400] Figure 2 The figure is a schematic structural diagram of a test device for an electric vehicle battery swapping software provided by one or more embodiments of this specification. The device includes: a scenario performance determination unit 202, a concurrency number determination unit 204, a test unit 206, and a test determination unit 208.

[0401] The scenario performance determination unit 202 determines each business scenario of the electric vehicle battery swapping software and determines the test performance goals of each business scenario before the electric vehicle battery swapping software goes online.

[0402] The concurrency number determination unit 204 determines the test concurrent user numbers of each business scenario according to the business data of each business scenario obtained in advance.

[0403] The test unit 206 writes a stress test script in a pre-set test platform according to each business scenario, the test goals of each business scenario, and the test concurrent user numbers of each business scenario, and runs the stress test script to collect the test performance data of each business scenario of the electric vehicle battery swapping software.

[0404] The test determination unit 208 completes the test of the electric vehicle battery swapping software when the test performance data of each business scenario of the electric vehicle battery swapping software meets the corresponding test performance goals.

[0405] Figure 3 The figure is a schematic structural diagram of a test device for an electric vehicle battery swapping software provided by one or more embodiments of this specification, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: determine each business scenario of the electric vehicle battery swapping software and determine the test performance goals of each business scenario before the electric vehicle battery swapping software goes online; determine the test concurrent user numbers of each business scenario according to the business data of each business scenario obtained in advance; write a stress test script in a pre-set test platform according to each business scenario, the test goals of each business scenario, and the test concurrent user numbers of each business scenario, and run the stress test script to collect the test performance data of each business scenario of the electric vehicle battery swapping software; complete the test of the electric vehicle battery swapping software when the test performance data of each business scenario of the electric vehicle battery swapping software meets the corresponding test performance goals.

[0406] A non-volatile computer storage medium provided by one or more embodiments of this specification stores computer-executable instructions, which can be implemented when executed by a computer to: determine each business scenario of the tram battery swapping software, and determine the test performance objectives of each business scenario before the tram battery swapping software goes online; determine the test concurrent user numbers of each business scenario according to the business data of each business scenario obtained in advance; in a pre-set test platform, write a stress test script according to each business scenario, the test objectives of each business scenario, and the test concurrent user numbers of each business scenario, and run the stress test script to collect the test performance data of each business scenario of the tram battery swapping software; when the test performance data of each business scenario of the tram battery swapping software meets the corresponding test performance objectives, complete the test of the tram battery swapping software.

[0407] Each embodiment in this specification is described in a progressive manner. For the same or similar parts between each embodiment, reference can be made to each other. The key point of each embodiment is to illustrate the differences from other embodiments. In particular, for the embodiments of the device, equipment, and non-volatile computer storage medium, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments.

[0408] The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be executed in a different order than in the embodiments and still achieve the desired results. Additionally, the processes depicted in the figures do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0409] The above is only one or more embodiments of this specification and is not used to limit this specification. For those skilled in the art, one or more embodiments of this specification can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of this specification shall be included within the scope of the claims of this specification.

Claims

1. A testing method for an electric vehicle battery swapping software, characterized in that, The method includes: Determine each business scenario of the tram battery swapping software, and determine the test performance goals of each business scenario before the tram battery swapping software goes online; Determine the test concurrent user numbers of each business scenario according to the business data of each business scenario obtained in advance; In a pre-set test platform, write a stress test script according to each business scenario, the test goals of each business scenario, and the test concurrent user numbers of each business scenario, and run the stress test script to collect the test performance data of each business scenario of the tram battery swapping software; When the test performance data of each business scenario of the tram battery swapping software meets the corresponding test performance goals, complete the test of the tram battery swapping software.

2. The test method for the tram battery swapping software according to claim 1, wherein The test performance goals include test concurrent user numbers and test performance metrics; When the test performance data of each business scenario of the tram battery swapping software meets the corresponding test performance goals, completing the test of the tram battery swapping software specifically includes: Based on the test performance data of each business scenario of the tram battery swapping software, determine whether the test concurrent user numbers in each business scenario meet the corresponding test performance metrics to obtain a test result; And / or, based on the test performance data of each business scenario of the tram battery swapping software, determine the upper limit concurrent user numbers that meet the corresponding test performance metrics in each business scenario.

3. The method according to claim 1, characterized in that, The method further includes: Based on the test goals and test concurrent user numbers of the business scenario, determine the initial concurrent user numbers and initial operation data corresponding to the initial test stage, and the initial operation data includes at least one of operation duration, operation interval, loop interval, concurrent interval, user loading, and decompression time; And / or, the method further includes: Obtain the first test result, the first concurrent user numbers, and the first operation data corresponding to the current test stage, and the current test stage includes the initial test stage and any test stage after the initial test stage; When it is determined that the first test result meets the test goals, based on the first test result, the first concurrent user numbers, the first operation data, the test goals, and the test concurrent user numbers, determine the second concurrent user numbers and the second operation data corresponding to the next test stage.

4. The test method for the tram battery swapping software according to claim 3, wherein The method further includes: Based on the concurrent user numbers and operation data corresponding to each business scenario in the same test stage, execute a multi-business scenario parallel test task to obtain the multi-business scenario test results corresponding to each business scenario in the same test stage; Based on the multi-business scenario test results, determine whether the test concurrent user numbers in each business scenario meet the corresponding test performance metrics to obtain a first test result; Based on the multi-business scenario test results, determine the first upper limit concurrent user numbers that meet the corresponding test performance metrics in each business scenario; And / or, the method further includes: Individually for each business scenario, based on the concurrent user numbers and operation data corresponding to the business scenario in the test stage, execute a single-business scenario test task to obtain the single-business scenario test results corresponding to the business scenario. Based on the test results of the single business scenario, determine whether the test concurrent user numbers in each business scenario meet the corresponding test performance indicators, and obtain the first test result; Based on the test results of the single business scenario, determine the first upper limit concurrent user numbers in each business scenario that meet the corresponding test performance indicators.

5. The test method for the tram battery swapping software according to claim 1, characterized in that Each of the business scenarios includes at least one of the following: charging and swapping station scenario, accessing payment page scenario, personal information scenario, order list scenario, online refund scenario, shift handover scenario, and emergency charging scenario; Preferably, the test concurrent user numbers in the charging and swapping station scenario include at least one of the following: The test concurrent user number in the charging and swapping station scenario is the number of users who simulate multiple users simultaneously performing operations such as checking stations, viewing battery and queuing information, and navigation functions; The test concurrent user number in the accessing payment page scenario is the number of users who simulate multiple users simultaneously performing the payment operation process; The test concurrent user number in the personal information scenario is the number of users who simulate multiple users simultaneously accessing personal information or setting pages; The test concurrent user number in the order list scenario is the number of users who simulate multiple users simultaneously accessing the order list page and viewing recharge and consumption orders; The test concurrent user number in the online refund scenario is the number of users who simulate multiple users simultaneously performing online refund operations; The test concurrent user number in the shift handover scenario is the number of users who simulate multiple users simultaneously performing shift handover operations; The test concurrent user number in the emergency charging scenario is the number of users who simulate multiple users simultaneously performing emergency charging operations.

6. The test method for the tram battery swapping software according to claim 1, wherein The stress test script is used to simulate the actual operations of the electric vehicle battery swapping software, including online data concurrent scenarios and driver user behavior concurrent scenarios; Preferably, the test concurrent user numbers include the average online data concurrent user number and the peak online data concurrent user number in the online data concurrent scenario, and the average driver user behavior concurrent user number and the peak driver user behavior concurrent user number in the driver user behavior concurrent scenario.

7. The testing method of the tram battery swapping software according to claim 1, characterized in that The determination of the test performance objectives for each business scenario before the electric vehicle battery swapping software goes online includes: Continuously increase the number of concurrent processing transactions in each business scenario of the electric vehicle battery swapping software to obtain performance indicators for different numbers of concurrent processing transactions; According to the performance indicators for different numbers of concurrent processing transactions, determine the test performance objectives for each business scenario before the electric vehicle battery swapping software goes online; And / or, the test performance objectives include at least one test performance indicator, and the test performance indicator includes one or more of TPS (Transactions Per Second), QPS (Queries Per Second), error rate, CPU, and Memory occupancy rate.

8. A test device for an electric vehicle battery swapping software, characterized in that, The device includes: A scenario performance determination unit that determines each business scenario of the electric vehicle battery swapping software and determines the test performance objectives for each business scenario before the electric vehicle battery swapping software goes online; A concurrent number determination unit that determines the test concurrent user numbers for each of the business scenarios according to the business data of each business scenario obtained in advance; A test unit, in a preset test platform, writes a stress test script according to the business scenarios, the test objectives of the business scenarios, and the number of concurrent users for testing of the business scenarios, and runs the stress test script to collect the test performance data of each business scenario of the electric vehicle battery swapping software; A test determination unit completes the test of the electric vehicle battery swapping software when the test performance data of each business scenario of the electric vehicle battery swapping software meets the corresponding test performance objectives.

9. A testing device for an electric vehicle battery swapping software, characterized in that, Comprising: At least one processor; And, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can implement the test method of the electric vehicle battery swapping software as described in 1-7.

10. A non-volatile computer storage medium, characterized in that, Stores computer-executable instructions that, when executed by a computer, can implement the test method of the electric vehicle battery swapping software as described in 1-7.

Images