Ota upgrade test method, apparatus and device

Abstract

The application discloses an OTA upgrade test method, device and equipment, and belongs to the technical field of computers. The method comprises the following steps: in response to a selection operation of a target test scene on an OTA upgrade test interface, obtaining a target signal type corresponding to the target test scene, wherein the target signal type refers to a signal type of a real vehicle signal required by an OTA upgrade process corresponding to the target test scene, and the OTA upgrade test interface comprises at least i test scenes; based on the target signal type, simulating a real vehicle signal corresponding to the target signal type to obtain a target simulation signal; and based on the target simulation signal, executing a test script corresponding to the target test scene to obtain a test result of the OTA upgrade process corresponding to the target test scene. In this way, the OTA upgrade process under different test scenes can be tested, thereby solving the OTA upgrade test difficulty problem caused by the absence of a real vehicle or the inability to reach the upgrade environment of the real vehicle.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an OTA upgrade testing method, apparatus, and device. Background Technology

[0002] With the development of technology, software update technology is becoming increasingly advanced. For example, OTA (Over-the-Air) technology is gaining popularity; it's a technology that pushes software updates directly to devices via wireless networks to remotely update device software. As automobiles become more intelligent and connected, smart cars have more sensors and more complex software systems, requiring more frequent software updates to solve problems and improve performance. Therefore, the application of OTA technology in the automotive industry is becoming increasingly widespread. For automobiles, safety is a top priority. If OTA updates are incorrect or incomplete, it may lead to vehicle malfunctions or safety issues, making preliminary OTA upgrade testing particularly important.

[0003] During OTA upgrade testing, the required real vehicle signals and corresponding upgrade procedures differ for different test scenarios. However, there is no real vehicle present during testing, or the upgrade environment cannot be replicated. Therefore, it is impossible to accurately test the upgrade procedures for different test scenarios, leading to difficulties in OTA upgrade testing. Summary of the Invention

[0004] This application provides an OTA upgrade testing method, apparatus, device, and storage medium, which can simulate real vehicle signals required for different test scenarios during the OTA upgrade process. This enables testing of the OTA upgrade process under different test scenarios, thereby improving the accuracy of OTA upgrade testing and providing convenience for OTA upgrade testing. The technical solution is as follows:

[0005] Firstly, an OTA upgrade testing method is provided, the method comprising:

[0006] In response to the selection operation of the target test scenario on the OTA upgrade test interface, the target signal type corresponding to the target test scenario is obtained. The target signal type refers to the signal type of the actual vehicle signal required by the OTA upgrade process corresponding to the target test scenario. The OTA upgrade test interface includes at least i test scenarios.

[0007] Based on the target signal type, the actual vehicle signal corresponding to the target signal type is simulated to obtain the target simulated signal;

[0008] Based on the target simulated signal, the test script corresponding to the target test scenario is executed to send the target simulated signal to the vehicle system. After receiving the target simulated signal, the vehicle system executes the target upgrade process to generate the test object. Then, the test object is obtained through the vehicle system and tested to obtain the test results of the OTA upgrade process corresponding to the target test scenario.

[0009] In this application, upon receiving a selection operation for a target test scenario, the system can first obtain the target signal type corresponding to the target test scenario in response to the selection operation. Since the OTA upgrade process differs for different test scenarios, the corresponding real-vehicle signals also differ. Therefore, the signal type of the real-vehicle signal required for the OTA upgrade process of the target test scenario can be obtained first. Then, based on the target signal type, the real-vehicle signal corresponding to the target signal type is simulated to obtain the target simulated signal, which is the simulated real-vehicle signal required for the OTA upgrade process of the target test scenario. Then, based on the target simulated signal, the test script corresponding to the target test scenario is executed to obtain the test results for the target test scenario. In this way, by simulating the real-vehicle signals required for different test scenarios, the real-vehicle environment under different test scenarios can be satisfied, thus enabling the testing of OTA upgrade processes under different test scenarios. This improves the accuracy of OTA upgrade testing and provides convenience for OTA upgrade testing in different test scenarios, solving the problem of difficulties in OTA upgrade testing caused by the lack of a real vehicle or the inability to achieve the upgrade environment of a real vehicle.

[0010] Optionally, the step of responding to the selection operation of the target test scenario on the OTA upgrade test interface and obtaining the target signal type corresponding to the target test scenario includes:

[0011] In response to the selection of the target test scenario on the OTA upgrade test interface, determine whether the login account corresponding to the OTA upgrade test has the target operation permission;

[0012] If the logged-in account has the target operation permissions, obtain the target signal type corresponding to the target test scenario.

[0013] Optionally, the step of simulating the actual vehicle signal corresponding to the target signal type to obtain the target simulated signal includes:

[0014] Obtain the default signal state corresponding to the target signal type;

[0015] Obtain a signal attribute library, which includes signal values ​​corresponding to different real vehicle signals;

[0016] Based on the target signal type and the default signal state, the target signal value is obtained from the signal attribute library;

[0017] The target signal value is assigned to the actual vehicle signal corresponding to the target signal type to obtain the target analog signal corresponding to the target signal type.

[0018] Optionally, the target test scenario includes at least j test functions, and the step of obtaining the target signal type corresponding to the target test scenario in response to the selection operation of the target test scenario on the OTA upgrade test interface includes:

[0019] In response to the selection operation of the target test function in the target test scenario, the target signal type and target signal state corresponding to the target test function are determined;

[0020] The step of simulating the actual vehicle signal corresponding to the target signal type based on the target signal type to obtain the target simulated signal includes:

[0021] Based on the target signal type and the target signal state, the actual vehicle signal corresponding to the target signal type is simulated to obtain the target simulated signal.

[0022] Optionally, the target signal type includes a first signal type and a second signal type, wherein the first signal type is the same as the signal type indicated by the target test function, and the second signal type is a signal type other than the first signal type. The step of determining the target signal state includes:

[0023] Based on the target testing function, the target signal state corresponding to the first signal type is determined;

[0024] The default signal state corresponding to the second signal type during OTA upgrade testing is determined as the target signal state corresponding to the second signal type.

[0025] Optionally, the object to be tested is the interface to be tested, and the testing of the object to be tested includes:

[0026] The interface to be tested is subjected to interface content verification and interface language verification to obtain the test results of the interface to be tested.

[0027] Optionally, the step of verifying the interface content of the interface to be tested includes:

[0028] Obtain the standard display content of the interface under test, which is the text content that the interface under test should originally display during the OTA upgrade test;

[0029] Determine whether the text content to be displayed on the interface under test is consistent with the standard display content;

[0030] If the text content to be displayed on the interface under test is consistent with the standard display content, the interface content verification of the interface under test is determined to be successful.

[0031] If the text content to be displayed on the interface under test is inconsistent with the standard display content, it is determined that the interface content verification of the interface under test has failed.

[0032] Optionally, the step of performing interface language verification on the interface to be tested includes:

[0033] Obtain the standard language text of the interface to be tested, wherein the standard language text refers to the standard translation text of the interface to be tested in different languages;

[0034] Obtain the development language text corresponding to the interface to be tested. The development language text refers to the language text displayed in different languages ​​by the interface to be tested during the OTA upgrade test.

[0035] If the standard language text is the same as the development language text, the interface language verification of the interface under test is deemed to have passed.

[0036] If the standard language text differs from the development language text, it is determined that the interface language verification for the interface under test has failed.

[0037] Secondly, an OTA upgrade testing device is provided, the device comprising:

[0038] The acquisition module is used to respond to the selection operation of the target test scenario on the OTA upgrade test interface, and acquire the target signal type corresponding to the target test scenario. The target signal type refers to the signal type of the real vehicle signal required by the OTA upgrade process corresponding to the target test scenario. The OTA upgrade test interface includes at least i test scenarios.

[0039] The signal simulation module is used to simulate the actual vehicle signal corresponding to the target signal type based on the target signal type to obtain the target simulated signal;

[0040] The testing module is used to execute the test script corresponding to the target test scenario based on the target simulated signal, so as to send the target simulated signal to the vehicle system. After receiving the target simulated signal, the vehicle system executes the target upgrade process to generate the test object. Then, the vehicle system obtains the test object and tests the test object to obtain the test result of the OTA upgrade process corresponding to the target test scenario.

[0041] Thirdly, a computer device is provided, the computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the above-described OTA upgrade testing method.

[0042] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described OTA upgrade testing method.

[0043] Fifthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the steps of the above-described OTA upgrade testing method.

[0044] It is understood that the beneficial effects of the second, third, fourth, and fifth aspects mentioned above can be found in the relevant descriptions in the first aspect above, and will not be repeated here. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0046] Figure 1 This is a schematic diagram of the implementation environment of an OTA upgrade testing method provided in an embodiment of this application;

[0047] Figure 2 This is a flowchart of an OTA upgrade testing method provided in an embodiment of this application;

[0048] Figure 3 This is a schematic diagram of an OTA upgrade test interface provided in an embodiment of this application;

[0049] Figure 4 This is a schematic diagram of another OTA upgrade test interface provided in an embodiment of this application;

[0050] Figure 5 This is a flowchart illustrating an OTA upgrade test for different power types, provided in an embodiment of this application.

[0051] Figure 6 This is a flowchart of an OTA upgrade test for an interface testing scenario provided in an embodiment of this application;

[0052] Figure 7This is a schematic diagram illustrating the functional implementation of an OTA upgrade testing method provided in an embodiment of this application;

