A method and apparatus for testing applications of a vehicle

Abstract

This application discloses a method and apparatus for testing vehicle applications, relating to the field of testing technology. The method is applied to a terminal under test and includes: establishing a communication channel with a simulation terminal via Bluetooth; generating corresponding control commands in response to a user's trigger operation on the application under test; transmitting the control commands to the simulation terminal via the communication channel, so that the simulation terminal can simulate the vehicle's processing based on the control commands and return corresponding response data via the communication channel; receiving the response data returned by the simulation terminal and verifying the application under test based on the response data. This application simulates a real vehicle using a simulation terminal, enabling closed-loop testing of vehicle applications in an environment without a real vehicle. This reduces testing costs and provides strong controllability, achieving automated testing of vehicle applications. This effectively avoids development process bottlenecks due to hardware lag, significantly shortens the testing cycle, and improves product iteration efficiency.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a method and apparatus for testing vehicle applications. Background Technology

[0002] With the rapid development of vehicle intelligence and connectivity technologies, vehicles have evolved from traditional transportation tools into mobile terminals integrating multiple intelligent functions. The accompanying vehicle applications (APPs), serving as the core bridge for user interaction with the vehicle, directly impact user experience and vehicle safety through their functional integrity and operational stability. These applications need to establish connections with the vehicle's infotainment system, electronic control unit (ECU), and other hardware modules via Bluetooth, wireless communication, etc., to enable a range of remote control and status query functions, such as vehicle power on / off, sound settings, traction control system (TCS) activation, battery status monitoring, and remote vehicle location. To ensure accurate compatibility and stable communication between the application and vehicle hardware after deployment, comprehensive integration testing is required during the development phase. This testing verifies the correctness of the entire process logic, including command transmission, response feedback, and anomaly handling. This is a crucial step in the implementation of intelligent vehicle systems.

[0003] In current technology, the common testing method for vehicle applications is the real-vehicle joint debugging mode. Specifically, after the vehicle hardware (vehicle system, ECU controller, etc.) is developed, testers install the application to be tested on a mobile terminal, go to the vehicle site, establish a communication connection with the real vehicle through the terminal, and verify the interaction effect of each function one by one.

[0004] It is evident that current testing methods for vehicle applications rely on physical vehicles, resulting in high and uncontrollable testing costs, difficulty in achieving automated testing, frequent development delays, extended testing cycles, and low product iteration efficiency. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a vehicle application testing method and apparatus. By simulating a real vehicle through a simulation terminal, the vehicle's application can undergo closed-loop testing in an environment without a physical vehicle, reducing testing costs and providing strong controllability. This enables automated testing of the vehicle's application, effectively preventing development processes from being blocked due to hardware lag, significantly shortening the testing cycle, and improving product iteration efficiency.

[0006] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a method for testing a vehicle's application, applied to a terminal under test, wherein the terminal under test runs an application to be tested, the application being used to implement remote control functions for the vehicle, the method comprising: A communication channel is established with the simulation terminal via Bluetooth; wherein the simulation terminal runs a vehicle function simulation application to simulate the real vehicle; In response to the user's triggering operation on the application under test, corresponding control commands are generated; The control commands are transmitted to the simulation terminal through the communication channel, so that the simulation terminal can simulate the vehicle's processing based on the control commands and return the corresponding response data through the communication channel. The system receives response data returned by the simulation terminal and verifies the application to be tested based on the response data.

[0007] In one possible implementation, establishing a communication channel with the simulation terminal via Bluetooth includes: Scan Bluetooth devices, identify simulation terminals running vehicle function simulation applications, and establish a communication channel with the simulation terminals.

[0008] In one possible implementation, the simulation terminal is used to simulate the vehicle's Bluetooth device, and the scanning of Bluetooth devices to identify the simulation terminal running a vehicle function simulation application includes: During the process of the simulation terminal broadcasting the vehicle's Bluetooth device information to the outside world via Bluetooth, Bluetooth devices are scanned, and based on the Bluetooth device information broadcast by the Bluetooth devices, simulation terminals running vehicle function simulation applications are identified; wherein, the Bluetooth device information includes: Bluetooth device identifier and Bluetooth service identifier.

[0009] In one possible implementation, the simulation terminal is used to simulate Bluetooth devices of multiple vehicles, and establishing a communication channel with the simulation terminal to complete Bluetooth connection pairing includes: A communication channel is established with the simulation terminal so that the terminal under test can establish a Bluetooth connection with the Bluetooth devices of the multiple vehicles simulated by the simulation terminal.

[0010] In one possible implementation, transmitting the control commands to the simulation terminal via the communication channel includes: The control command is encoded into a preset format to obtain the encoded control command; wherein, the preset format includes JSON format or binary protocol format; The encoded control instructions are written into the target feature value through the communication channel, so as to transmit the control instructions to the simulation terminal.

[0011] In one possible implementation, verifying the application to be tested based on the response data includes: The response data is parsed to obtain the simulation execution result returned by the simulation terminal; The simulation execution result is determined to match the expected execution result corresponding to the control command in order to verify the application to be tested.

[0012] In one possible implementation, the method further includes: The system receives an abnormal scenario signal simulated by the simulation terminal; wherein the abnormal scenario signal carries an identifier of the abnormal type, and the abnormal type includes at least one of: Bluetooth disconnection, control command transmission timeout, and verification failure. In response to the abnormal scenario signal, the application under test performs the processing corresponding to the abnormal scenario signal and monitors the running status of the application under test. Based on the aforementioned operating status, the application to be tested is verified.

[0013] In one possible implementation, the application under test supports enabling and disabling safe mode; transmitting the control commands to the simulation terminal via the communication channel includes: When the application under test is in safe mode, the control command is encrypted based on the preset encryption algorithm corresponding to the safe mode, and the encrypted control command is transmitted to the simulation terminal through the communication channel, so that the simulation terminal can decrypt the encrypted control command, restore the control command, simulate the vehicle's processing process based on the control command, and return the corresponding response data through the communication channel. When the application under test is in safe mode with security turned off, the control commands are transmitted directly to the simulation terminal through the communication channel.

