Digital key test method and system

Abstract

The invention relates to a digital key test method. The method comprises the following steps: loading a test case from a test case management platform; based on a position tag in the test case, indexing a signal strength data subset corresponding to the position tag from a signal strength database; generating an instantiated test scene according to the signal strength data subset and the test case; recharging the signal intensity value corresponding to the instantiated test scene into the controller to be tested; and controlling a mobile terminal application based on the instantiated test scene so as to test the controller to be tested.

Description

Technical Field

[0001] This application relates to the field of automated testing, and more specifically, to a digital key testing method and system. Background Technology

[0002] Hardware-in-the-loop (HIL) testing is an efficient and commonly used testing method in the development and verification of automotive embedded software. A key testing step in HIL testing of Bluetooth digital key controllers is simulating the Received Signal Strength Indicator (RSSI). RSSI is a crucial parameter for measuring Bluetooth signal strength. The vehicle controller relies on the RSSI values ​​received from anchor points at different locations to calculate the relative position of the mobile terminal, thereby triggering corresponding vehicle functions (such as welcome lights illuminating, door unlocking, and vehicle start).

[0003] Currently, a common method for simulating RSSI signal variations in testing is to physically move the test phone. This method is inefficient, difficult to automate and repeat large-scale testing, and cannot accurately reproduce complex signal strength scenarios.

[0004] In existing technologies, there are also some related testing solutions. For example, some solutions use physical devices such as shielding boxes to mechanically interfere with signal strength; others obtain scenario information from the test platform and generate instructions to send to the simulated vehicle system. These solutions either rely on specific physical equipment or do not involve the direct simulation and feedback of the RSSI signal itself, making it difficult to meet the needs of efficient, comprehensive, and automated testing of Bluetooth key controllers. Summary of the Invention

[0005] According to one aspect of this application, a digital key testing method is provided, the method comprising the following steps: loading test cases from a test case management platform; indexing a subset of signal strength data corresponding to the location tags in the test cases from a signal strength database; generating an instantiated test scenario based on the subset of signal strength data and the test cases; feeding back the signal strength value corresponding to the instantiated test scenario into the controller under test; and controlling a mobile terminal application based on the instantiated test scenario to test the controller under test.

[0006] The provided digital key testing method may optionally or additionally involve obtaining the signal strength dataset in the signal strength database in advance through an acquisition device.

[0007] The provided digital key testing method may optionally or additionally generate the instantiated test scenario by traversing and combining the indexed subset of signal strength data with the mobile terminal application operation information in the test case.

[0008] The provided digital key testing method may optionally or additionally implement the power-back through one or more of the following: bus emulation and diagnostic methods.

[0009] The provided digital key testing method may optionally include, or additionally, the location label including one or more of the following: a start area and a welcome area.

[0010] According to another aspect of this application, a digital key testing system is provided, the testing system comprising: a test case loading module configured to load test cases from a test case management platform; a data indexing module configured to index a subset of signal strength data corresponding to the location tags in the test cases from a signal strength database; a scene instantiation module configured to generate an instantiated test scene based on the subset of signal strength data and the test cases; a signal feedback module configured to feed back the signal strength value corresponding to the instantiated test scene to the controller under test; and a test execution module configured to control a mobile terminal application based on the instantiated test scene to test the controller under test.

[0011] Optionally or additionally, the signal strength dataset in the signal strength database of the provided digital key testing system is pre-acquired by an acquisition device.

[0012] The provided digital key testing system may optionally or additionally configure the scenario instantiation module to generate the instantiated test scenario by traversing and combining the indexed subset of signal strength data with the mobile terminal application operation information in the test case.

[0013] The provided digital key testing system may optionally or additionally include a signal feedback module that is further configured to feed back the signal strength value corresponding to the instantiated test scenario to the controller under test via one or more of the following: bus simulation and diagnostic methods.

[0014] The provided digital key testing system may optionally include, as an alternative, location label including one or more of the following: a start area and a welcome area.

