Smart card multi-task concurrent test method and system

Abstract

The invention provides a multi-task concurrent test method and system for an intelligent card, and relates to the technical field of intelligent card testing, and the method comprises the steps: determining a test case script according to a test task demand of a to-be-tested intelligent card; based on the test case script, a test task is issued to the test terminal, the test engine analyzes the test task, and a test operation instruction set is determined; based on the test operation instruction set, starting a plurality of test threads and drawing up a multi-task processing scene, calling a concurrent execution mechanism to carry out concurrent test on the smart card to be tested, and monitoring performance indexes; and based on the performance index monitoring result, adjusting a preset test thread number and a preset test thread load in the concurrent execution mechanism, and then outputting a test log of the to-be-tested smart card. The technical problems that in the prior art, due to the fact that a single-thread testing method is adopted, the testing efficiency is low, and the performance in an actual concurrent scene cannot be accurately tested are solved, and the intelligent card testing efficiency and the accuracy and comprehensiveness of a testing result are improved.

Description

Technical Field

[0001] This application relates to the technical field of smart card testing, and particularly to a method and system for concurrent testing of multiple tasks of a smart card. Background Art

[0002] With the wide application of smart card technology, the performance and reliability testing thereof has become a key link to ensure the security and efficiency of smart cards. Smart card testing is mainly used to verify its functional and performance manifestations under various application scenarios, including transaction speed, concurrent processing ability, and stability under complex operating conditions.

[0003] Existing smart card testing methods mostly adopt a single-threaded serial testing method, that is, each test task is executed sequentially to evaluate the functions and performance of the smart card one by one. However, this testing method has obvious limitations. On the one hand, the single-threaded testing efficiency is low, and a large number of test tasks cannot be completed in a short time, resulting in an extended testing cycle. On the other hand, in actual usage scenarios, smart cards often need to process multi-task concurrent operations. For example, at the peak of transactions, multiple user requests are processed simultaneously, or different task requirements are quickly responded to in a complex environment. The single-threaded testing method shows obvious limitations when simulating these high-load and multi-task running scenarios, and it is difficult to accurately evaluate the performance of the smart card under high load and multi-task switching, thus affecting the accuracy and comprehensiveness of the test results and unable to provide sufficient basis for the optimization and improvement of the smart card. Summary of the Invention

[0004] This application provides a method and system for concurrent testing of multiple tasks of a smart card, which solves the technical problems that the existing technology has low testing efficiency and cannot fully simulate the actual running situation of the smart card in a multi-task concurrent scenario due to the adoption of a single-threaded testing method, affecting the accuracy and comprehensiveness of the test results, and achieves the technical effects of improving the testing efficiency of the smart card and the accuracy and comprehensiveness of the test results.

[0005] In view of the above problems, on the one hand, this application provides a method for concurrent testing of multiple tasks of a smart card, and the method includes: determining a test case script according to the test task requirements of the smart card to be tested; issuing a test task to a test terminal based on the test case script; after receiving the test task, a test engine parses the test task to determine a set of test operation instructions; based on the set of test operation instructions, starting multiple test threads and formulating a multi-task processing scenario; in the multi-task processing scenario, calling a concurrent execution mechanism to perform concurrent testing on the smart card to be tested and monitoring performance indicators, where the concurrent execution mechanism includes a preset number of test threads and a preset test thread load; based on the monitoring results of the performance indicators, adjusting the preset number of test threads and the preset test thread load in the concurrent execution mechanism, and then outputting the test log of the smart card to be tested.

[0006] On the other hand, the present application also provides an intelligent card multi-task concurrent testing system, which includes: a script matching module for determining a test case script according to the test task requirements of the intelligent card to be tested; a task distribution module for distributing test tasks to a test terminal based on the test case script; a task parsing module for parsing the test task through a test engine after receiving the test task to determine a set of test operation instructions; a scenario formulation module for starting multiple test threads and formulating a multi-task processing scenario based on the set of test operation instructions; a concurrent testing module for performing concurrent testing on the intelligent card to be tested by invoking a concurrent execution mechanism in the multi-task processing scenario and monitoring performance indicators, where the concurrent execution mechanism includes a preset number of test threads and a preset test thread load; and a test log output module for adjusting the preset number of test threads and the preset test thread load in the concurrent execution mechanism based on the performance indicator monitoring results, and then outputting the test log of the intelligent card to be tested.

[0007] One or more technical solutions provided in the present application have at least the following technical effects or advantages:

[0008] By customizing the test case script according to the test task requirements of the intelligent card to be tested, it can ensure that the test can be carried out according to the specific requirements of the intelligent card to be tested, improving the pertinence and effectiveness of the test. Distributing the designed test tasks to the test terminal enables the efficient transfer and execution of the test tasks. Parsing the test tasks through the test engine to generate a specific set of test operation instructions realizes the logical transformation of the test tasks, refining the received test tasks into specific operation instructions and providing a clear execution direction for subsequent multi-threaded operations. Based on the set of test operation instructions, starting multiple test threads and formulating a multi-task processing scenario to simulate the complex environment in the actual use of the intelligent card, making the test closer to the real situation. In the multi-task processing scenario, invoking the concurrent execution mechanism to perform concurrent testing on the intelligent card and monitoring the performance indicators simultaneously can timely detect the performance of the intelligent card during multi-task concurrency. The preset number of test threads and load can control the scale and pressure of the concurrent testing, simulating concurrent tasks of different intensities. By dynamically adjusting the number of test threads and the load, the self-adaptive optimization of the test process is achieved, improving the test efficiency and the accuracy of the results. At the same time, the output test log provides detailed data support for problem location and performance evaluation.

