OTA upgrade test method, device and equipment

Abstract

The invention discloses an OTA upgrade test method, device and equipment, and belongs to the technical field of computers. Comprising the steps that in response to a selection operation on a target test scene on an OTA upgrading test interface, a target signal type corresponding to the target test scene is acquired, the target signal type refers to a signal type of a real vehicle signal required by an OTA upgrading process corresponding to the target test scene, and the OTA upgrading test interface comprises at least i test scenes; simulating a real vehicle signal corresponding to the target signal type based on the target signal type to obtain a target simulation signal; and based on the target analog 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. Thus, testing of the OTA upgrading process in different testing scenes can be achieved, and the problem that OTA upgrading testing is difficult due to the fact that no real vehicle exists or the upgrading environment where the real vehicle is located cannot be achieved is solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an OTA upgrade test method, device and equipment. Background Art

[0002] With the development of science and technology, software update technology is becoming more and more advanced. For example, OTA (Over-the-Air) technology is becoming more and more popular. It is a technology that pushes software updates directly to devices through wireless networks to achieve remote updates of device software. With the development of intelligent and interconnected cars, smart cars have more sensors and more complex software systems, and more frequent software updates are required to solve problems and improve performance. Therefore, the application of OTA technology in the automotive industry is becoming more and more extensive. For cars, the priority is safety. If the OTA update is incorrect or incomplete, it may cause car failures or safety problems, so the early OTA upgrade test is particularly important.

[0003] During the OTA upgrade test, the actual vehicle signals and corresponding upgrade processes required for different test scenarios are different. However, there is no actual vehicle during the test, or the upgrade environment of the actual vehicle cannot be achieved. Therefore, it is impossible to accurately test the upgrade process of different test scenarios, which will cause the problem of difficulty in OTA upgrade testing. Summary of the invention

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

[0005] In a first aspect, an OTA upgrade test method is provided, the method comprising:

[0006] In response to a selection operation of a target test scenario on an OTA upgrade test interface, a target signal type corresponding to the target test scenario is obtained, where the target signal type refers to a signal type of a real vehicle signal required for an OTA upgrade process corresponding to the target test scenario, and the OTA upgrade test interface includes at least i test scenarios;

[0007] Based on the target signal type, simulating a real vehicle signal corresponding to the target signal type to obtain a target simulation signal;

[0008] Based on the target simulation signal, execute the test script corresponding to the target test scenario to send the target simulation signal to the vehicle computer, so that the vehicle computer executes the target upgrade process to generate an object to be tested after receiving the target simulation signal, and then obtains the object to be tested through the vehicle computer and tests the object to be tested to obtain the test result of the OTA upgrade process corresponding to the target test scenario.

[0009] In the present application, after receiving the selection operation of the target test scene, the target signal type corresponding to the target test scene can be obtained in response to the selection operation of the target test scene. Since the OTA upgrade process corresponding to different test scenes is different, the corresponding real vehicle signals are also different, so the signal type of the real vehicle signal required for the OTA upgrade process corresponding to the target test scene 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 simulation signal, that is, the real vehicle signal required for the OTA upgrade process corresponding to the target test scene is simulated. Then, based on the target simulation signal, the test script corresponding to the target test scene is executed to obtain the test result of the target test scene. In this way, by simulating the real vehicle signal required for different test scenes, the real vehicle environment under different test scenes can be satisfied, so the test of the OTA upgrade process under different test scenes can be realized. Thereby improving the accuracy of the OTA upgrade test and providing convenience for the OTA upgrade test of different test scenes, solving the problem of OTA upgrade test difficulties caused by the absence of a real vehicle or the inability to reach the upgrade environment where the real vehicle is located.

[0010] Optionally, in response to a selection operation of a target test scenario on an OTA upgrade test interface, obtaining a target signal type corresponding to the target test scenario includes:

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

[0012] In a case where the login account has the target operation authority, the target signal type corresponding to the target test scenario is obtained.

[0013] Optionally, based on the target signal type, simulating a real vehicle signal corresponding to the target signal type to obtain a target simulation signal includes:

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

[0015] Acquire a signal attribute library, wherein the signal attribute library includes signal values ​​corresponding to different real vehicle signals;

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

[0017] The target signal value is assigned to the real vehicle signal corresponding to the target signal type to obtain a target simulation signal corresponding to the target signal type.

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

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

[0020] The step of simulating a real vehicle signal corresponding to the target signal type based on the target signal type to obtain a target simulation signal includes:

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

[0022] Optionally, the target signal type includes a first signal type and a second signal type, the first signal type is a signal type in the target signal type that is the same as the signal type indicated by the target test function, and the second signal type is a signal type in the target signal type except the first signal type, and the step of determining the target signal state includes:

[0023] Based on the target test function, determining a target signal state corresponding to the first signal type;

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

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

[0026] Interface content verification and interface language verification are performed on the interface to be tested to obtain a test result of the interface to be tested.

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

[0028] Obtaining standard display content of the interface to be tested, where the standard display content is the text content that should be originally displayed on the interface to be tested during the OTA upgrade test;

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

[0030] When the text content currently to be displayed on the interface to be tested is consistent with the standard display content, determining that the interface content verification of the interface to be tested has passed;

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

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

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

[0034] Obtaining a development language text corresponding to the interface to be tested, wherein the development language text refers to a language text displayed in different languages ​​by the interface to be tested during the OTA upgrade test;

[0035] In the case where the standard language text is the same as the development language text, determining that the interface language verification of the interface to be tested is passed;

[0036] When the standard language text is different from the development language text, it is determined that the interface language verification of the interface to be tested has failed.

[0037] In a second aspect, an OTA upgrade test device is provided, the device comprising:

[0038] an acquisition module, configured to, in response to a selection operation of a target test scenario on an OTA upgrade test interface, acquire a target signal type corresponding to the target test scenario, wherein the target signal type refers to a signal type of a real vehicle signal required for an OTA upgrade process corresponding to the target test scenario, and the OTA upgrade test interface includes at least i test scenarios;

[0039] A signal simulation module, used to simulate a real vehicle signal corresponding to the target signal type based on the target signal type to obtain a target simulation signal;

[0040] A test module is used to execute a test script corresponding to the target test scenario based on the target simulation signal to send the target simulation signal to the vehicle computer, so that the vehicle computer executes a target upgrade process to generate an object to be tested after receiving the target simulation signal, and then obtains the object to be tested through the vehicle computer and tests the object to be tested to obtain a test result of the OTA upgrade process corresponding to the target test scenario.

[0041] In a third aspect, a computer device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the above-mentioned OTA upgrade test method when executed by the processor.

[0042] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned OTA upgrade test method is implemented.

[0043] In a fifth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the steps of the above-mentioned OTA upgrade test method.

[0044] It can be understood that the beneficial effects of the second, third, fourth and fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0046] Figure 1 It is a schematic diagram of an implementation environment of an OTA upgrade test method provided in an embodiment of the present application;

[0047] Figure 2 It is a flow chart of an OTA upgrade test method provided in an embodiment of the present application;

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

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

[0050] Figure 5 This is a flow chart of an OTA upgrade test corresponding to different power types provided in an embodiment of the present application;

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

[0052] Figure 7It is a structural diagram of the function implementation of an OTA upgrade test method provided in an embodiment of the present application;

[0053] Figure 8 It is a structural diagram of an OTA upgrade test device provided in an embodiment of the present application;

[0054] Fig. 9 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0056] It should be understood that the "multiple" mentioned in this application refers to two or more. In the description of this application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate the clear description of the technical solution of this application, the words "first" and "second" are used to distinguish between the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the words "first" and "second" do not limit the quantity and execution order, and the words "first" and "second" do not limit them to be different.

[0057] First, the terms involved in the embodiments of the present application are explained.

[0058] OTA upgrade: OTA upgrade applied to automobiles generally refers to the technology of remotely upgrading the vehicle system through wireless networks. Generally speaking, OTA upgrades include FOTA (Firmware Over The Air) and SOTA (Software Over The Air).

