Test method and device, debugger, equipment, storage medium and program product

Abstract

The invention relates to a test method and device, a debugger, equipment, a storage medium and a program product, and relates to the technical field of OTA. The method is applied to a test system, and the test system comprises a test device and a debugger. The method comprises the steps that the testing device sends a debugging instruction to the debugger; in response to the debugging instruction, the debugger adjusts internal variables of the OTA upgrading data packet to obtain an OTA upgrading program packet corresponding to the at least one simulation test scene, and sends the OTA upgrading program packet corresponding to the at least one simulation test scene to the test device; for each simulation test scene, the test device executes OTA upgrade operation on the target controller based on the OTA upgrade data packet corresponding to the simulation test scene to obtain a test result corresponding to the simulation test scene; the test result is used for reflecting whether the OTA upgrading operation of the target controller in the simulation test scene is abnormal or not. Therefore, the OTA upgrading test can be carried out by simulating different use scenes and conditions, and the accuracy of the OTA test is improved.

Description

Technical Field

[0001] The present application relates to the field of OTA technology, in particular to the field of OTA upgrade test technology, and specifically to a test method, apparatus, debugger, equipment, storage medium and program product. Background Art

[0002] With the rapid development and standardization of OTA technology, the complexity of vehicle software systems has increased significantly. How to ensure the stability and security of these software during the update process has become a key issue that the industry needs to solve. In this case, the importance of testing Over-the-Air Technology (OTA) has become increasingly prominent.

[0003] Related technology CN114201189A proposes to control the entire automatic upgrade system through a self-developed human-machine interface (HMI) system to complete the initiation, process control and result recording and analysis of OTA upgrade tasks.

[0004] Related technology CN115396941A proposes a method and system for automatically controlling OTA stress testing, which can complete the management and control of OTA upgrade tasks, and record and analyze the results.

[0005] However, the accuracy of the method for testing OTA upgrades in the related art is low. Summary of the invention

[0006] The present application provides a test method, apparatus, debugger, device, storage medium and program product to at least solve the technical problem that the method for testing OTA upgrade in the related art is not comprehensive enough, resulting in low accuracy. The technical solution of the present application is as follows:

[0007] According to the first aspect provided by the present application, a testing method is provided, which is applied to a testing system, and the testing system includes: a testing device and a debugger; the method includes: the testing device sends a debugging instruction to the debugger; the debugging instruction is used to instruct to adjust the internal variables of the OTA upgrade data packet; in response to the debugging instruction, the debugger adjusts the internal variables of the OTA upgrade data packet, obtains at least one OTA upgrade package corresponding to a simulated test scenario, and sends at least one OTA upgrade package corresponding to the simulated test scenario to the testing device; for each simulated test scenario, the testing device performs an OTA upgrade operation on the target controller based on the OTA upgrade data packet corresponding to the simulated test scenario, and obtains a test result corresponding to the simulated test scenario; the test result is used to reflect whether the OTA upgrade operation of the target controller in the simulated test scenario is abnormal.

[0008] According to the above-mentioned technical means, the present application may, in a possible manner, test the OTA upgrade operation of the target controller to be tested in a test scenario by a test device, and obtain a test result corresponding to the test scenario, including: the test device obtains an OTA upgrade data packet of the target controller to be tested; based on the OTA upgrade data packet, the test device tests the OTA upgrade operation of the target controller during the process of performing the OTA upgrade operation on the target controller in the test scenario, and obtains a test result corresponding to the test scenario.

[0009] According to the above technical means, this application adjusts the OTA upgrade data packet through the debugger, simulates different usage scenarios and conditions for OTA upgrade testing, and can promptly discover and repair various problems that may occur during the upgrade process, thereby greatly improving the stability and reliability of the system after the upgrade. In addition, multi-scenario testing can cover various situations during the OTA upgrade operation of the target controller, thereby discovering more potential problems and defects. Therefore, this application can accurately test the OTA upgrade operation of the target controller.

[0010] In one possible approach, the simulation test scenario includes but is not limited to at least one of the following: a stress test scenario, a forward test scenario, a fault test scenario, and an abnormal test scenario.

[0011] In one possible method, a testing device performs an OTA upgrade operation on a target controller based on an OTA upgrade data packet corresponding to a simulated test scenario to obtain a test result corresponding to the simulated test scenario, including: the testing device obtains a target test case corresponding to the simulated test scenario; the testing device tests the OTA upgrade operation of the target controller based on the target test case corresponding to the simulated test scenario to obtain a test result corresponding to the test scenario.

[0012] According to the above technical means, this application uses different test cases corresponding to different scenarios to ensure that the OTA upgrade operation is fully tested in various possible environments. It helps to find problems that are not easily exposed in conventional test environments, thereby greatly improving the comprehensiveness and coverage of the test. In addition, through automated or semi-automated test processes, a large number of test cases can be quickly executed, and test logs can be recorded in real time to improve detection efficiency.

[0013] In one possible manner, a testing device tests the OTA upgrade operation of a target controller based on a target test case corresponding to a simulated test scenario to obtain a test result corresponding to the test scenario, including: the testing device parses the target test case corresponding to the simulated test scenario to obtain a test process corresponding to the simulated test scenario; the testing device executes the test process corresponding to the simulated test scenario, tests the OTA upgrade operation of the target controller, and obtains a test log corresponding to the simulated test scenario; the testing device analyzes the test log corresponding to the test scenario to obtain a test result corresponding to the simulated test scenario.