[0014] In one possible implementation, the method further includes: Record the sending time and content of the control command, the receiving time and content of the response data, and form a complete test log.

[0015] Secondly, embodiments of this application provide a vehicle application testing device, applied to a terminal under test, wherein the terminal under test runs an application to be tested, the application being used to implement remote control functions for the vehicle, and the device includes: The channel establishment module is used to establish a communication channel with the simulation terminal via Bluetooth; wherein, the simulation terminal runs a vehicle function simulation application to simulate the real vehicle; The instruction generation module is used to generate corresponding control instructions in response to the user's trigger operation on the application to be tested; The instruction transmission module is used to transmit the control instructions to the simulation terminal through the communication channel, so that the simulation terminal can simulate the vehicle's processing based on the control instructions and return corresponding response data through the communication channel. The application testing module is used to receive response data returned by the simulation terminal and verify the application to be tested based on the response data.

[0016] Compared with existing technologies, this application has the following advantages: by simulating the communication and processing behavior of real vehicles through a simulation terminal, the application under test can carry out closed-loop testing without relying on a real vehicle or waiting for the vehicle hardware to be ready, effectively avoiding the development process being blocked due to hardware lag, significantly shortening the testing cycle and improving product iteration efficiency; at the same time, testers do not need to frequently go to the vehicle site, and a low-cost testing environment can be built simply through the Bluetooth connection between the terminal under test and the simulation terminal. Moreover, the simulation environment is not affected by external factors, has strong controllability, and is suitable for remote development and multi-person parallel testing needs. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a vehicle application testing method provided in this application embodiment; Figure 2 An example diagram of the interface of an application to be tested provided for an embodiment of this application; Figure 3 A flowchart illustrating the testing method for applications under abnormal scenarios provided in this application embodiment; Figure 4 An interactive schematic diagram of a vehicle application testing method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a vehicle application testing device provided in an embodiment of this application. Detailed Implementation

[0019] As described above, the common testing method for vehicle applications in current technology is the real-vehicle joint debugging mode. That is, the tester installs the application to be tested on a mobile terminal, goes to the vehicle site, establishes a communication connection with the real vehicle through the terminal, and verifies / tests the interactive effects of each function of the vehicle application one by one.

[0020] Current testing methods for vehicle applications typically rely on physical vehicles, requiring testers to travel to specific locations and incurring additional costs such as site rental and personnel commuting. Furthermore, real-vehicle testing is susceptible to external factors such as weather, site conditions, and vehicle condition, making it difficult to consistently reproduce test conditions and resulting in an uncontrollable testing environment. Moreover, real-vehicle testing relies on manual verification of functional interactions, and vehicle hardware lacks standardized simulation interfaces or programmable test triggering mechanisms. This prevents the automatic generation of test scenarios, transmission of instructions, and collection of results through scripting and process-based methods, hindering the implementation of automated testing. Consequently, this prolongs the testing cycle of vehicle applications and leads to inefficient product iteration.

[0021] Furthermore, existing testing requires that the vehicle hardware (vehicle infotainment system, ECU controller, etc.) be fully developed and ready. However, the hardware development cycle is usually longer than the application software development cycle, which means that the application development and testing processes cannot proceed in parallel. They can only passively wait for the hardware to arrive, which directly causes the development process to be blocked.

[0022] This application provides a method for testing vehicle applications, applied to a terminal under test (DUT). The method includes: establishing a communication channel with a simulation terminal via Bluetooth; generating corresponding control commands in response to user-triggered operations on the DUT; transmitting the control commands to the simulation terminal via the communication channel, allowing the simulation terminal to simulate the vehicle's processing based on the control commands and return corresponding response data via the communication channel; receiving the response data returned by the simulation terminal and verifying the DUT based on the response data. This application simulates the communication and processing behavior of a real vehicle using a simulation terminal, enabling the DUT to conduct closed-loop testing without relying on a real vehicle or waiting for vehicle hardware to be ready. This effectively avoids development process bottlenecks due to hardware delays, significantly shortens the testing cycle, and improves product iteration efficiency. Furthermore, it eliminates the need for testers to frequently visit the vehicle site; a low-cost testing environment can be built simply through a Bluetooth connection between the DUT and the simulation terminal. The simulation environment is unaffected by external factors, highly controllable, and adaptable to remote development and multi-person parallel testing needs.

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0024] Example 1: The following is combined Figures 1-4This application provides a detailed description of a vehicle application testing method based on its embodiments.

[0025] First, the vehicle application testing method provided in this application embodiment is applied to the terminal under test, on which the application to be tested is running. The application is used to realize the remote control function of the vehicle.

[0026] In this context, the terminal under test (DUT) refers to a terminal device with Bluetooth communication capabilities, capable of installing and running the application under test. The DUT serves as the runtime environment for the application under test, establishing a communication connection with the simulation terminal and completing command interaction and functional verification. Specifically, the DUT is generally a mobile terminal device, such as a smartphone, tablet, or portable smart terminal. As long as the mobile terminal device supports the Bluetooth protocol, has sufficient hardware performance to run the application under test, and meets the communication compatibility requirements of the simulation terminal, it can be used as the DUT in this embodiment.

[0027] It should be noted that, in the embodiments of this application, the most common terminal under test is a smartphone running the application to be tested.

[0028] The application under test refers to a mobile application (APP) specifically developed for vehicles to enable remote interaction between users and vehicles. Its core function is to establish a connection with the vehicle's infotainment system, ECU controller, and other hardware modules via wireless communication (Bluetooth communication), thereby enabling various remote control and status query operations on the vehicle. For example, the functions supported by the application under test include, but are not limited to: vehicle power on / off control, sound effect mode setting, traction control system (TCS) on / off, battery remaining power query, and remote vehicle location triggering.