[0059] FOTA upgrade refers to upgrading the car's firmware, such as upgrading the accelerator pedal's response strength to make acceleration more linear and comfortable, etc. Another example is upgrading the braking capability and shortening the braking distance to improve driving safety.

[0060] SOTA upgrade refers to upgrading the car's software, for example, upgrading the multimedia system, changing the operating interface, theme, changing the dashboard display style, etc.

[0061] Zhou Ligong Library: refers to Zhou Ligong CAN (Controller Area Network) bus development kit. Zhou Ligong Library includes signal values ​​corresponding to different real vehicle signals on the vehicle. Developers can use Zhou Ligong Library to more easily know the signal values ​​corresponding to different real vehicle signals, so that they can more conveniently develop CAN communication related projects.

[0062] Before describing the OTA upgrade test method provided in the embodiment of the present application, the implementation environment involved in the embodiment of the present application is first described.

[0063] For example, Figure 1 This is a schematic diagram of an implementation environment of an OTA upgrade test method provided in an embodiment of the present application, see Figure 1 , Figure 1 It includes a computer device 101 and a vehicle computer 102 .

[0064] The computer device 101 is used to test the OTA upgrade process. For example, the computer device 101 can be a terminal device such as a desktop computer, a portable computer, a PDA, etc. In the embodiment of the present application, the OTA upgrade test method can be packaged into an OTA test tool, and the computer device 101 can be installed with the OTA test tool to test the OTA upgrade process through the OTA test tool.

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

[0066] In some embodiments, the implementation environment of the OTA upgrade test method may also include a signal sending device 103. The signal sending device 103 is used to send a real vehicle signal to the vehicle computer 102. In an embodiment of the present application, a signal attribute library may be stored in the signal sending device 103. During the OTA upgrade test, the computer device 101 can simulate the real vehicle signal by calling the signal attribute library, and the subsequent signal sending device 103 can send the simulated real vehicle signal to the vehicle computer 102.

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

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

[0069] After simulating the real vehicle signal, the computer device 101 can send the simulated real vehicle signal to the vehicle computer 102. After receiving the corresponding real vehicle signal, the vehicle computer 102 starts to simulate the OTA upgrade process. After that, the vehicle computer 102 returns the signals, interfaces and other data generated in the upgrade process to the computer device 101, so that the computer device 101 tests the signals and interfaces generated during the OTA upgrade process to verify the accuracy of the OTA upgrade process.

[0070] The application scenarios of the embodiments of the present application are further described.

[0071] Generally speaking, the purpose of OTA upgrade testing is to ensure the safety and stability of the car after the upgrade. That is to say, after the OTA upgrade, whether the car will have any malfunctions or safety issues, and whether the problems that existed in the previous version have been solved in the upgraded version.

[0072] In the related technology, when performing OTA upgrade testing, the technician downloads the installation package from the server and installs the downloaded installation package to perform OTA upgrade on the vehicle computer. During the OTA upgrade of the vehicle computer, the technician needs to observe the upgrade process all the time to check whether there are any problems with the interface, data, etc. generated during the upgrade process.

[0073] Since manual verification sometimes has errors, in order to ensure stability after the upgrade, multiple OTA upgrades are generally required to verify the accuracy of the upgraded version. However, an OTA upgrade contains more signals and upgrade content, and the time consumed for an OTA upgrade is also relatively long. If multiple OTA upgrade tests are required, the time consumed will increase exponentially. Therefore, the above upgrade method invests a lot in time and labor costs, and may even lead to problems with product delivery on time.

[0074] In addition, during the OTA upgrade test, the actual vehicle signals and corresponding upgrade processes required for different test scenarios are different. However, there is no actual vehicle during the test, or the upgrade environment of the actual vehicle cannot be achieved. Therefore, it is impossible to accurately test the upgrade process of different test scenarios, which will cause the problem of difficulty in OTA upgrade testing.

[0075] For example, today's automotive industry includes vehicles of different power types, including traditional fuel vehicles, emerging pure electric vehicles, and hybrid vehicles. It should be understood that vehicles of different power types involve different types of signals and have different hardware structures. Therefore, the OTA upgrade process is different for vehicles of different power types.

[0076] For the OTA upgrade test of emerging pure electric vehicles and hybrid vehicles, the OTA upgrade test is generally carried out on a test bench. However, the test bench has certain limitations in simulating the actual working environment of the vehicle, which will result in the absence of a real vehicle or the failure to meet the real vehicle conditions, thus causing the OTA upgrade test of the relevant power type to be unable to be carried out.

[0077] To this end, an embodiment of the present application provides an OTA upgrade test method, which can be applied to the scenario of testing the OTA upgrade process.

[0078] Specifically, the test tool installed on the computer device can display an OTA upgrade test interface, which may include at least i test scenarios. When the user wants to test the corresponding OTA upgrade process under a certain test scenario, the user can click on the corresponding test scenario. After that, the computer device can respond to the selection operation of this test scenario on the OTA upgrade test interface, and first obtain the signal type and signal state of the real vehicle signal corresponding to this test scenario. Then, based on the signal type and signal state of the real vehicle signal corresponding to this test scenario, the real vehicle signal required for the OTA upgrade process corresponding to this test scenario is simulated to obtain the target simulation signal. Finally, based on the target simulation signal, the test script corresponding to this test scenario is executed to send the target simulation signal to the vehicle computer, so that the vehicle computer executes the target upgrade process to generate the object to be tested after receiving the target simulation signal, and then obtains the object to be tested through the vehicle computer and tests the object to be tested, thereby obtaining the test result of the OTA upgrade process corresponding to this test scenario.

[0079] In this case, by simulating the real vehicle signals required for different test scenarios, the real vehicle environment in different test scenarios can be met, so the OTA upgrade process in different test scenarios can be tested. This improves the accuracy of the OTA upgrade test and provides convenience for OTA upgrade tests in different test scenarios, solving the problem of OTA upgrade test difficulties caused by the lack of a real vehicle or the inability to reach the upgrade environment of the real vehicle. In addition, through the above-mentioned automatic execution of the test script, OTA automatic upgrade testing can be performed, which can save time and labor costs, and can avoid the problem of product delivery on time.

[0080] The OTA upgrade test method provided in the embodiment of the present application is explained in detail below.

[0081] Figure 2 is a flow chart of an OTA upgrade test method provided in an embodiment of the present application. The method can be applied to computer equipment. Figure 2 , the method comprises the following steps.

[0082] Step 201: 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 real vehicle signal required for 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 is used to provide technicians with test entries for at least i test scenarios. When the technicians want to test a test scenario among at least i test scenarios, they click on the corresponding test scenario to start testing the OTA upgrade process corresponding to the corresponding test scenario.

[0085] Optionally, the OTA upgrade test interface may include at least i scene controls, and the multiple scene controls correspond to at least i test scenes one by one, that is, any one of the at least i test scenes corresponds to a corresponding scene control. In addition, after clicking a scene control corresponding to a test scene, it is equivalent to starting the test of the OTA upgrade process corresponding to the test scene.

[0086] For example, Figure 3 This is a schematic diagram of an OTA upgrade test interface provided in an embodiment of the present application, see Figure 3 , Figure 3 The OTA upgrade test interface 301 includes a plurality of scene controls 302, including a scene control 302 corresponding to a precondition test scene, a scene control 302 corresponding to a fuel type test scene, a scene control 302 corresponding to a hybrid type test scene, a scene control 302 corresponding to a pure electric type test scene, and a scene control 302 corresponding to an interface test scene. For example, if the user wants to test the OTA upgrade process under the hybrid type test scene, the user can click the scene control 302 corresponding to the hybrid type test scene.

[0087] It should be understood that different real vehicle signals are required for OTA upgrades in different test scenarios. In this case, after selecting the target test scenario, the signal type of the real vehicle signal required for the target test scenario can be obtained, that is, which real vehicle signals are required, so that the corresponding OTA upgrade can be performed accordingly.

[0088] Optionally, the operation of step 201 may be: based on the scene identifier of the target test scene, obtaining the target signal type corresponding to the target test scene from the first corresponding relationship.

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