[0014] According to the above technical means, this application covers a variety of possible different situations through multi-scenario testing, which helps to ensure the comprehensiveness of the test, improve the coverage of the test, reduce omissions and untested parts, and thus more comprehensively evaluate the stability and reliability of the OTA upgrade operation. In addition, the test log corresponding to each scenario records in detail various information and data during the test process, including test steps, input data, output results, abnormal information, etc., so that problems can be quickly located and repaired.

[0015] In one possible manner, the testing device analyzes the test log corresponding to the test scenario to obtain the test result corresponding to the simulated test scenario, including: the testing device analyzes the test log corresponding to the simulated test scenario to obtain the test data corresponding to the test log; when the testing device determines that the test data does not meet the expected results, the testing device determines the test result corresponding to the simulated test scenario as abnormal; when the testing device determines that the test data meets the expected results, the testing device determines the test result corresponding to the simulated test scenario as normal.

[0016] According to the above technical means, this application can clearly determine whether the execution results of each test scenario meet expectations by comparing the test data and the expected results. In addition, the test efficiency can be significantly improved through automated log analysis and result determination process. Compared with manually checking the test logs one by one, automated tools can complete this process more quickly and accurately, thereby shortening the test cycle and improving test efficiency.

[0017] In one possible approach, when the debugger determines that the network of the test device where the target controller is located is offline, the debugger sends an acquisition instruction to the vehicle computer; the acquisition instruction is used to indicate an OTA upgrade package; in response to the acquisition instruction, the vehicle computer sends the OTA upgrade package to the debugger.

[0018] According to the above-mentioned technical means, the present application dynamically selects a method for obtaining OTA upgrade data packets according to the network status, so that the test can be carried out more flexibly and is not restricted by the network status, thereby improving the adaptability and continuity of the test.

[0019] In one possible approach, the debugger sends an acquisition instruction to the cloud platform when it determines that the network of the test device where the target controller is located is online; the acquisition instruction is used to instruct the sending of an OTA upgrade package; in response to the acquisition instruction, the cloud platform sends the OTA upgrade package to the debugger.

[0020] According to the second aspect provided by the present application, a testing method is provided, which is applied to a testing device, and the method includes: sending a debugging instruction to a debugger; the debugging instruction is used to instruct to adjust the internal variables of the OTA upgrade data packet; receiving an OTA upgrade program package corresponding to at least one simulated test scenario sent by the debugger; for each simulated test scenario, performing an OTA upgrade operation on a target controller based on the OTA upgrade data packet corresponding to the simulated test scenario, and obtaining a test result corresponding to the simulated test scenario; the test result is used to reflect whether the OTA upgrade operation of the target controller in the simulated test scenario is abnormal.

[0021] According to the third aspect provided by the present application, a testing method is provided, which is applied to a debugger, and the method includes: receiving a debugging instruction sent by a testing device; the debugging instruction is used to instruct to adjust the internal variables of the OTA upgrade data packet; in response to the debugging instruction, the internal variables of the OTA upgrade data packet are adjusted to obtain an OTA upgrade program package corresponding to at least one simulated test scenario, and at least one OTA upgrade program package corresponding to the simulated test scenario is sent to the testing device.

[0022] According to the fourth aspect provided by the present application, a testing device is provided, including: a sending unit, a receiving unit and a testing unit; the sending unit is used to send debugging instructions to a debugger; the debugging instructions are used to instruct to adjust the internal variables of the OTA upgrade data packet; the receiving unit is used to receive an OTA upgrade program package corresponding to at least one simulated test scenario sent by the debugger; the testing unit is used to perform an OTA upgrade operation on a target controller for each simulated test scenario based on the OTA upgrade data packet corresponding to the simulated test scenario, and obtain a test result corresponding to the simulated test scenario; the test result is used to reflect whether the OTA upgrade operation of the target controller in the simulated test scenario is abnormal.

[0023] In one possible manner, the test unit is specifically used to: obtain a target test case corresponding to a simulated test scenario; test the OTA upgrade operation of the target controller based on the target test case corresponding to the simulated test scenario, and obtain a test result corresponding to the test scenario.

[0024] In one possible manner, the test unit is specifically used to: parse the target test case corresponding to the simulation test scenario to obtain the test process corresponding to the simulation test scenario; execute the test process corresponding to the simulation test scenario, perform test operations on the OTA upgrade operation of the target controller, and obtain the test log corresponding to the simulation test scenario; analyze the test log corresponding to the simulation test scenario to obtain the test result corresponding to the simulation test scenario.

[0025] In one possible manner, the test unit is specifically used to: analyze the test log corresponding to the simulated test scenario to obtain test data corresponding to the test log; when it is determined that the test data does not meet the expected results, determine the test results corresponding to the simulated test scenario as abnormal; when it is determined that the test data meets the expected results, determine the test results corresponding to the simulated test scenario as normal.