[0053] Figure 8 This is a schematic diagram of the structure of an OTA upgrade testing device provided in an embodiment of this application;

[0054] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0056] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0057] First, the terms used in the embodiments of this application will be explained.

[0058] OTA (Over-The-Air) upgrades: In automotive applications, OTA upgrades generally refer to the technology of remotely upgrading the vehicle's infotainment system via a wireless network. Typically, OTA upgrades include FOTA (Firmware Over The Air) and SOTA (Software Over The Air).

[0059] FOTA upgrades refer to firmware upgrades for automobiles. For example, they can upgrade the accelerator pedal response for more linear and comfortable acceleration, or upgrade braking performance to shorten braking distance and improve driving safety.

[0060] SOTA upgrade refers to upgrading the car's software, such as upgrading the multimedia system to change the user interface, theme, or instrument panel display style.

[0061] Zhou Ligong Library: This refers to the Zhou Ligong CAN (Controller Area Network) bus development kit. The Zhou Ligong Library includes signal values ​​corresponding to different real-world vehicle signals. Developers can use the Zhou Ligong Library to more easily obtain the corresponding signal values ​​for different real-world vehicle signals, thus facilitating the development of CAN communication-related projects.

[0062] Before describing the OTA upgrade testing method provided in the embodiments of this application, the implementation environment involved in the embodiments of this application will be described first.

[0063] For example, Figure 1 This is a schematic diagram of the implementation environment of an OTA upgrade testing method provided in an embodiment of this application. See also... Figure 1 , Figure 1 This includes computer equipment 101 and vehicle-mounted equipment 102.

[0064] Computer device 101 is used to test the OTA upgrade process. For example, computer device 101 can be a desktop computer, laptop computer, PDA, or other terminal device. In this embodiment, the OTA upgrade testing method can be packaged into an OTA testing tool, and computer device 101 can be equipped with this OTA testing tool to test the OTA upgrade process.

[0065] In this embodiment of the application, during the OTA upgrade test, the computer device 101 can call the Zhou Ligong library to simulate the actual vehicle signal, and then send the simulated actual vehicle signal to the vehicle unit 102.

[0066] In some embodiments, the implementation environment of this OTA upgrade testing method may further include a signal transmitting device 103. The signal transmitting device 103 is used to send real vehicle signals to the vehicle infotainment system 102. In this embodiment, the signal transmitting device 103 may store a signal attribute library. During the OTA upgrade testing process, the computer device 101 can simulate real vehicle signals by calling this signal attribute library, and subsequently, the signal transmitting device 103 can send the simulated real vehicle signals to the vehicle infotainment system 102.

[0067] The vehicle infotainment system 102 is the vehicle infotainment device used in the OTA upgrade test. In other words, during the OTA upgrade test, the vehicle infotainment system 102 actually simulates the corresponding OTA upgrade, so that the computer device 101 can determine whether there are any problems with the vehicle infotainment system 102 during the OTA upgrade process.

[0068] Optionally, the computer device 101 communicates with the vehicle's infotainment system 102 via a wired or wireless connection.

[0069] After simulating real vehicle signals, computer device 101 can send the simulated real vehicle signals to vehicle infotainment system 102. Upon receiving the corresponding real vehicle signals, vehicle infotainment system 102 begins simulating the OTA upgrade process. Afterwards, vehicle infotainment system 102 returns the signals, interface, and other data generated during the upgrade process to computer device 101, allowing computer device 101 to test the signals and interface generated during the OTA upgrade process to verify the accuracy of the OTA upgrade process.

[0070] The application scenarios of the embodiments of this application will be further described.

[0071] Generally, the purpose of OTA upgrade testing is to ensure the safety and stability of the car after the upgrade. In other words, it is to check whether the car will experience malfunctions or safety issues after the OTA upgrade, and whether the problems that existed in the previous version have been resolved in the upgraded version.

[0072] In related technologies, when conducting OTA upgrade tests, technicians download and install the installation package from the server to enable the vehicle's infotainment system to perform an OTA upgrade. During the OTA upgrade process, technicians need to continuously monitor the upgrade process to check for any issues with the interface, data, etc. generated during the upgrade.

[0073] Because manual verification can sometimes be inaccurate, multiple OTA (Over-The-Air) upgrades are typically required to verify the accuracy of the upgraded version and ensure stability after the upgrade. However, a single OTA upgrade involves numerous signals and upgrade content, and the time required for a single OTA upgrade is considerable. Therefore, with multiple OTA upgrade tests required, the time consumed will increase exponentially. Consequently, this upgrade method incurs significant time and manpower costs and may even lead to delays in product delivery.

[0074] Furthermore, the required real-vehicle signals and corresponding upgrade procedures differ for different test scenarios during OTA upgrade testing. However, there is no real vehicle present during testing, or the upgrade environment cannot be replicated. Therefore, it is impossible to accurately test the upgrade procedures for different test scenarios, leading to difficulties in OTA upgrade testing.

[0075] For example, the automotive industry today includes vehicles with different powertrains, including traditional gasoline-powered cars, as well as emerging pure electric vehicles and hybrid vehicles. It should be understood that different powertrain types involve different types of signals and have different hardware structures; therefore, the OTA (Over-The-Air) upgrade process differs for each type of vehicle.

[0076] For OTA upgrade testing of emerging pure electric vehicles and hybrid vehicles, it is generally carried out on a test bench. However, test benches have certain limitations in simulating the actual working environment of vehicles. This can lead to situations where there is no real vehicle available or the conditions of the real vehicle cannot be met, thus causing problems such as the inability to conduct OTA upgrade tests for the relevant powertrain types.

[0077] Therefore, this application provides an OTA upgrade testing method that can be applied to scenarios where the OTA upgrade process is tested.

[0078] Specifically, the testing tool installed on the computer device can display an OTA upgrade testing interface. This interface can include at least i test scenarios. When a user wants to test the OTA upgrade process corresponding to a specific test scenario, they can click on the corresponding test scenario. The computer device then responds to the selection of this test scenario on the OTA upgrade testing interface by first obtaining the signal type and signal state of the actual vehicle signal corresponding to that test scenario. Next, based on the signal type and signal state of the actual vehicle signal corresponding to this test scenario, it simulates the actual vehicle signal required for the OTA upgrade process of that test scenario to obtain the target simulated signal. Finally, based on the target simulated signal, it executes the test script corresponding to this test scenario to send the target simulated signal to the vehicle's infotainment system. Upon receiving the target simulated signal, the vehicle's infotainment system executes the target upgrade process to generate the test object. The system then obtains the test object and tests it, thereby obtaining the test result for the OTA upgrade process corresponding to this test scenario.

[0079] In this scenario, by simulating the real vehicle signals required for different test scenarios, the actual vehicle environment under these scenarios can be satisfied, thus enabling testing of the OTA upgrade process under different test scenarios. This improves the accuracy of OTA upgrade testing and provides convenience for OTA upgrade testing in different test scenarios, solving the problem of difficulties in OTA upgrade testing caused by the lack of a real vehicle or the inability to achieve the upgrade environment of a real vehicle. Furthermore, the automated execution of the aforementioned test scripts enables automated OTA upgrade testing, saving time and manpower costs and avoiding issues related to delayed product delivery.

[0080] The OTA upgrade testing method provided in the embodiments of this application will be explained in detail below.

[0081] Figure 2 This is a flowchart illustrating an OTA upgrade testing method provided in an embodiment of this application. This method can be applied to computer devices. See also... Figure 2 The method includes the following steps.

[0082] Step 201: In response to the selection operation of the target test scenario on the OTA upgrade test interface, obtain the target signal type corresponding to the target test scenario. The target signal type refers to the signal type of the actual vehicle signal required by the OTA upgrade process corresponding to the target test scenario. The OTA upgrade test interface includes at least i test scenarios.

[0083] i is an integer greater than or equal to 1.

[0084] The OTA upgrade test interface provides technicians with test entry points for at least i test scenarios. When a technician wants to test a specific test scenario among the at least i test scenarios, they can click on the corresponding test scenario to begin testing the OTA upgrade process for that test scenario.

[0085] Optionally, the OTA upgrade test interface may include at least i scene controls, each corresponding to one of at least i test scenarios. That is, any one of the at least i test scenarios has a corresponding scene control. Furthermore, clicking on a scene control corresponding to a test scenario effectively starts the OTA upgrade process for that test scenario.

[0086] For example, Figure 3 This is a schematic diagram of an OTA upgrade test interface provided in an embodiment of this application. See also... Figure 3 , Figure 3 This includes an OTA upgrade test interface 301. The OTA upgrade test interface 301 includes multiple scenario controls 302, specifically scenario controls 302 for precondition test scenarios, fuel type test scenarios, hybrid type test scenarios, pure electric type test scenarios, and interface test scenarios. For example, if a user wants to test the OTA upgrade process in a hybrid type test scenario, they can click the scenario control 302 corresponding to the hybrid type test scenario.

[0087] It should be understood that the actual vehicle signals required for OTA upgrades differ depending on the test scenario. In such cases, after selecting the target test scenario, the required signal types of the actual vehicle signals for that scenario can be determined, i.e., which actual vehicle signals are needed, allowing for subsequent OTA upgrades.

[0088] Optionally, step 201 can be performed by: obtaining the target signal type corresponding to the target test scenario from the first correspondence based on the scenario identifier of the target test scenario.