[0090] The first corresponding relationship is a corresponding relationship between a scene identifier and a signal type. The first corresponding relationship includes multiple scene identifiers and multiple signal types, wherein one scene identifier may correspond to multiple signal types.

[0091] In the embodiment of the present application, the first corresponding relationship can be pre-calibrated by a technician, and the technician can perform the calibration based on the vehicle signal file.

[0092] The vehicle signal file is a file for storing the vehicle signal type, that is, the vehicle signal file can include the signal types of all signals set on the vehicle. Optionally, the vehicle signal file can be a dbc file, which is a file including the vehicle signal.

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

[0094] In this case, by pre-establishing a correspondence between the scene identifier and the signal type, when performing an OTA upgrade test, 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 embodiment of the present application, any one of the at least i test scenarios may further include at least j test functions.

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

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

[0098] In this case, the OTA upgrade test interface may 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 the present application, see Figure 4 , Figure 4Including an OTA upgrade test interface 401. Among them, the OTA upgrade test interface 401 includes multiple function controls 402, and the multiple function controls 402 refer to controls of at least j test functions corresponding to each test scenario in at least i test scenarios. For example, in the interface test scenario, it includes controls for successful interface test functions, controls for failed interface test functions, controls for upgrade interface test functions, etc. When the technician wants to test a certain test function in a certain test scenario, he can click the control of the corresponding test function. For example, the technician wants to test the OTA upgrade process when the gear position does not meet the test scenario of the hybrid type, then he can click the function control 402 of the gear position not meeting this test function in the test scenario of the hybrid type.

[0099] Optionally, the operation of step 201 may be: in response to a selection operation of a target test function in a target test scenario, determining a target signal type and a 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 for a signal, it can include different signal states. For example, for the gear signal, it can include multiple different signal states, such as signal states including P gear, N gear, D gear, R gear, etc. For another example, for the parking state signal, it can include two signal states: parked and not parked. For another example, for the engine state signal, it can include two signal states: off and running.

[0101] It should be understood that the real vehicle signals required in the same test scenario are the same, but the signal states of the real vehicle signals corresponding to different test functions are different. Figure 4 Give an example.

[0102] For example, the target test scenario is a fuel type test scenario, and the target test function is gear position not satisfied. Then it can be determined that the target signal types corresponding to the target test scenario are gear position, parking status, engine status, battery power, etc. That is, when performing an OTA upgrade test of the fuel type test scenario, the signal types of the required real vehicle signals include gear position, parking status, engine status, battery power, etc.

[0103] In addition, the signal states of the above signals are different under different test functions. For example, if the target test function is that the gear position is not satisfied, then the signal state of the above gear position signal can be D gear or R gear, etc., the signal state of the parking state can be parked, the signal state of the engine state can be off, and the signal state of the battery power can be sufficient. For another example, when the target test function is that the handbrake is not satisfied, then the signal state of the gear position signal can be P gear or N gear, the signal state of the parking state can be not parked, the signal state of the engine state can be off, and the signal state of the battery power can be sufficient.