[0029] like Figure 1 As shown in the embodiment of this application, a method for testing vehicle applications includes the following steps: S101. Establish a communication channel with the simulation terminal via Bluetooth connection.

[0030] The simulation terminal runs a vehicle function simulation application to simulate a real vehicle.

[0031] A simulation terminal refers to a terminal device with Bluetooth communication capabilities that runs vehicle function simulation applications. It is used to simulate the Bluetooth communication behavior, command processing logic, and status feedback mechanism of a real vehicle, providing a virtual vehicle interaction object for the application under test. Simply put, a simulation terminal is a "virtual surrogate" of a real vehicle in a test scenario, thus replicating the interaction between the vehicle and the application under test without relying on vehicle hardware. The simulation terminal can take many forms, not limited to smartphones, but also including devices with Bluetooth communication capabilities such as tablets, smartwatches, and Raspberry Pis. As long as it can run a vehicle function simulation application and broadcast Bluetooth services, it can realize the simulated interaction function of virtual vehicles. In some testing scenarios, the simulation terminal can also take the form of a hardware simulator, embedding the simulation logic into a dedicated hardware module such as a Bluetooth development board to form a dedicated "vehicle simulator". This type of hardware module does not rely on an operating system and directly simulates vehicle communication protocols through built-in firmware, adapting to the high-efficiency testing requirements of automated testing pipelines. At the same time, the simulation terminal supports a cloud-based collaborative deployment mode, which can migrate the core functions of the vehicle function simulation application, such as protocol parsing and multi-vehicle status management, to a cloud server. The terminal side only acts as a Bluetooth gateway responsible for data forwarding. The cloud can dynamically load the appropriate simulation strategy according to the testing requirements of different vehicle models, realizing "one-time configuration, multi-terminal sharing" and greatly improving the adaptability to multiple scenarios.

[0032] The vehicle function simulation application is a dedicated software installed and running on the simulation terminal. It has a built-in Bluetooth service configuration module, command response engine, state simulation module and anomaly simulation module. It enables the simulation terminal to simulate the Bluetooth broadcast of a real vehicle, parse the control commands sent by the application under test, generate simulated response data and vehicle status information, and support the simulation of various abnormal scenarios to build a closed-loop test environment. The application can be flexibly deployed to adapt to different forms of simulation terminals. It can be fully installed on general smart terminals such as smartphones and tablets to achieve independent operation with full functionality; or it can be lightweight and embedded in the firmware of a dedicated hardware simulator, streamlining non-core functions to achieve efficient simulation without an operating system, meeting the rapid response requirements of automated testing; or it can adopt a "terminal + cloud" collaborative deployment architecture, where the terminal side retains basic functions such as Bluetooth service configuration and data transmission and reception, while the core instruction parsing logic, multi-vehicle state simulation rules, and abnormal scenario configuration are deployed in the cloud. The cloud can uniformly manage multi-vehicle simulation strategies and distribute them to each terminal simulation device as needed, enabling one set of simulation logic to adapt to multiple terminals and multiple vehicle models, effectively improving the utilization rate of test resources and the ability to cover multiple scenarios, ensuring that simulation terminals of various forms can stably replicate the interaction logic of real vehicles, and providing a consistent and reliable virtual test object for the application under test.

[0033] The communication channel refers to the bidirectional data transmission link established between the terminal under test (DUT) and the emulated terminal based on the Bluetooth protocol. In one possible implementation, the communication channel established between the DUT and the emulated terminal is a GATT (Generic Attribute Profile) communication channel; the GATT communication channel is a Bluetooth data transmission link built based on the Generic Attribute Profile and is the core application layer protocol channel for data interaction between Bluetooth Low Energy devices.

[0034] For example, taking smartphone A as the terminal under test and smartphone B as the simulation terminal, smartphone B's safe vehicle function simulation application simulates a real vehicle after being launched; smartphone A installs and launches the application under test, and finds smartphone B through Bluetooth scanning; smartphone A and smartphone B establish a communication channel, at which time the application under test on smartphone A can interact with the vehicle function simulation application (i.e., the simulated vehicle) on smartphone B.

[0035] In one possible implementation, Bluetooth devices are scanned to identify emulation terminals running vehicle function simulation applications, and a communication channel is established with the emulation terminals.

[0036] Specifically, the terminal under test filters the scanned Bluetooth devices, retaining only Bluetooth devices of emulated terminals running vehicle function simulation applications and excluding irrelevant Bluetooth devices; the terminal under test initiates a Bluetooth pairing request to the identified emulated terminal, and after completing identity authentication, establishes a communication channel.

[0037] For example, taking smartphone A as the terminal under test and smartphone B as the simulated terminal, smartphone A scans five Bluetooth devices in the vicinity and identifies smartphone B among the five Bluetooth devices through filtering rules; smartphone A and smartphone B establish a communication channel.

[0038] In one possible implementation, the simulation terminal is used to simulate the vehicle's Bluetooth devices. While the simulation terminal is broadcasting the vehicle's Bluetooth device information to the outside world via Bluetooth, it scans for Bluetooth devices and identifies the simulation terminal running a vehicle function simulation application based on the broadcast Bluetooth device information.

[0039] The Bluetooth device in this context refers to the Bluetooth communication module integrated into a real vehicle (such as the Bluetooth component of the in-vehicle infotainment system or the Bluetooth interface of the ECU). Its core function is to establish a wireless connection with mobile applications, receive control commands sent by the vehicle's app (such as power on / off and activating the vehicle's TCS), and provide feedback on vehicle status information (such as battery level and fault codes). The simulation terminal, through software configuration, can fully reproduce the core communication characteristics of this device (such as broadcast message format, service type, and command parsing logic), thereby simulating the Bluetooth device of a real vehicle.