[0089] The scene identifier of the target test scene is used to uniquely identify the target test scene.

[0090] The first correspondence is the correspondence between scene identifiers and signal types. The first correspondence includes multiple scene identifiers and multiple signal types. One scene identifier can correspond to multiple signal types.

[0091] In the embodiments of this application, the first correspondence can be pre-calibrated by a technician, who can calibrate it based on the vehicle signal file.

[0092] A vehicle signal file is a file used to store the signal types of a vehicle; that is, it can include all the signal types set on the vehicle. Optionally, this vehicle signal file can be a .dbc file, which is a file that includes all vehicle signals.

[0093] Specifically, for any one of at least i test scenarios, the technician can obtain the signal type corresponding to that test scenario from the vehicle signal file and match the scenario identifier of that test scenario with the obtained signal type. By performing this operation for each of the at least i test scenarios, the signal type corresponding to the scenario identifier of each test scenario can be obtained.

[0094] In this case, by pre-establishing the correspondence between scene identifiers and signal types, when conducting OTA upgrade testing, after selecting the target test scene, the target signal type corresponding to the target test scene can be quickly determined from the first correspondence, thereby improving the efficiency of signal type determination.

[0095] In the embodiments of this application, any one of the at least i test scenarios may also include at least j test functions.

[0096] j is an integer greater than or equal to 1.

[0097] These at least j test functions are used to implement tests under different upgrade conditions corresponding to the test scenario.

[0098] In this case, the OTA upgrade test interface can also include at least j test functions for different test scenarios. For example, Figure 4 This is a schematic diagram of another OTA upgrade test interface provided in an embodiment of this application. See also... Figure 4 , Figure 4The system includes an OTA upgrade test interface 401. This interface 401 includes multiple functional controls 402, which represent at least j test functions corresponding to each of at least i test scenarios. For example, in an interface test scenario, these controls might include controls for successful interface testing, failed interface testing, and upgrade interface testing. When a technician wants to test a specific function within a particular test scenario, they can click the corresponding control. For instance, if a technician wants to test the OTA upgrade process when the gear ratio is not met in a hybrid test scenario, they can click the control 402 for the "gear ratio not met" test function in the hybrid test scenario.

[0099] Optionally, step 201 can be performed by: in response to the selection operation of the target test function in the target test scenario, determining the target signal type and target signal state corresponding to the target test function.

[0100] The target signal state refers to the signal state of the actual vehicle signal corresponding to the target signal type. It should be understood that a single signal can include different signal states. For example, a gear position signal can include multiple different signal states, such as P, N, D, and R. Similarly, the parking status signal can include both parked and unparked states. Furthermore, the engine status signal can include both off and running states.

[0101] It should be understood that the required real vehicle signals are the same under the same test scenario, but the signal states of the real vehicle signals corresponding to different test functions are different. In conjunction with the above... Figure 4 For example.

[0102] For example, if the target test scenario is a fuel-type test scenario, and the target test function is a gear position not being met, then the target signal types corresponding to the target test scenario can be determined to be gear position, parking status, engine status, battery level, etc. In other words, when performing OTA upgrade testing for a fuel-type test scenario, the required real-vehicle signal types include gear position, parking status, engine status, battery level, etc.

[0103] Furthermore, the signal states of the above signals differ depending on the test function. For example, if the target test function is gear position failure, the gear position signal state could be D or R, the parking status signal state could be parked, the engine status signal state could be off, and the battery charge signal state could be charged sufficiently. As another example, if the target test function is handbrake failure, the gear position signal state could be P or N, the parking status signal state could be unparked, the engine status signal state could be off, and the battery charge signal state could be charged sufficiently.

[0104] In this case, by selecting the target test function in the target test scenario, in addition to obtaining the target signal type, the target signal status corresponding to the target test function is also obtained. This allows for the acquisition of detailed information about the signals required to test the OTA upgrade process in the target test scenario. Subsequently, based on the target signal type and target signal status, the actual vehicle signals can be accurately simulated, thereby enabling more detailed testing of the target test scenario and more precise testing of the OTA upgrade process.

[0105] As one possible implementation, the target signal type may include a first signal type and a second signal type; the first signal type is the same as the signal type indicated by the target test function among the target signal types. The second signal type is any other signal type among the target signal types besides the first signal type.

[0106] For example, target signal types include gear position, parking status, engine status, and battery level. If the target test function is that the gear position is not met, then the first signal type will be gear position, and the second signal type will be parking status, engine status, and battery level.

[0107] The target signal state can be determined as follows: based on the target test function, determine the target signal state corresponding to the first signal type; and determine the default signal state corresponding to the second signal type during OTA upgrade testing as the target signal state corresponding to the second signal type.

[0108] The operation of determining the target signal state corresponding to the first signal type based on the target test function can be: determining the signal state corresponding to the signal type indicated by the target test function as the target signal state corresponding to the first signal type.

[0109] For example, if the target test function is "gear not satisfied," then the signal type indicated by the target test function is "gear," and the indicated signal state is the signal state corresponding to "gear not satisfied," meaning the signal state can include either D or N gear. Therefore, it can be determined that the target signal state corresponding to the gear in the target signal type is either D or N gear.

[0110] Furthermore, under normal circumstances, during OTA upgrade testing, multiple real-vehicle signals can be set with default signal states, thereby enabling OTA upgrade testing in a real-vehicle environment under the default signal states. Therefore, in this embodiment, if the target test function does not indicate the signal state of the second signal type, the signal state of the second signal type can be the default signal state.

[0111] Optionally, step 201 may also involve: responding to the selection of a target test scenario on the OTA upgrade test interface, determining whether the login account corresponding to the OTA upgrade test has the target operation permission; and if the login account has the target operation permission, obtaining the target signal type corresponding to the target test scenario.

[0112] In this embodiment of the application, the target operation permission may include the operation permission to perform operations on the OTA upgrade test interface and to conduct subsequent OTA upgrade tests.

[0113] Generally, when conducting OTA testing, technicians first need to log in to the corresponding account on the testing platform before they can perform the tests. Furthermore, different accounts may have different access permissions. Therefore, in this embodiment, before conducting OTA upgrade testing, it can be determined whether the logged-in account has the target access permissions.

[0114] Therefore, by determining whether the login account corresponding to the OTA upgrade test has the target operation permissions, the corresponding OTA upgrade test can only be conducted if the login account has the target operation permissions. When non-professional testers are present, they may not be familiar enough with the OTA upgrade testing process, resulting in inaccurate test results. Therefore, the above operation can avoid some erroneous testing phenomena by non-professional testers in OTA upgrade testing.

[0115] The operation to determine whether the login account corresponding to the OTA upgrade test has the target operation permission can be as follows: traverse the target permission list and check whether the login account exists in the target permission list; if the login account exists in the permission list, determine that the login account has the target operation permission; if the login account does not exist in the permission list, determine that the login account does not have the target operation permission.

[0116] The target permission list refers to a list of login accounts that have the specified permissions. This list may include multiple login accounts, and it should be understood that all of these accounts in the target permission list possess the specified permissions. Therefore, if a login account appears in the target permission list, it means that that login account has the specified permissions.

[0117] It is worth noting that in step 201, after the technician selects the target test scenario, the computer device can obtain the target signal type corresponding to the target test scenario. However, in the prior art, OTA upgrade testing cannot be successfully completed due to the lack of a real vehicle or the inability to meet the requirements of the real vehicle environment. Therefore, in this embodiment, the real vehicle signals required in the OTA upgrade testing process can be simulated, thereby enabling the subsequent implementation of the corresponding OTA upgrade test.

[0118] Step 202: Based on the target signal type, simulate the actual vehicle signal corresponding to the target signal type to obtain the target simulated signal.

[0119] In this embodiment, by simulating the real vehicle signals required for different test scenarios, the real vehicle environment under different test scenarios can be met. Therefore, subsequent testing of the OTA upgrade process under different test scenarios can be achieved. This solves the problem of difficulties in OTA upgrade testing caused by the lack of a real vehicle or the inability to achieve the upgrade environment of a real vehicle.

[0120] In one possible implementation, step 202 may involve: obtaining the default signal state corresponding to the target signal type; obtaining the signal attribute library; obtaining the target signal value from the signal attribute library based on the target signal type and the default signal state; and assigning the target signal value to the actual vehicle signal corresponding to the target signal type to obtain the target analog signal corresponding to the target signal type.

[0121] The signal attribute library includes signal values ​​corresponding to different real-vehicle signals. Optionally, the signal attribute library can be a power supply library. For example, for high-voltage signals of pure electric vehicles, the signal attribute library can include the signal value corresponding to the high-voltage signal as 0xC:Powerup4LVcharging. Specifically, the signal attribute library can include signal values ​​for all signal states corresponding to different signal types. For example, the signal attribute library can include signal values ​​for different gear states corresponding to gear position signals, including the signal value for P gear as 0x00, the signal value for N gear as 0x02, and the signal value for D gear as 0x03, etc.

[0122] It should be understood that the signal value refers to the CAN signal value corresponding to a signal in CAN communication.

[0123] In this scenario, by retrieving the target signal value from the signal attribute library and assigning it to the corresponding real vehicle signal of the target signal type, it's equivalent to obtaining the signal value of that real vehicle signal during real vehicle communication. In other words, it's like generating a signal for real vehicle communication, thus simulating that real vehicle signal. Therefore, assigning the signal value to the real vehicle signal provides a relatively convenient way to simulate real vehicle signals, improving the convenience and flexibility of signal simulation.