[0015] According to another aspect of this application, a program product is also provided, the program product comprising program instructions that, when executed, implement any of the methods described above.

[0016] A non-temporary storage medium is also provided, which includes program instructions that, when executed, can implement any of the methods described above.

[0017] A vehicle is also provided, the vehicle including the aforementioned digital key testing system. Attached Figure Description

[0018] The above and / or other aspects and advantages of this application will become clearer and more readily understood from the following description taken in conjunction with the accompanying drawings, in which the same or similar elements are denoted by the same reference numerals. In the drawings: Figure 1 A schematic flowchart of a digital key testing method 100 according to an embodiment of this application is shown; and Figure 2 A schematic block diagram of a digital key testing system 200 according to an embodiment of this application is shown. Detailed Implementation

[0019] The following detailed description is merely exemplary in nature and is not intended to limit the disclosed technology or its application and use. Furthermore, it is not intended to be bound by any express or implied theory presented in the foregoing technical fields, background art, or the following detailed description.

[0020] In the following detailed description of the embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it will be apparent to those skilled in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0021] Terms such as “comprising” and “including” indicate that, in addition to the units and steps that are directly and explicitly stated in the specification, the technical solution of this application does not exclude the presence of other units and steps that are not directly or explicitly stated.

[0022] In the following, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings.

[0023] Now for reference Figure 1 , Figure 1 This is a schematic flowchart of a digital key testing method 100 according to an embodiment of this application. Figure 1 As shown, this method is executed in a hardware-in-the-loop test environment that includes a host computer, a controller under test, and a mobile terminal (such as a test phone), and specifically includes the following steps: S110: Load test cases from the test case management platform; In this step, the automated test engine deployed on the test bench's host computer accesses the test case management platform via a standard communication protocol (e.g., HTTP). This platform can be a file management platform for unified management and version control of digital key controller test cases for a specific vehicle model project. The test engine queries and downloads the required automated test case set to its local machine through the platform interface. Each test case contains structured description information; the test engine reads this information and converts it into a corresponding executable automated test script, providing the instruction basis for subsequent testing.

[0024] S120: Based on the location tags in the test cases, the engine indexes a subset of signal strength data corresponding to the location tags from the signal strength database. The test engine parses the loaded test cases and extracts the defined "location tags". These tags are specified according to the positioning requirements of the controller under test and typically include categories such as "startup area", "welcome area", and "other". Subsequently, the engine accesses a pre-built RSSI (Signal Strength Index) database through the database interface.

[0025] A subset of data in the RSSI database is pre-collected using acquisition devices. The specific acquisition process involves a system comprised of a vehicle equipped with a Bluetooth controller and multiple anchor points, a high-precision positioning mobile device (such as a programmable robot or guide rail), a test mobile phone, and a dedicated acquisition program. During acquisition, the test mobile phone is fixed to the high-precision mobile device, and the program controls the device to traverse multiple pre-defined test points within different areas (such as the start-up area and welcome area) pre-defined around the vehicle. At each point, the acquisition program synchronously records the RSSI values ​​received from the test mobile phone at each anchor point on the vehicle and associates them with the current area label, ultimately forming a mapping relationship between "location label - RSSI dataset" and uploading it to the database, thus completing the database construction.

[0026] The test engine uses the location label in the test case as the query keyword to index all RSSI data records that match the label from the RSSI database, forming a subset of signal strength data.

[0027] S130: Generate instantiated test scenarios based on a subset of signal strength data and test cases. The core of this step is to combine abstract test cases with specific signal data to generate directly executable test instances. Specifically, instantiating test scenarios involves iterating and combining each data record in the indexed subset of signal strength data with the mobile terminal application operation steps described in the test case. For example, a test case might be described as: "Click the APP unlock button in the welcome area." If N different sets of "welcome area" RSSI data are indexed from the database, the "click the unlock button" operation will be repeatedly executed using these N sets of data, thereby instantiating N specific test scenarios. This process can derive a large number of test instances from a single test case, greatly expanding test coverage. Furthermore, during instantiation, generalization can be performed using mobile terminals of different brands or models connected to the test system to ensure compatibility with more devices. Simultaneously, a reasonable fluctuation range can be set for the original RSSI data to generate data with perturbations, thereby generalizing more effective test data for verifying robustness.

