NFC equipment testing method and device, equipment and storage medium

Abstract

The embodiment of the invention relates to an NFC equipment testing method and device, equipment and a storage medium, and the method comprises the steps: determining a target testing version selected by a user under the condition that a testing mode is an automatic mode, and obtaining a preset testing configuration file bound with the target testing version, the preset test configuration file comprises a plurality of NFC test cases and test parameters bound to each NFC test case; and executing the NFC test cases one by one based on the test parameters. According to the embodiment of the invention, when the NCF test cases are executed one by one, the test parameters can be automatically switched without manually switching the test parameters, so that the test efficiency can be improved, human errors can be prevented from being introduced, and the test consistency and stability are improved.

Description

Technical Field

[0001] This disclosure relates to the field of Near Field Communication (NFC) testing, and more particularly to a testing method, apparatus, device, and storage medium for NFC devices. Background Technology

[0002] NFC is a short-range wireless communication technology widely used in mobile payments, access control, smart tags, and IoT devices. To ensure NFC devices are compatible with and comply with international standards, the NFC Forum has developed a series of technical specifications and provides the Device Test Application (DTA) for compliance testing of NFC devices. The DTA is an official testing tool provided by the NFC Forum, designed to automate the testing of NFC devices with minimal human intervention to ensure compliance with technical specifications.

[0003] However, current DTA requires manual switching of test parameters (such as Pattern Number), which not only reduces testing efficiency but may also introduce human error, affecting the consistency and stability of the test. Summary of the Invention

[0004] To address or at least partially address the aforementioned technical problems, this disclosure provides a testing method, apparatus, device, and storage medium for NFC devices.

[0005] A first aspect of this disclosure provides a method for testing an NFC device, the method comprising: When the test mode is automatic, the target test version selected by the user is determined, and the preset test configuration file bound to the target test version is obtained. The preset test configuration file includes multiple NFC test cases and test parameters bound to each NFC test case. Based on the test parameters, the NFC test cases are executed one by one.

[0006] A second aspect of this disclosure provides a testing apparatus for an NFC device, the apparatus comprising: The first acquisition module is used to determine the target test version selected by the user when the test mode is automatic, and to acquire the preset test configuration file bound to the target test version, wherein the preset test configuration file includes multiple NFC test cases and test parameters bound to each NFC test case. The first execution module is used to execute the NFC test cases one by one based on the test parameters.

[0007] A third aspect of this disclosure provides an electronic device comprising: a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the method described in the first aspect.

[0008] A fourth aspect of this disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the method of the first aspect described above.

[0009] The technical solution provided in this disclosure has the following advantages compared with the prior art: This embodiment of the disclosure can determine the target test version selected by the user when the test mode is automatic, and obtain the preset test configuration file bound to the target test version. The preset test configuration file includes multiple NFC test cases and test parameters bound to each NFC test case. Based on the test parameters, the NFC test cases are executed one by one. Therefore, by adopting the above technical solution, test parameters can be automatically switched when executing NCF test cases one by one, eliminating the need for manual switching. This improves testing efficiency, avoids introducing human error, and enhances the consistency and stability of the test. Attached Figure Description

[0010] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0011] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart of a testing method for an NFC device provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of a user interface provided in an embodiment of this disclosure; Figure 3 This is a flowchart illustrating a test example of an NFC device provided in this disclosure embodiment; Figure 4 This is a flowchart illustrating the workflow of an automated control module during testing, as provided in an embodiment of this disclosure. Figure 5 This is a schematic diagram of the structure of a testing device for an NFC device provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this disclosure. Detailed Implementation