[0124] The operation of obtaining the target signal value from the signal attribute library based on the target signal type and the default signal state can be as follows: based on the type identifier of the target signal type, determine all signal values ​​corresponding to the target signal type from the signal attribute library; based on the default signal state, obtain the target signal value from all signal values.

[0125] The type identifier of the target signal type is used to uniquely identify the target signal type. For example, if the target signal type is gear position, the type identifier of gear position can be set to GearPosition.

[0126] All signal values ​​corresponding to the target signal type refer to the signal values ​​under all signal states corresponding to the target signal type, that is, the signal values ​​corresponding to different signal states of the target signal type.

[0127] In this case, the above operation is to first determine the signal values ​​corresponding to all signal states of the target signal type from the signal attribute library, and then obtain the signal value corresponding to the default signal state from the signal values ​​corresponding to all signal states. In this way, the specific signal value of the real vehicle signal to be simulated can be obtained accurately.

[0128] For example, if the target signal type is gear position and the default signal state is P (Park), then the above operation process is as follows: First, based on the gear type identifier GearPosition, retrieve all signal values ​​corresponding to the gear from the signal attribute library. For example, the signal value for P is 0x00, the signal value for N (Neutral) is 0x02, the signal value for D (Driving) is 0x03, and the signal value for R (Reverse) is 0x04. Then, retrieve the signal value corresponding to the default signal state (P) from all the signal values, which is 0x00. That is, determine that the target signal value corresponding to the target signal type is 0x00.

[0129] The following example illustrates the simulation process of the target analog signal corresponding to the above target signal type.

[0130] For example, target signal types include gear position, parking status, engine status, and battery level. The default signal status for gear position is P (Park), the default signal status for parking status is parked, and the default signal status for engine status is off.

[0131] For the gear position signal, firstly, based on the gear type identifier GearPosition, all signal values ​​corresponding to the gear are retrieved from the signal attribute library. Then, the signal value corresponding to the default signal state (P gear) is retrieved from all signal values ​​as 0x00, thus determining the target signal value corresponding to the target signal type as 0x00. Next, the target signal value is assigned to the gear position signal, which is equivalent to executing the operation GearPosition == 0x00, thus making the target analog signal corresponding to the gear position GearPosition == 0x00.

[0132] For the parking status signal, firstly, based on the parking status type identifier EPBStatus, all signal values ​​corresponding to the parking status signal are retrieved from the signal attribute library. Then, the signal value corresponding to the default signal status (parked) is retrieved from all signal values ​​as 0f01, thus determining the target signal value corresponding to the parking status as 0f01. Next, the target signal value is assigned to the parking status signal, which is equivalent to executing the operation EPBStatus == 0f01. Therefore, the target analog signal corresponding to the parking status signal is EPBStatus == 0f01.

[0133] For the engine status signal, firstly, based on the engine status type identifier EngineStatus, all signal values ​​corresponding to the engine status signal are retrieved from the signal attribute library. Then, the signal value corresponding to the default signal status (engine off) is retrieved from all signal values ​​as 0g01, which determines the target signal value corresponding to the engine status signal as 0g01. Next, the target signal value is assigned to the engine status signal, that is, the operation EngineStatus == 0g01 is executed. Thus, the target analog signal corresponding to the engine status signal is EngineStatus == 0g01.

[0134] Another possible implementation involves, upon receiving a selection operation for a target test function in the target test scenario, obtaining a signal attribute library; based on the target signal type and target signal state, obtaining the target signal value from the signal attribute library; and assigning the target signal value to the actual vehicle signal corresponding to the target signal type to obtain the target analog signal corresponding to the target signal type.

[0135] In this case, when technicians want to test the OTA upgrade process under specific upgrade conditions, they can perform the simulation steps of the target simulated signal described above. This allows them to simulate the real vehicle signals required for OTA upgrade testing under specific upgrade conditions, and thus enable the testing of the OTA upgrade process under specific upgrade conditions.

[0136] The operation of obtaining the target signal value from the signal attribute library based on the target signal type and the target signal state can be as follows: based on the type identifier of the target signal type, determine all signal values ​​corresponding to the target signal type from the signal attribute library; based on the target signal state, obtain the target signal value from all signal values.

[0137] In this case, the above operation is to first determine the signal values ​​corresponding to all signal states of the target signal type from the signal attribute library, and then obtain the signal value corresponding to the target signal state from the signal values ​​corresponding to all signal states, so as to obtain the specific signal value of the real vehicle signal to be simulated. In this way, the specific signal value of the real vehicle signal to be simulated can be accurately obtained.

[0138] It should be understood that the specific operation of obtaining the target signal value from the signal attribute library based on the target signal type and the target signal state is similar to the specific operation of obtaining the target signal value from the signal attribute library based on the target signal type and the default signal state in the first possible implementation, and will not be repeated here.

[0139] Step 203: Based on the target simulated signal, execute the test script corresponding to the target test scenario to send the target simulated signal to the vehicle system. After receiving the target simulated signal, the vehicle system executes the target upgrade process to generate the test object. Then, the vehicle system obtains the test object and tests it to obtain the test results of the OTA upgrade process corresponding to the target test scenario.

[0140] The object to be tested is the data generated during the OTA upgrade of the vehicle's infotainment system that needs to be tested. For example, if an interface pops up during the OTA upgrade process, then this interface is the data that needs to be tested, and the object to be tested can be this interface.

[0141] The target upgrade process refers to the OTA upgrade process corresponding to the target test scenario. For example, if the target test scenario is a fuel-type test scenario, then the target upgrade process can be the process of performing OTA upgrades on fuel-type vehicles.

[0142] The test script corresponding to the target test scenario refers to the test script used to test the OTA upgrade process corresponding to the target test scenario.

[0143] Executing the above test script involves the following process: After obtaining the target simulated signal, the computer device can send the target simulated signal to the vehicle's infotainment system. Upon receiving the target simulated signal, the vehicle's infotainment system essentially simulates the process of receiving real vehicle signals from other controllers. Based on the received target simulated signal, the vehicle's infotainment system will then perform an OTA (Over-The-Air) upgrade. During the OTA upgrade process, corresponding data may be generated, which can be referred to as the test object. Subsequently, the vehicle's infotainment system can return the test object to the computer device, allowing the computer device to retrieve the test object from the vehicle's infotainment system. Upon receiving the test object returned by the vehicle's infotainment system, the computer device can verify the test object to check for any problems in the OTA upgrade process, thus obtaining the test results of the OTA upgrade process corresponding to the target test scenario.

[0144] In this scenario, by sending a target simulation signal to the vehicle's infotainment system, the system perceives itself as being in a real vehicle environment, allowing for the simulation of OTA (Over-The-Air) upgrades within that simulated environment. This solves the problem of being unable to perform OTA upgrade tests when there is no physical vehicle or the real vehicle environment is not suitable, and makes the OTA upgrade testing process more convenient.

[0145] Specifically, step 203 can be performed as follows: sending a target analog signal to the vehicle's infotainment system so that the system executes the target upgrade process and generates a test object after receiving the signal; obtaining the test object from the system; and testing the test object.

[0146] In this embodiment of the application, when the object to be tested is an interface, the interface to be tested can be tested.

[0147] In this case, the operation to test the object under test can be: to verify the interface content and the interface language of the interface under test, and to obtain the test results of the interface under test.

[0148] Interface content verification is used to test whether the content displayed on the interface is correct. It should be understood that for testing pop-up interfaces during the upgrade process, the main test is whether the content displayed on the pop-up interface is correct. For example, the content to be displayed on the upgrade success interface should be "Upgrade successful". Therefore, the test for the upgrade success interface should be to test whether the content currently displayed on the interface is "Upgrade successful".

[0149] Interface language verification is used to test whether the content displayed on the interface corresponding to different languages ​​is correct. In some embodiments, it may also include scenarios with multiple languages. It should be understood that vehicles can be sold in different countries, so the language used by the vehicle's infotainment system should also be different. In this case, it is also possible to test whether the content displayed on the same interface is correct when it is displayed in different languages.

[0150] In current technology, testing the interface generated during OTA upgrades involves technicians manually checking the interface as it pops up during the upgrade process to ensure the accuracy of the displayed content and translations. However, to guarantee the accuracy and stability after the OTA upgrade, dozens of repeated tests are usually required. Therefore, testing the interface in the above manner would be extremely labor-intensive and time-consuming.

[0151] In this case, by automatically executing the corresponding test scripts, the interface content and language can be automatically verified. This allows for the automatic verification of the interface content and the language displayed on the interface, thereby achieving automated testing of the interface during the OTA upgrade testing process and improving the efficiency of interface testing.

[0152] The steps for verifying the interface content of the interface under test include: obtaining the standard display content of the interface under test; determining whether the text content currently displayed on the interface under test is consistent with the standard display content; if the text content currently displayed on the interface under test is consistent with the standard display content, determining that the interface content verification of the interface under test has passed; if the text content currently displayed on the interface under test is inconsistent with the standard display content, determining that the interface content verification of the interface under test has failed.

[0153] The standard display content refers to the text that should have been displayed on the interface under test during the OTA upgrade testing process. It should be understood that during development, the content to be displayed on each interface is based on the development requirements document. Specifically, the development requirements document includes the text content that should be displayed on each interface, and subsequent technical personnel can write the text content to be displayed on each interface based on the development requirements document. In this embodiment, the standard display content can be the text content that should be displayed on the interface under test as specified in the development requirements document.