[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, so that the detailed information of the signal required to test the OTA upgrade process under the target test scenario can be obtained. Then, the actual vehicle signal can be accurately simulated based on the target signal type and target signal status, and the target test scenario can be tested more carefully, so that the OTA upgrade process can be tested more accurately.

[0105] As a possible implementation, the target signal type may include a first signal type and a second signal type; the first signal type is a signal type in the target signal type that is the same as the signal type indicated by the target test function; and the second signal type is a signal type in the target signal type other than the first signal type.

[0106] For example, the target signal types include gear position, parking state, engine state, and battery power. If the target test function is gear position not satisfied, the first signal type is gear position, and the second signal type is parking state, engine state, and battery power.

[0107] The target signal state may be determined by: determining the target signal state corresponding to the first signal type based on the target test function; and determining the default signal state corresponding to the second signal type during the OTA upgrade test 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 may include: 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 position not satisfied, the signal type indicated by the target test function is gear position, and the indicated signal state is the signal state corresponding to gear position not satisfied, that is, the signal state may include D gear or N gear. Thus, it can be determined that the target signal state corresponding to the gear position in the target signal type is D gear or N gear.

[0110] In addition, generally, when performing OTA upgrade testing, multiple real vehicle signals can be set with default signal states, so that OTA upgrade testing in a real vehicle environment under the default signal state can be implemented. Therefore, in the embodiment of the present application, when 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, the operation of step 201 can also be: in response to the selection operation 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 authority; if the login account has the target operation authority, obtain the target signal type corresponding to the target test scenario.

[0112] In an embodiment of the present application, the target operation authority may include the operation authority to operate on the OTA upgrade test interface and perform subsequent OTA upgrade tests.

[0113] Generally, when a technician performs an OTA test, he or she must first log in to the corresponding account on the test platform. Only after logging in can the corresponding test be performed, and different accounts may have different corresponding operation permissions. Therefore, in the embodiment of the present application, before performing the OTA upgrade test, it is also possible to determine whether the logged-in account has the target operation permission.

[0114] In this way, by determining whether the login account corresponding to the OTA upgrade test has the target operation authority, the corresponding OTA upgrade test can be performed only if the login account has the target operation authority. When there are non-professional testers, they may not be familiar with the OTA upgrade test process, and the test results obtained will not be accurate enough. Therefore, the above operation can avoid the phenomenon of some non-professional testers making mistakes in OTA upgrade tests.

[0115] Among them, the operation to determine whether the login account corresponding to the OTA upgrade test has the target operation authority can be: traverse the target permission list to determine 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 authority; if the login account does not exist in the permission list, determine that the login account does not have the target operation authority.

[0116] The target permission list refers to a list of login accounts with target operation permissions. The target permission list may include multiple login accounts. It should be understood that the multiple login accounts in the target permission list all have target operation permissions. Therefore, if the login account exists in the target permission list, it means that the login account has the target operation permission.

[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, when performing OTA upgrade testing, the OTA upgrade test cannot be completed smoothly due to the lack of a real vehicle or the unsatisfactory real vehicle environment. Therefore, in the embodiment of the present application, the real vehicle signal required during the OTA upgrade test can be simulated, so that the corresponding OTA upgrade test can be implemented later.

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

[0119] In the embodiment of the present application, by simulating the real vehicle signals required for different test scenarios, the real vehicle environment in different test scenarios can be met, so that the OTA upgrade process in different test scenarios can be tested later. In this way, the problem of OTA upgrade testing difficulties caused by the lack of a real vehicle or the inability to reach the upgrade environment of the real vehicle is solved.

[0120] In one possible implementation, the operation of step 202 may be: obtaining a default signal state corresponding to the target signal type; obtaining a signal attribute library; obtaining a target signal value from the signal attribute library based on the target signal type and the default signal state; assigning the target signal value to the actual vehicle signal corresponding to the target signal type, and obtaining a target simulation 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 Zhou Ligong library. For example, for the high-voltage signal of a pure electric vehicle, the signal attribute library may include a signal value corresponding to the high-voltage signal of 0xC:Powerup4LVcharging. Specifically, the signal attribute library may include signal values ​​under all signal states corresponding to different signal types. For example, the signal attribute library may include signal values ​​of different gear states corresponding to the gear signal, including a signal value of 0x00 for P gear, a signal value of 0x02 for N gear, a signal value of 0x03 for D gear, and so on.

[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 case, by obtaining the target signal value from the signal attribute library and assigning the target signal value to the real vehicle signal corresponding to the target signal type, it is equivalent to obtaining the signal value of the real vehicle signal during real vehicle communication. In other words, it is equivalent to generating a signal during real vehicle communication, so it can be said that the real vehicle signal is simulated. In this way, by assigning the signal value to the real vehicle signal, it is a more convenient way to simulate the real vehicle signal, which improves the convenience and flexibility of signal simulation.

[0124] Among them, based on the target signal type and the default signal state, the operation of obtaining the target signal value from the signal attribute library can be: based on the type identifier of the target signal type, determining all signal values ​​corresponding to the target signal type from the signal attribute library; based on the default signal state, obtaining 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 a target signal type is a gear position, the type identifier of the gear position can be set to GearPosition.

[0126] All signal values ​​corresponding to the target signal type refer to signal values ​​under all signal states corresponding to the target signal type, that is, 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 corresponding to 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, so as to obtain the specific signal value of the actual vehicle signal to be simulated. In this way, the specific signal value of the actual vehicle signal to be simulated can be accurately obtained.

[0128] For example, if the target signal type is gear position and the default signal state is P gear, then the above operation process is: first, based on the gear type identifier GearPosition, obtain all signal values ​​corresponding to the gear position from the signal attribute library, such as the signal value of P gear is 0x00, the signal value of N gear is 0x02, the signal value of D gear is 0x03, and the signal value of R gear is 0x04. Then, the signal value corresponding to the default signal state (P gear) is obtained from all signal values ​​as 0x00, that is, the target signal value corresponding to the target signal type is determined to be 0x00.

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

[0130] For example, the target signal types include gear position, parking state, engine state, and battery power. The default signal state corresponding to the gear position is P gear, the default signal state corresponding to the parking state is parked, and the default signal state corresponding to the engine state is off.

[0131] For the gear position signal, firstly based on the gear position type identifier GearPosition, all signal values ​​corresponding to the gear position are obtained from the signal attribute library, and then the signal value corresponding to the default signal state (P gear) is obtained from all signal values ​​as 0x00, that is, the target signal value corresponding to the target signal type is determined to be 0x00. Then the target signal value is assigned to the gear position signal, that is, the operation of GearPosition==0x00 is performed, so that the target analog signal corresponding to the gear position is GearPosition==0x00.

[0132] For the parking state signal, firstly, based on the parking state type identifier EPBStatus, all signal values ​​corresponding to the parking state signal are obtained from the signal attribute library, and then the signal value corresponding to the default signal state (parked) is obtained from all signal values ​​as 0f01, that is, the target signal value corresponding to the parking state is determined to be 0f01. Then, the target signal value is assigned to the parking state signal, that is, the operation of EPBStatus==0f01 is performed, so that the target analog signal corresponding to the parking state signal is EPBStatus==0f01.

[0133] For the engine status signal, firstly, based on the type identifier EngineStatus of the engine status, all signal values ​​corresponding to the engine status signal are obtained from the signal attribute library, and then the signal value corresponding to the default signal status (ignition off) is obtained from all signal values, that is, the target signal value corresponding to the engine status signal is determined to be 0g01. Then, the target signal value is assigned to the engine status signal, that is, the operation of EngineStatus==0g01 is executed, so that the target analog signal corresponding to the engine status signal is EngineStatus==0g01.

[0134] Another possible implementation method is to obtain a signal attribute library when a selection operation for a target test function in a target test scenario is received; obtain a target signal value from the signal attribute library based on the target signal type and the target signal state; assign the target signal value to the real vehicle signal corresponding to the target signal type, and obtain a target simulation signal corresponding to the target signal type.

[0135] In this case, when the technician wants to test the OTA upgrade process under specific upgrade conditions, he can execute the above-mentioned simulation steps of the target simulation signal, thereby simulating the real vehicle signal required for the OTA upgrade test under specific upgrade conditions, and then testing the OTA upgrade process under specific upgrade conditions.

[0136] Among them, based on the target signal type and the target signal state, the operation of obtaining the target signal value from the signal attribute library can be: based on the type identifier of the target signal type, determining all signal values ​​corresponding to the target signal type from the signal attribute library; based on the target signal state, obtaining 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 corresponding to 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 above-mentioned 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 manner, and will not be repeated here.

[0139] Step 203: Based on the target simulation signal, execute the test script corresponding to the target test scenario to send the target simulation signal to the vehicle computer, so that the vehicle computer executes the target upgrade process to generate the object to be tested after receiving the target simulation signal, and then obtains the object to be tested through the vehicle computer and tests the object to be tested to obtain the test result of the OTA upgrade process corresponding to the target test scenario.

[0140] The object to be tested is the data that needs to be tested generated during the OTA upgrade of the vehicle computer. For example, if an interface pops up during the OTA upgrade, 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 may be a process for performing OTA upgrades on fuel type vehicles.

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

[0143] Executing the above test script is to perform the following process: after obtaining the target simulation signal, the computer device can send the target simulation signal to the vehicle computer. After receiving the target simulation signal, the vehicle computer simulates the process of receiving the real vehicle signal sent by other controllers, so that the vehicle computer will perform the corresponding OTA upgrade according to the received target simulation signal, and in the process of OTA upgrade, corresponding data may be generated, which can be called the object to be tested. The vehicle computer can then return the object to be tested to the computer device, so that the computer device obtains the object to be tested from the vehicle computer. When the computer device receives the object to be tested returned by the vehicle computer, it can verify the object to be tested to verify whether there is a problem with the OTA upgrade process, that is, the test result of the OTA upgrade process corresponding to the target test scenario can be obtained.

[0144] In this case, by sending a target simulation signal to the vehicle computer, the vehicle computer thinks that it is in the corresponding real vehicle environment, so that the corresponding OTA upgrade can be simulated in the simulated real vehicle environment. In this way, the problem of being unable to perform the corresponding OTA upgrade test when there is no real vehicle or the real vehicle environment is not satisfactory is solved, and the OTA upgrade test process becomes more convenient.

[0145] Specifically, the operation of step 203 may be: sending a target simulation signal to the vehicle computer, so that the vehicle computer executes a target upgrade process after receiving the target simulation signal and generates an object to be tested; obtaining the object to be tested from the vehicle computer; and testing the object to be tested.

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

[0147] In this case, the operation of testing the object to be tested may be: performing interface content verification and interface language verification on the interface to be tested, and obtaining a test result of the interface to be tested.

[0148] Interface content verification is used to test whether the content displayed on the interface is correct. It should be understood that for the test of the pop-up interface 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 in the upgrade success interface should be "Upgraded Successfully", so the test of the upgrade success interface should be to test whether the content currently displayed on the interface is "Upgraded Successfully".

[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 can also include scenarios in multiple languages. It should be understood that vehicles can be sold to different countries, so the language used by the vehicle system should also be different languages. 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 the prior art, when testing the interface generated during the OTA upgrade process, when an interface pops up during the OTA upgrade, the technicians manually check whether the content displayed on the interface is correct and whether the translation is correct. However, in order to ensure the accuracy and stability after the OTA upgrade, dozens of repeated tests are usually required. If the interface is tested in the above manner, it will be very labor-intensive and time-consuming.

[0151] In this case, by automatically executing the corresponding test scripts, the interface content and interface language verification can be automatically verified, so that the content of the interface and the language displayed on the interface can be automatically verified, thereby realizing automated testing of the interface during the OTA upgrade test, and then improving the test efficiency of the interface test.

[0152] Among them, the step of verifying the interface content of the interface to be tested includes: obtaining the standard display content of the interface to be tested; determining whether the text content currently displayed on the interface to be tested is consistent with the standard display content; when the text content currently displayed on the interface to be tested is consistent with the standard display content, determining that the interface content verification of the interface to be tested has passed; when the text content to be displayed on the interface to be tested is inconsistent with the standard display content, determining that the interface content verification of the interface to be tested has failed.

[0153] The standard display content is the text content that should be displayed on the interface to be tested during the OTA upgrade test. It should be understood that during the development process, the technical staff writes the content to be displayed on each interface 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 staff can write the text content that should be displayed on each interface according to the development requirements document. In an embodiment of the present application, the standard display content can be the text content that should be displayed on the interface to be tested in the development requirements document.

[0154] For example, the development requirement document can be an execl file. During the development process, the technician will convert the execl 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 execl file can be used to verify whether the content displayed on the interface actually seen by the user is correct. Therefore, the text content that should be displayed on the interface to be tested in the execl file can be compared with the text content currently displayed on the interface to be tested, and then it can be known whether the content to be displayed on the interface to be tested is incorrect.

[0155] In this case, when the content currently displayed on the interface to be tested is consistent with the standard display content, it means that the content currently displayed on the interface to be tested is the text content that should be displayed on the interface as required by the development requirement document, which means that the content currently displayed on the interface to be tested is correct. Therefore, it can be determined that the interface content verification of the interface to be tested has passed.

[0156] When the content currently displayed on the interface to be tested is inconsistent with the standard display content, it means that the content currently displayed on the interface to be tested is not the text content that should be displayed on the interface to be tested as required by the development requirement document. In other words, the content currently displayed on the interface to be tested is inconsistent with the development requirements, that is, the content currently displayed on the interface to be tested is incorrect. Therefore, it can be determined that the interface content verification of the interface to be tested has failed.

[0157] Among them, the step of performing interface language verification on the interface to be tested includes: obtaining the standard language text of the interface to be tested; obtaining the development language text corresponding to the interface to be tested; when the standard language text and the development language text are the same, determining that the interface language verification of the interface to be tested has passed; when the standard language text and the development language text are different, determining that the interface language verification of the interface to be tested has not passed.

[0158] The standard language text refers to the standard translation text in different languages ​​corresponding to the interface to be tested. Optionally, the standard language text is the standard display content translated into different languages ​​based on the above standard display content.

[0159] The development language text includes the language text displayed in different languages ​​on the interface to be tested during the OTA upgrade test. The development language text is the language text corresponding to the different languages ​​written into the development code by the technicians during the development process. The interface to be tested 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 ​​currently to be displayed on the interface to be tested.

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

[0161] When the standard language text is different from the development language text, it means that the standard translation texts in different languages ​​corresponding to the interface to be tested are different from the language texts to be displayed in different languages ​​of the interface to be tested during the OTA upgrade test, that is, the text content displayed in different languages ​​of the interface to be tested during the test is not the standard translation text, which indicates that there are problems with the text content corresponding to different languages ​​displayed on the interface to be tested during the test. Therefore, it can be determined that the interface language verification of the interface to be tested has failed.

[0162] It is worth noting that when it is determined that the interface language verification of the interface to be tested has failed or the interface content verification has failed, manual secondary verification can be performed.

[0163] Specifically, when the interface language verification or the interface content verification of the interface to be tested fails, a first reminder message can be output; and the interface to be tested that has not passed the verification is subsequently displayed so that a technician can manually test the interface to be tested.

[0164] The first reminder information is used to indicate that the interface to be tested has not passed the test.

[0165] In this case, after outputting the first reminder message, the technician can learn that the interface to be tested has not passed the test. Then, by displaying the interface to be tested, the technician can further perform manual testing on the interface to be tested to check whether the content displayed on the interface to be tested is correct or whether the language texts corresponding to different languages ​​displayed on the interface to be tested are correct.

[0166] In this way, when the interface language verification of the interface to be tested fails or the interface content verification fails, the interface to be tested can be tested more accurately through manual secondary verification to improve the interface accuracy of the interface to be tested.

[0167] Optionally, the OTA upgrade test interface may display multiple interface opening entrances, such as multiple interface opening controls. When a technician wants to manually verify an interface, he can click the interface opening control of the corresponding interface, so that after clicking the interface opening control of the corresponding interface, the corresponding interface can be called to achieve the rendering of the corresponding interface, thereby displaying the corresponding interface, and then the corresponding interface can be manually verified.

[0168] It should be noted that the above steps can realize automatic testing of each interface during the upgrade process, and can realize automatic testing of interface content and interface language. Only when an interface fails the test, further manual secondary verification is performed. Compared with the prior art in which technicians check the interface content one by one, that is, the method of manual testing throughout the process, the test efficiency of the interface test can be improved.

[0169] The following is a detailed description of the OTA upgrade test process for specific test scenarios.

[0170] In an embodiment of the present application, at least i test scenarios may include a precondition test scenario, test scenarios of different power types, and an interface test scenario.

[0171] Among them, the precondition test scenario is a scenario for checking the test environment before the OTA upgrade test, and its purpose is to check whether the current test environment meets the environmental requirements of the OTA upgrade test.

[0172] Before conducting an OTA upgrade test, 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, in the development and testing process, by being in DEBUG mode, the system will not perform actual OTA upgrades. Factory mode is a mode set in the factory when the vehicle is not sold. OTA upgrades are not supported in factory mode, so the system needs to be out of factory mode during testing. Therefore, when conducting an OTA upgrade test, the test environment needs to meet certain conditions, and the test environment can be checked for this reason.

[0173] The interface test scenario is a scenario for testing the interface that pops up during the OTA upgrade process, that is, to determine whether there is a problem with the interface that pops up during the OTA upgrade process. In an embodiment of the present application, the interface test scenario can be triggered when the interface content verification and interface language verification of the interface fail in other test scenarios. For example, in test scenarios of different power types, after testing the interface, if it is determined that an interface fails the test, the interface test scenario can be triggered.

[0174] Test scenarios for different power types refer to scenarios for OTA upgrade tests on vehicles with different power types. Since the OTA upgrade processes for different power types are different, test scenarios for different power types can be distinguished. In the embodiment of the present application, test scenarios for different power types include test scenarios for fuel type, test scenarios for pure electric type, and test scenarios for hybrid type.

[0175] First, the OTA upgrade test corresponding to the test scenarios of different power types is described in detail. It should be understood that each of the test scenarios of different power types can include at least j test functions. The OTA upgrade test corresponding to the test scenarios of different power types can specifically include the following steps (1) to (3).

[0176] (1) In response to a selection operation of a target test function of a test scenario of a target power type, a target signal type and a target signal state corresponding to the test scenario of the target power type are obtained.

[0177] The target power type may be a fuel type, a pure electric type, or a hybrid type.

[0178] The target test function may be one test function among the at least j test functions.

[0179] Since vehicles of different power types have different structures, the actual vehicle signals involved in the vehicles are also different. In addition, the signal states of the actual vehicle signals corresponding to different test functions in a test scenario are also different, so the target signal type and target signal state can be obtained.

[0180] For example, the target signal types corresponding to the fuel type test scenario may include gear position, handbrake, engine speed, engine status, battery power, etc. In this case, the test functions of the fuel type test scenario may include OTA upgrade test when the gear position is not satisfied, OTA upgrade test when the handbrake is not satisfied, and OTA upgrade test when the battery power is not satisfied.

[0181] For another example, the target signal types corresponding to the hybrid test scenario may include voltage, gear, vehicle speed, handbrake, engine status, engine speed, etc. In this case, the test functions of the hybrid test scenario may include OTA upgrade test during high voltage upgrade, OTA upgrade test during low voltage upgrade, OTA upgrade test when vehicle speed is not satisfied, upgrade test when gear is not satisfied, OTA upgrade test when handbrake is not satisfied, and other test functions.

[0182] For example, if the technician selects the OTA upgrade test for the high-voltage upgrade in the hybrid type test scenario, then the target signal types corresponding to the OTA upgrade test for the high-voltage upgrade can include voltage, vehicle speed, parking status, gear position, etc. Then the target signal state corresponding to each target signal type can be: the target signal state corresponding to the voltage signal is the high-voltage state, the target signal state corresponding to the vehicle speed signal is that the vehicle speed meets the conditions, the target signal state corresponding to the parking status is parked, and the target signal state corresponding to the gear position is P gear 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 a target simulation signal.

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

[0185] In this way, the real vehicle signals required for the OTA upgrade process of different power types can be simulated, so that when conducting OTA upgrade tests of different power types, different real vehicle signals can be simulated, so that the corresponding OTA upgrade tests under different power types can be realized under different real vehicle conditions, thereby solving the problem that the OTA upgrade process of different power types cannot be tested in the real vehicle environment, which can improve the accuracy of the OTA upgrade test.

[0186] Since pure electric and hybrid vehicles include high voltage upgrade and low voltage upgrade during OTA upgrade, in pure electric and hybrid test scenarios, the target signal type may include a voltage signal, and the target signal state may include a high voltage state or a low voltage state.

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

[0188] In this case, it is equivalent to first determining whether this OTA upgrade test is a high-voltage upgrade or a low-voltage upgrade. If this OTA upgrade test is a high-voltage upgrade, a high-voltage signal is simulated; if this OTA upgrade test is a low-voltage upgrade, a low-voltage signal is simulated. This allows the high-voltage environment or low-voltage environment required in the OTA upgrade process for pure electric and hybrid types to be met.

[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 computer, so that the vehicle computer executes the target upgrade process to generate the object to be tested after receiving the target simulation signal, and then obtains the object to be tested through the vehicle computer and tests the object to be 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 simulation signal required in the test scenario of the target power type, the computer device can send the target simulation signal to the vehicle computer. After receiving the target simulation signal, the vehicle computer is equivalent to receiving the real vehicle signal returned by each controller in the real vehicle communication. Therefore, after receiving the target simulation signal, the vehicle computer will detect that the upgrade environment it is in is satisfactory, and then the corresponding OTA upgrade can be simulated. Afterwards, the corresponding object to be tested can be generated during the OTA upgrade process. After that, the computer device obtains the object to be tested from the vehicle computer and tests the object to be tested, so as to know whether there is a problem in the OTA upgrade process for the target power type.

[0191] In the embodiment of the present application, the object to be tested may be an interface generated during the OTA upgrade process. In this case, testing the object to be tested is equivalent to testing the interface that pops up during the OTA upgrade process.

[0192] Specifically, the operation of testing the interface may be to perform interface content verification and interface language verification on the interface.

[0193] The operations of performing interface content verification and interface language verification on the interface are similar to the operations of performing interface content verification and interface language verification on the interface to be tested, and will not be repeated here.

[0194] For ease of understanding, now combined Figure 5 The OTA upgrade test corresponding to different power types provided in the embodiment of the present application is exemplified. For example, Figure 5 This is a flowchart of an OTA upgrade test corresponding to different power types provided in an embodiment of the present application.

[0195] like Figure 5 As shown, after selecting the target test function in the test scenario of the target power type, the target signal type and target signal status are first obtained, and at the same time, the vehicle computer requests to enter the vehicle OTA. In addition, when the target power type is a pure electric type or a hybrid type, it is also determined whether the OTA upgrade is a high-voltage upgrade or a low-voltage upgrade. If the OTA upgrade is a high-voltage upgrade, a high voltage is requested. After that, the computer device simulates the high-voltage signal and returns it to the vehicle computer. After receiving the high-voltage signal, the vehicle computer starts the high-voltage upgrade. If the OTA upgrade is a low-voltage upgrade, a high voltage is requested. After that, the computer device simulates the low-voltage signal and returns it to the vehicle computer. After receiving the low-voltage signal, the vehicle computer starts the low-voltage upgrade until the upgrade is successful.

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

[0197] (1) In response to a selection operation of a target interface test function in an interface test scenario, a target signal type and a target signal state corresponding to the interface test scenario are obtained.

[0198] (2) Based on the target signal type and target signal state corresponding to the interface test scenario, the real vehicle signal corresponding to the target signal type is simulated to obtain the target simulation 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 computer, so that the vehicle computer executes the target upgrade process to generate the interface to be tested after receiving the target simulation signal, and then obtains the interface to be tested through the vehicle computer and tests the interface to be tested, so as to obtain the test result of the OTA upgrade process corresponding to the interface test scenario.

[0200] Specifically, the operation of step (3) can be: sending a target analog signal to the vehicle computer, so that the vehicle computer executes the OTA upgrade process and generates a test interface after receiving the target analog signal; obtaining the test interface from the vehicle computer; performing interface content verification and interface language verification on the test interface to obtain the test result of the test interface.

[0201] In this case, after receiving the simulation signal, the vehicle computer determines the actual vehicle environment according to the received simulation signal, and then starts to simulate the OTA upgrade process corresponding to the target interface test function, so as to simulate and generate the interface corresponding to the target interface test function, and thus obtain the interface to be tested. After that, the computer device obtains the interface to be tested through the vehicle computer, tests the interface to be tested, and obtains the test result of the interface to be tested.

[0202] Among them, the specific operations of performing interface content verification and interface language verification on the interface to be tested to obtain the test result of the interface to be tested are the same as the specific operations of performing interface content verification and interface language verification on the interface to be tested in the aforementioned step 203, which will not be repeated here.

[0203] For ease of understanding, now combined Figure 6 The following is an example of an OTA upgrade test in an interface test scenario. Figure 6 It is a flowchart of an OTA upgrade test for an interface test scenario provided in an embodiment of the present application.

[0204] like Figure 6As shown, after selecting the target interface test function, the standard display content and standard language text can be imported, and then the interface content verification and interface language verification of the interface to be tested can be performed based on the standard display content and standard language text. Specifically, the standard display content is compared with the content currently displayed by the interface to be tested, and the standard language text is compared with the development language text, so as to automatically generate the verification result. In the case that the interface content verification or the interface language verification fails, a manual secondary verification can be performed. Specifically, the interface that has not been verified can be opened, and then the computer device pops up the interface that has not been verified, so that the technician can perform manual verification.

[0205] Finally, the OTA upgrade test of 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 of the precondition test scenario may include the following steps (1) to (3).

[0206] (1) In response to a selection operation of an environment check function in a precondition test scenario, a target signal type and a target signal state corresponding to the precondition test scenario are obtained.

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

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

[0209] In this case, before the OTA upgrade test, the technician can first select the environmental check function in the prerequisite test scenario to check the actual vehicle environment before the OTA upgrade test to determine whether the actual 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, the real vehicle signal corresponding to the target signal type is simulated to obtain the target simulation 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 computer, so that the vehicle computer executes the target upgrade process to generate the object to be tested after receiving the target simulation signal, and then obtains the interface to be tested through the vehicle computer and tests the object to be tested to obtain the test result of the environmental check function.

[0212] Specifically, the operation of step (3) may be: sending a target simulation signal to the vehicle computer so that the vehicle computer performs an environmental check after receiving the target simulation signal and generates an object to be tested; judging whether the object to be tested meets a preset upgrade condition; and outputting a target reminder message if the object to be tested does not meet the preset upgrade condition.

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

[0214] The preset upgrade conditions are used to indicate the test environment that should be met during the OTA upgrade test. In an embodiment of the present application, the preset upgrade conditions may include multiple real vehicle signals that should meet the conditions during the OTA upgrade test.

[0215] The target reminder information includes the actual vehicle signals that are not met in this OTA upgrade test.

[0216] In this case, when judging whether the currently simulated real vehicle signal meets the test environment of the OTA upgrade test, if it is detected that a real vehicle signal does not meet the requirements of the test environment, the target reminder information that the real vehicle signal does not meet the test environment can be output to enable the technician to know that the real vehicle signal does not meet the test environment.

[0217] In this way, by outputting target reminder information when the preset upgrade conditions are not met in this OTA upgrade test, technicians can promptly learn of the actual vehicle signals that are not met, so that corresponding adjustments can be made in time afterwards.

[0218] Optionally, if the current OTA upgrade test meets the preset upgrade conditions, a second reminder message may be output. The second reminder message is used to remind the technician that the test environment meets the requirements.

[0219] In an embodiment of the present application, the precondition test scenario may also include multiple environmental information setting functions. Furthermore, when the object to be tested 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 may be reset so that the object to be tested meets the preset upgrade conditions again.

[0220] Multiple environment information setting functions are used to set different real vehicle environments. For example, the environment information setting function may include a factory mode release function, a DEBUG setting function, and the like.

[0221] In an embodiment of the present application, at least one environment information setting function is a selection made based on the above-mentioned target reminder information. That is, when the technicians learn which real vehicle environments are not satisfied during this OTA upgrade test, they can subsequently use multiple environment information setting functions to set the real vehicle environment accordingly so that the corresponding real vehicle environment meets the requirements. For example, when performing an environmental check, if it is found that the system is not in DEBUG mode, then the DEBUG setting function can be used to put the system back into DEBUG mode.

[0222] The OTA upgrade test method provided by the embodiment of the present application is described below in the form of functional modules. For example, Figure 7 It is a structural diagram of the functional implementation of an OTA upgrade test method provided in an embodiment of the present application.

[0223] like Figure 7 As shown, Figure 7 Including device management function, power management function and OTA upgrade test function. It should be understood that in the process of implementing the OTA upgrade test function provided in the embodiment of the present application, the device management function and power management function can be used. Therefore, the device management function, power management function and OTA upgrade test function are described here.

[0224] From the front-end perspective, Figure 7 As shown, the OTA upgrade test method provided in the embodiment of the present application involves a device management interface, a power management interface and an OTA upgrade test interface.

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

[0226] The transmission channel between the vehicle computer and the computer device can be opened and closed in the device management interface. The device management interface may include selection controls corresponding to multiple transmission channels. Specifically, there are multiple transmission channels for signal transmission between the vehicle computer and the computer device. When starting the vehicle computer, you can first click the corresponding selection control to select the channel for signal transmission, such as a default channel. In addition, the device management interface may also include a start button and a close button. After selecting the channel, you can click the start button to start the vehicle computer. In the case of a startup failure, a failure pop-up window can be displayed in the device management interface, that is, a startup failure reminder message is displayed in the form of a pop-up window, and then the start button can be clicked again to restart the vehicle computer. In the case of a successful startup, a success pop-up window can be displayed in the device management interface. Later, when the technician needs to stop the connection between the vehicle computer and the computer device, he can click the close button at any time to stop the signal transmission.

[0227] The power management interface can simulate the power signal, specifically, it can simulate the signal of different power modes. For example, the power management interface may include normal power mode, ten-minute mode, standby mode, etc. For example, after clicking the normal power mode, the technician can simulate the normal working mode of the power supply to work, so that the OTA upgrade process can be tested when the power supply is in normal mode. For another example, after clicking the ten-minute mode, the ten-minute mode of the power supply can be simulated, so that the OTA upgrade process can be tested in the ten-minute mode. For another example, when clicking the standby mode, the standby mode of the power supply can be simulated, so that the OTA upgrade process can be tested in the standby mode.

[0228] The OTA upgrade test interface may 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 function, GBOM (Global Bill of Materials) version check, ECU information check, factory mode release, DEBUG mode setting, conditional switch check, vehicle version check and other test functions.

[0230] The test scenarios for different power types can include test scenarios for fuel type, PHEV (Plug-in Hybrid Electric Vehicle), HEV (Hybrid Electric Vehicle), and pure electric type vehicles. In addition, the test scenarios for different power types can also include OTA upgrade test functions under different upgrade conditions.

[0231] The interface test scenario may include verification of the interface display, interface content, and interface language translation, and specifically may be verification testing of the upgrade success interface, upgrade failure interface, download interface, and other interfaces.

[0232] The following introduces some data files and packaging classes that support the functional implementation of the OTA upgrade test method.

[0233] In the embodiment of the present application, different interfaces, different upgrade conditions, and different test scenarios are encapsulated into classes and added to the click event of a control, so that the technician can determine the target signal type and target signal state of the corresponding test scenario by clicking the control displayed on the OTA upgrade test interface, and then simulate the real vehicle signal based on the target signal type and target signal state, which is equivalent to simulating the real vehicle signal required in the corresponding test scenario and sending it to the vehicle computer. After the vehicle computer detects that it is in the corresponding real vehicle environment, it can perform an OTA upgrade of the corresponding test scenario, so that the computer device can test the object to be tested generated during the OTA upgrade process of the vehicle computer, and then the OTA upgrade process under the corresponding upgrade conditions can be tested.

[0234] For data files, the embodiments of the present application involve the storage of dbc files, development requirement documents, standard language texts, and development language texts.

[0235] Optionally, multiple tool classes and multiple event classes may be encapsulated in the embodiment of the present application.

[0236] Among them, multiple tool classes may include device management class (used to start the vehicle computer), real vehicle signal class (used to send and receive signals), file reading and writing class (used to read and write 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, a click event will be triggered, thereby executing the code encapsulated by the click event to implement the test of the OTA upgrade process under the corresponding upgrade conditions.

[0238] A pop-up event means that when a pop-up reminder is needed during the OTA upgrade test, the pop-up event can be triggered to pop up the corresponding interface. For example, when the upgrade success interface pops up, the pop-up event can be triggered to pop up the upgrade success interface.

[0239] It is worth noting that the OTA upgrade test method provided in the embodiment of the present application uses a data-driven method to perform functional encapsulation of various interface elements and real vehicle signals, and then performs front-end interface rendering, so that different test scenarios of OTA upgrades can be classified, and different test scenarios can be switched with one click in a control manner through code encapsulation. In addition, the OTA upgrade test method provided in the embodiment of the present application does not require the actual OTA upgrade service. The OTA upgrade interface to be tested can be quickly called through code encapsulation with a button trigger. In addition, the real vehicle signals required in the OTA upgrade process of different power types can be simulated, so as to realize the testing of the OTA upgrade process of vehicles with different power types.

[0240] In an embodiment of the present application, after receiving the selection operation of the target test scene, the computer device can respond to the selection operation of the target test scene and first obtain the target signal type corresponding to the target test scene. Since the OTA upgrade process corresponding to different test scenes is different, the corresponding real vehicle signals are also different, so the signal type of the real vehicle signal required for the OTA upgrade process corresponding to the target test scene 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 simulation signal, that is, the real vehicle signal required for the OTA upgrade process corresponding to the target test scene is simulated. Then, based on the target simulation signal, the test script corresponding to the target test scene is executed to obtain the test result of the target test scene. In this way, by simulating the real vehicle signal required for different test scenes, the real vehicle environment under different test scenes can be satisfied, so the test of the OTA upgrade process under different test scenes can be realized. Thereby improving the accuracy of the OTA upgrade test and providing convenience for the OTA upgrade test of different test scenes, solving the problem of OTA upgrade test difficulties caused by the absence of a real vehicle or the inability to reach the upgrade environment where the real vehicle is located.

[0241] Figure 8 1 is a schematic diagram of the structure of an OTA upgrade test device provided in an embodiment of the present application. The OTA upgrade test device can be implemented by software, hardware, or a combination of both to form part or all of a computer device, and the computer device can be the following Fig. 9 Computer equipment shown. Figure 8 The device includes: an acquisition module 801, a signal simulation module 802 and a testing module 803.

[0242] An acquisition module 801 is used to obtain a target signal type corresponding to the target test scenario in response to a selection operation of the target test scenario on the OTA upgrade test interface, where the target signal type refers to a signal type of a real vehicle signal required for the OTA upgrade process corresponding to the target test scenario, and 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 a target simulation signal;

[0244] The test module 803 is used to execute the test script corresponding to the target test scenario based on the target simulation signal to send the target simulation signal to the vehicle computer, so that the vehicle computer executes the target upgrade process to generate the object to be tested after receiving the target simulation signal, and then obtains the object to be tested through the vehicle computer and tests the object to be tested to obtain the test result of the OTA upgrade process corresponding to the target test scenario.

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

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

[0247] When the login account has target operation permissions, obtain the target signal type corresponding to the target test scenario.

[0248] Optionally, the signal simulation module 802 is used to:

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

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

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

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

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

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

[0255] Optionally, the signal simulation module 802 is used to:

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

[0257] Optionally, the target signal type includes a first signal type and a second signal type, the first signal type is a signal type in the target signal type that is the same as the signal type indicated by the target test function, and the second signal type is a signal type in the target signal type except the first signal type, and the acquisition module 801 is used to:

[0258] Based on the target test function, determining a target signal state corresponding to the first signal type;

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

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

[0261] Perform interface content verification and interface language verification on the interface to be tested to obtain the test result of the interface to be tested.

[0262] Optionally, the testing module 803 is used to:

[0263] Get the standard display content of the interface to be tested. The standard display content is the text content that should be displayed on the interface to be tested during the OTA upgrade test.

[0264] Determine whether the text content currently displayed on the interface to be tested is consistent with the standard display content;

[0265] When the text content currently to be displayed on the interface to be tested is consistent with the standard display content, it is determined that the interface content verification of the interface to be tested has passed;

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

[0267] Optionally, the testing module 803 is used to:

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

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

[0270] When the standard language text is the same as the development language text, it is determined that the interface language verification of the interface to be tested has passed;

[0271] In the case where the standard language text is different from the development language text, it is determined that the interface language verification of the interface to be tested has failed.

[0272] In an embodiment of the present application, after receiving the selection operation of the target test scene, the target signal type corresponding to the target test scene can be obtained in response to the selection operation of the target test scene. Since the OTA upgrade process corresponding to different test scenes is different, the corresponding real vehicle signals are also different, so the signal type of the real vehicle signal required for the OTA upgrade process corresponding to the target test scene 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 simulation signal, that is, the real vehicle signal required for the OTA upgrade process corresponding to the target test scene is simulated. Then, based on the target simulation signal, the test script corresponding to the target test scene is executed to obtain the test result of the target test scene. In this way, by simulating the real vehicle signal required for different test scenes, the real vehicle environment under different test scenes can be satisfied, so the test of the OTA upgrade process under different test scenes can be realized. Thereby improving the accuracy of the OTA upgrade test and providing convenience for the OTA upgrade test of different test scenes, solving the problem of OTA upgrade test difficulties caused by the absence of a real vehicle or the inability to reach the upgrade environment where the real vehicle is located.

[0273] It should be noted that: the OTA upgrade test device provided in the above embodiment only uses the division of the above-mentioned functional modules as an example when testing the OTA upgrade process. In actual applications, the above-mentioned 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 may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit, and the above integrated units may be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the protection scope of the embodiments of the present application.

[0275] The OTA upgrade test device and the OTA upgrade test method embodiment provided in the above embodiment belong to the same concept. The specific working process of the units and modules in the above embodiment and the technical effects brought about can be found in the method embodiment part and will not be repeated here.

[0276] Fig. 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Fig. 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, the steps in the OTA upgrade test method in the above embodiment are implemented.

[0277] The computer device 9 may be a general-purpose computer device or a dedicated computer device. In a specific implementation, the computer device 9 may be a terminal device such as a desktop computer, a portable computer, a palmtop computer, etc. The embodiment of the present application does not limit the type of the computer device 9. Those skilled in the art will understand that Fig. 9 It is only an example of the computer device 9 and does not constitute a limitation on the computer device 9. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components, such as input and output devices, network access devices, etc.

[0278] The processor 90 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

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

[0280] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0281] An embodiment of the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the steps in the above-mentioned method embodiments.

[0282] If the integrated unit is implemented in the form of 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, the present application implements all or part of the processes in the above method embodiments, which can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the steps of each of the above method embodiments can be implemented. Among them, the computer program includes computer program code, which can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device that can carry the computer program code to the camera / terminal device, recording medium, 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 device. The computer-readable storage medium mentioned in the present 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 to implement the above embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The computer instructions can be stored in the above-mentioned computer readable storage medium.

[0284] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0285] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example 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 performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0286] In the embodiments provided in the present application, it should be understood that the disclosed devices / computer equipment and methods can be implemented in other ways. For example, the device / computer equipment embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0287] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0288] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. An OTA upgrade test method, characterized in that: The method comprises: In response to a selection operation of a target test scenario on an OTA upgrade test interface, a target signal type corresponding to the target test scenario is acquired, where the target signal type refers to a signal type of a real vehicle signal required for an OTA upgrade process corresponding to the target test scenario, and the OTA upgrade test interface includes at least i test scenarios; Based on the target signal type, simulating a real vehicle signal corresponding to the target signal type to obtain a target simulation signal; Based on the target simulation signal, execute the test script corresponding to the target test scenario to send the target simulation signal to the vehicle computer, so that the vehicle computer executes the target upgrade process to generate an object to be tested after receiving the target simulation signal, and then obtains the object to be tested through the vehicle computer and tests the object to be tested to obtain the test result of the OTA upgrade process corresponding to the target test scenario.

2. The method according to claim 1, characterized in that The step of obtaining, in response to a selection operation of a target test scenario on an OTA upgrade test interface, a target signal type corresponding to the target test scenario includes: In response to a selection operation of the target test scenario on the OTA upgrade test interface, determining whether the login account corresponding to the OTA upgrade test has target operation authority; In a case where the login account has the target operation authority, the target signal type corresponding to the target test scenario is obtained.

3. The method according to claim 1, characterized in that The step of simulating a real vehicle signal corresponding to the target signal type based on the target signal type to obtain a target simulation signal includes: Obtaining a default signal state corresponding to the target signal type; Acquire a signal attribute library, wherein the signal attribute library includes signal values ​​corresponding to different real vehicle signals; Based on the target signal type and the default signal state, obtaining a target signal value from the signal attribute library; The target signal value is assigned to the real vehicle signal corresponding to the target signal type to obtain a target simulation signal corresponding to the target signal type.

4. The method according to claim 1, characterized in that The target test scenario includes at least j test functions, and the step of obtaining a target signal type corresponding to the target test scenario in response to a selection operation on the OTA upgrade test interface includes: In response to a selection operation of a target test function in the target test scenario, determining a target signal type and a target signal state corresponding to the target test function; The step of simulating a real vehicle signal corresponding to the target signal type based on the target signal type to obtain a target simulation signal includes: Based on the target signal type and the target signal state, a real vehicle signal corresponding to the target signal type is simulated to obtain a target simulation signal.

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

6. The method according to claim 1, characterized in that The object to be tested is an interface to be tested, and the testing of the object to be tested includes: Interface content verification and interface language verification are performed on the interface to be tested to obtain a test result of the interface to be tested.

7. The method according to claim 6, characterized in that The step of performing interface content verification on the interface to be tested includes: Obtaining standard display content of the interface to be tested, where the standard display content is the text content that should be originally displayed on the interface to be tested during the OTA upgrade test; Determine whether the text content currently displayed on the interface to be tested is consistent with the standard display content; When the text content currently to be displayed on the interface to be tested is consistent with the standard display content, determining that the interface content verification of the interface to be tested has passed; When the text content currently to be displayed on the interface to be tested is inconsistent with the standard display content, it is determined that the interface content verification of the interface to be tested has failed.

8. The method according to claim 6, characterized in that The step of performing interface language verification on the interface to be tested includes: Obtaining a standard language text of the interface to be tested, wherein the standard language text refers to a standard translation text in different languages ​​corresponding to the interface to be tested; Obtaining a development language text corresponding to the interface to be tested, wherein the development language text refers to a language text displayed in different languages ​​by the interface to be tested during the OTA upgrade test; In the case where the standard language text is the same as the development language text, determining that the interface language verification of the interface to be tested is passed; When the standard language text is different from the development language text, it is determined that the interface language verification of the interface to be tested has failed.

9. An OTA upgrade test device, characterized in that: The device comprises: an acquisition module, configured to, in response to a selection operation of a target test scenario on an OTA upgrade test interface, acquire a target signal type corresponding to the target test scenario, wherein the target signal type refers to a signal type of a real vehicle signal required for an OTA upgrade process corresponding to the target test scenario, and the OTA upgrade test interface includes at least i test scenarios; A signal simulation module, used to simulate a real vehicle signal corresponding to the target signal type based on the target signal type to obtain a target simulation signal; A test module is used to execute a test script corresponding to the target test scenario based on the target simulation signal to send the target simulation signal to the vehicle computer, so that the vehicle computer executes a target upgrade process to generate an object to be tested after receiving the target simulation signal, and then obtains the object to be tested through the vehicle computer and tests the object to be tested to obtain a test result of the OTA upgrade process corresponding to the target test scenario.

10. A computer device, characterized in that: The computer device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the method according to any one of claims 1 to 8 when executed by the processor.

Images