[0013] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0014] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0015] NFC is a short-range wireless communication technology widely used in mobile payments, access control, smart tags, and IoT devices. To ensure NFC devices are compatible with and comply with international standards, the NFC Forum has developed a series of technical specifications and provided the Device Test Application (DTA) for compliance testing of NFC devices. The DTA is an official testing tool provided by the NFC Forum, designed to automate the testing of NFC devices with minimal human intervention to ensure compliance with technical specifications. However, the current DTA requires manual switching of test parameters. For example, during Poll Mode testing, the Pattern Number still needs to be manually switched to achieve different read / write operations. This leads to the following problems: 1) Excessive manual intervention affects testing efficiency. During testing, each time a Poll Mode test case is executed, the tester needs to manually change the Pattern Number. Testers must monitor the test progress in real time and manually adjust parameters. This mode significantly reduces testing efficiency, especially during large-scale batch testing, which is time-consuming. 2) It easily introduces human error, affecting test accuracy. Manually switching Pattern Numbers is prone to errors, potentially leading to inconsistent test data, test interruptions, or even incorrect test results, impacting the final device certification outcome. 3) Lack of flexibility and difficulty in test retesting. Existing DTA only supports manual switching of Pattern Numbers. When a single test case fails, retesting requires re-executing the entire test process, wasting time and resources. In summary, existing DTA testing solutions in Poll Mode suffer from low testing efficiency, excessive manual intervention, error susceptibility, and complex retesting, affecting the development and certification of NFC devices. Therefore, an automated testing solution is urgently needed to improve testing efficiency, reduce manual intervention, and enhance testing flexibility. In view of this, this disclosure provides a testing method, apparatus, device, and storage medium for NFC devices.

[0016] Figure 1 This is a flowchart illustrating a testing method for an NFC device according to an embodiment of this disclosure. This method can be executed by an electronic device. The electronic device can be exemplarily understood as a device such as a mobile phone, tablet computer, laptop computer, desktop computer, or smart TV. Figure 1 As shown, the method provided in this embodiment includes the following steps: S110. When the test mode is automatic, determine the target test version selected by the user and obtain the preset test configuration file bound to the target test version. The preset test configuration file includes multiple NFC test cases and test parameters bound to each NFC test case.

[0017] In this embodiment, the testing method for the NFC device (i.e., the device under test) can be executed by an automated testing system integrated into the NFC device. This automated testing system decouples the test logic from the application interface to ensure efficient execution of the test process and ease of user operation. The overall architecture includes the following key modules: application interaction module, automated control module, test case management module, and test device control module.

[0018] In this embodiment of the disclosure, the application interaction module provides a user interface that allows users to select a test mode and monitor the test status and results in real time. Test modes may include, for example, an automatic mode and a manual mode. In automatic mode, no manual setting of test parameters is required, and all NFC test cases under the target test version can be run automatically. In manual mode, users can manually set test parameters through the user interface.

[0019] Specifically, the target test version is the candidate test version selected by the user from multiple candidate test versions. Different candidate test versions (such as CR13, CR14, etc.) contain different NFC test cases and / or their execution order. For example, Figure 2 This is a schematic diagram of a user interface provided in an embodiment of this disclosure. For example... Figure 2 As shown, the candidate test version (i.e. the target test version) selected by the user is CR13.

[0020] Specifically, for each candidate test version, a preset test configuration file can be created in advance based on the NFC test cases included in the candidate test version and the execution order of each NFC test case. The preset test configuration file includes each NFC test case under the candidate test version and the test parameters bound to each NFC test case.