[0028] S140: Feedback the signal strength values ​​corresponding to the instantiated test scenario to the controller under test. After generating the test scenario, the RSSI values ​​defined in the scenario, representing the signal environment at a specific location, need to be simulated and injected into the controller under test. The feedback operation can be implemented in different ways depending on the interface and communication protocol of the actual controller. In some embodiments, it can be mainly implemented through bus emulation and diagnostic methods. Bus emulation method: The RSSI values ​​are encapsulated according to the specified message format (such as CAN message) and periodically sent to the vehicle network bus where the controller under test is located through a bus interface card (such as CANoe hardware) to simulate the process of each anchor module reporting signal strength. Diagnostic method: The RSSI values ​​are written as parameters into the corresponding storage area or signal variable inside the controller under test through a diagnostic service (such as UDS service). In addition, other specific devices or programs can also be used for feedback as needed. Through feedback, a simulated wireless signal environment is built for the controller without physically moving the mobile phone.

[0029] S150: Based on the instantiated test scenario, the mobile terminal application is controlled to test the controller under test. In this step, the test engine converts the specific description of the test scenario into actual control instructions for the mobile terminal application. For example, controlling the corresponding function buttons or controls on the mobile app. These instructions are usually issued to the test phone for execution through an automated testing framework (such as Appium). At the same time, the controller under test receives the fed-back RSSI value (simulating the phone's location) and function trigger requests (such as unlock commands) from the mobile app via a real Bluetooth link. The controller's internal software integrates these two types of inputs, performs location calculations and logical judgments, and outputs the corresponding control actions (such as issuing a door unlock command). The test engine synchronously observes the output of the controller under test (such as by listening to bus messages, reading diagnostic responses, or monitoring relay status), and automatically compares the actual output with the expected results defined in the test cases to determine whether the test passes and records the test results.

[0030] Now for reference Figure 2 , Figure 2 A schematic block diagram of a digital key testing system 200 according to an embodiment of this application is shown. Figure 2 As shown, this system, deployed in a hardware-in-the-loop test bench, is used to implement the above method and mainly includes the following functional modules: a test case loading module 210, configured to load test cases from a test case management platform. This module is responsible for communicating with the remote management platform, obtaining and parsing test case files, and providing the system with the source of test logic.

[0031] The data indexing module 220 is configured to index a subset of signal strength data corresponding to the location tags in the signal strength database. As mentioned earlier, the dataset in the signal strength database is pre-acquired by the aforementioned acquisition device. Location tags typically include categories such as start-up areas and welcome areas. This module enables efficient retrieval of massive amounts of pre-stored RSSI data.

[0032] The scenario instantiation module 230 is configured to generate instantiated test scenarios based on a subset of signal strength data and test cases.

[0033] In some embodiments, the scenario instantiation module 230 may be further configured to generate the instantiated test scenario by traversing and combining the indexed subset of signal strength data with the mobile terminal application operation information in the test cases. This module is a fusion of test data and test logic, capable of generating a queue of executable test instances in batches.

[0034] The signal feedback module 240 is configured to feed back the signal strength value corresponding to the instantiated test scenario to the controller under test.

[0035] In some embodiments, the signal feedback module 240 may be further configured to feed back the signal strength value corresponding to the instantiated test scenario to the controller under test via one or more of the following: bus emulation and diagnostic methods. This module is the execution unit for emulation signal injection and is responsible for interacting with the physical interface of the controller under test.

[0036] The test execution module 250 is configured to control a mobile terminal application based on an instantiated test scenario to test the controller under test. This module typically includes two core sub-functions: first, controlling a mobile APP to perform operations through mobile terminal automation tools; and second, observing and determining the response behavior of the controller under test through methods such as bus monitoring, diagnostic scanning, or IO acquisition, thus completing the automated test closed loop.

[0037] Through the collaborative work of the above modules, the system achieves full-process automation from test case and RSSI data management, automatic test scenario construction, signal simulation feedback to terminal control and result verification, significantly improving the testing efficiency and coverage of digital key functions.

[0038] This application also provides a program product including program instructions that, when executed, can implement any of the examples described above.

[0039] This application also provides a non-temporary storage medium storing program instructions that, when executed, can implement any of the examples described above.

[0040] This application also provides a vehicle that includes the digital key testing system described above. The vehicle referred to in this application can mean any suitable vehicle having a drive system consisting of at least a battery, a power conversion device, and a drive motor, such as a hybrid electric vehicle, an electric vehicle, a plug-in hybrid electric vehicle, etc. A hybrid electric vehicle is a vehicle having two or more power sources, such as a gasoline-powered and an electric vehicle.

[0041] The technical features in the various embodiments of this application can be combined with each other to form new implementation methods without departing from the spirit of this application and without conflicting with each other. Although specific embodiments of this application have been shown and described in detail to illustrate the principles of this application, it should be understood that this application can be implemented in other ways without departing from such principles.

Claims

1. A digital key testing method, characterized in that, The method includes the following steps: Load test cases from the test case management platform; Based on the location labels in the test cases, a subset of signal strength data corresponding to the location labels is indexed from the signal strength database; An instantiated test scenario is generated based on the subset of signal strength data and the test cases; The signal strength value corresponding to the instantiated test scenario is fed back to the controller under test; The mobile terminal application is controlled based on the instantiated test scenario to test the controller under test.

2. The method according to claim 1, characterized in that, The signal strength dataset in the signal strength database is obtained in advance by the acquisition device.

3. The method according to claim 1, characterized in that, The instantiated test scenario is generated by traversing and combining the indexed subset of signal strength data with the mobile terminal application operation information in the test case.

4. The method according to claim 1, characterized in that, The power-back is achieved through one or more of the following: bus emulation and diagnostic methods.

5. The method according to claim 1, characterized in that, The location labels include one or more of the following: start area and welcome area.

6. A digital key testing system, characterized in that, The testing system includes: The test case loading module is configured to load test cases from the test case management platform; The data indexing module is configured to index a subset of signal strength data corresponding to the location labels in the test case from the signal strength database. A scenario instantiation module is configured to generate instantiated test scenarios based on the subset of signal strength data and the test cases; The signal feedback module is configured to feed back the signal strength value corresponding to the instantiated test scenario to the controller under test; The test execution module is configured to control the mobile terminal application based on the instantiated test scenario in order to test the controller under test.

7. The system according to claim 6, characterized in that, The signal strength dataset in the signal strength database is obtained in advance by the acquisition device.

8. The system according to claim 6, characterized in that, The scenario instantiation module is further configured to generate the instantiated test scenario by traversing and combining the indexed subset of signal strength data with the mobile terminal application operation information in the test case.

9. The system according to claim 6, characterized in that, The signal feedback module is further configured to feed back the signal strength value corresponding to the instantiated test scenario to the controller under test through one or more of the following: bus simulation and diagnostic methods.

10. The system according to claim 6, characterized in that, The location labels include one or more of the following: start area and welcome area.

11. A program product, characterized in that, The program product includes program instructions that, when executed, can implement the method according to any one of claims 1 to 5.

12. A non-temporary storage medium, characterized in that, The storage medium stores program instructions that, when executed, can implement the method according to any one of claims 1 to 5.

13. A vehicle, characterized in that, The vehicle includes a digital key testing system as described in any one of claims 6-10.

Images