[0040] The Bluetooth device information includes: Bluetooth device identifier and Bluetooth service identifier. Bluetooth device information refers to the data set broadcast by the emulation terminal through its Bluetooth module, used to identify the identity and service capabilities of the Bluetooth devices in the vehicle. The Bluetooth device identifier is used to uniquely distinguish different Bluetooth devices and can be divided into hardware identifiers (such as the device MAC address) and custom identifiers (such as the preset device name "Car-Sim-001"), ensuring that the terminal under test can accurately locate the Bluetooth devices of the target vehicle simulated by the emulation terminal. The Bluetooth service identifier, also known as the Universal Unique Identifier (UUID) for Bluetooth services, such as "0000FFB0-0000-1000-8000-00805F9B34FB", is used to identify the specific service type provided by the Bluetooth device, ensuring that the terminal under test only establishes communication channels with the Bluetooth devices of the simulated vehicle that support that Bluetooth device, filtering out irrelevant Bluetooth devices.

[0041] Furthermore, Bluetooth device information also includes: feature value permissions.

[0042] Specifically, when the simulation terminal starts the vehicle function simulation application, the application automatically configures Bluetooth parameters to simulate the core characteristics of a real vehicle's Bluetooth device, thus simulating the vehicle's Bluetooth device. The simulation terminal continuously broadcasts the Bluetooth device information of this simulated vehicle's Bluetooth device to inform surrounding devices of its identity as a "simulated vehicle's Bluetooth device" (simulated vehicle). Subsequently, while the simulation terminal is broadcasting the vehicle's Bluetooth device information, the terminal under test initiates a Bluetooth scan, collects broadcast data from surrounding Bluetooth devices, and extracts the Bluetooth device information of each surrounding Bluetooth device. It then matches the Bluetooth device information of each Bluetooth device with the Bluetooth device information of the simulated vehicle's Bluetooth device. When both the Bluetooth device identifier and the service identifier of the collected Bluetooth device match, the collected Bluetooth device is identified as the simulated vehicle's Bluetooth device, meaning the simulation terminal running the vehicle function simulation application has been identified.

[0043] In one possible implementation, the simulation terminal is used to simulate the Bluetooth devices of multiple vehicles and establish a communication channel with the simulation terminal so that the terminal under test can establish a Bluetooth connection with the Bluetooth devices of the multiple vehicles simulated by the simulation terminal.

[0044] Specifically, the simulation terminal uses software technologies (such as Bluetooth multi-instance and BLE Mesh protocol) to simultaneously simulate Bluetooth devices from multiple real vehicles. Each simulated vehicle's Bluetooth device has an independent Bluetooth device identifier, but they share the same Bluetooth service identifier. For example, the simulation terminal uses Bluetooth multi-instance technology to create multiple virtual vehicle Bluetooth device instances (i.e., Bluetooth devices from multiple vehicles), configuring each Bluetooth device instance with an independent Bluetooth device identifier and the same Bluetooth service identifier. The simulation terminal simultaneously broadcasts the Bluetooth device information of multiple Bluetooth device instances, waiting for the terminal under test to initiate a Bluetooth connection.

[0045] When the simulation terminal simulates Bluetooth devices from multiple vehicles, and the terminal under test (DUT) establishes a communication channel with the simulation terminal, it can establish independent communication channels with the Bluetooth devices of the multiple vehicles simulated by the simulation software through this communication channel. This simulates a one-to-many Bluetooth connection for the DUT, thus adapting to batch testing scenarios involving multiple vehicles and vehicle models.

[0046] In this embodiment, there is no need to prepare multiple real vehicles or multiple simulation terminal hardware. Multi-vehicle simulation is achieved solely through virtualization using a single simulation terminal software, significantly reducing testing hardware costs and saving on testing space requirements. The terminal under test can simultaneously establish connections with multiple simulated vehicles, supporting parallel testing of multiple vehicle models and devices without needing to connect to real vehicles one by one, thus shortening the testing cycle for multiple scenarios. Furthermore, it improves testing scalability, allowing for flexible increases or decreases in the number of simulated vehicles (e.g., expanding from 3 to 8, adapting to the maximum connection count of the Bluetooth chip) without modifying the underlying connection logic, thus adapting to different batch testing needs.

[0047] S102. In response to the user's trigger operation on the application to be tested, generate corresponding control instructions.

[0048] Among them, the triggering operation refers to the interactive operation performed by the user on the application interface of the terminal under test to start a specific vehicle function, and is a prerequisite for triggering the application to generate control commands.

[0049] To make it easier to understand, the following will be combined with... Figure 2 Let me give an example of how to trigger an operation.

[0050] like Figure 2 The application interface 200 to be tested shown includes a "View Battery Status" button 201 and a "Turn on TCS" button 202. When the user clicks the "View Battery Status" button 201, the user inputs a trigger operation, i.e., the trigger operation is the user's click on the "View Battery Status" button 201.

[0051] Control commands refer to standardized data instructions generated by the application under test in response to user-triggered operations, according to a preset communication protocol, used to control or query vehicle functions. They are the core data carrier for interaction between the terminal under test and the simulation terminal (simulated vehicle). The commands must conform to the communication protocol specifications of real vehicles to ensure direct adaptation to real vehicles after testing, without requiring modification of the command logic.

[0052] Specifically, if the application under test has a mapping relationship between "trigger operation and control command", then in response to the user's trigger operation on the application under test, a control command corresponding to the trigger operation is generated based on the mapping relationship between "trigger operation and control command".

[0053] Furthermore, simultaneously, the transmission time and content of the control commands are recorded. The transmission time refers to the time when the application under test completes the standardized encapsulation of the commands and prepares to transmit them to the simulation terminal, rather than the time when the user triggers the operation; the command content refers to the complete and standardized control command data included in the command, which is encapsulated according to the preset vehicle communication protocol after the application under test responds to the user's trigger operation.