[0009] In summary, the present application can simulate the multi-task concurrent scenario in the actual use of the smart card, and by dynamically adjusting the parameters of the concurrent execution mechanism, achieve efficient, comprehensive, and accurate testing of the smart card. This solution not only greatly improves the efficiency of smart card testing, enabling complex testing tasks to be completed in a shorter time, but also more comprehensively and accurately evaluates the performance of the smart card in the actual application by simulating a real multi-task concurrent environment, improving the accuracy and comprehensiveness of the test results, and providing strong support for the performance improvement and problem analysis of the smart card.

[0010] The above description is only an overview of the technical solution of the present application. In order to be able to more clearly understand the technical means of the present application, it can be implemented in accordance with the content of the specification. And in order to make the above and other purposes, features, and advantages of the present application more obvious and understandable, the specific embodiments of the present application are specifically exemplified below. Brief Description of the Drawings

[0011] Figure 1 It is a schematic flowchart of a smart card multi-task concurrent testing method provided by an embodiment of the present application.

[0012] Figure 2 It is a schematic structural diagram of a smart card multi-task concurrent testing system provided by an embodiment of the present application.

[0013] Description of the reference numerals: script matching module 10, task distribution module 20, task parsing module 30, scenario formulation module 40, concurrent testing module 50, test log output module 60. Detailed Embodiments

[0014] By providing a smart card multi-task concurrent testing method and system in an embodiment of the present application, the technical problem in the prior art that the testing efficiency is low and the actual running situation of the smart card in the multi-task concurrent scenario cannot be fully simulated due to the adoption of a single-thread testing method, affecting the accuracy and comprehensiveness of the test results, is solved, and the technical effects of improving the testing efficiency of the smart card and the accuracy and comprehensiveness of the test results are achieved.

[0015] Embodiment 1, as Figure 1 shown, an embodiment of the present application provides a smart card multi-task concurrent testing method, and the method includes:

[0016] Step S1: Determine the test case script according to the test task requirements of the smart card to be tested.

[0017] Specifically, the smart card to be tested can be any smart card that needs to undergo performance or function testing. The test task requirements are determined based on the application scenarios, functions, and performance requirements of the smart card to be tested. The specific requirements for testing include function testing, performance testing, security testing, etc. A test case script refers to a set that contains test inputs, execution conditions, and expected results designed to test the functions and performance of a smart card. Test cases are used to verify whether the smart card meets the design requirements.

[0018] Analyze the test task requirements such as the functions and application scenarios of the smart card to be tested. For example, if it is a mobile phone SIM card, consider its communication functions under 2G, 3G, 4G, and 5G networks, as well as the test requirements for functions such as text messages and calls. Then, based on these requirements, match the corresponding test case script from the pre-written test case scripts. Taking the mobile phone SIM card as an example, the written test case scripts include: test cases for sending text messages to different numbers (local numbers, foreign numbers, international numbers), test cases for making calls under different network signal strengths, etc.

[0019] Step S1 clarifies the specific content and expected results of the test, providing a detailed plan and guidance for subsequent testing, and ensuring the comprehensiveness and pertinence of the test.

[0020] Step S2: Based on the test case script, send the test task to the test terminal.

[0021] Specifically, the test terminal is the device that executes the test task, which can be a dedicated test instrument or an ordinary computer device, etc. For example, the test terminal for a bank card smart card may be a bank card swiping terminal emulator for simulating a real swiping environment; for a SIM card, the test terminal may be a mobile phone emulator or a real mobile phone device. According to the test case script written in Step S1, use the task sending tool to send the test task to the test terminal. For example, in an automated test framework, tasks can be sent through a test management tool such as TestRail.

[0022] Step S2 realizes the transfer of the test task from the planning stage to the execution device, enabling the test terminal to start preparing to execute the test task according to the predetermined test case script.

[0023] Step S3: After receiving the test task, the test engine parses the test task to determine the set of test operation instructions.

[0024] Specifically, the test engine is a software component responsible for executing and managing the test process. It can perform operations such as parsing test tasks, executing test operations, and collecting test results. Examples include Junit (Java), pytest (Python), TestNG, etc. The set of test operation instructions refers to the specific test operation instructions parsed from the test case script, such as card reading, card writing, verification, etc.

[0025] When the test terminal receives a test task, the test engine starts to work and calls the built-in parsing algorithm (such as a parsing algorithm based on syntax analysis) to parse the test task. Taking the smart card test of a bank card as an example, if the test task is to simulate a transaction of 100 yuan, the test engine will parse this task and break it down into a series of specific operation instructions, such as reading smart card information, verifying whether the account balance is sufficient, and performing a transfer operation. These specific operation instructions form a set of test operation instructions to guide subsequent specific test operations.

[0026] By step S3, the overall test task is refined into an executable set of test operation instructions, providing a specific execution basis for subsequent actual test operations.

[0027] Step S4: Based on the set of test operation instructions, start multiple test threads and formulate a multi-task processing scenario.

