Test method and device of vehicle OTA platform, electronic equipment and storage medium
By receiving test instructions and confirming the vehicle model in the test scenario, and extracting test case sets using a pre-built scenario library, the OTA platform is automated for testing. This solves the problems of long testing time and low accuracy of vehicle OTA platforms, and improves the efficiency, accuracy and automation level of multi-vehicle testing.
Patent Information
- Application Number
- CN202410862125.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-06-28
- Publication Date
- 2026-02-06
- Estimated Expiration
- 2044-06-28
AI Technical Summary
In existing technologies, the testing of vehicle OTA platforms is time-consuming and has a low accuracy rate. It cannot cover diverse testing scenarios and follow the different business logic of multiple vehicle models, resulting in increased manpower and time costs and decreased test accuracy and practicality.
By receiving test instructions from the target OTA platform, identifying the target test scenario and vehicle model, extracting the corresponding test case set using a pre-built scenario library, performing automated testing on the OTA platform, generating test reports, and achieving targeted assessment of different business logics under multiple vehicle models.
It improves the efficiency and accuracy of testing, diversifies the testing functions of the OTA platform and enhances its automation level, and solves the problems of low efficiency and low accuracy of manual testing.
Smart Images

Figure CN118779228B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of vehicle testing, and in particular relates to a vehicle OTA (Over-the-Air Technology) platform test method and device, an electronic device, and a storage medium. BACKGROUND
[0002] With the development of automobile intelligence, the application proportion of OTA cloud upgrade technology in the Internet of Vehicles business increases accordingly. With the OTA access of different vehicle models, OTA upgrade scenarios are increasing, and the upgrade messages and TBOX feedback results of different vehicle models are further diversified with the changes in scene and configuration parameters, making the test work of the OTA cloud platform tend to be complex.
[0003] In the related art, the test work of the OTA cloud platform can be performed by manually entering vehicle model data, manually distinguishing OTA requirements of different vehicle models, manually performing regression testing, and manually checking reported message parsing fields.
[0004] However, in the related art, the data processing and test operation based on manual work is time-consuming and has low accuracy, which affects the development cycle of the platform system, cannot cover diversified scene testing and follow different business logics of multiple vehicle models, increases the cost of manpower and time, and reduces the accuracy and practicality of testing, which needs to be solved urgently. SUMMARY
[0005] The present application provides a vehicle OTA platform test method, device, electronic device, and storage medium to solve the problem in the related art that the data processing and test operation based on manual work is time-consuming and has low accuracy, which affects the development cycle of the platform system, cannot cover diversified scene testing and follow different business logics of multiple vehicle models, increases the cost of manpower and time, and reduces the accuracy and practicality of testing.
[0006] The first aspect of the present application provides a vehicle OTA platform test method, comprising the following steps: receiving a current test instruction of a target OTA platform; confirming a target test scene and at least one target test vehicle model of the target OTA platform based on the current test instruction; confirming a set of test scene use cases to be tested of the target OTA platform according to the target test scene and the at least one target test vehicle model, testing the target OTA platform by using the set of test scene use cases to be tested, obtaining a running result of the set of test scene use cases to be tested, and generating a test report of the target OTA platform according to the running result.
[0007] Optionally, in an embodiment of the present application, the confirming the to-be-tested scenario case set of the target OTA platform according to the target test scenario and the at least one target test vehicle model comprises: in a case where the target test scenario is a function test scenario, confirming, by the current test instruction, a function case level of the function test scenario; based on the function case level and the at least one target test vehicle model, extracting corresponding function test cases from a pre-constructed function scenario library, and obtaining the to-be-tested scenario case set from the function test cases.
[0008] Optionally, in an embodiment of the present application, the confirming the to-be-tested scenario case set of the target OTA platform according to the target test scenario and the at least one target test vehicle model comprises: in a case where the target test scenario is a stress test scenario, confirming, by the current test instruction, an execution number and a timeout label of each target test vehicle model in the at least one target test vehicle model; based on the execution number, constructing a corresponding virtual vehicle of each target test vehicle model respectively, and extracting, from a pre-constructed stress scenario library, a stress test case according to each target test vehicle model, and obtaining the to-be-tested scenario case set from the stress test case, the timeout label and the virtual vehicle.
[0009] Optionally, in an embodiment of the present application, the confirming the to-be-tested scenario case set of the target OTA platform according to the target test scenario and the at least one target test vehicle model comprises: in a case where the target test scenario is a compatibility test scenario, obtaining each compatible test vehicle model of the target OTA platform based on the at least one target test vehicle model, and confirming, by the current test instruction, a compatibility case level of each compatible test vehicle model; based on each compatible test vehicle model and the compatibility case level, extracting corresponding compatibility test cases from a pre-constructed compatibility scenario library, and obtaining the to-be-tested scenario case set from the compatibility test cases.
[0010] Optionally, in an embodiment of the present application, the running result comprises a case number of the to-be-tested scenario case set, gateway uplink and downlink time and execution log, and a test passing state and a case number of each case in the to-be-tested scenario case set.
[0011] The second aspect embodiment of the application provides a testing device of a vehicle OTA platform, comprising: a receiving module configured to receive a current testing instruction of a target OTA platform; a confirming module configured to confirm a target testing scene and at least one target testing vehicle model of the target OTA platform based on the current testing instruction; and a testing module configured to confirm a set of to-be-tested scene use cases of the target OTA platform according to the target testing scene and the at least one target testing vehicle model, test the target OTA platform by using the set of to-be-tested scene use cases, obtain a running result of the set of to-be-tested scene use cases, and generate a testing report of the target OTA platform according to the running result.
[0012] Optionally, in an embodiment of the application, the testing module comprises: a first confirming unit configured to, in a case where the target testing scene is a function testing scene, confirm a function use case level of the function testing scene according to the current testing instruction; and a first extracting unit configured to extract corresponding function testing use cases from a pre-constructed function scene library based on the function use case level and the at least one target testing vehicle model, and obtain the set of to-be-tested scene use cases from the function testing use cases.
[0013] Optionally, in an embodiment of the application, the testing module comprises: a second confirming unit configured to, in a case where the target testing scene is a stress testing scene, confirm an execution number and a timeout label of each target testing vehicle model in the at least one target testing vehicle model according to the current testing instruction; and a second extracting unit configured to construct a corresponding virtual vehicle of each target testing vehicle model based on the execution number, and extract stress testing use cases corresponding to each target testing vehicle model from a pre-constructed stress scene library, and obtain the set of to-be-tested scene use cases from the stress testing use cases, the timeout label and the virtual vehicle.
[0014] Optionally, in an embodiment of the application, the testing module comprises: a third confirming unit configured to, in a case where the target testing scene is a compatibility testing scene, obtain each compatible testing vehicle model of the target OTA platform based on the at least one target testing vehicle model, and confirm a compatibility use case level of each compatible testing vehicle model according to the current testing instruction; and a third extracting unit configured to extract corresponding compatibility testing use cases from a pre-constructed compatibility scene library based on each compatible testing vehicle model and the compatibility use case level, and obtain the set of to-be-tested scene use cases from the compatibility testing use cases.
[0015] Optionally, in an embodiment of the application, the running result comprises a use case number of the set of to-be-tested scene use cases, gateway uplink and downlink time and execution logs, and a test pass state and a use case number of each use case in the set of to-be-tested scene use cases.
[0016] The third aspect of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the test method of the vehicle OTA platform as described in the above embodiments.
[0017] The fourth aspect of the present application provides a computer readable storage medium, which stores a computer program, and the program is executed by a processor to implement the test method of the vehicle OTA platform as described above.
[0018] The fifth aspect of the present application provides a computer program, which is executed to implement the test method of the vehicle OTA platform as described above.
[0019] The embodiments of the present application can confirm the use case set for testing the OTA platform based on different test scenarios of the OTA platform and vehicle models to be tested, and test the OTA platform according to the use case set to obtain a test report, thereby realizing the targeted examination of different business logics under multiple vehicle models, improving the efficiency and accuracy of the test, making the test function of the OTA platform more diversified, and improving the test automation level. Thus, the problems in the related art, such as long time consumption and low accuracy of manual data processing and test operation, affecting the development cycle of the platform system, being unable to cover diversified scene tests and follow different business logics of multiple vehicle models, increasing the labor and time costs, and reducing the accuracy and practicality of the test, are solved.
[0020] Additional aspects and advantages of the present application will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS
[0021] The above and / or additional aspects and advantages of the present application will become apparent and be readily appreciated from the following description, taken in conjunction with the accompanying drawings, in which:
[0022] Figure 1 A flowchart of a test method of a vehicle OTA platform according to an embodiment of the present application;
[0023] Figure 2 A web-based process schematic diagram of the OTA platform test of an embodiment of the present application;
[0024] Figure 3 A structure schematic diagram of a test device of a vehicle OTA platform according to an embodiment of the present application;
[0025] Figure 4 A structure schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION
[0026] Embodiments of the present application are described below in detail, examples of which are shown in the accompanying drawings, in which the same or similar notations represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by reference to the drawings are exemplary and are intended to explain the present application, and cannot be understood as limiting the present application.
[0027] The test method, device, electronic equipment and storage medium of the vehicle OTA platform of the embodiments of the present application are described below with reference to the accompanying drawings. In view of the problems in the related art mentioned in the background, the manual data processing and test operation is time-consuming and has low accuracy, which affects the development cycle of the platform system, cannot cover diversified scene tests and follow different business logics of multiple vehicle models, increases the labor and time costs, and reduces the accuracy and practicability of the test. The present application provides a test method for a vehicle OTA platform. In the method, a use case set for testing the OTA platform can be confirmed based on different test scenarios of the OTA platform and a vehicle to be tested, and the OTA platform is tested according to the use case set to obtain a test report, thereby achieving targeted examination of different business logics under multiple vehicle models, improving the efficiency and accuracy of the test, and making the test functions of the OTA platform more diversified and the test automation level higher. Thus, the problems in the related art, such as the manual data processing and test operation being time-consuming and having low accuracy, affecting the development cycle of the platform system, being unable to cover diversified scene tests and follow different business logics of multiple vehicle models, increasing the labor and time costs, and reducing the accuracy and practicability of the test, are solved.
[0028] Specifically, Figure 1 A flowchart of a test method for a vehicle OTA platform provided by an embodiment of the present application is shown.
[0029] As Figure 1 shown, the test method for the vehicle OTA platform includes the following steps:
[0030] In step S101, a current test instruction of a target OTA platform is received.
[0031] It can be understood that in the embodiments of the present application, the target OTA platform can be an OTA vehicle networking platform to be tested, and the specific test process of the platform in the following steps can be performed on the target OTA platform according to the current test instruction.
[0032] In step S102, a target test scenario and at least one target test vehicle model of the target OTA platform are confirmed based on the current test instruction.
[0033] It can be understood that in the embodiments of the present application, the target test scene can include software update, firmware upgrade, function test, performance test, security test and other test scenes of the OTA vehicle networking platform, such as automatic testing of functionality, compatibility and performance test, etc. Among them, the hardware configuration, software version, network compatibility and other factors of different target vehicle models can be evaluated to ensure the effectiveness of the test.
[0034] In step S103, the set of test scene use cases to be tested of the target OTA platform is confirmed according to the target test scene and the at least one target test vehicle model, the target OTA platform is tested by using the set of test scene use cases to be tested, the running results of the set of test scene use cases to be tested are obtained, and a test report of the target OTA platform is generated according to the running results.
[0035] It can be understood that in the embodiments of the present application, the key points of OTA platform testing and the target vehicle type can be determined by analyzing the specific requirements of the target test scene and the target vehicle model, and the set of test scene use cases to be tested is obtained. Among them, the use case can be for a certain specific function or scene, execute the test case and record the test process and results, and collect various data in the test process to obtain the running results of the set of test scene use cases to be tested, and then analyze and classify the running results to evaluate the performance indicators of the OTA platform, such as update speed, stability, resource consumption, etc. By formulating detailed test case set, the target test scene can be fully covered, ensuring the comprehensiveness of the test, and improving the repeatability and comparability of the test.
[0036] Optionally, in an embodiment of the present application, confirming the set of test scene use cases to be tested of the target OTA platform according to the target test scene and the at least one target test vehicle model comprises: in the case that the target test scene is a function test scene, confirming a function use case level of the function test scene by a current test instruction; based on the function use case level and the at least one target test vehicle model, extracting corresponding function test use cases from a pre-constructed function scene library to obtain the set of test scene use cases to be tested from the function test use cases.
[0037] In actual execution process, the function test scene can evaluate the function running capability of the target OTA platform, a function scene library containing multiple function test scenes can be pre-constructed, each scene has corresponding function test use cases, and the test scenes in the scene library are classified according to the function use case level, so as to facilitate subsequent extraction and matching.
[0038] Specifically, when the target test scene is a function test scene, the function test use cases matched with the function use case level and the target test vehicle model can be extracted from the function scene library, the extracted function test use cases are combined into the set of test scene use cases to be tested, and all related test points are ensured to be covered.
[0039] Optionally, in an embodiment of the present application, the set of scenario use cases to be tested of the target OTA platform is determined according to the target test scenario and the at least one target test vehicle, including: in the case that the target test scenario is a stress test scenario, determining the execution quantity and the timeout label of each target test vehicle in the at least one target test vehicle by the current test instruction; constructing a virtual vehicle corresponding to each target test vehicle based on the execution quantity, and extracting a stress test use case corresponding to each target test vehicle from a pre-constructed stress scenario library, to obtain the set of scenario use cases to be tested from the stress test use case, the timeout label and the virtual vehicle.
[0040] In actual execution, the stress test scenario can evaluate the carrying capacity of the target OTA platform, and a stress scenario library containing multiple stress test scenarios can be pre-constructed, each scenario having a corresponding stress test use case. According to the target test vehicle, a stress test scenario suitable for the vehicle is selected, and a stress test use case matching the target test vehicle is extracted from the stress scenario library. The extracted stress test use cases are combined to form the set of scenario use cases to be tested.
[0041] Specifically, the execution quantity and the timeout label can be configured for each target test vehicle according to the test instruction, to create a corresponding virtual vehicle for each target test vehicle, and to ensure that each virtual vehicle simulates the hardware and software configuration of a real vehicle, and the timeout label is integrated in the set of use cases, to ensure that the timeout condition can be identified during testing. Subsequently, the virtual vehicle can be used to execute the test use cases one by one according to the set of scenario use cases to be tested, and the test process and results can be recorded. The virtual vehicle and the stress test use case can be reused in different test scenarios, improving the resource reuse rate.
[0042] Optionally, in an embodiment of the present application, the set of scenario use cases to be tested of the target OTA platform is determined according to the target test scenario and the at least one target test vehicle, including: in the case that the target test scenario is a compatibility test scenario, obtaining each compatible test vehicle of the target OTA platform based on the at least one target test vehicle, and determining the compatibility use case level of each compatible test vehicle by the current test instruction; extracting a corresponding compatible test use case from a pre-constructed compatibility scenario library based on each compatible test vehicle and the compatibility use case level, to obtain the set of scenario use cases to be tested from the compatible test use case.
[0043] In actual execution, the compatibility test scene can evaluate the compatibility of the target OTA platform for each vehicle model. A compatibility scene library containing multiple compatibility test scenes is constructed in advance, each scene has corresponding test cases, and according to each compatible test vehicle and compatible test case level, the compatible test scene suitable for the vehicle model is selected, and the compatible test cases matched with the compatible test vehicle and the compatible test case level are extracted from the compatible scene library to form a test scene case set.
[0044] Specifically, the compatible test case level can be configured for each target test vehicle according to the test instruction, and the compatibility test is performed according to the multiple target test vehicles selected by the user, so as to evaluate the compatibility of each compatible test vehicle with the OTA platform.
[0045] Optionally, in an embodiment of the present application, the running result includes the number of test cases in the test scene case set, the gateway uplink and downlink time and the execution log, and the test passing state and case number of each test case in the test scene case set.
[0046] In actual execution, the running result can include the name of the selected scene library, the number of test cases under the scene library, the gateway uplink and downlink time under each scene, the number of passed and failed test cases in the scene library, the number of each test case, and the execution log path of the target test scene.
[0047] As shown in Figure 2 The working content of the embodiment of the present application is described in detail below with one specific embodiment. The web-based process of the OTA platform test of one embodiment of the present application is shown in the following.
[0048] Specifically, the test html interface is developed using python+vue3.0+selenium+request, and the page includes cascading filtering of test scenes and filtering of different test types (supporting function test, stress test and compatibility test).
[0049] Further, in the function test scene, JX65 vehicle model-multiple piece upgrade-differential upgrade-xxx test case or JX65 vehicle model-multiple piece upgrade-differential upgrade-xxx test case ~ xxx test case can be selected, wherein if the user does not select the test case level, the default is to execute all scene library titles under the scene, and only the vehicle model is selected. The default is to execute all scenes under the vehicle model. In the stress test scene, the selection is according to the vehicle model-number-gateway timeout time, such as jx65 vehicle model-1000-10S after filtering. In the compatibility test scene, the user selects multiple vehicle models, and after multiple selection, the scene library under each vehicle model can be mapped and the scene test case is executed.
[0050] After the user selects the scene, one-key submission is performed, and after execution, the running result is displayed, including the selected scene library name, the number of use cases under the scene library, the gateway uplink and downlink time under each scene, the number of passed and failed, and the scene use case number, and the execution log path. After the test result information is displayed on the Html page, the default generates an allure test report, and the output content of the allure test report supports custom template extension.
[0051] In the scene test execution process, the scene library scene execution code can be written by using the python language to obtain the parameters obtained on the interface to the scene library title, or the case number is mapped to the python component; the request and selenium of the python underlying layer are used to simulate the interface or interface instruction issuing code, the python generates the corresponding proto according to the protocol list, generates the corresponding message format and sends it to the platform server through the mqtt protocol; the python language is used to grab the gateway log, the database storage field value, and the interface result language to judge the use case execution result under the scene use case, for example, the interface dialogue script and the test scene can be compared to determine whether they are consistent; the test comparison result is returned. The test result and the verification content are returned and displayed on the page of the test tool website, which is convenient for the test personnel to check; the test result is stored in the database according to the test time and the test scene, the code is continuously updated after the integration of jenkins, continuous integration, and the interface report is generated by combining allure.
[0052] The test method of the vehicle OTA platform provided in the embodiments of the present application can confirm the use case set for testing the OTA platform based on different test scenes of the OTA platform and vehicle models to be tested, and test the OTA platform based on the use case set to obtain a test report, thereby realizing the targeted examination of different business logics under multiple vehicle models, improving the efficiency and accuracy of the test, and making the test function of the OTA platform more diversified and the test automation level higher. Therefore, the problems in the related art that the manual data processing and test operation are time-consuming and have low accuracy, affect the development cycle of the platform system, cannot cover diversified scene tests and follow different business logics of multiple vehicle models, increase the labor and time costs, and reduce the accuracy and practicality of the test are solved.
[0053] Secondly, the test device of the vehicle OTA platform according to the embodiments of the present application is described with reference to the accompanying drawings.
[0054] Figure 3 is a structural schematic diagram of the test device of the vehicle OTA platform in the embodiments of the present application.
[0055] As Figure 3As shown, the test device 10 of the vehicle OTA platform includes a receiving module 100, a confirming module 200, and a test module 300.
[0056] The receiving module 100 is configured to receive a current test instruction of a target OTA platform.
[0057] The confirming module 200 is configured to confirm a target test scene and at least one target test vehicle model of the target OTA platform based on the current test instruction.
[0058] The test module 300 is configured to confirm a set of to-be-tested scene use cases of the target OTA platform according to the target test scene and the at least one target test vehicle model, test the target OTA platform by using the set of to-be-tested scene use cases, obtain a running result of the set of to-be-tested scene use cases, and generate a test report of the target OTA platform according to the running result.
[0059] Optionally, in an embodiment of the present application, the test module 300 includes:
[0060] The first confirming unit is configured to, in a case where the target test scene is a function test scene, confirm a function use case level of the function test scene according to the current test instruction.
[0061] The first extracting unit is configured to, based on the function use case level and the at least one target test vehicle model, extract corresponding function test use cases from a pre-constructed function scene library, and obtain the set of to-be-tested scene use cases from the function test use cases.
[0062] Optionally, in an embodiment of the present application, the test module 300 includes:
[0063] The second confirming unit is configured to, in a case where the target test scene is a stress test scene, confirm an execution quantity and a timeout label of each target test vehicle model in the at least one target test vehicle model according to the current test instruction.
[0064] The second extracting unit is configured to, based on the execution quantity, construct a corresponding virtual vehicle for each target test vehicle model respectively, and extract stress test use cases corresponding to each target test vehicle model from a pre-constructed stress scene library, and obtain the set of to-be-tested scene use cases from the stress test use cases, the timeout label, and the virtual vehicle.
[0065] Optionally, in an embodiment of the present application, the test module 300 includes:
[0066] The third confirming unit is configured to, in a case where the target test scene is a compatibility test scene, obtain each compatibility test vehicle model of the target OTA platform based on the at least one target test vehicle model, and confirm a compatibility use case level of each compatibility test vehicle model according to the current test instruction.
[0067] The third extraction unit is configured to extract corresponding compatible test cases from a pre-constructed compatible scenario library based on each compatible test vehicle model and compatible use case level, and obtain a set of to-be-tested scenario cases from the compatible test cases.
[0068] Optionally, in an embodiment of the present application, the running result includes the number of use cases in the set of to-be-tested scenario cases, gateway uplink and downlink time and execution log, and test passing status and use case number of each use case in the set of to-be-tested scenario cases.
[0069] It should be noted that the foregoing explanation and description of the embodiment of the vehicle OTA platform test method also applies to the vehicle OTA platform test device of the embodiment, which will not be described here again.
[0070] The vehicle OTA platform test device according to the embodiment of the present application can confirm a set of use cases for testing the OTA platform based on different test scenarios and to-be-tested vehicle models of the OTA platform, and test the OTA platform according to the set of use cases to obtain a test report, thereby achieving targeted examination of different business logics under multiple vehicle models, improving the efficiency and accuracy of the test, making the test function of the OTA platform more diversified, and improving the test automation level. Thus, the problems in the related art, such as long time consumption and low accuracy of manual data processing and test operation, affecting the development cycle of the platform system, being unable to cover diversified scenario tests and follow different business logics of multiple vehicle models, increasing the cost of manpower and time, and reducing the accuracy and practicality of the test, are solved.
[0071] Figure 4 The structure schematic diagram of the electronic device provided in the embodiment of the present application is shown. The electronic device can include:
[0072] The memory 401, the processor 402, and the computer program stored in the memory 401 and executable on the processor 402.
[0073] The processor 402 executes the program to implement the vehicle OTA platform test method provided in the above embodiment.
[0074] Further, the electronic device further includes:
[0075] The communication interface 403 is configured to communicate between the memory 401 and the processor 402.
[0076] The memory 401 is configured to store the computer program executable on the processor 402.
[0077] The memory 401 can include a high-speed RAM memory, and can also include a non-volatile memory, such as at least one disk memory.
[0078] If the memory 401, the processor 402 and the communication interface 403 are implemented independently, the communication interface 403, the memory 401 and the processor 402 can be connected with each other through a bus and complete communication between each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For convenience of representation, Figure 4 Only one thick line is used to represent the bus in the figure, but it does not mean that there is only one bus or only one type of bus.
[0079] Optionally, in a specific implementation, if the memory 401, the processor 402 and the communication interface 403 are integrated on a chip, the memory 401, the processor 402 and the communication interface 403 can complete communication between each other through an internal interface.
[0080] The processor 402 can be a Central Processing Unit (CPU), or an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement one or more embodiments of the present application.
[0081] The embodiment further provides a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the test method of the vehicle OTA platform.
[0082] The embodiment further provides a computer program. The computer program is executed to implement the test method of the vehicle OTA platform.
[0083] In the description of the specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example" or "some examples" means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, the person skilled in the art can combine and combine the different embodiments or examples described in the specification and the features of the different embodiments or examples without contradiction.
[0084] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0085] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0086] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.
[0087] It should be understood that parts of the present application can be realized in hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be realized by software or firmware stored in a memory and executed by a suitable instruction execution system. As in another embodiment, if realized by hardware, any one or a combination of the following technologies known in the art can be used: discrete logic circuit with logic gate circuit for implementing logic functions on data signals, application specific integrated circuit with suitable combination logic gate circuit, programmable gate array (PGA), field programmable gate array (FPGA), etc.
[0088] Those skilled in the art of the present technology can understand that all or part of the steps carried out by the above-mentioned embodiment methods can be completed by a program instructing the relevant hardware, and the program can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.
[0089] In addition, each functional unit in each embodiment of the present application can be integrated into one processing module, or each unit can exist physically alone, or two or more units can be integrated into one module. The above-mentioned integrated module can be realized in the form of hardware or in the form of a software functional module. When the integrated module is realized in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer readable storage medium.
[0090] The above-mentioned storage medium can be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it should be understood that the above-mentioned embodiments are exemplary and cannot be understood as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above-mentioned embodiments within the scope of the present application.
Claims
1. A method for testing a vehicle OTA platform, the method comprising: The method comprises the following steps: receiving a current test instruction of a target OTA platform; confirming a target test scene and at least one target test vehicle of the target OTA platform based on the current test instruction; confirming a set of to-be-tested scene use cases of the target OTA platform according to the target test scene and the at least one target test vehicle, testing the target OTA platform by using the set of to-be-tested scene use cases, obtaining a running result of the set of to-be-tested scene use cases, and generating a test report of the target OTA platform according to the running result; the confirming of the set of to-be-tested scene use cases of the target OTA platform according to the target test scene and the at least one target test vehicle comprises: in a case where the target test scene is a function test scene, confirming a function use case level of the function test scene according to the current test instruction; based on the function use case level and the at least one target test vehicle, extracting corresponding function test use cases from a pre-constructed function scene library to obtain the set of to-be-tested scene use cases from the function test use cases; the confirming of the set of to-be-tested scene use cases of the target OTA platform according to the target test scene and the at least one target test vehicle comprises: in a case where the target test scene is a stress test scene, confirming an execution quantity and a timeout label of each target test vehicle in the at least one target test vehicle according to the current test instruction; based on the execution quantity, constructing a corresponding virtual vehicle of each target test vehicle respectively, and extracting stress test use cases corresponding to each target test vehicle from a pre-constructed stress scene library to obtain the set of to-be-tested scene use cases from the stress test use cases, the timeout label and the virtual vehicle.
2. The method of claim 1, wherein, the confirming of the set of to-be-tested scene use cases of the target OTA platform according to the target test scene and the at least one target test vehicle comprises: in a case where the target test scene is a compatibility test scene, obtaining each compatible test vehicle of the target OTA platform based on the at least one target test vehicle, and confirming a compatibility use case level of each compatible test vehicle according to the current test instruction; based on each compatible test vehicle and the compatibility use case level, extracting corresponding compatibility test use cases from a pre-constructed compatibility scene library to obtain the set of to-be-tested scene use cases from the compatibility test use cases.
3. The method of claim 1, wherein, The running result comprises a use case quantity of the set of to-be-tested scene use cases, gateway uplink and downlink time and an execution log, and a test pass state and a use case number of each use case in the set of to-be-tested scene use cases.
4. A testing apparatus of a vehicle OTA platform, characterized by, The method comprises: a receiving module configured to receive a current test instruction of a target OTA platform; a confirming module configured to confirm a target test scene and at least one target test vehicle of the target OTA platform based on the current test instruction; The test module is configured to confirm a set of scene use cases to be tested for the target OTA platform according to the target test scene and the at least one target test vehicle, test the target OTA platform by using the set of scene use cases to be tested, obtain a running result of the set of scene use cases to be tested, and generate a test report of the target OTA platform according to the running result. The test module comprises: The first confirming unit is configured to, when the target test scene is a function test scene, confirm a function use case level of the function test scene according to the current test instruction. The first extracting unit is configured to extract corresponding function test use cases from a pre-constructed function scene library based on the function use case level and the at least one target test vehicle, and obtain the set of scene use cases to be tested from the function test use cases. The test module comprises: The second confirming unit is configured to, when the target test scene is a stress test scene, confirm an execution number and a timeout label of each target test vehicle in the at least one target test vehicle according to the current test instruction. The second extracting unit is configured to construct a virtual vehicle corresponding to each target test vehicle based on the execution number, and extract stress test use cases corresponding to each target test vehicle from a pre-constructed stress scene library, and obtain the set of scene use cases to be tested from the stress test use cases, the timeout label, and the virtual vehicle.
5. An electronic device, comprising: The computer program is stored in the memory and executable on the processor, and the processor executes the program to implement the test method of the vehicle OTA platform according to any one of claims 1-3. The program is executed by the processor to implement the test method of the vehicle OTA platform according to any one of claims 1-3.
6. A computer-readable storage medium having stored thereon a computer program, characterized in that,
Citation Information
Patent Citations
OTA small-flow flash test system and method
CN115408268A
Vehicle OTA method giving consideration to performance test and storage medium
CN116668432A