[0026] According to the fifth aspect provided by the present application, a debugger is provided, including: a receiving unit and an adjustment unit; the receiving unit is used to receive a debugging instruction sent by a test device; the debugging instruction is used to instruct to adjust the internal variables of the OTA upgrade data packet; the adjustment unit is used to adjust the internal variables of the OTA upgrade data packet in response to the debugging instruction, obtain an OTA upgrade program package corresponding to at least one simulated test scenario, and send at least one OTA upgrade program package corresponding to the simulated test scenario to the test device.

[0027] According to the sixth aspect provided by the present application, an electronic device is provided, comprising: a processor; a memory for storing processor executable instructions; wherein the processor is configured to execute instructions to implement the method of the above-mentioned first aspect and any possible implementation manner thereof.

[0028] According to the seventh aspect provided by the present application, a computer-readable storage medium is provided. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the method in the above-mentioned first aspect and any possible implementation method thereof.

[0029] According to the eighth aspect provided by the present application, a computer program product is provided, the computer program product comprising computer instructions, and when the computer instructions are executed on an electronic device, the electronic device executes the method of the above-mentioned first aspect and any possible implementation manner thereof.

[0030] Therefore, the above technical features of the present application have the following beneficial effects:

[0031] (1) By adjusting the OTA upgrade data packet through the debugger and simulating different usage scenarios and conditions for OTA upgrade testing, various problems that may occur during the upgrade process can be discovered and repaired in a timely manner, thereby greatly improving the stability and reliability of the system after the upgrade. In addition, multi-scenario testing can cover various situations during the OTA upgrade operation of the target controller, thereby discovering more potential problems and defects. Therefore, this application can accurately test the OTA upgrade operation of the target controller.

[0032] (2) By providing different test cases for different scenarios, we ensure that OTA upgrade operations are fully tested in all possible environments. This helps to discover problems that are not easily exposed in conventional test environments, thereby greatly improving the comprehensiveness and coverage of the test. In addition, through automated or semi-automated test processes, a large number of test cases can be quickly executed, and test logs can be recorded in real time to improve detection efficiency.

[0033] (3) Covering multiple possible situations through multi-scenario testing helps ensure the comprehensiveness of the test, improve the test coverage, reduce omissions and untested parts, and more comprehensively evaluate the stability and reliability of OTA upgrade operations. In addition, the test log corresponding to each scenario records in detail various information and data during the test process, including test steps, input data, output results, abnormal information, etc., so that problems can be quickly located and repaired.

[0034] (4) By comparing the test data with the expected results, it is possible to clearly determine whether the execution results of each test scenario meet expectations. In addition, the test efficiency can be significantly improved through automated log analysis and result determination. Compared with manually checking the test logs one by one, automated tools can complete this process more quickly and accurately, thereby shortening the test cycle and improving test efficiency.

[0035] (5) By dynamically selecting the method for obtaining OTA upgrade data packets according to the network status, the test can be carried out more flexibly and is not restricted by the network status, thereby improving the adaptability and continuity of the test.

[0036] It should be noted that the technical effects brought about by any implementation method in the second to fifth aspects can refer to the technical effects brought about by the corresponding implementation method in the first aspect, and will not be repeated here.

[0037] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification are used to explain the principles of the present application, and do not constitute an improper limitation on the present application.

[0039] Figure 1 is a flow chart of a testing method according to an exemplary embodiment;

[0040] Figure 2 is a schematic diagram of a testing system according to an exemplary embodiment;

[0041] Figure 3 is a schematic diagram of a testing device according to an exemplary embodiment;

[0042] Figure 4 is a flow chart of a TBOX online test according to an exemplary embodiment;

[0043] Figure 5 is a flow chart of a TBOX offline test according to an exemplary embodiment;

[0044] Figure 6 is a flow chart showing a vehicle-side test according to an exemplary embodiment;

[0045] Figure 7 is a schematic diagram showing a test process according to an exemplary embodiment;

[0046] Figure 8 is a block diagram of a testing device according to an exemplary embodiment;

[0047] Fig. 9 is a block diagram of a debugger according to an exemplary embodiment;

[0048] Fig.10 It is a block diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0049] In order to enable ordinary persons in the art to better understand the technical solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0050] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0051] As mentioned in the background technology, in order to solve the problem of low accuracy in testing OTA upgrades in related technologies, the present application provides a testing method, which is applied to a testing system, and the testing system includes: a testing device and a debugger. The testing device sends a debugging instruction to the debugger, and then, in response to the debugging instruction, the debugger adjusts the internal variables of the OTA upgrade data packet to obtain an OTA upgrade package corresponding to at least one simulated test scenario, and sends an OTA upgrade package corresponding to at least one simulated test scenario to the testing device. Then, for each simulated test scenario, the testing device performs an OTA upgrade operation on the target controller based on the OTA upgrade data packet corresponding to the simulated test scenario, and obtains the test results corresponding to the simulated test scenario, thereby performing multi-scenario testing on the target controller to avoid the problem that the testing method in the related technology is not fully covered, resulting in low accuracy. Therefore, the present application can accurately test the OTA upgrade operation of the target controller.

[0052] For ease of understanding, the testing method provided in this application is specifically introduced below with reference to the accompanying drawings.