[0028] Specifically, a test thread is the smallest unit of the program execution flow. In multi-task processing, each thread can independently execute the test task of a specific function of the smart card. For example, one thread is responsible for testing the storage function of the smart card, and another thread is responsible for testing the encryption function of the smart card, etc. The multi-task processing scenario refers to the scenario of simulating the smart card processing multiple tasks simultaneously during actual use. For example, when the smart card is used in an access control system and a payment system, it may face the scenario of access control verification and payment operation simultaneously.

[0029] According to the set of test operation instructions, use multi-thread programming techniques (such as using the Thread class or Executor framework in Java to create and manage threads) to start multiple test threads. Then, according to the actual application scenario and test requirements of the smart card, formulate a multi-task processing scenario. For example, for a smart card with both bus card and electronic wallet functions, the formulated multi-task processing scenario can be: while simulating swiping the bus card, perform the consumption operation of the electronic wallet.

[0030] By step S4, starting multiple test threads and formulating a multi-task processing scenario can more realistically simulate the actual working environment of the smart card, thereby improving the reliability and effectiveness of the test results.

[0031] Step S5: In the multi-task processing scenario, call the concurrent execution mechanism to conduct concurrent testing on the smart card to be tested, and monitor performance metrics. The concurrent execution mechanism includes a preset number of test threads and a preset test thread load.

[0032] Specifically, the concurrent execution mechanism is a mechanism for managing the simultaneous execution of multiple tasks. In smart card testing, this mechanism stipulates how to start multiple test threads simultaneously for testing, including parameters such as the preset number of test threads and the preset test thread load. Among them, the preset number of test threads refers to the number of test threads started and executed simultaneously; the preset test thread load refers to the amount of tasks or resource occupancy borne by each thread. Performance metrics are metrics used to evaluate the performance of a smart card, such as response time, throughput, error rate, etc.

[0033] In the multi-task processing scenario, call the pre-set concurrent execution mechanism to conduct concurrent testing on the smart card. For example, set 10 test threads, and the load of each thread is 10 transactions per second. During the testing process, use performance monitoring tools (such as JMeter, Grafana, Prometheus, etc.) to monitor performance metrics, such as the response time and throughput of the smart card. Taking the payment function of the smart card as an example, when multiple payment operations are executed concurrently, monitor performance metrics such as the average response time of the payment operation.

[0034] Through Step S5, multiple tasks of the smart card can be tested simultaneously, and by monitoring the performance metrics, the performance of the smart card under multi-task concurrency can be understood in a timely manner.

[0035] Step S6: Based on the performance metric monitoring results, adjust the preset number of test threads and the preset test thread load in the concurrent execution mechanism, and then output the test log of the smart card to be tested.

[0036] Specifically, the performance metric monitoring results refer to the data results of the smart card performance obtained through the performance monitoring tool in Step S5. The test log refers to a detailed log recording the test process and results, including test time, test operations, performance metrics, error information, etc.

[0037] According to the performance metric monitoring results, dynamically adjust the preset number of test threads and the preset test thread load. For example, if it is found that a certain performance metric does not meet the expectation (such as the response time exceeds the set threshold), the preset number of test threads can be reduced or the load of each thread can be lowered. Record the test process and results in detail in the test log, and use a log output tool to output the test log of the smart card to be tested. The test log contains basic information about the test, test results, performance metrics, etc.

[0038] By adjusting the concurrent execution mechanism, the test process can be optimized, enabling the test results to more accurately reflect the performance of the smart card. The test log provides detailed basis for subsequent test analysis, troubleshooting, etc.

[0039] Furthermore, step S4 further includes:

[0040] Step S41: Introduce network environment parameters, where the network environment parameters include network latency, packet loss rate, and bandwidth limit.

[0041] Step S42: Simulate network conditions based on the network environment parameters.

[0042] Step S43: Under the limitation of network conditions, perform network environment configuration for the multi-task processing scenario.

[0043] Specifically, network environment parameters are some metrics used to describe the network status, including parameters such as network latency, packet loss rate, and bandwidth limit. Among them, network latency refers to the delay time of data transmission in the network, usually measured in milliseconds (ms). The packet loss rate refers to the proportion of lost data packets during network transmission, usually expressed as a percentage. Bandwidth limit refers to the maximum data rate of network transmission, usually expressed in bits per second (bps) or bytes per second (B / s).

[0044] When simulating concurrent tests, the network environment is a factor that cannot be ignored. Especially when simulating smart card applications (such as payment or identity authentication, etc.), the quality of the network directly affects the response speed of the card and the stability of the system. Therefore, in the test, by setting different network environment parameters such as network latency, packet loss rate, and bandwidth limit, various network environments in the actual use process of the smart card are simulated.

[0045] According to the determined network environment parameters, use a network simulator (such as NS-3, OPNET, etc.) to simulate network conditions. For example, in NS-3, the network conditions with a network latency of 50 ms, a packet loss rate of 3%, and a bandwidth limit of 50 Mbps can be simulated by setting the corresponding network topology structure, node attributes, etc.

[0046] Network environment configuration means configuring the test environment according to network environment parameters in the multi-task processing scenario to ensure that the test tasks are executed under the simulated network conditions. After simulating the network conditions, perform network environment configuration for each task or component in the multi-task processing scenario. For example, if there are multiple smart cards simultaneously performing data transmission tasks in the multi-task processing scenario, then according to the simulated network latency, packet loss rate, and bandwidth limit, configure parameters such as the data transmission protocol and cache size of each smart card to ensure that each test thread is affected by network latency, packet loss rate, and bandwidth limit when performing test operations.