[0054] In one possible implementation, in addition to receiving control commands actively sent by the application under test, the simulation terminal also supports receiving external control commands via Wi-Fi, USB, NFC and other methods. It can be seamlessly integrated into the CI / CD system and directly drive the simulation terminal to accurately execute various test operations through automated test scripts without manual intervention, thus meeting the full-process automated testing requirements of continuous integration and continuous delivery.

[0055] S103. The control command is transmitted to the simulation terminal through the communication channel, so that the simulation terminal can simulate the vehicle's processing based on the control command and return the corresponding response data through the communication channel.

[0056] Among them, response data refers to the standardized feedback data generated by the simulation terminal after simulating the vehicle's processing, corresponding to the control commands. This includes information such as command execution results and vehicle simulation status, which is used to verify the correctness of the interactive logic of the application under test.

[0057] The process of simulating a vehicle refers to the simulation terminal replicating the core processing logic of a real vehicle (excluding the mechanical execution actions of the real vehicle) based on control commands. This includes parsing commands, judging the validity of commands, and executing the corresponding functional logic (such as the command "Enable TCS" corresponding to "Mark TCS status as enabled").

[0058] Specifically, the terminal under test (DUT) transmits control commands to the simulation terminal via the established communication channel, ensuring accurate delivery of commands without loss or crosstalk. After receiving the control commands, the simulation terminal first parses the intent of the commands and then replicates the processing logic of the real vehicle. Throughout the process, there are no actual vehicle hardware actions; only software logic simulation is used. The simulation terminal encapsulates the simulation processing results into standardized response data and pushes it to the DUT via the same communication channel, completing the entire closed loop of "command-processing-response" and providing a basis for subsequent verification of the application under test.

[0059] In this embodiment, without relying on real vehicle hardware, the complete verification of the application under test's functionality is achieved through a closed loop of instruction transmission, simulation processing, and response return, solving the test lag problem caused by real vehicle dependence. Furthermore, the simulation terminal simulates the core processing logic of a real vehicle, ensuring the consistency of the correlation between instructions and responses, and guaranteeing the authenticity and validity of the test results.

[0060] In one possible implementation, the control command is encoded into a preset format to obtain the encoded control command; the encoded control command is then written into the target feature value through a communication channel to transmit the control command to the simulation terminal.

[0061] The preset formats include JSON format or binary protocol format, which are standardized data formats agreed upon in advance by the terminal under test and the simulation terminal, adapted to Bluetooth communication channels and command parsing, to unify command encoding rules and ensure that there are no compatibility issues in cross-device interaction.

[0062] JSON format is a lightweight text format characterized by high readability and easy parsing. It is suitable for complex command parameter transmission and testing / debugging scenarios, allowing users to intuitively view command content without additional decoding. Binary protocol format is a compact binary data format characterized by high transmission efficiency, low bandwidth consumption, and low latency. It is well-suited to the high-efficiency communication needs of real-world automotive scenarios and aligns with the actual application scenarios of vehicle Bluetooth communication.

[0063] Among them, the target feature value is a preset feature value in the Bluetooth device information of the simulation terminal, which is used exclusively for receiving control commands. It is configured with write permission and is the only entry point for downlink transmission of control commands in the Bluetooth communication channel. The unique identifier of the feature value ensures the directional transmission of control commands.

[0064] In this embodiment, directional transmission is achieved by writing a preset target feature value, which avoids the control command being mistakenly transmitted to other feature values, solves the problem of transmission chaos in scenarios with multiple feature values, and ensures that the command is delivered accurately.

[0065] In one possible implementation, the application under test supports enabling and disabling security mode. When the application under test is in security mode, the control commands are encrypted using a preset encryption algorithm corresponding to the security mode. The encrypted control commands are then transmitted to the simulation terminal via a communication channel. The simulation terminal decrypts the encrypted control commands, restores the original control commands, simulates the vehicle's processing flow based on the control commands, and returns the corresponding response data via the communication channel. When the application under test is in security mode disabled, the control commands are directly transmitted to the simulation terminal via the communication channel.

[0066] In this context, "Security Mode" refers to the encrypted communication mode of the application under test. Enabling Security Mode means that control command transmission is encrypted throughout the entire process, adapting to the communication security requirements of real-world in-vehicle scenarios (preventing commands from being tampered with or stolen); disabling Security Mode means that plaintext communication mode is used, and control commands are transmitted directly without encryption, adapting to scenarios without security requirements such as testing, debugging, and functional verification, resulting in higher transmission efficiency.

[0067] The preset encryption algorithm refers to the symmetric encryption algorithm pre-defined for the application and simulation terminal under test. Lightweight, high-efficiency algorithms (such as AES-128 and SM4) are further optimized to ensure that encryption and decryption efficiency does not affect the smoothness of the test. Encryption processing refers to encrypting and converting control commands according to the preset encryption algorithm to generate encrypted, unparseable ciphertext control commands. Decryption processing refers to reversing the encrypted control commands according to the same preset encryption algorithm to restore the plaintext control commands (i.e., the decrypted control commands), ensuring that subsequent simulation processing executes normally.

[0068] In this embodiment, encrypted transmission in secure mode prevents instructions from being tampered with or stolen, effectively testing the security encryption function of the application under test and ensuring that it meets the security requirements of real vehicles after going online; plaintext transmission in secure mode is disabled, eliminating the need for encryption and decryption time, improving the efficiency of basic function testing, and meeting the needs of rapid iteration testing.

[0069] Furthermore, the preset encryption algorithm is consistent with that of real vehicles, and applications that pass the test can be deployed directly without modifying the secure communication logic, thus reducing development costs.

[0070] S104. Receive the response data returned by the simulation terminal, and verify the application to be tested based on the response data.