[0154] For example, the development requirements document can be an Excel file. During development, engineers will convert the Excel file into an XML configuration file and import it into the development code so that the corresponding content can be rendered and displayed on the interface later. Then, when testing the interface later, the Excel file can be used to verify whether the content actually displayed by the user is correct. By comparing the text content that should be displayed on the interface under test in the Excel file with the text content that is currently displayed on the interface under test, it can be determined whether the content displayed on the interface under test is incorrect.

[0155] In this case, if the content currently displayed on the interface under test is consistent with the standard display content, it means that the content currently displayed on the interface under test is the text content that should be displayed on the interface as required by the development requirements document. This indicates that the content currently displayed on the interface under test is correct, and therefore it can be determined that the interface content verification of the interface under test has passed.

[0156] If the content currently displayed on the interface under test is inconsistent with the standard display content, it means that the content currently displayed on the interface under test is not the text content that should be displayed on the interface under test as required by the development requirements document. In other words, the content currently displayed on the interface under test is different from the development requirements, and therefore the content currently displayed on the interface under test is incorrect. Thus, it can be determined that the interface content verification of the interface under test has failed.

[0157] The steps for verifying the interface language of the interface under test include: obtaining the standard language text of the interface under test; obtaining the corresponding development language text of the interface under test; if the standard language text and the development language text are the same, determining that the interface language verification of the interface under test has passed; if the standard language text and the development language text are different, determining that the interface language verification of the interface under test has failed.

[0158] Standard language text refers to the standard translated text in different languages ​​corresponding to the interface under test. Optionally, standard language text is the standard display content translated into different languages ​​based on the aforementioned standard display content.

[0159] The development language text includes the language text displayed on the interface under test in different languages ​​during OTA upgrade testing. The development language text is the language text corresponding to the different languages ​​written into the development code by technical personnel during the development process. The interface under test will subsequently call the development language text written in the development code to display the corresponding content. In other words, the language text included in the development language text can represent the language text corresponding to the different languages ​​that the interface under test is currently displaying.

[0160] In this case, if the standard language text and the development language text are the same, it means that the standard translation text of the interface under test in different languages ​​is the same as the language text to be displayed by the interface under test in different languages ​​during the OTA upgrade test. In other words, the content displayed by the interface under test in different languages ​​during the test is the standard language content. Therefore, it can be determined that the interface language verification of the interface under test has passed.

[0161] If the standard language text and the development language text are different, it means that the standard translation text of the interface under test in different languages ​​is different from the language text to be displayed on the interface under test in different languages ​​during the OTA upgrade test. In other words, the text content displayed on the interface under test in different languages ​​during the test is not the standard translation text, which indicates that there is a problem with the text content corresponding to the different languages ​​displayed on the interface under test during the test. Therefore, it can be determined that the interface language verification of the interface under test has failed.

[0162] It is worth noting that if the interface language verification or the interface content verification of the interface to be tested fails, a second manual verification can be performed.

[0163] Specifically, if the interface language verification or the interface content verification of the interface to be tested fails, the first reminder message can be output; subsequently, the interface to be tested that failed verification will be displayed so that technicians can manually test the interface to be tested.

[0164] The first notification message indicates that the interface under test has failed the test.

[0165] In this situation, after the first reminder message is output, the technicians can know that the interface under test has failed the test. By displaying the interface under test, the technicians can then conduct further manual testing to check whether the content displayed on the interface under test is correct or whether the language text corresponding to the different languages ​​displayed on the interface under test is correct.

[0166] In this way, if the interface language verification or the interface content verification fails, manual secondary verification can be performed to test the interface more accurately, thereby improving the accuracy of the interface.

[0167] Optionally, the OTA upgrade test interface can display multiple entry points for different interfaces, such as multiple interface launch controls. When technicians want to manually verify a particular interface, they can click the corresponding interface launch control. Clicking the control will invoke the corresponding interface, rendering it and allowing for manual verification.

[0168] It should be noted that the above steps enable automated testing of each interface during the upgrade process, including automated testing of interface content and language. Only if an interface fails testing will further manual verification be performed. Compared to existing technologies where technicians manually check each interface, i.e., the entire process is manual, this significantly improves the efficiency of interface testing.

[0169] The OTA upgrade testing process for specific test scenarios will be explained in detail below.

[0170] In this application embodiment, at least i test scenarios may include precondition test scenarios, test scenarios of different power types, and interface test scenarios.

[0171] Among them, the precondition test scenario is used to check the test environment before OTA upgrade testing. Its purpose is to check whether the current test environment meets the environmental requirements of OTA upgrade testing.

[0172] Before conducting OTA upgrade testing, the test environment needs to meet certain requirements. For example, the system needs to be in DEBUG mode and not in factory mode. DEBUG mode is a debugging mode used in the development and testing process; that is, during development and testing, by being in DEBUG mode, the system is prevented from performing actual OTA upgrades. Factory mode is a mode set up for vehicles that are not yet sold and are still in the factory. OTA upgrades are not supported in factory mode, so the system needs to be in a different state during testing. Therefore, the test environment needs to meet certain conditions before conducting OTA upgrade testing, and for this reason, the test environment can be checked.

[0173] The interface testing scenario is used to test the interface that pops up during the OTA upgrade process, that is, to determine whether there are any problems with the interface that pops up during the OTA upgrade process. In the embodiments of this application, the interface testing scenario can be triggered when the interface content verification and interface language verification fail in other testing scenarios. For example, after testing the interface in different power type testing scenarios, if it is determined that an interface has failed the test, then the interface testing scenario can be triggered.

[0174] Different powertrain type test scenarios refer to scenarios where OTA upgrade tests are performed on vehicles with different powertrain types. Since the OTA upgrade processes differ for different powertrain types, test scenarios for different powertrain types can be distinguished. In the embodiments of this application, different powertrain type test scenarios include fuel-powered test scenarios, pure electric test scenarios, and hybrid test scenarios.

[0175] First, a detailed explanation of the OTA upgrade tests corresponding to different power types will be provided. It should be understood that each power type test scenario may include at least j test functions. The OTA upgrade tests corresponding to different power types test scenarios may specifically include the following steps (1)-(3).

[0176] (1) In response to the selection operation of the target test function in the test scenario of the target power type, obtain the target signal type and target signal status corresponding to the test scenario of the target power type.

[0177] The target power type can be one of the following: gasoline, pure electric, or hybrid.

[0178] The target test function can be one of at least j test functions.

[0179] Because vehicles with different powertrains have different structures, the actual vehicle signals involved also differ. Furthermore, the signal states of the actual vehicle signals corresponding to different test functions within a test scenario also vary. Therefore, it is possible to obtain the target signal type and target signal state.

[0180] For example, the target signal types for fuel-related test scenarios could include gear position, handbrake, engine speed, engine status, and battery charge. In this case, the test functions for fuel-related test scenarios could include OTA upgrade tests when the gear position, handbrake, and battery charge are insufficient.

[0181] For example, the target signal types for hybrid-type test scenarios may include voltage, gear position, vehicle speed, handbrake, engine status, and engine speed. In this case, the test functions for hybrid-type test scenarios may include OTA upgrade tests during high-voltage upgrades, OTA upgrade tests during low-voltage upgrades, OTA upgrade tests when vehicle speed is not met, upgrade tests when gear position is not met, and OTA upgrade tests when handbrake is not met.

[0182] For example, if the technician selects an OTA upgrade test for a high-voltage upgrade in a hybrid test scenario, the target signal types for the OTA upgrade test for high-voltage upgrade can include voltage, vehicle speed, parking status, gear, etc. The target signal status for each target signal type can be: the target signal status for voltage signal is high-voltage status, the target signal status for vehicle speed signal is vehicle speed meets the condition, the target signal status for parking status is parked, and the target signal status for gear is P or N gear.

[0183] (2) Based on the target signal type and target signal state corresponding to the test scenario of the target power type, the actual vehicle signal corresponding to the target signal type is simulated to obtain the target simulated signal.

[0184] In this case, it is equivalent to simulating the actual vehicle signals required for the target test function. For example, if the target test function is the OTA upgrade test during high voltage upgrade, then the actual vehicle signals required during high voltage upgrade can be simulated.

[0185] In this way, the real vehicle signals required for OTA upgrade processes of different power types can be simulated, enabling the simulation of different real vehicle signals when conducting OTA upgrade tests for different power types. This allows for OTA upgrade tests for different power types to be performed under different real vehicle conditions, thereby solving the problem that OTA upgrade processes for different power types cannot be tested in a way that closely matches the real vehicle environment. This can improve the accuracy of OTA upgrade tests.

[0186] Because over-the-air (OTA) updates for both pure electric and hybrid vehicles include both high-voltage and low-voltage updates, the target signal type can include voltage signals in the test scenarios for pure electric and hybrid vehicles, and the target signal state can include either a high-voltage state or a low-voltage state.

[0187] Specifically, if the target power type is pure electric or hybrid, and the target test function is high-voltage upgrade test, the high-voltage state of the voltage signal is simulated to obtain a high-voltage simulated signal; if the target test function is low-voltage upgrade test, the low-voltage state of the voltage signal is simulated to obtain a low-voltage simulated signal.