[0047] Through the above steps, near - actual network conditions are created in the test environment, enabling the smart card to be tested in this simulated network environment, thereby more accurately evaluating the performance of the smart card under different network conditions.

[0048] Further, after determining the test operation instruction set, the method further includes:

[0049] Step S3 - 1: Define a multi - application switching instruction, where the multi - application switching instruction includes a start operation, a multi - application switching operation, and a close operation.

[0050] Step S3 - 2: Through the test engine, insert the multi - application switching instruction into the test operation instruction set to determine the test process of the smart card to be tested.

[0051] Specifically, the multi - application switching instruction refers to a set of operation instructions used to simulate the switching of the smart card between multiple applications or tasks, including start operations, multi - application switching operations, and close operations, etc. Each instruction represents an operation, helping the test engine to switch between different applications. Among them, the start operation is used to start or activate a specific application program or service. For example, start the payment function or identity authentication function in the smart card. The multi - application switching operation is used to switch between multiple applications or functions. For example, switch the payment application and the identity authentication application on the same smart card. The close operation is used to stop or close the currently active application program or service and end the operation of the current application.

[0052] During the use of the smart card, the smart card may need to switch from one application program to another (for example, from the payment application to the query application). By defining the multi - application switching instruction, the actual situations that the user may encounter during use are simulated, ensuring the integrity and authenticity of the test scenario. The multi - application switching instruction needs to be defined according to the application functions of the smart card and the actual use scenarios. First, analyze all the application functions that the smart card possesses. For example, if it is a smart card with functions such as access control, consumption, and identity recognition, determine the start, switch, and close logics for each function. Then, use a test script writing tool to define these operation instructions in the form of code. Taking TestNG as an example, functions can be created in the test script to represent the instructions for the start operation, multi - application switching operation, and close operation respectively. Using the test engine, insert the defined multi - application switching instruction into the already determined test operation instruction set to improve the test process of the smart card to be tested, so that it not only includes the test of basic functions but also covers the operation tests related to multi - application switching, thereby being able to more comprehensively and accurately test the functional integrity of the smart card and the stability of switching between different applications. For example, the test process includes starting the payment application, performing a payment operation, switching to the access control application, performing an access control operation, and closing the payment application.

[0053] Further, before outputting the test log of the smart card to be tested, it also includes:

[0054] Step S6-1: Collect the historical interaction data between the smart card to be tested and external devices.

[0055] Step S6-2: Based on the historical interaction data, simulate interaction operations according to the test case script.

[0056] Step S6-3: Meanwhile, evaluate the compatibility of the interaction process, obtain compatibility test data, and enter the compatibility test data into the test log.

[0057] Specifically, the historical interaction data refers to the data records generated when the smart card to be tested interacts with external devices (such as card readers, payment terminals, access control devices, etc.) in the past. For example, information such as the card swiping time, card swiping result (success or failure), and corresponding access control permission level when the smart card interacts with the access control device; or data such as the transaction amount, transaction time, and merchant name when the smart card conducts transactions at the payment terminal. The historical interaction data between the smart card to be tested and external devices is collected from the smart card management system, transaction log database, or the log file of the external device. These historical interaction data provide an actual reference basis for subsequent simulated interaction operations and compatibility evaluations, enabling the test to be carried out based on real interaction situations and improving the authenticity and effectiveness of the test.

[0058] Analyze the test case script to determine the interaction scenarios and operation types that need to be simulated. For example, the test case script requires simulating the interaction between the smart card and the payment terminal, including operations such as payment and refund. Then, combined with the historical interaction data, use simulation tools (such as smart card simulator software) to simulate the interaction operations. Taking the simulation of the payment operation between the smart card and the payment terminal as an example, according to information such as the payment amount range and payment frequency in the historical interaction data, set corresponding parameters in the simulator to reproduce the payment operation process, including communication with the payment terminal, data encryption and decryption, and transaction result feedback. By simulating real interaction operations, the correctness of the interaction function between the smart card and external devices can be accurately tested in the test environment, and possible interaction problems can be discovered, such as communication protocol incompatibility and data processing errors.

[0059] Compatibility test data refers to the data obtained when evaluating the compatibility of a smart card during its interaction with external devices, including data on whether the interaction is successful, whether there is data loss or errors, the interaction response time, etc. During the process of simulating interaction operations, various interaction situations are observed and recorded simultaneously. For example, check whether the communication between the smart card and the simulated external device is smooth and whether the data transmission is accurate. Use performance monitoring tools (such as Perfmon or sar, etc.) to monitor the interaction response time, and use data verification tools (such as CRC verification tools, etc.) to check whether there is data loss or errors. Obtain compatibility test data based on these observation and monitoring results. For example, record information such as the number of successful interactions, the number of failed interactions, error codes, timestamps, etc., and enter them into the test log.

[0060] Through the above steps, the test environment is made closer to the actual usage scenario, enabling a more comprehensive evaluation of the performance and compatibility of the smart card in a multi-application environment, discovering potential compatibility issues, improving the practicality and reliability of the test results, and providing valuable data support for improving the design of the smart card and optimizing its collaborative work with external devices.

[0061] Furthermore, the steps for configuring the concurrent execution mechanism include:

[0062] Based on the test case script, define the time slice size and polling strategy. Configure the concurrent execution mechanism according to the time slice size and polling strategy.