[0053] Figure 1 is a flow chart of a testing method according to an exemplary embodiment. Figure 1 As shown, the test method is applied to a test system, the test system includes: a test device, a debugger, and the test method includes the following steps: S101-S103.

[0054] S101. The testing device sends a debugging instruction to a debugger.

[0055] The debugging instruction is used to instruct the adjustment of the internal variables of the OTA upgrade data packet.

[0056] In one possible way, a communication connection can be established between the test device and the debugger. This connection can be made in a variety of ways, including but not limited to wired connection (such as USB, serial port, etc.) and wireless connection (such as Wi-Fi, Bluetooth, etc.). The specific communication method used depends on the configuration of the test environment, the physical location of the device, and the security and reliability requirements of the communication. This application does not make specific restrictions on this.

[0057] Optionally, the OTA upgrade data package may include an OTA online upgrade data package and an OTA offline upgrade data package. The OTA online upgrade data package may be deployed in the cloud platform, including an upgrade data package for the current version and an upgrade data package for the next version. The OTA offline upgrade data package may be deployed in the vehicle computer, including an upgrade data package for the current version and an upgrade data package for the next version.

[0058] S102. In response to the debugging instruction, the debugger adjusts the internal variables of the OTA upgrade data packet to obtain at least one OTA upgrade program package corresponding to the simulated test scenario, and sends the at least one OTA upgrade program package corresponding to the simulated test scenario to the test device.

[0059] Optionally, the simulation test scenario may include but is not limited to at least one of the following: a stress test scenario, a forward test scenario, a fault test scenario, and an abnormal test scenario.

[0060] It should be noted that when the simulated test scenario is a fault scenario, different network environments (such as high latency, low bandwidth), device status (such as low battery, tight storage space), and firmware version differences (such as compatibility issues between old and new versions) can be simulated to fully cover various situations that may be encountered during the upgrade process.

[0061] In one possible way, in response to the debugging instruction, the debugger can fine-tune the internal variables of the OTA upgrade data packet. These internal variables may include but are not limited to the version number of the upgrade package, the target firmware address, the checksum algorithm parameters, the retry strategy settings, the timeout period, etc., so as to obtain at least one OTA upgrade package corresponding to the simulated test scenario, and send at least one OTA upgrade package corresponding to the simulated test scenario to the test device.

[0062] Alternatively, the debugger may send the OTA upgrade package corresponding to at least one simulated test scenario to the cloud platform or the vehicle computer. The cloud platform and the vehicle computer may store the OTA upgrade package corresponding to at least one simulated test scenario.

[0063] In one possible manner, before debugging, the debugger can send an acquisition instruction to the vehicle computer when it is determined that the network of the test device where the target controller is located is offline. The acquisition instruction is used to instruct to send an OTA upgrade package. In response to the acquisition instruction, the vehicle computer sends the OTA upgrade package to the debugger.

[0064] Alternatively, the debugger may send an acquisition instruction to the cloud platform when it is determined that the network of the test device where the target controller is located is online. In response to the acquisition instruction, the cloud platform sends an OTA upgrade program package to the debugger.

[0065] S103. For each simulation test scenario, the test device performs an OTA upgrade operation on the target controller based on the OTA upgrade data packet corresponding to the simulation test scenario to obtain a test result corresponding to the simulation test scenario.

[0066] The test results are used to reflect whether the OTA upgrade operation of the target controller is abnormal in the simulated test scenario.

[0067] In one possible manner, the test device may obtain a target test case corresponding to the simulated test scenario. The test device may test the OTA upgrade operation of the target controller based on the target test case corresponding to the simulated test scenario to obtain a test result corresponding to the test scenario.

[0068] Among them, the test device can determine the corresponding target test cases based on different simulation test scenarios. The target test cases can cover all aspects of a single scenario test. The target test cases can also cover all aspects of multiple simulation test scenarios for the OTA upgrade operation of the target controller.

[0069] In one possible manner, the test device may automatically complete the test of the OTA upgrade operation of the target controller through a script or instruction set preset in a target test case.

[0070] In one possible manner, the test device can parse the target test case corresponding to the simulated test scenario to obtain the test process corresponding to the simulated test scenario. The test device can execute the test process corresponding to the simulated test scenario, test the OTA upgrade operation of the target controller, and obtain the test log corresponding to the simulated test scenario. The test device can analyze the test log corresponding to the simulated test scenario to obtain the test result corresponding to the simulated test scenario. The specific implementation method of the test device testing the OTA upgrade operation of the target controller based on the target test case corresponding to the simulated test scenario and obtaining the test result corresponding to the test scenario can be referred to S201-S203 below.

[0071] Based on the above Figure 1 According to the technical solution in the present application, the present application can perform OTA upgrade tests by simulating different usage scenarios and conditions, and can promptly discover and repair various problems that may occur during the upgrade process, thereby greatly improving the stability and reliability of the system after the upgrade. In addition, multi-scenario testing can cover various situations during the OTA upgrade operation of the target controller, thereby discovering more potential problems and defects. Therefore, the present application can accurately test the OTA upgrade operation of the target controller.

[0072] In some embodiments, in order to test the OTA upgrade operation of the target controller based on the target test case corresponding to the simulated test scenario and obtain the test results corresponding to the test scenario, the test method provided in the embodiment of the present application also includes the following steps: S201-S203.