[0188] In this scenario, the system first determines whether the OTA upgrade test is a high-voltage or low-voltage upgrade. If it's a high-voltage upgrade, a high-voltage signal is simulated; if it's a low-voltage upgrade, a low-voltage signal is simulated. This ensures that the required high-voltage or low-voltage environment is met during the OTA upgrade process for both pure electric and hybrid vehicles.

[0189] (3) Based on the target simulation signal, execute the test script corresponding to the test scenario of the target power type to send the target simulation signal to the vehicle system. After receiving the target simulation signal, the vehicle system executes the target upgrade process to generate the test object. Then, the test object is obtained through the vehicle system and tested to obtain the test result of the OTA upgrade process corresponding to the test scenario of the target power type.

[0190] After simulating the target simulated signal required for the test scenario of the target powertrain type, the computer equipment can send the target simulated signal to the vehicle's infotainment system. Upon receiving the target simulated signal, the vehicle's infotainment system essentially receives the real vehicle signals returned by the controllers in actual vehicle communication. Therefore, after receiving the target simulated signal, the vehicle's infotainment system will detect that its upgrade environment is met, and can then simulate the corresponding OTA upgrade. Subsequently, during the OTA upgrade process, a corresponding test object can be generated. The computer equipment then obtains the test object from the vehicle's infotainment system and tests it, thereby identifying any problems in the OTA upgrade process for the target powertrain type.

[0191] In this embodiment, the object under test can be an interface generated during the OTA upgrade process. In this case, testing the object under test is equivalent to testing the interface that pops up during the OTA upgrade process.

[0192] Specifically, testing the interface can involve verifying the interface content and verifying the interface language.

[0193] The operations for verifying the interface content and interface language are similar to those for verifying the interface content and interface language of the interface under test, and will not be repeated here.

[0194] To facilitate understanding, we will now combine... Figure 5 The OTA upgrade tests corresponding to different power types provided in the embodiments of this application are illustrated by way of example. For example, Figure 5 This is a flowchart of an OTA upgrade test corresponding to different power types provided in an embodiment of this application.

[0195] like Figure 5 As shown, after selecting the target test function in the test scenario for the target power type, the target signal type and target signal status are first obtained, and the vehicle's infotainment system requests to enter the vehicle-wide OTA (Over-The-Air) update. Additionally, if the target power type is pure electric or hybrid, it is further determined whether this OTA update is a high-voltage or low-voltage update. If it is a high-voltage update, a high-voltage upgrade request is made. The computer then simulates a high-voltage signal and returns it to the vehicle's infotainment system, which begins the high-voltage upgrade upon receiving the signal. If the OTA update is a low-voltage update, a low-voltage upgrade request is made. The computer then simulates a low-voltage signal and returns it to the vehicle's infotainment system, which begins the low-voltage upgrade upon receiving the signal, continuing until the upgrade is successful.

[0196] The following provides a detailed explanation of OTA upgrade testing in the interface testing scenario. The interface testing scenario may include multiple interface testing functions, which are used to test multiple different interfaces involved in the OTA upgrade process. The OTA upgrade testing process in the interface testing scenario may include the following steps.

[0197] (1) In response to the selection operation of the target interface test function in the interface test scenario, obtain the target signal type and target signal status corresponding to the interface test scenario.

[0198] (2) Based on the target signal type and target signal state corresponding to the interface test scenario, simulate the real vehicle signal corresponding to the target signal type to obtain the target simulated signal.

[0199] (3) Based on the target simulation signal, execute the test script corresponding to the interface test scenario to send the target simulation signal to the vehicle system. After receiving the target simulation signal, the vehicle system executes the target upgrade process to generate the interface to be tested. Then, the vehicle system obtains the interface to be tested and tests it to obtain the test results of the OTA upgrade process corresponding to the interface test scenario.

[0200] Specifically, step (3) can be performed as follows: send a target analog signal to the vehicle system so that the vehicle system can execute the OTA upgrade process and generate the interface to be tested after receiving the target analog signal; obtain the interface to be tested from the vehicle system; verify the interface content and interface language of the interface to be tested to obtain the test results of the interface to be tested.

[0201] In this scenario, the vehicle's infotainment system receives a simulated signal and determines its actual vehicle environment based on this signal. It then begins simulating the OTA (Over-The-Air) upgrade process corresponding to the target interface test function, thereby generating the interface for that function and obtaining the interface under test. The computer then acquires this interface through the vehicle's infotainment system and performs tests to obtain the test results.

[0202] The specific steps for verifying the interface content and language of the interface under test to obtain the test results are the same as those described in step 203 above, and will not be repeated here.

[0203] To facilitate understanding, we will now combine... Figure 6 An OTA upgrade test for a user interface testing scenario is illustrated with an example. For example, Figure 6 This is a flowchart of an OTA upgrade test for an interface testing scenario provided in an embodiment of this application.

[0204] like Figure 6As shown, after selecting the target interface testing function, standard display content and standard language text can be imported. Then, based on the standard display content and standard language text, interface content verification and interface language verification of the interface under test can be performed. Specifically, the standard display content is compared with the content currently displayed on the interface under test, and the standard language text is compared with the development language text, thereby automatically generating verification results. If the interface content verification or interface language verification fails, manual secondary verification can be performed. Specifically, the failed interface can be opened, and the computer device will display the failed interface for technical personnel to perform manual verification.

[0205] Finally, the OTA upgrade test for the precondition test scenario is described in detail. The precondition test scenario may include an environment check function. In this case, the OTA upgrade test for the precondition test scenario may include the following steps (1)-(3).

[0206] (1) In response to the selection operation of the environment check function in the precondition test scenario, obtain the target signal type and target signal status corresponding to the precondition test scenario.

[0207] The environment check function is used to check whether there are any problems in the real vehicle environment during OTA upgrade testing.

[0208] In this embodiment of the application, the target signal state corresponding to the precondition test scenario can be the default signal state of the signal corresponding to the target signal type.

[0209] In this case, before the OTA upgrade test, technicians can first select the environment check function in the precondition test scenario to check the real vehicle environment before the OTA upgrade test and determine whether the real vehicle environment meets the requirements of the OTA upgrade test.

[0210] (2) Based on the target signal type and target signal state corresponding to the precondition test scenario, simulate the real vehicle signal corresponding to the target signal type to obtain the target simulated signal.

[0211] (3) Based on the target simulation signal, execute the test script corresponding to the environmental check function to send the target simulation signal to the vehicle unit. After receiving the target simulation signal, the vehicle unit executes the target upgrade process to generate the test object. Then, the test interface is obtained through the vehicle unit and the test object is tested to obtain the test results of the environmental check function.

[0212] Specifically, step (3) can be performed as follows: send a target simulation signal to the vehicle system so that the vehicle system can perform an environmental check and generate a test object after receiving the target simulation signal; determine whether the test object meets the preset upgrade conditions; and output a target reminder message if the test object does not meet the preset upgrade conditions.

[0213] In the precondition test scenario, the main purpose is to check whether the OTA test environment meets the preset upgrade conditions. The object under test can be data that can represent the OTA test environment, and the test environment is represented by some real vehicle signals. Therefore, the object under test can be multiple real vehicle signals.

[0214] Preset upgrade conditions are used to represent the test environment that should be met during the OTA upgrade test. In this embodiment, the preset upgrade conditions may include multiple real vehicle signals that should be met during the OTA upgrade test.

[0215] The target alert information includes real-vehicle signals that were not met during this OTA upgrade test.

[0216] In this scenario, when determining whether the simulated vehicle signal meets the test environment requirements for OTA upgrade testing, if a vehicle signal is detected as not meeting the test environment requirements, a target reminder message indicating that the vehicle signal does not meet the test environment requirements can be output so that technicians can be informed that the vehicle signal does not meet the test environment requirements.

[0217] In this way, by outputting target reminder information when the preset upgrade conditions are not met in this OTA upgrade test, technicians can be informed of the unmet real vehicle signals in a timely manner, so that they can make corresponding adjustments in a timely manner.

[0218] Optionally, if the OTA upgrade test meets the preset upgrade conditions, a second reminder message can be output. This second reminder message is used to notify technical personnel that the test environment meets the requirements.

[0219] In this embodiment, the precondition test scenario may further include multiple environmental information setting functions. Furthermore, if the object under test does not meet the preset upgrade conditions, in response to the selection operation of at least one environmental information setting function in the OTA upgrade test interface, the target environmental information can be reset so that the object under test again meets the preset upgrade conditions.

[0220] Multiple environmental information settings functions are available to configure different real-vehicle environments. For example, these functions may include factory mode deactivation and debug settings.

[0221] In this embodiment, at least one environmental information setting function is selected based on the aforementioned target reminder information. That is, when technicians learn which real-vehicle environments are not met during the OTA upgrade test, they can subsequently use multiple environmental information setting functions to adjust the real-vehicle environment accordingly, ensuring that the corresponding real-vehicle environment meets the requirements. For example, if during an environmental check it is found that the system is not in DEBUG mode, the DEBUG setting function can be used to put the system back into DEBUG mode.

[0222] The OTA upgrade testing method provided in this application embodiment will be described below in the form of functional modules. For example, Figure 7 This is a schematic diagram illustrating the functional implementation of an OTA upgrade testing method provided in an embodiment of this application.

