Server-side performance testing methods and systems
By combining the SE simulation module and the test equipment management service, the problem of high cost and low efficiency in server-side performance testing has been solved, and a high-efficiency, low-cost testing method has been achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHENZHEN SNOWBALL TECHNOLOGY CO LTD
- Filing Date
- 2023-03-23
- Publication Date
- 2026-05-26
AI Technical Summary
In existing technologies, server-side performance testing relies on physical equipment (SE), resulting in high testing costs and low efficiency.
The SE simulation module and test equipment management service are used to establish communication with the server through the simulation module, send and receive APDU commands, perform performance tests, and generate test results.
It reduced testing costs, improved testing efficiency, and reduced reliance on physical equipment.
Smart Images
Figure CN116340066B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, and more specifically, to a server-side performance testing method and system. Background Technology
[0002] "Over-the-air" services typically consist of a "Mobile Security Module" (SE), a "Mobile Client (APP / Mini Program)", and a "Service Server". Through the mobile internet, these services, which were originally only available at fixed locations, are now available on mobile devices. Examples include over-the-air issuance, over-the-air top-up, and over-the-air ticketing for mobile transportation cards.
[0003] Server-side performance testing relies heavily on physical device SEs (security environment chips embedded in the device) for business requests, which involve numerous interactions with these physical device SEs. Even if the tested object is solely the server, business function testing can only be conducted based on physical device SEs. This method of testing server-side performance using physical device SEs requires a large number of physical device SEs to interact simultaneously with the server under performance testing, and necessitates efficient scheduling of these numerous physical device SEs. This results in excessively high costs and low testing efficiency for server-side performance testing. Summary of the Invention
[0004] The purpose of this application is to provide a server-side performance testing method and system, which solves the above-mentioned problems existing in the prior art, reduces testing costs, and improves testing efficiency.
[0005] Firstly, a server-side performance testing method is provided, applied to a system that tests both a client and a server. The server includes a SE simulation module and the service under test. The method may include:
[0006] The test client sends a test service request to the service under test; the test service request includes the type of service to be tested and the device identifier of the SE simulation module used for testing.
[0007] The service under test establishes a communication connection with the corresponding SE simulation module based on the device identifier, and detects whether the SE simulation module can perform target service testing of the service type to be tested;
[0008] If so, a test service response is sent to the test client, the test service response including multiple APDU instructions related to the target service test;
[0009] The test client sends the multiple APDU commands and different test data corresponding to the service type to be tested to the SE simulation module through different threads;
[0010] The SE simulation module executes corresponding test operations based on the multiple APDU commands and different test data corresponding to the service type to be tested, and sends RPDU responses of the corresponding APDU commands to the test client. The RPDU responses include operation result information.
[0011] The test client encapsulates the RPDU response of each APDU instruction into a new test service request and sends the new test service request to the service under test.
[0012] The service under test verifies each RPDU response in the new test service request and sends the verification result to the test client;
[0013] Based on the verification results, the test client generates the performance test results of the service under test.
[0014] In one possible implementation, the test server also includes a Test Equipment Management Service (TDMS).
[0015] Before the test client sends a test service request to the service under test, the method further includes:
[0016] The test client, based on the test data and test start command input by the tester, sends a device data acquisition request to the test device management service based on the test start command; the device data acquisition request includes the requested type of service to be tested; the test data includes different test data corresponding to different service types;
[0017] Based on the type of the service to be tested requested, the test equipment management service obtains the test equipment data of the corresponding SE simulation module and sends a device data acquisition response to the test client. The device data acquisition response includes the test equipment data and test chip-related data. The test equipment data includes account information and device identifier required during the test.
[0018] The test client sends the relevant data of the test chip to the SE simulation module;
[0019] The SE simulation module loads the relevant data of the test chip into memory to complete the initialization process before testing.
[0020] In one possible implementation, the business type to be tested includes at least one business type to be tested;
[0021] The service under test checks whether the SE simulation module can perform target service testing of the service type to be tested, including:
[0022] After the service under test establishes a communication connection with the corresponding SE simulation module based on the device identifier, it obtains the device status data of the SE simulation module;
[0023] Based on the device status data of the SE simulation module, it is determined whether the SE simulation module can perform target service tests corresponding to each service type to be tested.
[0024] In one possible implementation, the method further includes:
[0025] If not, a test service response is sent to the test client, which includes an indication that the test service has failed.
[0026] In one possible implementation, the different threads include threads corresponding to each business type;
[0027] The test client sends the multiple APDU commands and different test data corresponding to the service type under test to the SE simulation module through different threads, including:
[0028] For each service type, the test client sequentially sends the multiple APDU instructions and the test data related to the corresponding APDU instructions from different test data corresponding to the service type under test to the SE simulation module through any thread of the corresponding service type.
[0029] In one possible implementation, the service under test verifies each RPDU response in the new test service request, including:
[0030] Based on the device status data and the multiple APDU commands, the service under test determines whether it can obtain all RPDU responses in the new test service request and whether the RPDU responses are valid.
[0031] If so, then generate a successful verification result;
[0032] If not, a verification result indicating verification failure will be generated.
[0033] In one possible implementation, after the test client generates the performance test results of the service under test based on the verification results, the method further includes:
[0034] The test client sends a data acquisition request to the SE simulation module;
[0035] The SE simulation module sends the current device data of the SE simulation module to the test client;
[0036] The test client sends the received current device data to the test device management service to store the current device data.
[0037] Secondly, a server-side performance testing system is provided, the system including a test client and a test server, the test server including an SE simulation module and the service under test;
[0038] The test client is used to send test service requests to the service under test; the test service request includes the type of service to be tested and the device identifier of the SE simulation module used for testing;
[0039] The service under test is used to establish a communication connection with the corresponding SE simulation module based on the device identifier, and to detect whether the SE simulation module can perform target service testing of the service type to be tested; if so, it sends a test service response to the test client, the test service response including multiple APDU instructions related to the target service test;
[0040] The test client is used to send the multiple APDU instructions and different test data corresponding to the service type to be tested to the SE simulation module through different threads;
[0041] The SE simulation module is used to execute corresponding test operations based on the multiple APDU commands and different test data corresponding to the service type to be tested, and send the corresponding APDU command RPDU response to the test client. The RPDU response includes operation result information.
[0042] The test client is used to encapsulate the RPDU response of each APDU instruction into a new test service request and send the new test service request to the service under test.
[0043] The service under test is used to verify each RPDU response in the new test service request and send the verification result to the test client.
[0044] A test client is used to generate performance test results for the service under test based on the verification results.
[0045] Thirdly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements any of the steps of the method described in the first aspect above.
[0046] The server-side performance testing method provided in this application is applied to a system consisting of a test client and a test server. The test server includes an SE simulation module and a service under test. The test client sends a test service request to the service under test. The test service request includes the type of service to be tested and the device identifier of the SE simulation module used for testing. The service under test establishes a communication connection with the corresponding SE simulation module based on the device identifier and checks whether the SE simulation module can perform target service testing of the type of service to be tested. If so, it sends a test service response to the test client. The test service response includes multiple APDU instructions related to the target service test. The test client sends tests to the SE simulation module through different threads. The test module sends multiple APDU commands and different test data corresponding to the service type under test. The SE simulation module executes corresponding test operations based on these APDU commands and the test data, and sends RPDU responses for the corresponding APDU commands to the test client. The RPDU responses include operation result information. The test client encapsulates the RPDU response for each APDU command into a new test service request and sends the new test service request to the service under test. The service under test verifies each RPDU response in the new test service request and sends the verification result to the test client. Based on the verification result, the test client generates the performance test results for the service under test. Compared with existing technologies, this method does not require a large number of physical SE devices, reducing testing costs and improving testing efficiency. Attached Figure Description
[0047] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0048] Figure 1 A system architecture diagram of an application server performance testing method provided in this application embodiment;
[0049] Figure 2 A flowchart illustrating a server-side performance testing method provided in an embodiment of this application;
[0050] Figure 3 This is a flowchart illustrating another server-side performance testing method provided in an embodiment of this application. Detailed Implementation
[0051] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0052] The server-side performance testing method provided in this application embodiment can be applied to... Figure 1 In the system architecture shown, such as Figure 1 As shown, the system may include: a test client (including Jmeter) and a test server, wherein the test server may include the SE simulation module MockSE, the test equipment management service TDMS, and the service under test Server.
[0053] 1. Preparations before testing:
[0054] (1) Data preparation: This mainly includes the device cplc (device unique identifier number) of the SE simulation module, the SE security domain key (initial value generated after negotiation with the service under test), and the device status of the SE simulation module.
[0055] (2) Application preparation:
[0056] A. Develop the SE simulation module MockSE and package it into a JAR file or other independent modules. This SE simulation module can simulate some functions of a physical SE device, with the functionality limited to completing performance tests.
[0057] B. Deploy the "Test Equipment Management Service TDMS" (hereinafter referred to as TDMS). This service is responsible for the management of test equipment data and equipment status, which is the relevant data management in the previous "Data Preparation" section.
[0058] C. Use load testing tools such as Jmeter to write performance test scripts, call MockSE and TDMS within the scripts, configure parameters such as concurrency and iteration count, and complete the deployment.
[0059] It should be noted that the SE simulation module mainly consists of applications and a database. It needs to implement various methods in the physical SE device to parse APDU commands and simulate the communication between the physical SE device and the service under test. Specifically, this includes:
[0060] 1. Internal and External Authentication: Similar to a handshake with the service under test (SUT). Both the SUT and the SE simulation module hold security domain keys and use corresponding algorithms to generate ciphertext, completing mutual identity verification. The security domain keys and algorithms are pre-negotiated after establishing the communication connection, and the SUT and SE simulation module maintain consistency. In real-world scenarios, the physical SE key is stored in the SE, while the SE simulation module uses a database to store the key.
[0061] 2. Key Replacement: The server issues a command to replace the initial key in the SE. During this process, the SE simulation module MockSE needs to parse the corresponding new key from the APUD command sent by the service under test, and use the new key to calculate the corresponding RPDU response to respond to the service under test's request. All subsequent authentication processes use the new key, and the new key is uploaded and stored in the database upon completion of the test.
[0062] 3. Card Activation: The service under test writes card data to the SE simulation module. The transmission of card data must be encrypted. The SE simulation module MockSE needs to parse the card data from the encrypted APUD command on the server side and upload the card data to the database when the test is completed, in preparation for subsequent over-the-air recharge tests.
[0063] Furthermore, the testing process for the system includes:
[0064] The test client is used to send test service requests to the service under test; the test service request includes the type of service to be tested and the device identifier of the SE simulation module used for testing;
[0065] The service under test is used to establish a communication connection with the corresponding SE simulation module based on the device identifier, and to detect whether the SE simulation module can perform target service testing of the service type under test; if so, it sends a test service response to the test client, which includes multiple APDU instructions related to the target service test.
[0066] The test client is used to send multiple APDU commands and different test data corresponding to the service type to be tested to the SE simulation module through different threads;
[0067] The SE simulation module is used to execute corresponding test operations based on multiple APDU commands and different test data corresponding to the service type under test, and send RPDU responses of the corresponding APDU commands to the test client. The RPDU response includes operation result information.
[0068] The test client is used to encapsulate the RPDU response of each APDU instruction into a new test service request and send the new test service request to the service under test.
[0069] The service under test is used to verify each RPDU response in the new test service request and send the verification result to the test client;
[0070] The test client is used to generate performance test results for the service under test based on the verification results.
[0071] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.
[0072] Figure 2 This is a flowchart illustrating a server-side performance testing method provided in an embodiment of this application. Figure 2 As shown, the method may include:
[0073] Step 21: The test client sends a test service request to the service under test.
[0074] In practice, before executing this step, the test client obtains the test data and test start command input by the tester; and based on the test start command, sends a device data acquisition request to the Test Equipment Management Service (TDMS); the device data acquisition request may include the device identifier of the requested SE simulation module; the test data may include different test data corresponding to different business types, such as different test data for over-the-air card activation business, or different test data for over-the-air recharge business.
[0075] The Test Equipment Management Service (TDMS) reads the test equipment data of the corresponding SE simulation module from the database based on the requested type of service to be tested, and sends a device data retrieval response to the test client. This response can include test equipment data, the type of service to be tested, test chip-related data, and user account information. The test equipment data includes account information and device identifiers required during testing. The test chip-related data includes the chip identifier (e.g., a public transport card chip identifier), the corresponding public transport card data, transaction counters, transaction keys, etc.—essentially all client data required for real-world business scenarios. Device identifiers are managed within TDMS, and this test equipment management service manages all test equipment data, test chip-related data, and user account information.
[0076] The test client sends test chip-related data to the SE simulation module;
[0077] The SE simulation module loads the relevant data of the test chip into memory to complete the initialization process before testing.
[0078] Next, the performance testing of the server service begins, at which point the test client sends a test service request to the service under test.
[0079] Step 22: After the service under test establishes a communication connection with the corresponding SE simulation module based on the device identifier, it checks whether the SE simulation module can perform target service testing of the service type to be tested, and sends the test service response to the test client.
[0080] After the tested service establishes a communication connection with the corresponding SE simulation module based on the device identifier, it obtains the device status data from the SE simulation module. The device status data may include the current status of the device, such as whether the card has been activated.
[0081] Based on the device status data of the SE simulation module, it is determined whether the SE simulation module can perform the target service test corresponding to each service type to be tested. For example, if the service type to be tested is card activation, and the device status data indicates that the SE simulation module has already activated a card, then the SE simulation module cannot currently perform the target service test, i.e., the card activation service. If the service type to be tested is recharge, and the device status data indicates that the SE simulation module is in a pending recharge state, then the SE simulation module can currently perform the target service test, i.e., the recharge service.
[0082] If so, a test service response is sent to the test client. This test service response may include multiple APDU commands related to the target service test.
[0083] If not, a test service response is sent to the test client. This test service response may include indications of service failure.
[0084] It should be noted that after the test client Jmeter initiates the last request, the service under test responds with "EOF" (endof file) to indicate that the process has ended.
[0085] Step 23: The test client sends multiple APDU commands and different test data corresponding to the service type to be tested to the SE simulation module through different threads.
[0086] Different threads can include threads corresponding to each business type. For example, if there are two business types, different threads can include two parts of threads, with each part of threads corresponding to one business type.
[0087] In practice, the test client parses the test service response to obtain multiple APDU instructions related to the target service test; and sends multiple APDU instructions and different test data corresponding to the service type to be tested to the SE simulation module through different threads.
[0088] Specifically, for each service type, the test client sequentially sends one APDU instruction from multiple APDU instructions to the SE simulation module through any thread of the corresponding service type, as well as test data related to the corresponding APDU instruction from different test data for the service type under test.
[0089] Furthermore, the test client can send multiple APDU instructions to the SE simulation module in a preset APDU instruction order. The preset APDU instruction order can be set based on the importance of the APDU instructions, or pre-set according to actual business needs, or set according to certain execution logic. The specific setting method is not limited in this application.
[0090] Step 24: The SE simulation module executes corresponding test operations based on multiple APDU commands and different test data corresponding to the service type to be tested.
[0091] Step 25: The SE simulation module sends the corresponding APDU command RPDU response to the test client.
[0092] The RPDU response may include operation result information.
[0093] Step 26: The test client encapsulates the RPDU response of each APDU instruction into a new test service request and sends the new test service request to the service under test.
[0094] In practice, the test client can encapsulate the corresponding RPDU response into a new test service request according to the order in which the APDU instructions are received.
[0095] Step 27: The service under test verifies each RPDU response in the new test service request and sends the verification result to the test client.
[0096] The service under test determines whether it can obtain all RPDU responses in the new test service request based on device status data and multiple APDU commands, and whether the RPDU responses are valid.
[0097] If so, then generate a successful verification result;
[0098] If not, a verification result indicating verification failure will be generated.
[0099] Step 28: The test client generates performance test results for the service under test based on the verification results.
[0100] In some embodiments, after generating the performance test results of the service under test, the test client can send a data acquisition request to the SE simulation module;
[0101] The SE simulation module sends the current device data of the SE simulation module to the test client;
[0102] The test client sends the received current device data to the test device management service to store the current device data.
[0103] In the embodiments described above, the testing process requires minimal memory resources, ensuring high reliability. Even if the testing process is abnormally interrupted, it will not affect the MockSE data. Furthermore, the performance testing method provided in this application exhibits strong correlation between the tested services; for example, the over-the-air recharge test requires the device to have already performed over-the-air card activation. Moreover, permanent data storage allows for flexible testing; for instance, there is no time limit between card activation and recharge tests. The testing environment of this application is highly flexible and can be used for other project tests, improving the utilization rate of the testing environment. Other project tests may include deleting bus cards, uploading bus cards from the device to the cloud, downloading bus cards from the cloud to the device, consumption, and card swiping. Additionally, the entire testing process uses pure software simulation, requiring no physical device involvement, thus reducing testing costs.
[0104] In one example, such as Figure 3 The diagram illustrates another server-side performance testing method provided in this application, wherein the tester is a Tester, the test client is JMeter, the SE simulation module is MockSE, the test device management service is TDMS, the database managed by the test device management service is DB, and the service under test is Server, including:
[0105] 1. JMeter retrieves the test data and test start command input by the Tester;
[0106] 2. JMeter sends a device data acquisition request to TDMS based on the start test command;
[0107] 3. TDMS reads test device data from the database based on the device data acquisition request;
[0108] 4. TDMS sends test equipment data to Jmeter;
[0109] 5. JMeter sends test equipment data to MockSE;
[0110] 6. JMeter sends a test service request to the Server;
[0111] 7. The server sends a test service response to JMeter;
[0112] 8. JMeter parses the APDU commands in the test service response and sends each APDU command to MockSE.
[0113] 9. MockSE parses APDU commands, executes corresponding test operations, and sends RPDU responses to Jmeter one by one;
[0114] 10. JMeter encapsulates the RPDU response into a new test service request and sends the new test service request to the Server;
[0115] 11. The server verifies the RPDU response and sends the verification result to Jmeter. It should be noted that steps 10-11 above can be performed multiple times.
[0116] 12. JMeter generates server performance test results based on the validation results;
[0117] Furthermore, after the individual target business test is completed, perform the following steps:
[0118] 13. JMeter requests MockSE to obtain current device data;
[0119] 14. JMeter sends the current device data returned by MockSE back to TDMS;
[0120] 15. TDMS stores the current device data in the DB.
[0121] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the server-side performance testing methods described in the above embodiments.
[0122] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the server-side performance testing methods described in the above embodiments.
[0123] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0124] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0125] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0126] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0127] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.
[0128] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims in this application and their equivalents, then this application also intends to include these modifications and variations.
Claims
1. A performance test method of a server side, characterized by, In a system applied to a test client and a test server, the test server includes a mobile device security simulation module and a service under test, and the method includes: The test client sends a test service request to the service under test; the test service request includes the type of service to be tested and the device identifier of the mobile device security simulation module. The service under test establishes a communication connection based on the device identifier and the mobile device security simulation module corresponding to the device identifier, and detects whether the mobile device security simulation module can perform target service testing of the service type to be tested; If so, a test service response is sent to the test client, the test service response including multiple APDU instructions related to the target service test; The test client sends the multiple APDU commands and different test data corresponding to the service type to be tested to the mobile device security simulation module through different threads; The mobile device security simulation module performs corresponding test operations based on the multiple APDU commands and different test data corresponding to the service type to be tested, and sends RPDU responses corresponding to the APDU commands to the test client. The RPDU responses include operation result information. The test client encapsulates the RPDU response of each APDU instruction into a new test service request and sends the new test service request to the service under test. The service under test verifies each RPDU response in the new test service request and returns the verification result to the test client; Based on the verification results, the test client generates the performance test results of the service under test.
2. The method of claim 1, wherein, The test server also includes Test Equipment Management Service (TDMS); Before the test client sends a test service request to the service under test, the method further includes: The test client obtains the test data and test start command input by the tester; and based on the test start command, sends a device data acquisition request to the Test Equipment Management Service (TDMS); the device data acquisition request includes the requested type of service to be tested; the test data includes different test data corresponding to different service types. Based on the service type of the request, the Test Device Management Service (TDMS) prepares the test data for the corresponding mobile device security simulation module and sends a device data acquisition response to the test client. The device data acquisition response includes test device data and test chip-related data. The test device data includes account information and device identifier required during the test. The test client sends the test chip-related data to the mobile device security simulation module; The mobile device security simulation module loads the relevant data of the test chip into memory to complete the initialization process before the test.
3. The method as described in claim 1, characterized in that, The business types to be tested include at least one business type to be tested; The service under test checks whether the mobile device security simulation module can perform target service testing of the service type to be tested, including: After the tested service establishes a communication connection with the mobile device security simulation module corresponding to the device identifier based on the device identifier, it obtains the device status data of the mobile device security simulation module. Based on the device status data of the mobile device security simulation module, it is determined whether the mobile device security simulation module can perform target service tests corresponding to each type of service to be tested.
4. The method as described in claim 3, characterized in that, The method further includes: If the mobile device security simulation module cannot perform the target service test corresponding to each service type to be tested, a test service response is sent to the test client, and the test service response includes indication information of service test failure.
5. The method as described in claim 3, characterized in that, The different threads include threads corresponding to each business type; The test client sends the multiple APDU commands and different test data corresponding to the service type under test to the mobile device security simulation module through different threads, including: For each service type, the test client sequentially sends the multiple APDU instructions and the test data related to the corresponding APDU instructions from different test data corresponding to the service type under test to the mobile device security simulation module through any thread of the corresponding service type.
6. The method as described in claim 3, characterized in that, The service under test verifies each RPDU response in the new test service request, including: Based on the device status data and the multiple APDU commands, the service under test determines whether it can obtain all RPDU responses in the new test service request and whether the RPDU responses are valid. If so, then generate a successful verification result; If not, a verification result indicating verification failure will be generated.
7. The method as described in claim 2, characterized in that, After the test client generates the performance test results of the service under test based on the verification results, the method further includes: The test client sends a data acquisition request to the mobile device security simulation module; The mobile device security simulation module sends the current device data of the mobile device security simulation module to the test client; The test client sends the received current device data to the test device management service to store the current device data.
8. A server-side performance testing system, characterized in that, The system includes a test client and a test server. The test server includes a mobile device security simulation module and the service under test. A test client is used to send test service requests to the service under test; the test service request includes the type of service to be tested and the device identifier of the mobile device security simulation module; The service under test is used to establish a communication connection based on the device identifier and the mobile device security simulation module corresponding to the device identifier, and to detect whether the mobile device security simulation module can perform target service testing of the service type to be tested; if so, it sends a test service response to the test client, the test service response including multiple APDU instructions related to the target service test; The test client is used to send the multiple APDU commands and different test data corresponding to the service type to be tested to the mobile device security simulation module through different threads; The mobile device security simulation module is used to perform corresponding test operations based on the multiple APDU commands and different test data corresponding to the service type to be tested, and send the corresponding APDU command RPDU response to the test client. The RPDU response includes operation result information. The test client is used to encapsulate the RPDU response of each APDU instruction into a new test service request and send the new test service request to the service under test. The service under test is used to verify each RPDU response in the new test service request and return the verification result to the test client. A test client is used to generate performance test results for the service under test based on the verification results.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-7.