[0073] S201. The testing device parses a target test case corresponding to a simulated test scenario to obtain a test flow corresponding to the simulated test scenario.

[0074] In one possible approach, the test processes corresponding to different test scenarios may be different.

[0075] In one example, the stress test scenario is to simulate multiple OTA upgrade operations to put the target controller in a high-load state, or to send device online request messages of different periods to the target controller through the bus during the upgrade process to achieve load stress testing. The forward test scenario can be used to characterize normal OTA upgrade operations. The fault test scenario can be used to characterize the target controller's ability to respond to abnormal situations by purposefully introducing faults and errors. The abnormal test scenario can embed abnormal scenario codes in advance to simulate various abnormal scenarios during the OTA upgrade process, such as sudden interruption of communication during the upgrade.

[0076] S202: The testing device executes a test process corresponding to the simulated test scenario, performs a test operation on the OTA upgrade operation of the target controller, and obtains a test log corresponding to the simulated test scenario.

[0077] In one possible manner, the test device may perform a test operation on the OTA upgrade operation of the target controller according to a test process corresponding to a simulated test scenario, and obtain a test log corresponding to the scenario.

[0078] In one example, the test device can obtain a fault test scenario by adjusting the internal variables of the OTA upgrade program. The test device can test the OTA upgrade operation of the target controller under the fault test scenario and obtain a test log corresponding to the fault test scenario.

[0079] In another example, the test device may perform multiple OTA upgrade operations on the target controller to simulate a stress test scenario. The test device may test the OTA upgrade operation of the target controller in a simulated stress test scenario to obtain a test log corresponding to the stress test scenario.

[0080] In one possible way, after determining the test process corresponding to each scenario, the test device enters the execution stage. The test device will test the OTA upgrade operation of the target controller one by one according to the test process. During this process, the test device will closely monitor the response, behavior and various state changes of the target controller during the upgrade process, such as abnormal information. At the same time, in order to record all information during the test in detail, the test device will generate a test log. This log not only records the execution of the test steps, but also includes various data, abnormal information, error codes, etc. generated during the test.

[0081] S203: The testing device analyzes the test log corresponding to the simulated test scenario to obtain the test result corresponding to the simulated test scenario.

[0082] In one possible manner, the test device may analyze the test log corresponding to the simulated test scenario to obtain the test data corresponding to the test log. The test device may determine the test result corresponding to the simulated test scenario as abnormal if it is determined that the test data does not meet the expected result. The test device may determine the test result corresponding to the simulated test scenario as normal if it is determined that the test data meets the expected result.

[0083] Specifically, after completing the test process for each scenario, the test device will enter the result analysis phase. The test device will first read and parse the test log corresponding to each scenario to extract key information and data. Then, the test device will compare and analyze this information and data based on the preset evaluation criteria and expected results.

[0084] By analyzing the records in the test log, the test device can determine whether the OTA upgrade operation of the target controller is successfully completed in each scenario, whether there are any exceptions or errors, and the specific causes of these exceptions or errors, and summarize the test results of all scenarios to obtain a test report.

[0085] Based on this, this application covers a variety of possible different situations through multi-scenario testing, which helps to ensure the comprehensiveness of the test, improve the coverage of the test, reduce omissions and untested parts, and more comprehensively evaluate the stability and reliability of OTA upgrade operations. In addition, the test log corresponding to each scenario records in detail various information and data during the test process, including test steps, input data, output results, abnormal information, etc., so that problems can be quickly located and repaired.

[0086] In some embodiments, Figure 2The figure shows a schematic diagram of a test system. The test system includes a cloud platform, a test device, a telematics BOX (TBOX), a debugger, a target controller, a vehicle computer, a power supply, other controllers, and a controller area network (CAN) card / Ethernet.

[0087] Among them, the test device can include a test case analysis module, a parameter configuration analysis module, a fault test module, a stress test module, a business layer, a processing module, an output module, and an analysis module. TBOX can include: an upgrade management module, a shielding detection module, and an abnormal scenario test module. The car computer can include an offline management module, a click module, and a storage module.

[0088] In one possible approach, the test case parsing module can be used to read and parse the test case to extract key elements required for the test, such as test steps, expected results, input parameters, etc. These elements are then converted into data structures or formats recognizable by other modules so that they can be effectively used during the test execution process.

[0089] The parameter configuration parsing module can be used to read the system configuration file and extract the parameters and settings required to execute the test and generate the report. These parameters may include configuration details of the test environment, the path of the report template, the level of logging, etc.

[0090] The fault test module and stress test module encapsulate the core functions or algorithms required for fault testing and stress testing respectively, and provide standardized interfaces for the business layer to call. The fault test module focuses on simulating and detecting the OTA upgrade operation of the target controller in an abnormal or error state, and the stress test module is used to evaluate the OTA upgrade operation performance of the target controller under high load or extreme conditions.

[0091] The business layer can integrate the specific logic of fault testing, positive testing (i.e. testing under normal conditions) and stress testing, and build a complete test process by calling the method interface of the above basic modules and combining test cases and test parameter data. This process ultimately drives the hardware system to perform tests and verify the various functions and performance indicators of the system.