[0223] like Figure 7 As shown, Figure 7 This includes device management functions, power management functions, and OTA upgrade testing functions. It should be understood that device management functions and power management functions can be used in implementing the OTA upgrade testing functions provided in the embodiments of this application; therefore, the device management functions, power management functions, and OTA upgrade testing functions are described herein.

[0224] From a front-end perspective, such as Figure 7 As shown, the OTA upgrade testing method provided in this application involves a device management interface, a power management interface, and an OTA upgrade testing interface.

[0225] The following explanation will focus on the device management interface, power management interface, and OTA upgrade test interface from the perspective of front-end and back-end interaction.

[0226] The device management interface allows users to enable and disable the transmission channel between the vehicle-mounted infotainment system and the computer device. The interface includes selection controls for multiple transmission channels. Specifically, there are multiple transmission channels between the vehicle-mounted infotainment system and the computer device for signal transmission. When starting the vehicle-mounted infotainment system, users can click the corresponding selection control to choose the transmission channel, such as a default channel. The interface also includes start and stop buttons. After selecting a channel, users can click the start button to start the vehicle-mounted infotainment system. If the start fails, a failure pop-up window will appear on the device management interface, displaying a notification of the failure. Users can then click the start button again to restart the system. If the start is successful, a success pop-up window will appear. When technicians need to disconnect the connection between the vehicle-mounted infotainment system and the computer device, they can click the stop button at any time to stop signal transmission.

[0227] The power management interface can simulate power signals, specifically signals for different power modes. For example, the interface can include normal power mode, ten-minute mode, and standby mode. For instance, after clicking normal power mode, technicians can simulate the normal operation of the power supply, allowing for OTA (Over-The-Air) upgrade testing while the power supply is in normal mode. Similarly, clicking ten-minute mode simulates the power supply's ten-minute operation, enabling OTA upgrade testing in this mode. Finally, clicking standby mode simulates the power supply's standby mode, allowing for OTA upgrade testing in standby mode.

[0228] The OTA upgrade test interface can include precondition test scenarios, test scenarios for different power types, and interface test scenarios.

[0229] Among them, the pre-condition test scenarios may include environmental check functions, GBOM (Global Bill of Materials) version check, ECU information check, factory mode deactivation, DEBUG mode setting, condition switch check, vehicle system version check and other test functions.

[0230] Test scenarios for different powertrain types can include test scenarios for gasoline-powered vehicles, PHEVs (Plug-in Hybrid Electric Vehicles), HEVs (Hybrid Electric Vehicles), and pure electric vehicles. Additionally, test scenarios for different powertrain types can also include OTA (Over-the-Air) upgrade testing capabilities under different upgrade conditions.

[0231] Interface testing scenarios can include verification of interface display, interface content, and interface language translation. Specifically, this can include verification tests of interfaces such as successful upgrade interface, failed upgrade interface, and download interface.

[0232] The following describes some data files and encapsulation classes that support the implementation of this OTA upgrade testing method.

[0233] In this embodiment, different interfaces, upgrade conditions, and test scenarios are encapsulated into classes and added to the click event of a control. This allows technicians to determine the target signal type and state for the corresponding test scenario by clicking the control displayed on the OTA upgrade test interface. Subsequently, based on the target signal type and state, a simulation of the actual vehicle signal is performed, effectively simulating the actual vehicle signal required for the corresponding test scenario and sending it to the vehicle's infotainment system. After detecting that it is in the corresponding real-vehicle environment, the vehicle's infotainment system can perform an OTA upgrade for the corresponding test scenario. This allows the computer equipment to test the objects under test generated during the OTA upgrade process, thereby enabling testing of the OTA upgrade process under the corresponding upgrade conditions.

[0234] Regarding data files, this application embodiment involves the storage of dbc files, development requirement documents, standard language text, and development language text.

[0235] Optionally, in this application embodiment, multiple utility classes and multiple event classes can be encapsulated.

[0236] Among them, multiple tool classes may include device management classes (for starting the vehicle's infotainment system), vehicle signal classes (for sending and receiving signals), and file read / write classes (for reading and writing data files), etc.

[0237] Multiple event classes can include click events, text events, pop-up events, and other events. Click events are applied to controls. When a technician clicks a control on the OTA upgrade test interface, the click event is triggered, executing the code encapsulated in that click event to test the OTA upgrade process under the corresponding upgrade conditions.

[0238] A pop-up event is a notification that is triggered during the OTA upgrade testing process. This event can be used to display the corresponding interface, such as when the upgrade success screen pops up.

[0239] It is worth noting that the OTA upgrade testing method provided in this application adopts a data-driven approach, functionally encapsulating various interface elements and real vehicle signals before rendering the front-end interface. This allows for the classification of different OTA upgrade test scenarios, and the switching between different test scenarios can be achieved with a single click via code encapsulation and controls. Furthermore, the OTA upgrade testing method provided in this application does not require actual OTA upgrade operations; instead, it uses code encapsulation and button triggers to quickly invoke the OTA upgrade interface to be tested. Additionally, it can simulate the real vehicle signals required in the OTA upgrade process for different power types, thereby enabling testing of the OTA upgrade process for vehicles with different power types.

[0240] In this embodiment, after receiving a selection operation for a target test scenario, the computer device can, in response to the selection operation, first obtain the target signal type corresponding to the target test scenario. Since the OTA upgrade process differs for different test scenarios, the corresponding real vehicle signals also differ. Therefore, the signal type of the real vehicle signal required for the OTA upgrade process of the target test scenario can be obtained first. Then, based on the target signal type, the real vehicle signal corresponding to the target signal type is simulated to obtain the target simulated signal, which is the simulated real vehicle signal required for the OTA upgrade process of the target test scenario. Then, based on the target simulated signal, the test script corresponding to the target test scenario is executed to obtain the test result for the target test scenario. Thus, by simulating the real vehicle signals required for different test scenarios, the real vehicle environment under different test scenarios can be satisfied, thereby enabling the testing of OTA upgrade processes under different test scenarios. This improves the accuracy of OTA upgrade testing and provides convenience for OTA upgrade testing in different test scenarios, solving the problem of difficulties in OTA upgrade testing caused by the lack of a real vehicle or the inability to achieve the upgrade environment of a real vehicle.

[0241] Figure 8 This is a schematic diagram of an OTA upgrade testing device provided in an embodiment of this application. The OTA upgrade testing device can be implemented as part or all of a computer device by software, hardware, or a combination of both. This computer device can be as described below. Figure 9 The computer equipment shown. See also Figure 8 The device includes: an acquisition module 801, a signal simulation module 802, and a test module 803.

[0242] The acquisition module 801 is used to respond to the selection operation of the target test scenario on the OTA upgrade test interface, and to acquire the target signal type corresponding to the target test scenario. The target signal type refers to the signal type of the actual vehicle signal required by the OTA upgrade process corresponding to the target test scenario. The OTA upgrade test interface includes at least i test scenarios.

[0243] The signal simulation module 802 is used to simulate the actual vehicle signal corresponding to the target signal type based on the target signal type to obtain the target simulated signal;

[0244] The test module 803 is used to execute the test script corresponding to the target test scenario based on the target simulated signal, so as to send the target simulated signal to the vehicle system. After receiving the target simulated signal, the vehicle system executes the target upgrade process to generate the test object. Then, the vehicle system obtains the test object and tests it to obtain the test results of the OTA upgrade process corresponding to the target test scenario.

[0245] Optionally, the acquisition module 801 is used for:

[0246] In response to the selection of the target test scenario on the OTA upgrade test interface, determine whether the login account corresponding to the OTA upgrade test has the target operation permission;

[0247] If the logged-in account has the target operation permissions, obtain the target signal type corresponding to the target test scenario.

[0248] Optionally, the signal analog module 802 is used for:

[0249] Get the default signal state corresponding to the target signal type;

[0250] Obtain the signal attribute library, which includes signal values ​​corresponding to different real vehicle signals;

[0251] Based on the target signal type and default signal state, obtain the target signal value from the signal attribute library;

[0252] The target signal value is assigned to the actual vehicle signal corresponding to the target signal type to obtain the target analog signal corresponding to the target signal type.

[0253] Optionally, the target test scenario includes at least j test functions, and module 801 is used for:

[0254] In response to the selection operation of the target test function in the target test scenario, determine the target signal type and target signal state corresponding to the target test function;

[0255] Optionally, the signal analog module 802 is used for:

[0256] Based on the target signal type and target signal state, the actual vehicle signal corresponding to the target signal type is simulated to obtain the target simulated signal.

[0257] Optionally, the target signal type includes a first signal type and a second signal type. The first signal type is the same as the signal type indicated by the target test function among the target signal types, and the second signal type is a signal type other than the first signal type among the target signal types. The acquisition module 801 is used for:

[0258] Based on the target testing function, determine the target signal state corresponding to the first signal type;

[0259] The default signal state corresponding to the second signal type during OTA upgrade testing is determined as the target signal state corresponding to the second signal type.

[0260] Optionally, the object to be tested is the interface to be tested, and the test module 803 is used for:

[0261] The interface to be tested is validated in terms of both content and language to obtain the test results.

[0262] Optionally, test module 803 is used for:

[0263] Obtain the standard display content of the interface under test. The standard display content is the text content that the interface under test should originally display during the OTA upgrade test.

[0264] Determine whether the text content currently displayed on the interface under test is consistent with the standard display content;

[0265] If the text content to be displayed on the interface under test is consistent with the standard display content, the interface content verification of the interface under test is deemed to have passed.

[0266] If the text content to be displayed on the interface under test is inconsistent with the standard display content, it is determined that the interface content verification of the interface under test has failed.

[0267] Optionally, test module 803 is used for:

[0268] Obtain the standard language text of the interface to be tested. The standard language text refers to the standard translation text of the interface to be tested in different languages.

[0269] Obtain the development language text corresponding to the interface to be tested. The development language text refers to the language text displayed in different languages ​​on the interface to be tested during the OTA upgrade test.

[0270] If the standard language text and the development language text are the same, the interface language verification of the interface to be tested is confirmed to be passed.

[0271] If the standard language text differs from the development language text, it is determined that the interface language verification of the interface under test has failed.

[0272] In this embodiment, upon receiving a selection operation for a target test scenario, the system can first obtain the target signal type corresponding to the target test scenario in response to the selection operation. Since the OTA upgrade process differs for different test scenarios, the corresponding real vehicle signals also differ. Therefore, the signal type of the real vehicle signal required for the OTA upgrade process of the target test scenario can be obtained first. Then, based on the target signal type, the real vehicle signal corresponding to the target signal type is simulated to obtain the target simulated signal, which is the simulated real vehicle signal required for the OTA upgrade process of the target test scenario. Then, based on the target simulated signal, the test script corresponding to the target test scenario is executed to obtain the test results for the target test scenario. Thus, by simulating the real vehicle signals required for different test scenarios, the real vehicle environment under different test scenarios can be satisfied, thereby enabling the testing of OTA upgrade processes under different test scenarios. This improves the accuracy of OTA upgrade testing and provides convenience for OTA upgrade testing in different test scenarios, solving the problem of difficulties in OTA upgrade testing caused by the lack of a real vehicle or the inability to achieve the upgrade environment of the real vehicle.

[0273] It should be noted that the OTA upgrade testing device provided in the above embodiments is only used as an example to illustrate the division of the above functional modules when testing the OTA upgrade process. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0274] The functional units and modules in the above embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of the embodiments of this application.