[0071] Specifically, the system receives response data returned by the simulation terminal, parses the response data, and obtains the simulation execution result returned by the simulation terminal; it then determines whether the simulation execution result matches the expected execution result corresponding to the control command, in order to verify the application under test.

[0072] The simulation execution result refers to the final result obtained after parsing the response data and performing simulated processing on the control command by the simulation terminal. It is a virtual replica of the result after the real vehicle executes the corresponding command. In one possible implementation, the simulation execution result includes: the control command execution status (success or failure) and the corresponding vehicle status (such as TCS activation status, battery level, and vehicle search trigger status).

[0073] The expected execution result refers to the standard expected feedback that the application under test has pre-stored for each type of control instruction.

[0074] Furthermore, if the simulation execution result matches the expected execution result corresponding to the control command, the application under test is determined to be functionally normal. If the simulation execution result does not match the expected execution result corresponding to the control command, the application under test is determined to be functionally abnormal.

[0075] In this embodiment, functional verification of the application under test is completed without relying on real vehicles, through response parsing and result comparison, thus solving the problems of reliance on and lag in existing real vehicle testing. Furthermore, based on the preset expected execution results as a benchmark, the comparison dimensions are clear, avoiding the subjective bias of manual verification, ensuring that the verification results are repeatable and traceable, and adapting to the needs of automated testing.

[0076] Furthermore, simultaneously, the reception time and data content of the response data are recorded. The reception time refers to the time when the application under test successfully and completely receives the response data returned by the simulation terminal through the communication channel; the data content refers to the complete and original response data itself that the application under test successfully receives and that the simulation terminal returns.

[0077] In one possible implementation, the sending time and content of control commands, as well as the receiving time and content of response data, are recorded to form a complete test log. This ensures that the command content, transmission sequence, and response feedback of each interaction correspond one-to-one and can be accurately traced back. This allows for rapid identification of the root cause of problems such as failed test verification, communication anomalies, or erratic responses—whether it's a problem with the command generation and parsing logic of the application under test, or a problem with the simulation processing and communication transmission of the emulation terminal—significantly improving troubleshooting efficiency and reducing unnecessary rework. Simultaneously, the log can be automatically generated and stored, eliminating the need for manual recording. It seamlessly adapts to automated testing and continuous integration processes, automatically supporting test report generation and iteration effect feedback, improving testing efficiency, reducing testing costs, and providing complete logs as original evidence of test results, ensuring the test process is reproducible and the results are verifiable, thus enhancing the rigor and credibility of the test.

[0078] To make it easier to understand, the following will be combined with... Figure 3The present application describes the testing of applications under abnormal scenarios in its embodiments.

[0079] S301, Receive abnormal scene signals simulated by the simulation terminal.

[0080] Among them, the abnormal scenario signal is a standardized test signal generated by the simulation terminal when it deviates from the normal command interaction logic, specifically simulating various fault scenarios during the interaction between the vehicle and the application under test. Its core function is to test the fault tolerance capability of the application under test. Specifically, the abnormal scenario signal carries an identifier of the abnormal type.

[0081] The anomaly types include at least one of the following: Bluetooth disconnection, control command transmission timeout, and verification failure. Bluetooth disconnection refers to the emulation terminal actively simulating a Bluetooth communication link interruption (such as signal loss or abnormal link disconnection), simulating a real-world scenario where the distance between the vehicle and the device under test is too great or environmental interference causes a disconnection. Control command transmission timeout refers to the emulation terminal intentionally delaying or failing to respond after receiving a control command, simulating a real-world scenario where weak signal or channel congestion causes a command transmission timeout. Verification failure refers to the emulation terminal intentionally sending a verification code mismatch signal to the received control command, simulating a real-world scenario where command transmission is lost or tampered with, leading to a verification failure.

[0082] S302. In response to an abnormal scenario signal, the application under test executes the processing procedure corresponding to the abnormal scenario signal and monitors the running status of the application under test.

[0083] Among them, the running status refers to the core running status of the application under test during and after the execution of exception handling behavior. It is the core basis for verifying the exception tolerance capability of the application under test. For example, the running status includes: whether it crashes / crashes, whether there is a function freeze, whether an exception prompt is given, whether normal interaction can be restored, and whether data is lost.

[0084] S303. Verify the application to be tested based on its running status.

[0085] Specifically, based on the running status of the application under test, it is determined whether its fault tolerance mechanism and fault self-healing capability meet the preset requirements. The core verification is whether the application under test can run stably under fault scenarios, so as to avoid the user experience from being ruined by anomalies in real scenarios.

[0086] In this embodiment, a simulation terminal is used to simulate high-frequency abnormal scenarios in vehicles, such as Bluetooth disconnection, control command transmission timeout, and verification failure. This fills the gap in existing testing, which only covers normal functions and lacks testing for abnormal scenarios, thus achieving comprehensive testing of both normal and abnormal scenarios. The abnormal scenarios are generated by software simulation, posing no real fault risk and can be accurately reproduced, facilitating repeated testing and optimization. At the same time, it can accurately verify the fault tolerance mechanism and self-healing capability of the application under test. By monitoring the running status of the application under test from multiple dimensions, it can comprehensively capture abnormal handling vulnerabilities, assisting in precise optimization and significantly improving the stability and robustness of the application under test in complex vehicle scenarios. Moreover, the simulated abnormalities are completely consistent with real vehicle scenarios, and after passing the test, no logic modification is required to adapt to real vehicles, reducing the risk of going live.

[0087] The above combination Figure 3 This application details the testing of applications under abnormal scenarios in its embodiments. The following section combines... Figure 4 The following example illustrates the interaction flow in a vehicle application testing method provided in an embodiment of this application.

[0088] like Figure 4 As shown, the terminal under test 410 and the simulation terminal 420 establish a communication channel; the terminal under test 410 responds to the user's trigger operation of the application under test, generates corresponding control commands, and sends the control commands to the simulation terminal 420 through the communication channel; the simulation terminal 420 simulates the processing of a real vehicle based on the control commands, generates response data, and returns it to the terminal under test 410 through the channel; the terminal under test 410 verifies the application under test based on the response data.