[0063] Specifically, in multitasking, a time slice refers to the small time periods into which the running time of the CPU (Central Processing Unit) is divided. The polling strategy is a method for determining the task execution order. In a multitasking scenario, the polling strategy determines how to take turns to obtain resources (such as CPU time slices) among multiple tasks to execute. Common polling strategies include First-Come, First-Served (FCFS), Shortest Job First (SJF), etc.

[0064] Define the time slice size and polling strategy according to the task requirements in the test case script and the characteristics of the smart card under test. If there are tasks in the test case script with strict requirements for task response time, such as a payment verification task that requires quick response, a smaller time slice size, such as 5 milliseconds, can be set to ensure that the task can be processed in a timely manner. For the selection of the polling strategy, if the execution times of tasks do not vary much and the order of task arrival is important, the First-Come, First-Served polling strategy can be selected. By defining the time slice size and polling strategy, the basic rules for task scheduling during concurrent execution of test tasks are clarified, which helps to reasonably allocate system resources, improve test efficiency and ensure test accuracy, enabling different types of tasks to be processed as expected.

[0065] Set relevant parameters in the concurrent execution mechanism according to the determined time slice size and polling strategy, so that the concurrent execution mechanism can run according to the predetermined rules. For example, adjust the scheduling time interval of threads according to the defined time slice size, and set the processing order of the task queue according to the polling strategy, etc.

[0066] Through the above steps, the concurrent execution mechanism can run according to the predetermined task scheduling rules, so that when conducting concurrent tests, it can manage the execution of multiple test threads more scientifically, improve the efficiency and accuracy of the tests, and better simulate the multi-task concurrent scenario in the actual operation of the smart card.

[0067] Furthermore, after step S3-2, it further includes:

[0068] Step S3-3: Define rollback conditions based on the test case script.

[0069] Step S3-4: Use the test engine to obtain the rollback rate according to the rollback conditions.

[0070] Step S3-5: Optimize and adjust the test process based on the rollback conditions and rollback rate.

[0071] Specifically, the rollback condition refers to the recovery measures that the test system should take when abnormal or unexpected situations occur during the test. During the test, some unexpected problems may be encountered, such as system crashes, function failures, or resource shortages, etc. At this time, a rollback mechanism is needed to restore the test process. The rollback condition is usually determined by the expected results and abnormal situations defined in the test case script. For example, if the output of a certain test step does not match the expectation, the rollback condition will be triggered. Exemplarily, when conducting a function test on a smart card, if the payment fails during the execution of the payment function test, the rollback condition can be defined in the test case script: when the payment fails, restart the payment module and reset the system state, and re-execute the payment test. Defining reasonable rollback conditions can ensure that when abnormal situations are encountered during the test, the stable state can be restored in time, avoiding inconsistent test results and pollution of the test environment, and improving the reliability and accuracy of the test.

[0072] The rollback rate refers to the number or proportion of times that, during the testing process, due to the triggering of rollback conditions, the system must be restored to the initial state. The rollback rate can reflect the stability of the testing environment and the effectiveness of the rollback conditions. During the testing process, the test engine monitors the execution of each test step according to the defined rollback conditions. If an exception occurs in a certain step, causing the test to fail and trigger a rollback, the test engine will record this rollback event and calculate the rollback rate (rollback rate = number of rollbacks / total number of tests). Exemplarily, when testing the payment function of a smart card, if multiple consecutive payment failures occur and trigger a rollback, the test engine will count these failure events and calculate the rollback rate. For example, if 10 tests are executed and there are 3 rollbacks, the rollback rate is 30%.

[0073] Based on the rollback rate and rollback conditions, the test engine can optimize in subsequent tests. By modifying test data, adjusting time configurations, increasing or decreasing the number of test threads, adjusting the execution order of test cases, etc., the test process can be adjusted to reduce ineffective rollback events, ensure the smooth progress of the test process, and thus improve the stability and efficiency of the test. Exemplarily, if the rollback rate is relatively high, for example, exceeding a certain threshold (such as 20%), then an in-depth analysis of the test process is required. Locate the weak links in the test process according to the rollback conditions. For example, if the rollback condition is that too many authentication failures lead to a rollback, then it is possible to check whether the test cases in the authentication link are reasonable and whether there are improper test environment settings. Adjust the test process for the problems found, and reduce the rollback rate by modifying the test data in the test case script, adjusting the configuration parameters of the test environment, changing the order of test operations, etc.

[0074] Furthermore, in step S6, based on the monitoring results of the performance metrics, adjusting the preset number of test threads and preset test thread load in the concurrent execution mechanism includes:

[0075] Step S61: Based on similar smart cards, collect historical performance metric data and build a machine learning model.

[0076] Step S62: Use the machine learning model to obtain the predicted load requirements.

[0077] Step S63: Through the monitoring results of the performance metrics, combined with the predicted load requirements, optimize the configuration of the preset number of test threads and preset test thread load in the concurrent execution mechanism.

[0078] Specifically, historical performance metric data refers to the performance data collected from previous tests of similar smart cards (such as response time, throughput, error rate, etc.), as well as data related to smart card configurations (such as memory size, chip model, etc.). The historical performance metric data is collected from historical test records. Using these historical performance metric data, a machine learning model is constructed to learn the performance change rules of smart cards under different working conditions, so as to predict the load requirements in the current test scenario. The machine learning model can be a linear regression model, a decision tree model, a neural network model, etc. An initial model is selected, and using deep learning frameworks such as TensorFlow or Scikit-learn, the initial model is trained with the historical performance metric data as the training data.