[0021] Specifically, test parameters refer to the specific parameters set for executing NFC test cases to configure the device's communication behavior and signal characteristics. Optionally, test parameters may include at least one of the following: the number of communication devices (e.g., ...). Figure 2 (Con.Dev), Pattern Number, Data Frame Rate (e.g.) Figure 2The test configuration includes the PCDF Rate, communication role, communication scenario, card type, operating mode, test configuration associated with F-type cards, timeout period, and test steps. The number of communication devices refers to the number of devices participating in near-field communication. The Pattern Number is a predefined bit sequence identifier used to stimulate the device under test (DUT). According to the NFC Forum Analog Specification, different numbers correspond to specific data content, modulation characteristics, and timing templates, used to verify receiver decoding capabilities and transmitter signal quality. The data frame rate refers to the communication bit rate. The communication role refers to the underlying operating mode adopted by the DUT during near-field communication, specifically including Polling (active mode) and Listening (passive mode). The communication scenario refers to the typical interaction modes participated in by the DUT in near-field communication, including P2P (peer-to-peer data exchange) and HCE (host card emulation) application scenarios. Card type refers to the underlying communication technology standard used by the contactless smart card or tag that NFC devices interact with. According to the NFC Forum specification, it mainly includes four types: Type A (ISO / IEC 14443-A), Type B (ISO / IEC 14443-B), Type F (JIS X 6319-4, FeliCa), and Type V (ISO / IEC 15693). The test configuration associated with a Type F card refers to a predefined set of configuration parameters (such as...) used to execute test cases for Type F technology. Figure 2 (TSN-F, DID). Timeout refers to the maximum allowed waiting time when performing a certain NFC test operation or waiting for a specific event response. If the expected feedback signal, state change, or completion flag is not received within this time, it is judged as a timeout failure. A test step refers to the smallest executable unit that constitutes a single NFC test case, containing a set of atomic operation instructions, parameter configurations, and expected verification conditions. A test case usually consists of multiple ordered test steps used to progressively complete protocol interaction, state transition, or functional verification.

[0022] S120. Based on the test parameters, execute the NFC test cases one by one.

[0023] In this embodiment, the automation control module manages the testing process, coordinates the execution of various modules, ensures that NFC test cases run smoothly according to predetermined logic, and automatically switches test parameters. The test case management module parses test configuration files (such as preset test configuration files in automatic mode and test configuration files in manual mode), manages the loading, execution, and result storage of NFC test cases, and supports the retesting of failed NFC test cases. The test equipment control module is primarily responsible for communicating with external testing instruments to ensure the normal operation of the NFC chip in the NFC device and acquiring necessary test data during execution.

[0024] Specifically, based on test parameters, NFC test cases are automatically loaded and executed one by one, and the corresponding test parameters are dynamically loaded and applied when switching NFC test cases. Of course, before this, it is also possible to communicate with external testing instruments to ensure the normal operation of the NFC chip in the NFC device, and parse the preset test configuration file bound to the target test version to obtain multiple NFC test cases and the test parameters bound to each NFC test case.

[0025] In some embodiments, NFC test cases are executed one by one based on test parameters, including: taking the first NFC test case as the current test case and the test parameters bound to the first NFC test case as the current test parameters; issuing corresponding test control commands to the NFC chip based on the current test case and the current test parameters to drive the NFC chip to perform corresponding communication operations, and recording the feedback data returned by the NFC chip; detecting whether the current test case has been successfully tested based on the feedback data; after the current test case has been successfully tested, switching the current test case to the next test case and switching the current test parameters to the test parameters bound to the next test case; returning to the steps of issuing corresponding test control commands to the NFC chip based on the current test case and the current test parameters to drive the NFC chip to perform corresponding communication operations, and recording the feedback data returned by the NFC chip, until all NFC test cases have been successfully tested.

[0026] Specifically, when the test process starts, the first NFC test case in the preset test configuration file bound to the target test version is set as the current test case. Combined with the test parameters bound to this current test case (i.e., the current test parameters), corresponding test control commands are sent to the NFC chip. These test control commands drive the NFC chip to perform specific near-field communication operations. During this process, the raw response data returned by the NFC chip (i.e., feedback data) is simultaneously collected and recorded as the basis for subsequent judgment on whether the current test case has been successfully tested. After the current test case passes (or after the retest count reaches a threshold without success), the next NFC test case is set as the current test case, and the test parameters bound to the next NFC test case are set as the current test parameters. The above test process is repeated until all NFC test cases are successfully tested (or all have been executed). Alternatively, in some embodiments, after the current test case has been executed, regardless of whether it was successful, the next NFC test case can be immediately set as the current test case, and the test parameters bound to the next NFC test case can be set as the current test parameters, in order to quickly execute all NFC test cases.