[0089] This application provides a method for testing vehicle applications, applied to a terminal under test (DUT). The method includes: establishing a communication channel with a simulation terminal via Bluetooth; generating corresponding control commands in response to user-triggered operations on the DUT; transmitting the control commands to the simulation terminal via the communication channel, allowing the simulation terminal to simulate the vehicle's processing based on the control commands and return corresponding response data via the communication channel; receiving the response data returned by the simulation terminal and verifying the DUT based on the response data. This application simulates the communication and processing behavior of a real vehicle using a simulation terminal, enabling the DUT to conduct closed-loop testing without relying on a real vehicle or waiting for vehicle hardware to be ready. This effectively avoids development process bottlenecks due to hardware delays, significantly shortens the testing cycle, and improves product iteration efficiency. Furthermore, it eliminates the need for testers to frequently visit the vehicle site; a low-cost testing environment can be built simply through a Bluetooth connection between the DUT and the simulation terminal. The simulation environment is unaffected by external factors, highly controllable, and adaptable to remote development and multi-person parallel testing needs. It can also be seamlessly integrated into automated testing and continuous integration systems through standardized command interaction and verification logic, further ensuring product launch stability and comprehensively solving current technical problems.

[0090] Furthermore, by identifying the Bluetooth device information (including identifier and service identifier) ​​of the simulation terminal, the target simulation device can be accurately matched; at the same time, it supports the simulation terminal to simulate the Bluetooth devices of multiple vehicles, allowing the terminal under test to establish connections with multiple virtual vehicles at the same time, covering complex test scenarios such as "multi-vehicle adaptation and batch control", and improving the comprehensiveness of the test.

[0091] Furthermore, by matching the simulated execution results with the expected results, the correctness of the functional logic of the application under test can be accurately verified. At the same time, it supports the simulation terminal to simulate high-frequency abnormal scenarios such as Bluetooth disconnection and instruction timeout, to test the fault tolerance and self-healing capabilities of the application under test, and avoid problems such as crashes and lags caused by abnormal scenarios after going online.

[0092] Furthermore, by recording the sending information of instructions and the receiving information of responses to form a complete log, the entire testing process can be traced, making it easier to quickly locate problems.

[0093] Example 2: The following is combined Figure 5 This application provides a detailed description of a vehicle application testing device according to its embodiments.

[0094] First, the present application provides a vehicle application testing device, which is applied to a terminal under test. The terminal under test runs an application to be tested, which is used to realize the remote control function of the vehicle.

[0095] like Figure 5As shown in the figure, a vehicle application testing device provided in this application embodiment includes the following modules: The channel establishment module 501 is used to establish a communication channel with the simulation terminal via Bluetooth; wherein, the simulation terminal runs a vehicle function simulation application to simulate a real vehicle; The instruction generation module 502 is used to generate corresponding control instructions in response to the user's trigger operation of the application to be tested; The instruction transmission module 503 is used to transmit control instructions to the simulation terminal through the communication channel, so that the simulation terminal can simulate the vehicle's processing based on the control instructions and return the corresponding response data through the communication channel. The application testing module 504 is used to receive response data returned by the simulation terminal and verify the application to be tested based on the response data.

[0096] In one possible implementation, the channel establishment module 501 is specifically used to scan Bluetooth devices, identify simulation terminals running vehicle function simulation applications, and establish a communication channel with the simulation terminals.

[0097] In one possible implementation, the simulation terminal is used to simulate the vehicle's Bluetooth device. The channel establishment module 501 is specifically used to scan the Bluetooth device during the process of the simulation terminal broadcasting the Bluetooth device information of the vehicle's Bluetooth device to the outside world via Bluetooth, and to identify the simulation terminal running the vehicle function simulation application based on the Bluetooth device information broadcast by the Bluetooth device. The Bluetooth device information includes: Bluetooth device identifier and Bluetooth service identifier.

[0098] In one possible implementation, the simulation terminal is used to simulate Bluetooth devices of multiple vehicles, and the channel establishment module 501 is specifically used to establish a communication channel with the simulation terminal so that the terminal under test can establish a Bluetooth connection with the Bluetooth devices of the multiple vehicles simulated by the simulation terminal.

[0099] In one possible implementation, the instruction transmission module 503 is specifically used to encode the control instruction into a preset format to obtain the encoded control instruction; wherein the preset format includes JSON format or binary protocol format; and write the encoded control instruction into the target feature value through the communication channel to transmit the control instruction to the simulation terminal.

[0100] In one possible implementation, the application test module 504 is used to parse the response data, obtain the simulated execution result returned by the simulation terminal, and determine whether the simulated execution result matches the expected execution result corresponding to the control command, so as to verify the application under test.

[0101] In one possible implementation, the device further includes: an anomaly testing module, used to receive an anomaly scene signal simulated by the simulation terminal; wherein the anomaly scene signal carries an identifier of the anomaly type, and the anomaly type includes at least one of: Bluetooth disconnection, control command transmission timeout, and verification failure; in response to the anomaly scene signal, the application under test executes the processing procedure corresponding to the anomaly scene signal and monitors the running status of the application under test; and based on the running status, the application under test is verified.

[0102] In one possible implementation, the application under test supports enabling and disabling a secure mode. The instruction transmission module 503 is used to encrypt the control instructions based on a preset encryption algorithm corresponding to the secure mode when the application under test is in secure mode, and transmit the encrypted control instructions to the simulation terminal through the communication channel. The simulation terminal can then decrypt the encrypted control instructions, restore the control instructions, simulate the vehicle's processing based on the control instructions, and return the corresponding response data through the communication channel. When the application under test is in secure mode disabled, the control instructions are directly transmitted to the simulation terminal through the communication channel.