[0092] The processing module can process and analyze data before and after the test. Before the test, the processing module can pre-process the input data to meet the test requirements. After the test, the processing module can conduct in-depth analysis of the generated data and extract valuable test results or performance indicators.

[0093] The output module can be configured or tested according to the specific needs of the case, selectively record key log information during the test, and generate a detailed test report based on the processed data. The report content includes but is not limited to test results, performance data, problem records and suggestions, etc., and is finally saved to the designated location of the test device for subsequent review and analysis.

[0094] The analysis module can further analyze the test report, either by writing code through automated scripts for in-depth analysis or by directly viewing the report data for subjective judgment and interpretation. The analysis results help evaluate system quality and guide subsequent optimization and improvement work.

[0095] The upgrade management module can receive and parse instructions from the vehicle control software to determine whether the current upgrade mode should be online or offline. When upgrading online, the module will start the communication process with the cloud platform to request the upgrade data package. In offline upgrade mode, it instructs to obtain the upgrade data package from the vehicle computer.

[0096] The shielding detection module can selectively shield certain detection steps according to preset rules or external instructions, or directly simulate these detections as passing status, so as to reduce the preparation time before upgrading or solve the upgrade restrictions under specific conditions.

[0097] The abnormal scenario test module can simulate various problems that may be encountered during the upgrade process, such as data transmission interruption, receipt of damaged or incorrect upgrade package data, and vehicle system resource conflicts, through preset scripts or dynamically generated abnormal conditions.

[0098] The offline management module can store and maintain multiple offline upgrade data packages of different versions.

[0099] The click module can use simulated click technology to automatically simulate user operations at appropriate times to complete necessary steps in the upgrade process, such as confirming the upgrade, restarting the device, etc.

[0100] The storage module can comprehensively record and save the log information generated by the vehicle computer during the OTA upgrade process, providing strong data support for subsequent troubleshooting, performance analysis and optimization.

[0101] In one possible way, TBOX can send upgrade instructions to the test device. TBOX can exchange data and log with the test device. TBOX can transmit online upgrade data packets with the cloud platform. The vehicle computer can provide a visual interface to TBOX and transmit offline upgrade data packets. TBOX can send upgrade instructions to the target controller. The target controller can send control instructions and fault instructions to the debugger. Data can be transmitted between the test device and the debugger and the CAN card / Ethernet. The target controller can send upgrade instructions to other controllers. The target controller can exchange data with the CAN card / Ethernet. The power supply can provide power to the test system.

[0102] In some embodiments, Figure 3 The figure shows a schematic diagram of a testing device.

[0103] In one possible approach, the test device can be run on a test bench. The business services that the test device can provide are fault testing, stress testing, and forward testing. The basic services that the test case can provide include fault testing foundation, stress testing foundation, processing data, output report, and output log. The test data of the test device can include test case analysis, parameter configuration analysis, and result analysis.

[0104] In some embodiments, Figure 4 FIG. 1 is a flow chart of a TBOX online test.

[0105] TBOX detects whether an online upgrade is in progress and obtains the upgrade data package from the cloud platform after detecting an online upgrade. TBOX detects and selects the upgrade version to determine whether it is a normal upgrade or a version rollback. A normal upgrade is to select the next version, and a version rollback is to select the current version. TBOX performs an OTA upgrade operation on the target controller and performs forward tests, stress tests, and abnormal scenario tests. TBOX records log data.

[0106] In some embodiments, Figure 5 Shown is a flow chart of TBOX offline testing.

[0107] TBOX detects whether it is an offline upgrade, and obtains the upgrade data package from the vehicle computer after detecting an online upgrade. TBOX detects the upgrade version selection and determines whether it is a normal upgrade or a version rollback. A normal upgrade is to select the next version, and a version rollback is to select the current version. TBOX performs OTA upgrade operations on the target controller and performs forward tests, stress tests, and abnormal scenario tests. TBOX records log data.

[0108] In some embodiments, Figure 6 The figure shows a flow chart of a vehicle-side test.

[0109] In one possible way, the vehicle computer detects whether to send an offline upgrade data packet. If it is necessary to send an offline upgrade data packet, the vehicle computer sends the offline upgrade data packet to the TBOX. If it is not necessary to send an offline upgrade data packet, or after sending the offline upgrade data packet to the TBOX, the vehicle computer automatically clicks the vehicle computer screen according to the instruction and records the log data.

[0110] In some embodiments, Figure 7 The figure shows a schematic diagram of a test process.

[0111] In one possible manner, the test device may read a test case. The test device may perform an OTA upgrade fault test. The test device may perform an OTA upgrade forward test. The test device may perform an OTA upgrade stress test. The test device may obtain test response data. The test device may determine that the test result is abnormal if the test response data is different from the expected result. The test device may determine that the test result is normal if the test response data is the same as the expected result. The test device may generate a test report based on the test result.

[0112] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to achieve the above functions, the test device includes a hardware structure and / or software module corresponding to each function. It should be easily appreciated by those skilled in the art that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware 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 exceed the scope of the present application.

[0113] The embodiment of the present application can exemplarily divide the functional modules of the test device according to the above method. For example, the test device can include various functional modules corresponding to the various functional divisions, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

[0114] Figure 8 is a block diagram of a testing device according to an exemplary embodiment. Figure 8 The testing device includes: a sending unit 301, a receiving unit 302 and a testing unit 303.