[0027] Specifically, the implementation methods for detecting whether the test is successful include at least one of the following: 1) Response content matching detection: The communication frame content returned by the NFC chip (such as ATQA, SENSF_RES, IDm / PMm, etc.) is compared field by field with the standard response expected by the NFC test case. If all fields (including length, value, and format) are completely consistent, it is considered successful; otherwise, it fails. 2) Protocol timing compliance detection: Check whether the key time parameters in the feedback data (such as the delay from sending the command to receiving the response, frame interval, bit duration, etc.) fall within the tolerance range allowed by the NFC Forum specification. If it times out or is too fast, it is considered a failure even if the content is correct. 3) Status flag and error code parsing: Read the status register or error flag bits returned by the NFC chip (such as CRC check failure, collision detection, timeout interrupt, etc.). If any unsuccessful status code exists, the test is directly considered a failure. 4) Interaction process integrity verification: For multi-step interaction test cases (such as activation-anti-collision-selection), check whether the feedback data has completely gone through all the stages specified in the protocol. If a response to any step is missing during the process, the process is considered interrupted and the test fails. However, this is not the only limitation.

[0028] Optionally, after detecting whether the current test case has been successfully tested based on feedback data, the method further includes: retesting the current test case if it fails.

[0029] In some implementations, after detecting whether the current test case has been successfully tested based on feedback data, the following steps are also included: if the current test case fails, check whether the current test case has dependent test cases. Dependent test cases refer to NFC test cases that have a data dependency relationship with the current test case and are located before the current test case. If there are dependent test cases, re-execute the dependent test cases and the current test case one by one. If there are no dependent test cases, re-execute the current test case.

[0030] Specifically, if the execution conditions, input parameters, or initial state of the current NFC test case partially or entirely depend on the execution results, device residual state, or shared context of one or more preceding NFC test cases, then the current NFC test case is determined to have dependent test cases. In other words, if the preceding NFC test cases that the current NFC test case depends on fail, the current NFC test case will not run correctly.

[0031] Specifically, all dependent test cases and the current test case are executed one by one according to the execution order of the dependent test cases and the current test case in the preset test configuration file.

[0032] Understandably, by automatically determining whether there are dependent test cases and automatically retesting the current NFC test cases that have failed based on the determination results, occasional interference can be effectively eliminated, the reliability of results can be improved, and manual intervention can be reduced, thereby improving the robustness and efficiency of automated testing.

[0033] In other embodiments, after detecting whether the current test case has been successfully tested based on feedback data, the method further includes: if the current test case fails, in response to the user's selection operation, determining a test case to be retested, wherein the test case to be retested includes the current test case; and re-executing the test case to be retested.

[0034] Specifically, test cases to be retested refer to NFC test cases selected by the user that need to be re-executed.

[0035] Specifically, when there are multiple test cases to be retested, all test cases to be retested are executed one by one according to the execution order of the test cases in the preset test configuration file.

[0036] Understandably, by manually selecting test cases to be retested, testers are allowed to make targeted retryes of NFC test cases based on their professional judgment, thus enabling flexible and precise intervention in the retesting process.

[0037] Optionally, before executing NFC test cases one by one based on test parameters, the following steps are also included: In response to user parameter modification, the system updates the test parameters for the corresponding NFC test cases in the preset test configuration file. Then, based on the updated test parameters, each NFC test case is executed sequentially. This allows testers to manually modify the test parameters in the preset configuration file, significantly improving the flexibility and usability of the automated testing system. For example, testers only need to adjust a few key test parameters in the preset configuration file to meet testing requirements, eliminating the need to manually set complete test parameters for each NFC test case. This maintains configuration efficiency while quickly achieving flexible coverage of specific scenarios.

[0038] Optionally, after executing each NFC test case based on the test parameters, the method further includes: generating and outputting a test report, wherein the test report includes the test results of each NFC test case, the retest status of each NFC test case, the switching record of test parameters, and the status information of the NFC device.

[0039] Specifically, the test result refers to whether the NFC test case was successfully tested.