[0079] Predicting the load requirement means predicting the load that the smart card under test needs to bear based on historical data and the machine learning model. The configuration information of the smart card under test (such as function enabling status, memory usage, etc.) and the basic information of the test environment (such as the performance parameters of the test device) are input into the constructed machine learning model, and the predicted load requirement is obtained through the calculation of the model. This result includes information such as the number of tasks expected to be processed by each test thread and the proportion of resources to be occupied.

[0080] According to the results of real-time performance monitoring (such as CPU occupancy rate, memory consumption, latency, etc.) and the prediction results of the machine learning model, adjust the number of test threads and the load of each thread in the concurrent execution mechanism. If the load of a certain test thread is too high (such as the resource utilization rate is close to 100%), and the predicted load requirement indicates that part of the tasks can be shared by other threads, the load of this thread can be adjusted. For example, allocate some tasks from the high-load thread to the lower-load thread. After optimizing the configuration, continue to monitor the performance metrics and repeat the above steps continuously until a satisfactory test effect is achieved, that is, the response time is within a reasonable range, the throughput reaches the expectation, etc. By optimizing the number of test threads and the load in the concurrent execution mechanism, the load pressure in the real scenario can be simulated more accurately, while avoiding overload and resource waste, thereby improving the test efficiency and the stability of the smart card and ensuring the reliability of the test results.

[0081] Furthermore, the method described in the embodiment of the present application further includes:

[0082] Step S71: Set an error judgment mechanism through error codes and exception information.

[0083] Step S72: Use the test engine to parse the error judgment mechanism, record the error occurrence time, context environment, and error code, and give a test exception reminder.

[0084] Specifically, an error code refers to a code representing the type of error generated by a smart card or a test system during the testing process. An exception message refers to a detailed error description generated by a smart card or a test system during the testing process, including information such as the cause and location of the error. An error judgment mechanism refers to the rules and logic for judging the type and severity of an error based on the error code and the exception message. Classify and organize the error codes and exception messages that may occur during the smart card testing process. Classification can be carried out according to the functional modules of the smart card (such as communication module, storage module, application program module, etc.) and the types of testing operations (such as read operation, write operation, transaction operation, etc.). Then, set specific error judgment mechanisms according to these classifications. The setting of the error judgment mechanism enables the rapid and accurate identification of the error type during the testing process, providing a basis for subsequent error handling, analysis, and recording, and helping to improve the accuracy and efficiency of testing.

[0085] When the test engine runs test cases, it will monitor the testing process according to the parsed error judgment mechanism. Once an error is detected, immediately record the time of error occurrence, the context environment, and the error code. Among them, the time of error occurrence refers to the exact time when an exception or error is detected, usually recorded in the form of a timestamp. The context environment refers to the running environment information when the error occurs, including hardware status, operating system environment, system load, network conditions, etc. Then, according to the settings of the test environment, perform test exception reminders in different ways. For example, in an automated testing environment, the exception message can be sent to a specified log file, and at the same time, the tester can be notified by email or instant messaging tool. If it is in an integration testing environment, it can also be integrated with the test management system to display exception reminders on the system interface.

[0086] By parsing the error judgment mechanism, the test engine can capture and record various errors occurring during the testing process in real time, providing detailed information for subsequent error troubleshooting. Timely exception reminders can ensure that testers or developers quickly understand and respond to problems during the testing process, thereby improving the testing efficiency and stability.

[0087] Furthermore, the test log of the smart card to be tested output in step S6 also includes:

[0088] Step S64: Set a health verification test case script, and the health verification test case script includes a hardware status verification process for the smart card to be tested, and the hardware status verification process includes a chip temperature verification node and a battery power verification node.

[0089] Step S65: Output the test log of the smart card to be tested, and then use the health verification test case script to perform hardware status verification to obtain a verification result.

[0090] Specifically, the health verification test case script is a script written to verify the health status of the smart card under test, which includes a series of processes and operation steps for verifying the hardware status of the smart card under test. The hardware status verification process refers to the process of checking the hardware status of the smart card, including a chip temperature verification node and a battery power verification node. The chip temperature verification node is a checkpoint for monitoring the internal chip temperature of the smart card; the battery power verification node is a checkpoint for checking the battery power status of the smart card.

[0091] Design a health verification test case script in the test plan. The script includes the verification of the hardware status of the smart card, especially the chip temperature and battery power. The role of these verification nodes is to regularly check the core hardware components of the smart card to ensure that the device will not cause abnormal functions or performance degradation due to hardware problems during the process of concurrent multitasking. Exemplarily, determine the normal ranges of chip temperature and battery power according to the hardware specifications and working requirements of the smart card. For example, for a certain smart card, the normal operating temperature range of its chip may be 0 to 70 °C, and the battery power range of 20% to 100% is the normal operating range. Use programming statements to write these conditions into the health verification test case script.

[0092] After outputting the test log of the smart card under test, run the health verification test case script. According to the hardware status verification process in the script, verify the chip temperature verification node and the battery power verification node in sequence, check whether the chip temperature and battery power are within the normal ranges, and obtain the verification results. This verification result reflects whether the hardware status of the smart card is normal.