[0275] The OTA upgrade testing device and the OTA upgrade testing method provided in the above embodiments belong to the same concept. The specific working process and technical effects of the units and modules in the above embodiments can be found in the method embodiments section, and will not be repeated here.

[0276] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 9 As shown, the computer device 9 includes a processor 90, a memory 91, and a computer program 92 stored in the memory 91 and executable on the processor 90. When the processor 90 executes the computer program 92, it implements the steps in the OTA upgrade test method in the above embodiments.

[0277] Computer device 9 can be a general-purpose computer device or a special-purpose computer device. In specific implementations, computer device 9 can be a desktop computer, a portable computer, a handheld computer, or other terminal device. This application embodiment does not limit the type of computer device 9. Those skilled in the art will understand that... Figure 9 The computer device 9 is merely an example and does not constitute a limitation on the computer device 9. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0278] Processor 90 can be a Central Processing Unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0279] In some embodiments, memory 91 may be an internal storage unit of the computer device 9, such as a hard disk or RAM of the computer device 9. In other embodiments, memory 91 may be an external storage device of the computer device 9, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD) card, flash card, etc., provided on the computer device 9. Furthermore, memory 91 may include both internal and external storage units of the computer device 9. Memory 91 is used to store the operating system, applications, boot loader, data, and other programs. Memory 91 may also be used to temporarily store data that has been output or will be output.

[0280] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.

[0281] This application provides a computer program product that, when run on a computer, causes the computer to perform the steps described in the various method embodiments above.

[0282] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above method embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate form. The computer-readable medium can include at least: any entity or device capable of carrying the computer program code to a photographing device / terminal device, a recording medium, a computer memory, ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage devices. The computer-readable storage medium mentioned in this application can be a non-volatile storage medium; in other words, it can be a non-transient storage medium.

[0283] It should be understood that all or part of the steps of the above embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented in whole or in part as a computer program product. The computer program product includes one or more computer instructions. The computer instructions can be stored in the above-described computer-readable storage medium.

[0284] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0285] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0286] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0287] The units described as separate components may or may not be physically separate. The components shown 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0288] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. An OTA upgrade testing method, characterized in that, The method includes: In response to the selection of a target test scenario on the OTA upgrade test interface, the target signal type and target signal status corresponding to the target test scenario are obtained. The target signal type refers to the signal type of the real vehicle signal required for the OTA upgrade process corresponding to the target test scenario, and the target signal status refers to the signal status of the real vehicle signal corresponding to the target signal type. The OTA upgrade test interface includes at least i test scenarios, and the target test scenario includes at least j test functions. The i test scenarios include a precondition test scenario, test scenarios for different power types, and an interface test scenario. The test scenarios for different power types are test scenarios for fuel type, test scenarios for pure electric type, and test scenarios for hybrid type. The test scenarios for different power types correspond to different target power types, and the target power types are fuel type, pure electric type, and hybrid type. Based on the target signal type and the target signal state, the actual vehicle signal corresponding to the target signal type is simulated to obtain the target simulated signal; Based on the target simulated signal, the test script corresponding to the target test scenario is executed to send the target simulated signal to the vehicle system. After receiving the target simulated signal, the vehicle system executes the target upgrade process to generate a test object. Then, the vehicle system obtains the test object and tests it to obtain the test results of the OTA upgrade process corresponding to the target test scenario. The test object is the data that needs to be tested generated during the OTA upgrade process of the vehicle system.

2. The method as described in claim 1, characterized in that, The step of responding to the selection operation of the target test scenario on the OTA upgrade test interface and obtaining the target signal type corresponding to the target test scenario includes: In response to the selection of the target test scenario on the OTA upgrade test interface, determine whether the login account corresponding to the OTA upgrade test has the target operation permission; If the logged-in account has the target operation permissions, obtain the target signal type corresponding to the target test scenario.

3. The method as described in claim 1, characterized in that, The step of simulating the actual vehicle signal corresponding to the target signal type based on the target signal type to obtain the target simulated signal includes: Obtain the default signal state corresponding to the target signal type; Obtain a signal attribute library, which includes signal values ​​corresponding to different real vehicle signals; Based on the target signal type and the default signal state, the target signal value is obtained from the signal attribute library; The target signal value is assigned to the actual vehicle signal corresponding to the target signal type to obtain the target analog signal corresponding to the target signal type.

4. The method as described in claim 1, characterized in that, The target signal type includes a first signal type and a second signal type. The first signal type is the same as the signal type indicated by the target test function among the target signal types. The second signal type is a signal type other than the first signal type among the target signal types. The step of determining the target signal state includes: Based on the target testing function, the target signal state corresponding to the first signal type is determined; The default signal state corresponding to the second signal type during OTA upgrade testing is determined as the target signal state corresponding to the second signal type.

5. The method as described in claim 1, characterized in that, The object to be tested is the interface to be tested, and the testing of the object to be tested includes: The interface to be tested is subjected to interface content verification and interface language verification to obtain the test results of the interface to be tested.

6. The method as described in claim 5, characterized in that, The steps for verifying the interface content of the interface to be tested include: Obtain the standard display content of the interface under test, which is the text content that the interface under test should originally display during the OTA upgrade test; Determine whether the text content to be displayed on the interface under test is consistent with the standard display content; If the text content to be displayed on the interface under test is consistent with the standard display content, the interface content verification of the interface under test is determined to be successful. If the text content to be displayed on the interface under test is inconsistent with the standard display content, it is determined that the interface content verification of the interface under test has failed.

7. The method as described in claim 5, characterized in that, The steps for performing interface language verification on the interface to be tested include: Obtain the standard language text of the interface to be tested, wherein the standard language text refers to the standard translation text of the interface to be tested in different languages; Obtain the development language text corresponding to the interface to be tested. The development language text refers to the language text displayed in different languages ​​by the interface to be tested during the OTA upgrade test. If the standard language text is the same as the development language text, the interface language verification of the interface under test is deemed to have passed. If the standard language text differs from the development language text, it is determined that the interface language verification for the interface under test has failed.

8. An OTA upgrade testing device, characterized in that, The device includes: The acquisition module is used to respond to the selection operation of the target test scenario on the OTA upgrade test interface, and acquire the target signal type and target signal status corresponding to the target test scenario. The target signal type refers to the signal type of the real vehicle signal required by the OTA upgrade process corresponding to the target test scenario, and the target signal status refers to the signal status of the real vehicle signal corresponding to the target signal type. The OTA upgrade test interface includes at least i test scenarios, the target test scenario includes at least j test functions, and the i test scenarios include precondition test scenarios, test scenarios of different power types, and interface test scenarios. The test scenarios of different power types are test scenarios of fuel type, test scenarios of pure electric type, and test scenarios of hybrid type. The test scenarios of different power types correspond to different target power types, and the target power types are fuel type, pure electric type, and hybrid type. The signal simulation module is used to simulate the actual vehicle signal corresponding to the target signal type based on the target signal type and the target signal state to obtain the target simulated signal; The testing module is used to execute the test script corresponding to the target test scenario based on the target simulated signal, so as to send the target simulated signal to the vehicle system. After receiving the target simulated signal, the vehicle system executes the target upgrade process to generate the test object. Then, the vehicle system obtains the test object and tests the test object to obtain the test result of the OTA upgrade process corresponding to the target test scenario. The test object is the data that needs to be tested generated by the vehicle system during the OTA upgrade process.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method as described in any one of claims 1 to 7.

Images