[0040] Specifically, the retesting status of NFC test cases refers to a complete record of the retry behavior performed for each NFC test case, including but not limited to: whether a retest was triggered, the number of retests, the timestamp of each execution, and the reason for failure (such as timeout, response mismatch).

[0041] Specifically, the test parameter switching record refers to the complete operation log of changing test parameters when executing different NFC test cases, including but not limited to: switching time, NFC test case ID, parameter values ​​before and after the change, etc.

[0042] Specifically, the status information of an NFC device refers to data used to characterize the operating status of the NFC device, including but not limited to: protocol layer status, register status, error flags, and radio frequency signal quality indicators.

[0043] Understandably, the output test report can systematically record the test information of each NFC test case, which not only makes it easier for testers to quickly locate problems, but also provides auditable and reproducible objective evidence for quality traceability.

[0044] The following describes the testing method for the NFC device provided in this disclosure embodiment, using a specific example. Figure 3 This is a flowchart illustrating a test example of an NFC device provided in this embodiment of the disclosure. Figure 4 This is a flowchart illustrating the workflow of an automated control module during testing, as provided in an embodiment of this disclosure. Figure 3 and Figure 4As shown, the test process includes five main stages: test initialization, test preparation, test execution, retesting of failed test cases, and test termination. Test initialization: After the test process begins, initialization operations are performed first, including software startup, application loading, and necessary resource configuration. After entering the user interface, testers can select different test modes, mainly including automatic mode and manual mode. In automatic mode, the test will be completed automatically based on the preset configuration file, which is suitable for batch testing scenarios. In manual mode, testers can manually select test parameters and customize the test process as needed, which is suitable for specific debugging or custom test requirements. After the test mode is selected, the test preparation stage begins. (2) Test preparation: The main task of the test preparation stage is to ensure that the test environment and equipment are in a usable state. This stage includes the following specific steps: Parse test configuration file: Read the test configuration file (preset test configuration file or test configuration file obtained by manually selecting test parameters) and obtain the NFC test cases to be executed and related test parameters. Initialize test equipment: Establish a communication connection with the test instrument, check whether the equipment status is normal, and perform necessary initialization operations, such as equipment self-test and calibration. Parameter configuration: According to the selected test mode and test configuration file, the corresponding test parameters are automatically loaded and prepared for subsequent test execution. After completing the above steps, the test process enters the execution phase. (3) Test execution: The test execution phase is the core part of the entire process. It will automatically execute NFC test cases according to the preset test logic. The specific process is as follows: Load test cases: Load NFC test cases one by one from the test configuration file and determine the corresponding test parameters. Automatic parameter switching: The current test case is detected by the automation control module and automatically switched according to the test case requirements during the test process to avoid manual intervention and improve test efficiency. Execute test: Send the corresponding test control instructions to the NFC chip, execute the test steps, and record test data and test results in real time. Before executing the test, the automation control module will check the current status of the NFC chip, including whether it is in an idle state and whether the previous NFC test case has been executed, to ensure that it will not affect the normal progress of the new test. If the current test case requires a specific Pattern Number (the same applies to other test parameters), the automation control module will automatically switch to the corresponding Pattern Number without manual intervention to improve test efficiency. The automation control module will also automatically analyze the test results and handle abnormal situations. For example, if the test is successful, the result will be recorded and the next test case will be entered. If the test fails, it will determine whether a retest is needed and automatically execute the retest process according to the set strategy. Test result recording: After the test is completed, the test results are automatically saved, including detailed data on successful and failed NFC test cases, for easy subsequent analysis and retesting.(4) Failed Test Case Retesting: For NFC test cases that fail during the testing process, two methods are provided: manual retesting and automatic retesting to improve testing efficiency. Automatic Retesting: It can automatically identify failed NFC test cases and re-execute them independently without affecting other test tasks, without having to start the entire test process from scratch. Manual Retesting: Users can select failed NFC test cases in the user interface and manually trigger retesting, which is suitable for analyzing specific problems or manually adjusting test parameters. After the retest is completed, new test results will be recorded again, and it will be determined whether further processing is needed based on the set test standards. (5) When all NFC test cases are executed, a test report is automatically generated and provides visualized test data statistics. The test report includes the following: test results for each NFC test case, retesting status of failed NFC test cases, key test parameters and parameter switching records, NFC device status information, test success rate, and failed test case analysis, for user reference and subsequent optimization of test strategies. After the test is completed, the connection with the test instrument is closed, the occupied resources are released, and the test process ends.