[0093] Record the hardware status verification results in the test log so that the testers can comprehensively understand the test situation of the smart card, including whether the hardware status is normal. This helps to evaluate the overall performance of the smart card, and when there are problems with the hardware status, the problem can be quickly located according to the verification results, and corresponding measures can be taken for repair or optimization.

[0094] In summary, the smart card multi-task concurrent test method provided by the embodiments of the present application has the following technical effects:

[0095] By customizing test case scripts according to the test task requirements of the smart card to be tested, it can ensure that the test can be carried out according to the specific requirements of the smart card to be tested, improving the pertinence and effectiveness of the test. Distribute the designed test tasks to the test terminals, enabling the efficient transfer and execution of the test tasks. Parse the test tasks through the test engine to generate a specific set of test operation instructions, realizing the logical transformation of the test tasks, refining the received test tasks into specific operation instructions, and providing a clear execution direction for subsequent multi-threaded operations. Based on the set of test operation instructions, start multiple test threads and formulate a multi-task processing scenario to simulate the complex environment in the actual use of the smart card, making the test closer to the real situation. In the multi-task processing scenario, call the concurrent execution mechanism to conduct concurrent tests on the smart card while monitoring performance indicators, enabling the timely discovery of the performance of the smart card during multi-task concurrency. The preset number of test threads and load can control the scale and pressure of the concurrent test, simulating concurrent tasks of different intensities. By dynamically adjusting the number of test threads and the load, the self-adaptive optimization of the test process is achieved, improving the test efficiency and the accuracy of the results. At the same time, the output test log provides detailed data support for problem location and performance evaluation. Steps such as introducing network environment parameters, defining multi-application switching instructions, and collecting historical interaction data further simulate the complex scenarios in the actual use of the smart card, evaluating its performance in terms of network conditions, multi-application switching, and compatibility. Define the time slice size, polling strategy, and rollback conditions to optimize the test process and improve the stability and reliability of the test process. Use a machine learning model to predict the load requirements to make the test configuration more scientific. Set up an error judgment mechanism and a health verification test case script to further ensure the stability of the test and the hardware reliability of the smart card.

[0096] Overall, the embodiment of the present application provides a flexible, efficient, and accurate multi-task concurrent test method for smart cards, which not only covers the testing of software functions and multi-task concurrency, but also considers various factors such as network environment, application switching, and compatibility with external device interactions, and also includes the verification of the hardware state. It can more realistically simulate the load pressure in the actual application environment, improve the test efficiency while ensuring the accuracy and comprehensiveness of the test results, and provide comprehensive data support for subsequent performance optimization.

[0097] Embodiment 2, as Figure 2 shown, based on the same inventive concept as the foregoing Embodiment 1, the embodiment of the present application provides a multi-task concurrent test system for smart cards, and the system includes:

[0098] A script matching module 10, configured to determine a test case script according to the test task requirements of the smart card to be tested.

[0099] A task distribution module 20, configured to distribute test tasks to test terminals based on the test case script.

[0100] The task parsing module 30 is configured to parse the test task through a test engine after receiving the test task, and determine a set of test operation instructions.

[0101] The scenario formulation module 40 is configured to start multiple test threads and formulate a multi-task processing scenario based on the set of test operation instructions.

[0102] The concurrent test module 50 is configured to call a concurrent execution mechanism to perform a concurrent test on the smart card under test in the multi-task processing scenario, and monitor performance metrics. The concurrent execution mechanism includes a preset number of test threads and a preset test thread load.

[0103] The test log output module 60 is configured to adjust the preset number of test threads and the preset test thread load in the concurrent execution mechanism based on the performance metric monitoring results, and then output the test log of the smart card under test.

[0104] Further, the scenario formulation module 40 in the embodiment of the present application is further configured to perform the following steps:

[0105] Introduce network environment parameters, where the network environment parameters include network latency, packet loss rate, and bandwidth limit; simulate network conditions based on the network environment parameters; and configure the network environment for the multi-task processing scenario under the limitation of the network conditions.

[0106] Further, the system in the embodiment of the present application further includes a test process determination module, and the test process determination module is configured to perform the following steps:

[0107] Define a multi-application switching instruction, where the multi-application switching instruction includes a start operation, a multi-application switching operation, and a close operation; insert the multi-application switching instruction into the set of test operation instructions through the test engine to determine the test process of the smart card under test.

[0108] Further, the system in the embodiment of the present application further includes a compatibility test module, and the compatibility test module is further configured to perform the following steps:

[0109] Collect historical interaction data between the smart card under test and external devices; simulate interaction operations according to the test case script based on the historical interaction data; at the same time, evaluate the compatibility of the interaction process, obtain compatibility test data, and enter the compatibility test data into the test log.

[0110] Further, the system in the embodiment of the present application further includes a concurrent execution configuration module, and the concurrent execution configuration module is configured to perform the following steps:

[0111] Based on the test case script, define the time slice size and polling strategy; configure the concurrent execution mechanism according to the time slice size and polling strategy.

[0112] Furthermore, the test process determination module in the embodiment of the present application is further configured to perform the following steps:

[0113] Based on the test case script, define the rollback condition; use the test engine to obtain the rollback rate according to the rollback condition; optimize and adjust the test process based on the rollback condition and rollback rate.

[0114] Furthermore, the test log output module 60 in the embodiment of the present application is further configured to perform the following steps:

[0115] Collect historical performance metric data based on similar smart cards to build a machine learning model; use the machine learning model to obtain the predicted load demand; optimize and configure the preset number of test threads and preset test thread load in the concurrent execution mechanism through the performance metric monitoring results in combination with the predicted load demand.

[0116] Furthermore, the system in the embodiment of the present application further includes an error judgment module, and the error judgment module is configured to perform the following steps:

[0117] Set an error judgment mechanism through error codes and exception information; use the test engine to parse the error judgment mechanism, and record the error occurrence time, context environment, and error code for test exception reminder.

[0118] Furthermore, the test log output module 60 in the embodiment of the present application is further configured to perform the following steps:

[0119] Set a health verification use case script, where the health verification use case script includes a hardware status verification process for the smart card to be tested, and the hardware status verification process includes a chip temperature verification node and a battery power verification node; output the test log of the smart card to be tested, and then use the health verification use case script to perform hardware status verification to obtain a verification result.

[0120] Through the foregoing detailed description of a multi-task concurrent test method for a smart card in this specification, those skilled in the art can clearly know a multi-task concurrent test system for a smart card in this embodiment. For the system disclosed in Embodiment 2, since it corresponds to the method disclosed in Embodiment 1, it has corresponding functional modules and beneficial effects. For the related parts, reference can be made to the description in the method part.

[0121] The foregoing description of the disclosed embodiments enables those skilled in the art to practice or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A smart card multi-task concurrent testing method, characterized in that: The method comprises: Determine the test case script according to the test task requirements of the smart card to be tested; Based on the test case script, send the test task to the test terminal; After receiving the test task, the test engine parses the test task and determines a set of test operation instructions; Based on the test operation instruction set, multiple test threads are started and a multi-tasking processing scenario is formulated; In the multi-task processing scenario, calling a concurrent execution mechanism to perform concurrent testing on the smart card to be tested and monitoring performance indicators, the concurrent execution mechanism including a preset number of test threads and a preset test thread load; Based on the performance indicator monitoring result, the preset number of test threads and the preset test thread load in the concurrent execution mechanism are adjusted, and then the test log of the smart card to be tested is output.

2. The method according to claim 1, characterized in that Based on the test operation instruction set, multiple test threads are started and a multi-task processing scenario is prepared, and the method further includes: Introducing network environment parameters, which include network delay, packet loss rate, and bandwidth limitation; Simulating network conditions based on the network environment parameters; Under the constraints of network conditions, a network environment configuration is performed for the multi-tasking scenario.

3. The method according to claim 1, characterized in that The method further comprises: Define a multi-application switching instruction, wherein the multi-application switching instruction includes a start operation, a multi-application switching operation, and a close operation; The test engine inserts the multi-application switching instruction into the test operation instruction set to determine the test process of the smart card to be tested.

4. The method according to claim 3, characterized in that The method comprises: Collect historical interaction data between the smart card under test and external devices; Based on the historical interaction data, simulating the interaction operation according to the test case script; At the same time, the compatibility of the interaction process is evaluated, compatibility test data is obtained, and the compatibility test data is entered into the test log.

5. The method according to claim 4, characterized in that The method further comprises: Based on the test case script, define the time slice size and polling strategy; The concurrent execution mechanism is configured according to the time slice size and the polling strategy.

6. The method according to claim 5, characterized in that The method further comprises: Based on the test case script, define rollback conditions; Using a test engine, obtaining a rollback rate according to the rollback condition; Based on the rollback conditions and rollback rate, the test process is optimized and adjusted.

7. The method according to claim 1, characterized in that Based on the performance indicator monitoring result, adjusting the preset number of test threads and the preset test thread load in the concurrent execution mechanism, the method further includes: Based on similar smart cards, collect historical performance indicator data and build machine learning models; Using the machine learning model, obtaining predicted load demand; The preset number of test threads and preset test thread load in the concurrent execution mechanism are optimized and configured based on the performance indicator monitoring results.

8. The method according to claim 1, characterized in that The method further comprises: Set up an error judgment mechanism through error codes and exception information; The test engine is used to parse the error judgment mechanism, and record the time when the error occurred, the context environment, and the error code to provide test abnormality reminders.

9. The method according to claim 1, characterized in that Outputting a test log of the smart card to be tested, the method further comprises: Setting a health verification use case script, wherein the health verification use case script includes a hardware status verification process of the smart card to be tested, wherein the hardware status verification process includes a chip temperature verification node and a battery power verification node; Output the test log of the smart card to be tested, and then use the health verification use case script to perform hardware status verification to obtain a verification result.

10. A smart card multi-task concurrent testing system, characterized in that: The system is used to execute a smart card multi-task concurrent testing method according to any one of claims 1 to 7, comprising: The script matching module is used to determine the test case script according to the test task requirements of the smart card to be tested; A task issuing module, used for issuing the test task to the test terminal based on the test case script; A task parsing module is used to, after receiving the test task, parse the test task through a test engine to determine a test operation instruction set; A scenario formulation module, used to start multiple test threads and formulate a multi-tasking processing scenario based on the test operation instruction set; A concurrent testing module, used to call a concurrent execution mechanism to perform concurrent testing on the smart card to be tested in the multi-tasking scenario and monitor performance indicators, wherein the concurrent execution mechanism includes a preset number of test threads and a preset test thread load; The test log output module is used to adjust the preset number of test threads and preset test thread load in the concurrent execution mechanism based on the performance indicator monitoring result, and then output the test log of the smart card to be tested.

Images