[0115] In a possible manner, the sending unit 301 is used to send a debugging instruction to a debugger.

[0116] In a possible manner, the receiving unit 302 is configured to receive an OTA upgrade program package corresponding to at least one simulated test scenario sent by a debugger.

[0117] In one possible method, the test unit 303 is used to perform an OTA upgrade operation on the target controller for each simulated test scenario based on the OTA upgrade data packet corresponding to the simulated test scenario, and obtain a test result corresponding to the simulated test scenario; the test result is used to reflect whether the OTA upgrade operation of the target controller in the simulated test scenario is abnormal.

[0118] In one possible manner, the testing unit 303 is specifically used to: obtain a target test case corresponding to a simulated test scenario; test the OTA upgrade operation of the target controller based on the target test case corresponding to the simulated test scenario, and obtain a test result corresponding to the test scenario.

[0119] In one possible manner, the test unit 303 is specifically used to: parse the target test case corresponding to the simulation test scenario to obtain the test process corresponding to the simulation test scenario; execute the test process corresponding to the simulation test scenario, perform test operations on the OTA upgrade operation of the target controller, and obtain the test log corresponding to the simulation test scenario; analyze the test log corresponding to the simulation test scenario to obtain the test result corresponding to the simulation test scenario.

[0120] In one possible manner, the test unit 303 is specifically used to: analyze the test log corresponding to the simulated test scenario to obtain test data corresponding to the test log; when it is determined that the test data does not meet the expected results, determine the test results corresponding to the simulated test scenario as abnormal; when it is determined that the test data meets the expected results, determine the test results corresponding to the simulated test scenario as normal.

[0121] Fig. 9 is a block diagram of a debugger according to an exemplary embodiment. Fig. 9 The debugger includes: a receiving unit 401 and an adjusting unit 402.

[0122] In a possible manner, the receiving unit 401 is configured to receive a debugging instruction sent by a testing device.

[0123] In one possible manner, the adjustment unit 402 is used to adjust the internal variables of the OTA upgrade data packet in response to the debugging instruction, obtain the OTA upgrade program package corresponding to at least one simulated test scenario, and send the OTA upgrade program package corresponding to at least one simulated test scenario to the test device.

[0124] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0125] Fig.10 FIG. 1 is a block diagram of an electronic device according to an exemplary embodiment. Fig.10 As shown, the electronic device includes but is not limited to: a processor 501 and a memory 502 .

[0126] The memory 502 is used to store executable instructions of the processor 501. It can be understood that the processor 501 is configured to execute instructions to implement the test method in the above embodiment.

[0127] It should be noted that those skilled in the art can understand that Fig.10 The electronic device structure shown in the figure does not constitute a limitation on the electronic device, and the electronic device may include Fig.10 More or fewer components may be shown, or certain components may be combined, or the components may be arranged differently.

[0128] The processor 501 is the control center of the electronic device. It uses various interfaces and lines to connect various parts of the entire electronic device. By running or executing software programs and / or modules stored in the memory 502, and calling data stored in the memory 502, it performs various functions of the electronic device and processes data, thereby monitoring the electronic device as a whole. The processor 501 may include one or more processing units. Optionally, the processor 501 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 501.

[0129] The memory 502 can be used to store software programs and various data. The memory 502 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application program required by at least one functional module (such as a determination unit, a processing unit, etc.), etc. In addition, the memory 502 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0130] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 502 including instructions, and the above instructions can be executed by a processor 501 of an electronic device to implement the method in the above embodiment.

[0131] In actual implementation, Figure 8The sending unit 301, the receiving unit 302 and the testing unit 303, and Fig. 9 The functions of the receiving unit 401 and the adjusting unit 402 in the embodiment can be obtained by Fig.10 The processor 501 in the embodiment calls the computer program stored in the memory 502. The specific execution process can refer to the description of the method part in the above embodiment, which will not be repeated here.

[0132] Optionally, the computer-readable storage medium may be a non-temporary computer-readable storage medium, for example, the non-temporary computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0133] In an exemplary embodiment, the present application also provides a computer program product including one or more instructions, and the one or more instructions can be executed by the processor 501 of the electronic device to complete the method in the above embodiment.

[0134] It should be noted that when the instructions in the above-mentioned computer-readable storage medium or one or more instructions in the computer program product are executed by the processor of the electronic device, the various processes of the above-mentioned method embodiment are implemented, and the same technical effect as the above-mentioned method can be achieved. To avoid repetition, they will not be repeated here.

[0135] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. 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.

[0136] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device 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 device, 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.

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

[0138] In addition, each functional unit in each embodiment of the present application 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. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0139] 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 readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or the full classification part or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including a number of instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute the full classification part or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, ROM, RAM, disk or CD and other media that can store program code.