[0045] In summary, the embodiments disclosed herein eliminate the need for manual switching of test parameters such as Pattern Number through an automated control mechanism, thereby improving the automation level of DTA certification testing, reducing manual operations, increasing testing efficiency and accuracy, and enhancing testing flexibility. Specifically, a modular architecture is adopted, separating the test logic from the application interface. The test logic can be executed by an automated program, while users can still monitor the test status through the application. An automated control module is used to automatically detect the parameters required for the current test case and automatically switch them according to the requirements of the current test case, avoiding manual intervention. The current test case that fails supports manual or automatic retesting. When a single NFC test case fails, the failed test can be re-executed through automated logic without having to run the entire test process from scratch, thus improving testing efficiency.

[0046] Figure 5 This is a schematic diagram of the structure of a testing device for an NFC device provided in an embodiment of this disclosure. This testing device for an NFC device can be understood as the aforementioned NFC device or a portion of the functional modules within the aforementioned NFC device. Figure 5 As shown, the testing apparatus 80 for the NFC device includes: The first acquisition module 510 is used to determine the target test version selected by the user when the test mode is automatic mode, and to acquire the preset test configuration file bound to the target test version, wherein the preset test configuration file includes multiple NFC test cases and test parameters bound to each NFC test case. The first execution module 520 is used to execute the NFC test cases one by one based on the test parameters.

[0047] Optionally, the test parameters include at least one of the following: number of communication devices, pattern number, data frame rate, communication role, communication scenario, card type, and test configuration associated with F-type cards.

[0048] Optionally, the first execution module 520 includes: a first determining submodule, configured to use the first NFC test case as the current test case and the test parameters bound to the first NFC test case as the current test parameters; The first execution submodule is used to send corresponding test control commands to the NFC chip based on the current test case and the current test parameters, so as to drive the NFC chip to perform corresponding communication operations and record the feedback data returned by the NFC chip. The first detection submodule is used to detect whether the current test case has been successfully tested based on the feedback data. The first switching submodule is used to switch the current test case to the next test case after the current test case is successfully tested, and to switch the current test parameters to the test parameters bound to the next test case. The first return submodule is used to return the steps of issuing corresponding test control commands to the NFC chip based on the current test case and the current test parameters to drive the NFC chip to perform corresponding communication operations, and recording the feedback data returned by the NFC chip, until all the NFC test cases are successfully tested.

[0049] Optionally, the device further includes a first retest module, used to detect whether the current test case has dependent test cases in the event that the current test case fails, after the current test case has been detected as having been successfully tested based on the feedback data. The dependent test cases refer to NFC test cases that have a data dependency relationship with the current test case and are located before the current test case. If the dependent test cases exist, re-execute the dependent test cases and the current test case one by one; If the dependent test case is not available, re-execute the current test case.

[0050] Optionally, the device further includes a second retesting module, used to determine a test case to be retested in response to a user's selection operation after the current test case has been detected as having been successfully tested based on the feedback data, in the event that the current test case has failed. The test case to be retested includes the current test case. Re-execute the test cases to be retested.

[0051] Optionally, the device further includes a first modification module, which, before executing the NFC test cases one by one based on the test parameters, further includes: updating the test parameters of the corresponding NFC test cases in the preset test configuration file in response to the user's parameter modification operation.

[0052] Optionally, the device further includes a first generation module, configured to, after executing the NFC test cases one by one based on the test parameters, further include: generating and outputting a test report, wherein the test report includes the test results of each NFC test case, the retest status of each NFC test case, the switching record of the test parameters, and the status information of the NFC device.