[0103] In one possible implementation, the device further includes a log recording module for recording the sending time and content of control commands, the receiving time and content of response data, and forming a complete test log.

[0104] This application provides a vehicle application testing device, comprising: a channel establishment module 501 for establishing a communication channel with a simulation terminal via Bluetooth; an instruction generation module 502 for generating corresponding control instructions in response to a user's triggering operation of the application to be tested; an instruction transmission module 503 for transmitting the control instructions to the simulation terminal via the communication channel, so that the simulation terminal can simulate the vehicle's processing based on the control instructions and return corresponding response data via the communication channel; and an application testing module 504 for receiving the response data returned by the simulation terminal and verifying the application to be tested based on the response data. This application's embodiments simulate the communication and processing behavior of a real vehicle using a simulation terminal, enabling the application under test to conduct closed-loop testing without relying on a real vehicle or waiting for vehicle hardware to be ready. This effectively avoids development process blockages due to hardware lag, significantly shortens the testing cycle, and improves product iteration efficiency. Simultaneously, it eliminates the need for testers to frequently visit the vehicle site; a low-cost testing environment can be built simply through a Bluetooth connection between the application under test and the simulation terminal. Furthermore, the simulation environment is unaffected by external factors, highly controllable, and adaptable to remote development and multi-person parallel testing needs. It can also be seamlessly integrated into automated testing and continuous integration systems through standardized command interaction and verification logic, further ensuring product launch stability and comprehensively solving current technical problems.

[0105] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. The components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment solution according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0106] The above is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for testing vehicle applications, characterized in that, The method is applied to a terminal under test, on which an application to be tested is running. The application is used to implement remote control functions for the vehicle. The method includes: A communication channel is established with the simulation terminal via Bluetooth; wherein the simulation terminal runs a vehicle function simulation application to simulate the real vehicle; In response to the user's triggering operation on the application under test, corresponding control commands are generated; The control commands are transmitted to the simulation terminal through the communication channel, so that the simulation terminal can simulate the vehicle's processing based on the control commands and return the corresponding response data through the communication channel. The system receives response data returned by the simulation terminal and verifies the application to be tested based on the response data.

2. The method according to claim 1, characterized in that, The step of establishing a communication channel with the simulation terminal via Bluetooth includes: Scan Bluetooth devices, identify simulation terminals running vehicle function simulation applications, and establish a communication channel with the simulation terminals.

3. The method according to claim 2, characterized in that, The simulation terminal is used to simulate the vehicle's Bluetooth device. The scanning of Bluetooth devices to identify simulation terminals running vehicle function simulation applications includes: During the process of the simulation terminal broadcasting the vehicle's Bluetooth device information to the outside world via Bluetooth, Bluetooth devices are scanned, and based on the Bluetooth device information broadcast by the Bluetooth devices, simulation terminals running vehicle function simulation applications are identified; wherein, the Bluetooth device information includes: Bluetooth device identifier and Bluetooth service identifier.

4. The method according to claim 3, characterized in that, The simulation terminal is used to simulate Bluetooth devices of multiple vehicles. Establishing a communication channel with the simulation terminal to complete Bluetooth connection pairing includes: A communication channel is established with the simulation terminal so that the terminal under test can establish a Bluetooth connection with the Bluetooth devices of the multiple vehicles simulated by the simulation terminal.

5. The method according to claim 1, characterized in that, The step of transmitting the control commands to the simulation terminal through the communication channel includes: The control command is encoded into a preset format to obtain the encoded control command; wherein, the preset format includes JSON format or binary protocol format; The encoded control instructions are written into the target feature value through the communication channel, so as to transmit the control instructions to the simulation terminal.

6. The method according to claim 1, characterized in that, The step of verifying the application to be tested based on the response data includes: The response data is parsed to obtain the simulation execution result returned by the simulation terminal; The simulation execution result is determined to match the expected execution result corresponding to the control command in order to verify the application to be tested.

7. The method according to claim 1, characterized in that, The method further includes: The system receives an abnormal scenario signal simulated by the simulation terminal; wherein the abnormal scenario signal carries an identifier of the abnormal type, and the abnormal type includes at least one of: Bluetooth disconnection, control command transmission timeout, and verification failure. In response to the abnormal scenario signal, the application under test performs the processing corresponding to the abnormal scenario signal and monitors the running status of the application under test. Based on the aforementioned operating status, the application to be tested is verified.

8. The method according to claim 1, characterized in that, The application under test supports enabling and disabling safe mode. The step of transmitting the control commands to the simulation terminal through the communication channel includes: When the application under test is in safe mode, the control command is encrypted based on the preset encryption algorithm corresponding to the safe mode, and the encrypted control command is transmitted to the simulation terminal through the communication channel, so that the simulation terminal can decrypt the encrypted control command, restore the control command, simulate the vehicle's processing process based on the control command, and return the corresponding response data through the communication channel. When the application under test is in safe mode with security turned off, the control commands are transmitted directly to the simulation terminal through the communication channel.

9. The method according to claim 1, characterized in that, The method further includes: Record the sending time and content of the control command, the receiving time and content of the response data, and form a complete test log.

10. A vehicle application testing device, characterized in that, The device is applied to a terminal under test, on which an application to be tested runs. This application is used to remotely control the vehicle. The device includes: The channel establishment module is used to establish a communication channel with the simulation terminal via Bluetooth; wherein, the simulation terminal runs a vehicle function simulation application to simulate the real vehicle; The instruction generation module is used to generate corresponding control instructions in response to the user's trigger operation on the application to be tested; The instruction transmission module is used to transmit the control instructions to the simulation terminal through the communication channel, so that the simulation terminal can simulate the vehicle's processing based on the control instructions and return corresponding response data through the communication channel. The application testing module is used to receive response data returned by the simulation terminal and verify the application to be tested based on the response data.

Images