[0140] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A testing method, characterized in that: Applied to a test system, the test system includes: a test device, a debugger; the method includes: The test device sends a debugging instruction to the debugger; the debugging instruction is used to instruct to adjust the internal variables of the over-the-air download technology OTA upgrade data packet; In response to the debugging instruction, the debugger adjusts the internal variables of the OTA upgrade data packet to obtain an OTA upgrade program package corresponding to at least one simulated test scenario, and sends the OTA upgrade program package corresponding to the at least one simulated test scenario to the test device; For each simulated test scenario, the testing device performs an OTA upgrade operation on the target controller based on the OTA upgrade data packet corresponding to the simulated test scenario, and obtains a test result corresponding to the simulated test scenario; the test result is used to reflect whether the OTA upgrade operation of the target controller under the simulated test scenario is abnormal.

2. The method according to claim 1, characterized in that The simulation test scenario includes but is not limited to at least one of the following: a stress test scenario, a forward test scenario, a fault test scenario, and an abnormal test scenario.

3. The method according to claim 2, characterized in that The test device performs an OTA upgrade operation on the target controller based on the OTA upgrade data packet corresponding to the simulated test scenario to obtain a test result corresponding to the simulated test scenario, including: The testing device obtains a target test case corresponding to the simulated test scenario; The testing device tests the OTA upgrade operation of the target controller based on the target test case corresponding to the simulated test scenario to obtain a test result corresponding to the test scenario.

4. The method according to claim 3, characterized in that The testing device tests the OTA upgrade operation of the target controller based on the target test case corresponding to the simulated test scenario, and obtains the test result corresponding to the test scenario, including: The testing device analyzes the target test case corresponding to the simulated test scenario to obtain a test process corresponding to the simulated test scenario; The testing device executes the test process corresponding to the simulated test scenario, performs a test operation on the OTA upgrade operation of the target controller, and obtains a test log corresponding to the simulated test scenario; The testing device analyzes the test log corresponding to the simulated test scenario to obtain the test result corresponding to the simulated test scenario.

5. The method according to claim 4, characterized in that The testing device analyzes the test log corresponding to the test scenario to obtain the test result corresponding to the simulated test scenario, including: The testing device analyzes the test log corresponding to the simulated test scenario to obtain test data corresponding to the test log; The testing device determines the test result corresponding to the simulated test scenario as abnormal if it is determined that the test data does not meet the expected result; When determining that the test data meets the expected result, the testing device determines the test result corresponding to the simulated test scenario as normal.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: When the debugger determines that the network of the test device where the target controller is located is in an offline state, the debugger sends an acquisition instruction to the vehicle computer; the acquisition instruction is used to instruct to send an OTA upgrade package; In response to the acquisition instruction, the vehicle computer sends the OTA upgrade program package to the debugger.

7. The method according to claim 6, characterized in that The method further comprises: The debugger sends an acquisition instruction to the cloud platform when it is determined that the network of the test device where the target controller is located is online; the acquisition instruction is used to instruct to send an OTA upgrade program package; In response to the acquisition instruction, the cloud platform sends the OTA upgrade package to the debugger.

8. A testing method, characterized in that: Applied to a test device, the method comprises: Sending a debugging instruction to the debugger; the debugging instruction is used to instruct to adjust the internal variables of the OTA upgrade data packet; Receiving an OTA upgrade program package corresponding to at least one simulated test scenario sent by the debugger; For each simulation test scenario, an OTA upgrade operation is performed on the target controller based on the OTA upgrade data packet corresponding to the simulation test scenario to obtain a test result corresponding to the simulation test scenario; the test result is used to reflect whether the OTA upgrade operation of the target controller in the simulation test scenario is abnormal.

9. A testing method, characterized in that: Applied to a debugger, the method comprises: Receiving a debugging instruction sent by a test device; the debugging instruction is used to instruct to adjust an internal variable of an OTA upgrade data packet; In response to the debugging instruction, internal variables of the OTA upgrade data packet are adjusted to obtain an OTA upgrade program package corresponding to at least one simulated test scenario, and the OTA upgrade program package corresponding to the at least one simulated test scenario is sent to the test device.

10. A testing device, characterized in that: The device comprises: a sending unit, a receiving unit and a testing unit; The sending unit is used to send a debugging instruction to the debugger; the debugging instruction is used to instruct to adjust the internal variables of the OTA upgrade data packet; The receiving unit is used to receive an OTA upgrade program package corresponding to at least one simulated test scenario sent by the debugger; The test unit is used to perform an OTA upgrade operation on the target controller for each simulated test scenario based on the OTA upgrade data packet corresponding to the simulated test scenario, and obtain a test result corresponding to the simulated test scenario; the test result is used to reflect whether the OTA upgrade operation of the target controller is abnormal under the simulated test scenario.

11. A debugger, characterized in that: The debugger comprises: a receiving unit and an adjusting unit; The receiving unit is used to receive a debugging instruction sent by the test device; the debugging instruction is used to instruct to adjust the internal variables of the OTA upgrade data packet; The adjustment unit is used to adjust the internal variables of the OTA upgrade data packet in response to the debugging instruction, obtain the OTA upgrade program package corresponding to at least one simulated test scenario, and send the OTA upgrade program package corresponding to the at least one simulated test scenario to the test device.

12. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to claim 8 or 9.

13. A computer-readable storage medium, characterized in that: When the computer-executable instructions stored in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is capable of performing the method as claimed in any one of claims 1 to 7.

14. A computer program product comprising instructions, characterized in that When the instructions are executed by a computer, the computer is caused to perform the method according to any one of claims 1 to 7.

Images