[0053] The apparatus provided in this embodiment can execute the methods of any of the above embodiments, and its execution method and beneficial effects are similar, so they will not be described again here.

[0054] This disclosure also provides an electronic device, which includes: a memory storing a computer program; and a processor for executing the computer program, wherein when the computer program is executed by the processor, it can implement the methods of any of the above embodiments.

[0055] Example, Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this disclosure. See below for details. Figure 6 The diagram illustrates a structural schematic suitable for implementing the electronic device 1000 in the embodiments of this disclosure. The electronic device 600 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0056] like Figure 6As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of electronic device 600. Processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0057] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 600 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0058] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0059] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0060] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0061] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0062] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in any of the above embodiments.

[0063] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0064] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0065] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0066] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0067] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0068] This disclosure also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the methods of any of the above embodiments. The execution method and beneficial effects are similar, and will not be described again here.

[0069] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0070] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. 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 this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A testing method for an NFC device, characterized in that, include: When the test mode is automatic, the target test version selected by the user is determined, and the preset test configuration file bound to the target test version is obtained. The preset test configuration file includes multiple NFC test cases and test parameters bound to each NFC test case. Based on the test parameters, the NFC test cases are executed one by one.

2. The method according to claim 1, characterized in that, The test parameters include at least one of the following: number of communication devices, pattern number, data frame rate, communication role, communication scenario, card type, test configuration associated with F-type card, timeout period, and test steps.

3. The method according to claim 1, characterized in that, The step of executing the NFC test cases one by one based on the test parameters includes: The first NFC test case is used as the current test case, and the test parameters bound to the first NFC test case are used as the current test parameters; Based on the current test case and the current test parameters, a corresponding test control command is sent to the NFC chip to drive the NFC chip to perform the corresponding communication operation, and the feedback data returned by the NFC chip is recorded. Based on the feedback data, determine whether the current test case was successfully tested; After the current test case is successfully tested, the current test case is switched to the next test case, and the current test parameters are switched to the test parameters bound to the next test case; Return to the steps of issuing corresponding test control commands to the NFC chip based on the current test case and the current test parameters to drive the NFC chip to perform the corresponding communication operation, and recording the feedback data returned by the NFC chip, until all the NFC test cases are successfully tested.

4. The method according to claim 3, characterized in that, After detecting whether the current test case was successfully tested based on the feedback data, the method further includes: If the current test case fails, check whether the current test case has dependent test cases, wherein the dependent test cases refer to NFC test cases that have a data dependency relationship with the current test case and are located before the current test case; If the dependent test cases exist, re-execute the dependent test cases and the current test case one by one; If the dependent test case is not available, re-execute the current test case.

5. The method according to claim 3, characterized in that, After detecting whether the current test case was successfully tested based on the feedback data, the method further includes: If the current test case fails, in response to the user's selection operation, a test case to be retested is determined, wherein the test case to be retested includes the current test case; Re-execute the test cases to be retested.

6. The method according to claim 1, characterized in that, Before executing the NFC test cases one by one based on the test parameters, the method further includes: In response to the user's parameter modification operation, the test parameters of the corresponding NFC test case in the preset test configuration file are updated.

7. The method according to claim 1, characterized in that, After executing the NFC test cases one by one based on the test parameters, the method further includes: Generate and output a test report, which includes the test results of each NFC test case, the retest status of each NFC test case, the switching record of the test parameters, and the status information of the NFC device.

8. A testing apparatus for an NFC device, characterized in that, include: The first acquisition module is used to determine the target test version selected by the user when the test mode is automatic, and to acquire the preset test configuration file bound to the target test version, wherein the preset test configuration file includes multiple NFC test cases and test parameters bound to each NFC test case. The first execution module is used to execute the NFC test cases one by one based on the test parameters.

9. An electronic device, characterized in that, include: A processor and a memory, wherein the memory stores a computer program that, when executed by the processor, performs the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-7.

Images