Vehicle body controller automatic test method, device, equipment and computer storage medium

Abstract

This application discloses an automatic testing method, apparatus, device, and computer storage medium for a vehicle body controller. The host computer parses test cases used to test the vehicle body controller under test, obtaining the correspondence between test steps and variables in the test cases and resource interfaces in the slave computer (i.e., resource correspondence). Then, for test steps of the result detection or operation execution type, it controls the slave computer to test the vehicle body controller under test according to the test steps and resource correspondence, and generates a test report for the vehicle body controller under test based on the execution status of the test steps. According to the embodiments of this application, by executing the automatic testing method for the vehicle body controller through the host computer, the slave computer can be controlled to automatically test the vehicle body controller under test and generate a corresponding test report. The entire testing process requires almost no manual intervention, resulting in higher testing efficiency, higher testing quality, and lower labor costs compared to traditional manual testing methods.

Description

Technical Field

[0001] This application belongs to the field of automotive electronics technology, and in particular relates to an automatic testing method, device, equipment and computer storage medium for a body controller. Background Technology

[0002] The Body Control Module (BCM), also known as the vehicle's computer, is an electronic control unit used in automotive engineering to control the vehicle's electrical systems and is a crucial component of a car. Testing the BCM is essential for improving vehicle safety and reliability.

[0003] Traditionally, body controller testing is performed manually. However, manual testing often suffers from low efficiency, poor quality, and high labor costs. Summary of the Invention

[0004] This application provides an automatic testing method, apparatus, device, computer storage medium, and program for vehicle body controllers, which can automatically test vehicle body controllers. Compared with manual testing, it has higher testing efficiency, better testing quality, and lower labor costs.

[0005] In a first aspect, embodiments of this application provide an automatic testing method for a vehicle body controller, applied to a host computer, the method comprising:

[0006] The pre-defined test cases are parsed to obtain the test steps and resource mappings. The test cases are used to test the vehicle body controller under test, and the resource mappings are the correspondences between the variables in the test cases and the resource interfaces in the lower-level machine. The lower-level machine is the lower-level machine that communicates with the upper-level machine to perform tests on the vehicle body controller under test.

[0007] Depending on whether the test step belongs to the result detection or operation execution type, the lower-level machine is controlled to test the vehicle body controller under test according to the correspondence between the test steps and resources. Among them, the result detection type test steps are used to read the values ​​of corresponding variables from the vehicle body controller under test, and the operation execution type test steps are used to set the values ​​of variables acting on the vehicle body controller under test.

[0008] Based on the execution of the test steps, a test report is generated for the tested vehicle body controller.

[0009] As one possible implementation, parsing pre-defined test cases includes:

[0010] Obtain the configuration information for the test cases. This information includes the path to the test case file and the page name where the resource mapping table in the test case file is located. The resource mapping table contains the correspondence between multiple variables and resource interfaces in the lower-level machine.

[0011] Read the test steps of each test case one by one according to the path where the test case file is located.

[0012] The test steps are converted into list variables in the host computer program in tabular form, generating a step list. The elements of the step list include step type, variable name and / or variable value.

[0013] Based on the page name of the resource mapping table in the test case file, parse the resource mapping table to obtain the correspondence between the variables in the test cases and the resource interfaces in the lower-level machine.

[0014] As one possible implementation, based on the test steps and resource correspondence, the lower-level machine is controlled to test the vehicle body controller under test, including:

[0015] Since the test type of the test step is a result detection class, the variables contained in the test step are used as target variables.

[0016] Based on the resource mapping relationship, the resource interface corresponding to the target variable is used as the target resource interface.

[0017] Generate the read command corresponding to the target resource interface.

[0018] The lower-level computer is controlled by a read command to read the value corresponding to the target variable in the vehicle body controller under test.

[0019] As one possible implementation, based on the test steps and resource correspondence, the lower-level machine is controlled to test the vehicle body controller under test, including:

[0020] The test type corresponding to the test step is an operation execution class, and the variables contained in the test step are used as target variables.

[0021] Based on the resource mapping relationship, the resource interface corresponding to the target variable is used as the target resource interface.

[0022] Generate the configuration commands corresponding to the target resource interface.

[0023] The lower-level computer sets the value of the target variable that acts on the vehicle body controller under test based on the setting command.

[0024] As one possible implementation, before generating a test report for the vehicle body controller under test based on the execution of the test steps, the method also includes:

[0025] The test type corresponding to the test step is a script interface class. Based on the script information contained in the test step, the script corresponding to the script information is executed, and the script execution result is obtained.

[0026] Based on the execution of the test steps, a test report is generated for the tested vehicle body controller, including:

[0027] A test report is generated based on the script execution results for the tested vehicle body controller.

[0028] As one possible implementation, a test report for the tested vehicle body controller is generated based on the execution of the test steps, including:

[0029] Based on the execution status of the test steps, determine the corresponding execution results and levels for each test step. These levels reflect the quality of the test step's execution.

[0030] Write the corresponding execution results and execution status levels of the test steps in the test report, along with the content of the test steps.

[0031] As one possible implementation, the data type of variables in the test cases may include one or more of the following data types:

[0032] Digital signals, analog signals, pulse width modulation signals, CAN signals, LIN signals, and resistors.

[0033] Secondly, this application also provides an automatic testing device for a vehicle body controller, applied to a host computer, the device comprising:

[0034] The test case step parsing module is used to parse preset test cases to obtain test steps and resource mappings. The test cases are used to test the vehicle body controller under test, and the resource mappings are the correspondences between variables in the test cases and resource interfaces in the lower-level machine. The lower-level machine is the lower-level machine that communicates with the upper-level machine to execute tests on the vehicle body controller under test.

[0035] The test case execution module, in response to whether a test step belongs to the result detection class or the operation execution class, controls the lower-level machine to test the vehicle body controller under test according to the correspondence between the test steps and resources. Specifically, the result detection class test steps are used to read the values ​​of corresponding variables from the vehicle body controller under test, while the operation execution class test steps are used to set the values ​​of variables acting on the vehicle body controller under test.

[0036] The common module is used to generate a test report for the vehicle body controller under test based on the execution of the test steps.

[0037] Thirdly, embodiments of this application also provide an electronic device, the device comprising: a processor and a memory storing computer program instructions.

[0038] When the processor executes the computer program instructions, it implements the automatic testing method for the body controller as described in the first aspect.

[0039] Fourthly, embodiments of this application also provide a computer-readable storage medium, characterized in that the computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the automatic testing method for the vehicle body controller as described in the first aspect.

[0040] Fifthly, embodiments of this application also provide a computer program product, wherein instructions in the computer program product, when executed by a processor of an electronic device, enable the electronic device to perform the automatic testing method for the body controller as described in the first aspect.

[0041] The automatic testing method, apparatus, device, and computer storage medium for vehicle body controllers in this application embodiment involve a host computer parsing test cases used to test the vehicle body controller under test. This allows the host computer to obtain the correspondence between test steps and variables within the test cases and resource interfaces in the slave computer (i.e., resource correspondence). Then, for test steps of the result detection or operation execution type, the host computer controls the slave computer to test the vehicle body controller under test based on the test steps and resource correspondence, and generates a test report for the vehicle body controller under test based on the execution status of the test steps. According to this application embodiment, by executing the automatic testing method for vehicle body controllers through the host computer, the slave computer can be controlled to automatically test the vehicle body controller under test and generate corresponding test reports. The entire testing process requires almost no manual intervention, resulting in higher testing efficiency, higher test quality, and lower labor costs compared to traditional manual testing methods. Attached Figure Description

[0042] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a schematic diagram of an application scenario provided in an embodiment of this application.

[0044] Figure 2 This is a flowchart illustrating an automatic testing method for a vehicle body controller provided in an embodiment of this application.

[0045] Figure 3 This is a flowchart illustrating a specific implementation of step S21 provided in an embodiment of this application.

[0046] Figure 4This is a schematic diagram of the overall testing process of the host computer during the automatic testing of a vehicle body controller, provided in an embodiment of this application.

[0047] Figure 5 This is a schematic diagram of the overall test process of the lower-level main system during the automatic testing of a vehicle body controller, provided in an embodiment of this application.

[0048] Figure 6 This is a schematic diagram of the overall test process of the lower-level resistor subsystem during the automatic testing of a vehicle body controller, provided in an embodiment of this application.

[0049] Figure 7 This is a schematic diagram of the structure of an automatic testing device for a vehicle body controller provided in an embodiment of this application.

[0050] Figure 8 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0051] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0052] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0053] Currently, manual testing of vehicle body controllers often requires constructing different input conditions for some hardwired pins of the controller under test, followed by manual observation of the load status driven by the controller. This process is typically time-consuming. Furthermore, for certain test steps involving precise time intervals, failure to detect or execute the corresponding operation at specific moments renders the test invalid and requires retesting, impacting efficiency. Secondly, manual testing is more prone to errors due to human negligence than automated testing, affecting test quality. Additionally, manual testing requires dedicated personnel for each task, increasing labor costs.

[0054] In view of this, this application provides an automatic testing method for a vehicle body controller. This automatic testing method can be run on a host computer. During testing, the host computer can control the slave computer based on the automatic testing method, and the slave computer can automatically perform the test on the vehicle body controller. The entire testing process requires almost no human intervention, thereby effectively avoiding the problems of low testing efficiency, poor testing quality, and high labor costs associated with manual testing.

[0055] The host computer can be a computer that can directly issue control commands, such as a computer, mobile phone, tablet, panel, touch screen, etc.

[0056] See Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application, such as... Figure 1 As shown, it may include a host computer 110, a slave computer 120 and a vehicle body controller under test 130, wherein the host computer 110 and the slave computer 120 are connected in communication, and the slave computer 120 is connected in communication with the vehicle body controller under test 130.

[0057] based on Figure 1 In the application scenario described, when testing the vehicle body controller 130 under test, the host computer 110 can run the automatic testing method for the vehicle body controller provided in this application embodiment, and control the slave computer 120 to test the vehicle body controller 130 under test based on the automatic testing method for the vehicle body controller. In this way, the automatic testing of the vehicle body controller 130 under test can be realized.

[0058] See Figure 2 This is a flowchart illustrating an automatic testing method for a vehicle body controller provided in an embodiment of this application. This testing method can be applied to, for example... Figure 1 The host computer shown is as follows: Figure 2 As shown in the embodiments of this application, the automatic testing method for the vehicle body controller may include the following steps:

[0059] S21. Parse the preset test cases to obtain the test steps and resource correspondence.

[0060] S22. In response to the test type being either result detection or operation execution, the lower-level machine is controlled to perform tests on the vehicle body controller under test based on the test steps and resource correspondence.

[0061] S23. Generate a test report for the tested vehicle body controller based on the execution of the test steps.

[0062] Among them, the test cases in S21 are test cases used to test the vehicle body controller under test, the resource correspondence is the correspondence between the variables in the test cases and the resource interfaces in the lower-level machine, and the lower-level machine is the lower-level machine that communicates with the upper-level machine to perform tests on the vehicle body controller under test.

[0063] Among them, the test steps of the result detection class in S22 are used to read the values ​​of the corresponding variables from the vehicle body controller under test, and the test steps of the operation execution class are used to set the values ​​of the variables acting on the vehicle body controller under test.

[0064] This application provides an automatic testing method for a vehicle body controller. The host computer parses test cases used to test the vehicle body controller under test, obtaining the correspondence between test steps and variables in the test cases and resource interfaces in the slave computer (i.e., resource correspondence). Then, for test steps of the result detection or operation execution type, the host computer controls the slave computer to test the vehicle body controller under test according to the test steps and resource correspondence, and generates a test report for the vehicle body controller under test based on the execution status of the test steps. According to this application embodiment, by executing the automatic testing method for the vehicle body controller through the host computer, the slave computer can be controlled to automatically test the vehicle body controller under test and generate corresponding test reports. The entire testing process requires almost no manual intervention, resulting in higher testing efficiency, higher testing quality, and lower labor costs compared to traditional manual testing methods.

[0065] In some embodiments, the variables in the test cases are typically those needed when testing the vehicle body controller under test. In actual testing, variables to be set or retrieved can be added line by line to the test cases according to the specific characteristics of the vehicle body controller under test. The data type of the variables can include one or more of the following: digital, analog, PWM (Pulse Width Modulation) signals, CAN (Controller Area Network) signals, LIN (Local Interconnect Network) signals, resistors, etc.

[0066] In some embodiments, in order to test the vehicle body controller under test via a lower-level computer, the lower-level computer, which is connected to the upper-level computer, can support functions such as digital output, digital input, PWM input, analog output, analog input, resistance function, CAN communication, and LIN communication.

[0067] In some embodiments, such as Figure 3 As shown, the specific implementation of the upper-level step S21 may include the following steps:

[0068] S31. Obtain the configuration information of the test cases. The configuration information includes the path to the test case file and the page name where the resource mapping table in the test case file is located. The resource mapping table contains the correspondence between multiple variables and resource interfaces in the lower-level machine.

[0069] S32. Read the test steps of each test case one by one according to the path where the test case file is located.

[0070] S33. Convert the test steps into list variables in the host computer program in tabular form, generating a step list, wherein the list variables include step type, variable name and / or variable value.

[0071] S34. Based on the page name of the resource mapping table in the test case file, parse the resource mapping table to obtain the correspondence between the variables in the test case and the resource interfaces in the lower-level machine.

[0072] As an example, a configuration interface can be set up in the host computer to configure test cases. When testing the vehicle body controller under test, the user can set the corresponding test case configuration information through the configuration interface. The path to the test case file in the configuration information indicates the file storage path of the test cases used in the test, allowing the host computer to successfully read the test case files based on this path.

[0073] Because the original test case files stored in the path where the test case files are located are usually not directly executable by the host computer, when parsing test cases in S21, the host computer can read the test steps contained in the test case files one by one based on the test case file path. For each test step, after reading it, it is converted into a list variable in the host computer program in tabular form and written into the step list, thus generating the step list corresponding to the test case. The elements in the step list can include information such as step type, variable name, variable value, and / or step number. By converting the test steps into list variables, the host computer program can directly execute and process each element in the step list according to the step information, achieving automatic execution of the test steps. The values ​​of each element in the step list corresponding to each test step are usually contained within the test step itself. Therefore, when parsing the test steps, the host computer can directly obtain the values ​​corresponding to each element in the step list from the test steps, and write the parsed values ​​into the corresponding columns of the elements, thus obtaining the step list corresponding to the test case.

[0074] Different test steps are typically used to implement different test functions, and the implementation of these functions requires the host computer to control the slave computer to execute them.

[0075] Different functions in the lower-level machine are typically implemented using different resource interfaces. Therefore, to ensure that the upper-level machine can control the lower-level machine to implement the corresponding functions based on the test steps, it is necessary to determine the resource mapping relationships before controlling the lower-level machine after obtaining the test steps.

[0076] Resource mapping relationships can be obtained by parsing the resource mapping table. The resource mapping table is a pre-set table used to record the mapping relationships between variables in test cases and resource interfaces in the lower-level machine. The completed resource mapping table can be stored in a test case file. Test case files typically contain multiple pages, and the page name where the resource mapping table is located indicates which page(s) of the test case file it resides on. Thus, the resource mapping table can be retrieved from the test case file based on its page name.

[0077] In some embodiments, the resource mapping relationship can be as shown in Table 1 below:

[0078] Table 1:

[0079] variable name Step type resource interface Remark Variable1 DO-H PA-2 Variable2 DO-L PA-3 Variable3 DI-H PA-4 Variable4 DI-L PA-5 Variable5 AO IIC1-1 Variable6 AI IIC1-2 Variable7 PWM-IN PWM-1 Variable8 RES RES-1 Variable9 CAN-OUT CAN-1 Variable10 CAN-IN CAN-2 Variable11 LIN-OUT LIN-1 Variable12 LIN-IN LIN-2

[0080] As shown in Table 1 above, the resource mapping table can include variable names, step types, resource interfaces, and remarks. The variable names here can be used directly when writing test cases, such as assigning values ​​to variables or judging the value of variables.

[0081] In this document, "Variable Name" refers to the identifier corresponding to each variable. In the "Step Type," DO-H and DO-L indicate that for a test system consisting of a host computer and a slave computer, the variable is a digital output. DO-H indicates that for the vehicle body controller under test, it is active high; that is, the logic is considered valid when the corresponding pin of the vehicle body controller under test detects a high level. DO-L indicates that for the vehicle body controller under test, the variable is active low; that is, the logic is considered valid when the corresponding pin of the vehicle body controller under test detects a low level. DI-H and DI-L indicate that the variable is a digital input for the test system. DI-H indicates that for the vehicle body controller under test, the variable is active high; that is, the logic is valid when the corresponding pin of the vehicle body controller under test outputs a high level. DI-L indicates that for the vehicle body controller under test, the variable is active low; that is, the logic is valid when the vehicle body controller under test outputs a low level. AO indicates that for the test system, the variable is an analog output. AI indicates that for the test system, the variable is an analog input. PWM-IN indicates that the variable is a PWM input for the test system. The expected duty cycle and frequency need to be specified in the test case to determine the PWM signal. RES indicates that the test system provides resistance to the vehicle controller under test. CAN-OUT and CAN-IN indicate that the corresponding variable is a CAN signal. CAN-OUT represents the CAN signal sent by the test system to the vehicle controller under test, and CAN-IN represents the CAN signal received by the test system from the vehicle controller under test. LIN-OUT and LIN-IN indicate that the corresponding variable is a LIN signal. LIN-OUT represents the LIN signal sent by the test system to the vehicle controller under test, and LIN-IN represents the LIN signal received by the test system from the vehicle controller under test.

[0082] The "Resource Interface" field specifies the resource interface name of the lower-level machine corresponding to each variable. For digital output and digital input variables, the name is "GPIO Group - Pin Number". For analog output and analog input variables, the name is "IIC Slave Serial Number - Internal Resource Serial Number". For PWM input variables, the name is "PWM - Test System PWM Resource Serial Number". For resistor-type variables, the name is "RES - Test System Resistor Resource Serial Number". For CAN signal-type variables, the name is "CAN - CAN Channel Serial Number". For LIN signal-type variables, the name is "LIN - LIN Channel Serial Number".

[0083] The "Remarks" column is usually used by testers to write notes and is not read by the host computer.

[0084] In the resource mapping table, elements in the same row correspond to the same variable.Taking Table 1 above as an example, the test step type of variable Variable1 is DO-H, and its corresponding resource interface is PA-2. PA-2 is the resource interface in the lower-level machine used to connect the digital input pins of the vehicle body controller under test. The test step type of variable Variable2 is DO-L, and its corresponding resource interface is PA-3. PA-3 is the resource interface in the lower-level machine used to connect the digital input pins of the vehicle body controller under test. The test step type of variable Variable3 is DI-H, and its corresponding resource interface is PA-4. PA-4 is the resource interface in the lower-level machine used to connect the digital output pins of the vehicle body controller under test. Variable4 belongs to a test step of type DI-L, with a corresponding resource interface of PA-5. PA-5 is the resource interface in the lower-level machine used to connect the digital output pins of the vehicle body controller under test. Variable5 belongs to a test step of type AO, with a corresponding resource interface of IIC1-1. IIC1-1 is the resource interface in the lower-level machine used to connect the analog input pins of the vehicle body controller under test. Variable6 belongs to a test step of type AI, with a corresponding resource interface of IIC1-2. IIC1-2 is the resource interface in the lower-level machine used to connect the analog output pins of the vehicle body controller under test. The test step type for iable7 is PWM-IN, and its corresponding resource interface is PWM-1. PWM-1 is the resource interface in the lower-level machine used to connect the output pin of the PWM controller under test. The test step type for Variable8 is RES, and its corresponding resource interface is RES-1. RES-1 is the resource interface in the lower-level machine used to connect the pin of the vehicle controller under test that requires a resistor. The test step type for Variable9 is CAN-OUT, and its corresponding resource interface is CAN-1. CAN-1 is the resource interface in the lower-level machine used to connect the CAN bus 1 interface of the vehicle controller under test. The test step type of Variable10 is CAN-IN, and its corresponding resource interface is CAN-2. CAN-2 is the resource interface used by the lower-level machine to connect to the CAN bus 2 interface of the body controller under test. The test step type of Variable11 is LIN-OUT, and its corresponding resource interface is LIN-1. LIN-1 is the resource interface used by the lower-level machine to connect to the LIN bus 1 interface of the body controller under test. The test step type of Variable12 is LIN-IN, and its corresponding resource interface is LIN-2. LIN-2 is the resource interface used by the lower-level machine to connect to the LIN bus 2 interface of the body controller under test.

[0085] The host computer can obtain the correspondence between variables in the test cases and resource interfaces in the slave computer by parsing the resource mapping table.

[0086] It should be noted that the resource mapping table can contain the correspondence between all variables that may be used in the test and the lower-level machine resource interfaces. The purpose is to ensure that the correspondence between the variables contained in the test cases can be obtained smoothly. However, the test cases do not have to contain all variables, or only a part of them. The specific variables included can be added according to the actual situation of the vehicle body controller under test.

[0087] After obtaining the test steps and resource correspondence, the host computer can control the slave computer to test the vehicle body controller under test.

[0088] Test steps can generally be categorized into result detection and operation execution types. The variables and execution processes involved in different types of test steps typically vary. Therefore, the control methods used by the host computer to manage the slave computer based on different test step types usually differ. For this reason, it is advisable to identify the test type of each test step before controlling the slave computer.

[0089] In some embodiments, the test type to which a test step belongs can be determined based on the step type of the test step.

[0090] Because result detection test steps are used to read the values ​​of variables from the vehicle body controller under test, test steps of type input can be classified as result detection test steps. Taking the table shown in Table 1 as an example, the test steps belonging to variables Variable3, Variable4, Variable6, Variable7, Variable10, and Variable12 can be identified as result detection test steps.

[0091] Because operation execution test steps are used to set the values ​​of variables for the vehicle body controller under test, test steps of output type and resistance type can be classified as operation execution test steps. Taking the table shown in Table 1 as an example, the test steps belonging to variables Variable1, Variable2, Variable5, Variable8, Variable9, and Variable11 can be identified as operation execution test steps.

[0092] After determining the test type of the test steps, the host computer can control the slave computer according to the test steps to test the vehicle body controller under test.

[0093] In some embodiments, in response to the test type of the test step being a result detection class, the specific implementation method of controlling the lower-level machine to test the vehicle body controller under test according to the test step and resource correspondence in S22 may include:

[0094] Use the variables included in the test steps as target variables.

[0095] Based on the resource mapping relationship, the resource interface corresponding to the target variable is used as the target resource interface.

[0096] Generate the read command corresponding to the target resource interface.

[0097] The lower-level computer is controlled by a read command to read the value corresponding to the target variable in the vehicle body controller under test.

[0098] As we know from the preceding content, the test steps of the result detection class are used to read the values ​​of the corresponding variables from the vehicle body controller under test. Therefore, the test steps of the result detection class can generate the read command corresponding to the target resource interface so that the lower-level machine can be controlled to read the value of the target variable from the vehicle body controller under test through the target resource interface.

[0099] In some embodiments, in response to the test type of the test step being an operation execution class, the specific implementation method of controlling the lower-level machine to test the vehicle body controller under test according to the test step and resource correspondence in S22 may include:

[0100] Use the variables included in the test steps as target variables.

[0101] Based on the resource mapping relationship, the resource interface corresponding to the target variable is used as the target resource interface.

[0102] Generate the configuration commands corresponding to the target resource interface.

[0103] The lower-level computer sets the value of the target variable in the vehicle body controller under test based on the setting command.

[0104] As we know from the preceding content, the test steps of the operation execution class are used to set the values ​​of variables that act on the vehicle body controller under test. Therefore, the test steps of the operation execution class can generate setting commands corresponding to the target resource interface, so as to control the lower-level machine to set the values ​​of the target variables that act on the vehicle body controller under test through the target resource interface.

[0105] In some embodiments, different modules can be used to test variables of different data types in the lower-level machine. For example, a microcontroller can be used to test digital quantities, PWM signals, analog quantities, and resistors, while a CAN / LIN bus monitoring device can be used to test CAN signals and LIN signals. Therefore, the methods used by the upper-level machine to control the lower-level machine to read or set the values ​​of target variables in the vehicle body controller under test based on read or set commands also differ.

[0106] If the test step to be executed by the host computer is a result detection type, and the data type of the target variable it contains is one of digital, PWM, or analog, then when the host computer controls the slave computer to read the value of the target variable in the tested vehicle body controller based on the read command, it can send the corresponding serial port read command to the slave computer and obtain the data returned by the slave computer through serial communication. If the test step to be executed by the host computer is a result detection type, and the data type of the target variable it contains is CAN signal or LIN signal, then when the host computer controls the slave computer to read the value of the target variable in the tested vehicle body controller based on the read command, it can directly read the CAN signal value or LIN signal value from the CAN / LIN bus monitoring device in the slave computer.

[0107] Similarly, if the test steps to be executed by the host computer are of the operation execution type, and the data type of the target variable included is one of digital quantity, analog quantity, or resistance, then when the host computer controls the slave computer to set the value of the target variable acting on the vehicle body controller under test, it can send the corresponding serial port setting command to the slave computer and obtain the data returned by the slave computer through serial communication. If the test steps to be executed by the host computer are of the operation execution type, and the data type of the target variable included is CAN signal or LIN signal, then when the host computer controls the slave computer to set the value of the target variable in the vehicle body controller under test based on the setting command, it can directly set the CAN signal value or LIN signal value in the CAN / LIN bus monitoring device in the slave computer. In this way, the CAN signal value or LIN signal value in the vehicle body controller under test can be set directly through the CAN / LIN bus monitoring device.

[0108] When a host computer controls a slave computer, it typically receives data returned by the slave computer. This data may include, but is not limited to, response information and test data from the slave computer. The response information indicates whether the slave computer executed the command successfully, whether the host computer needs to resend the command, and whether the sent command was erroneous. The test data may include the actual values ​​of target variables returned by result-detection test steps, i.e., the values ​​of target variables read by the slave computer from the vehicle controller under test. The host computer can determine the execution status of the test steps based on the data returned by the slave computer.

[0109] In some embodiments, the test steps of result detection and operation execution classes are typically used to control the lower-level computer to perform setting or reading operations on the corresponding variables in the vehicle body controller under test. However, for some complex test scenarios, simply setting and reading variables cannot obtain the desired data. For example, some complex test scenarios may require setting a value for a first variable and then reading the value of a second variable after a preset interval, which includes a "preset interval" condition. This condition often cannot be achieved through test steps of simple result detection and operation execution classes. This makes it impossible for the upper-level computer to obtain accurate data, and thus impossible to determine whether the data of the target variable in the test step is accurate, resulting in an inaccurate determination of the execution status of the test step. In this case, a script file can be pre-written, and the program logic required for the complex test scenario can be written in code into a function or method of an object according to a fixed development pattern. The function or method can then record the success or failure information of each sub-step in the test report. Then, a specific test step in the test case can be written as the script file name, the name of the function (or method) in this script file to be executed, and the parameters passed to the function (or method). When the host computer processes this test step, it will execute the corresponding function (or method) in this script file to handle complex test scenarios. This type of test step usually only needs to be executed by the host computer, so it does not belong to the result detection class or operation execution class. Therefore, the test type for this type of test step is determined as the script interface class.

[0110] Correspondingly, before executing the test steps, the host computer also needs to identify whether the test steps are script interface classes. The identification method can be to determine whether the test steps contain script file names, function (or method) names in script files, or input parameters to functions (or methods). If any of these are contained, the test type of the test steps is determined to be a script interface class.

[0111] If the test type of the test step is a script interface class, the host computer will execute the script corresponding to the script information contained in the test step and obtain the script execution result. The script information may include script file name, function (or method) name in the script file and / or input parameters to the function (or method), etc., which can be used to identify the script.

[0112] In this way, the host computer can accurately determine the execution status of some test steps based on the script execution results.

[0113] Furthermore, the host computer can generate a test report corresponding to the vehicle body controller under test based on the execution status of the test steps.

[0114] In some embodiments, before executing S23, the execution status of the test steps can be determined first. The host computer can determine the execution status of the test steps using one or more of the following methods:

[0115] Determine if the test step belongs to any of the following categories: result detection, operation execution, or script interface. If not, the test step is considered to have failed.

[0116] If the test type of the test step is determined to be either result detection or operation execution, it can be further determined whether the data type of the variables contained in the test step belongs to the preset data type. If not, the test step is determined to have failed.

[0117] Based on the response information returned by the lower-level machine, determine whether the command sent to the lower-level machine was an error. If so, the test step is considered to have failed.

[0118] Based on the response information returned by the lower-level machine, determine whether the lower-level machine executed successfully. If the lower-level machine fails to execute, the test step is determined to have failed.

[0119] If the response information returned by the lower-level machine indicates successful execution, then based on the test data and / or script execution results returned by the lower-level machine, determine whether the actual value of the target variable in the test step matches the preset expected value in the test case. If it matches, the test step is considered successful; otherwise, it is considered a failure. Matching can be either equality or similarity, which can be set according to the specific circumstances.

[0120] If the response data returned by the lower-level machine indicates that the lower-level machine needs the upper-level machine to resend the command, then the test step is considered to have failed.

[0121] Currently, when testing the vehicle body controller, the data types of variables that need to be tested are mainly digital, PWM, analog, resistance, CAN signals, and LIN signals. Therefore, the preset data types mentioned above can include digital, PWM, analog, resistance, CAN signals, and LIN signals. If a variable other than the preset data type appears in the test step, it can be determined that the test step is abnormal. Therefore, before executing a test step, it is necessary to determine whether the data type of the target variable included in the test step belongs to the preset data type. If it does, the test step continues; if it does not, the test step is not executed, and the execution status of the test step is determined to be a failure.

[0122] Similarly, the test types for test steps are mainly divided into three categories: result detection, operation execution, and script interface. If a test step does not belong to any of these three categories, it can be determined that the test step is an abnormal step, and thus the test step will no longer be executed, and the execution status of the test step will be determined as a failure.

[0123] Once the execution status of the test steps is determined, a test report for the tested vehicle body controller can be generated through S23 based on the execution status of the test steps. This eliminates the need for testers to compile test reports separately, further reducing the workload of testers.

[0124] In some embodiments, when generating a test report in S23, the level corresponding to the execution result and execution status of the test step can be determined based on the execution status of the test step. The level is used to reflect the quality of the execution of the test step. The level corresponding to the execution result and execution status of the test step is written into the test report along with the content of the test step.

[0125] As an example, the test can be divided into three levels: Normal, Warning, and Error. Each test step executed by the host computer will distinguish between different situations and write information corresponding to the different levels in the test report. Different levels can correspond to different conditions. When a test step is executed, the conditions it meets can be determined based on its execution status, and the level corresponding to the met conditions will be used as the test step's level. The conditions corresponding to each level can be set according to requirements.

[0126] Because a test step may be sent multiple times during the entire test process due to various reasons (such as needing to resend commands to the lower-level machine), a test step may correspond to multiple levels in the test report, with each level corresponding to each sending situation.

[0127] As an example, the conditions corresponding to the "normal" level can include the test step succeeding; the conditions corresponding to the "warning" level can include the test step failing due to resending during the entire test process; and the conditions corresponding to the "error" level can include any failure of the test step other than failure caused by resending the command, such as the target variable not belonging to the preset data type, the test step not belonging to any of the result detection class, operation execution class, or script interface class, lower-level machine execution failure, the test data and / or script execution results returned by the lower-level machine not meeting the expected values, etc.

[0128] When generating a test report, in addition to specifying the test step's level, you can also include relevant information. This information explains why the test step was classified as normal, warning, or error, allowing testers to determine the cause of the failure and make appropriate adjustments. For example, if a test step is classified as error, and the error is caused by a variable of type "PWN" that is not a default data type, the report could include information such as "PWN" to indicate the cause of the error.

[0129] In some embodiments, when the host computer performs the test steps, it can also determine whether a serious problem has occurred, and terminate the test if a serious problem is determined to have occurred.

[0130] One method for determining whether a serious problem has occurred is to check whether the corresponding command has been resent to the lower-level machine during the execution of the current test step. If it has been resent, the number of resentments is determined. If the number of resentments reaches a preset threshold and the lower-level machine still returns a request for resentment, a serious problem is identified. Since the lower-level machine cannot successfully execute the command after multiple resentments, it indicates that the test cannot be completed smoothly. Therefore, the test is terminated. Terminating the test reduces wasted time and preserves the current state for future troubleshooting.

[0131] In some embodiments, a test case typically contains multiple test steps. Therefore, during the testing process, after executing one test step, the host computer can check whether there are any unexecuted test steps in the currently executing test case. If so, it continues to execute the unexecuted test steps until all test steps in the test case have been executed, thus determining that the test case has been completed. This avoids the problem of missing test items.

[0132] In some embodiments, multiple test cases may be required when testing the vehicle body controller under test. Therefore, during the testing process, after executing one test case, the host computer can check if there are any unexecuted test cases. If so, it continues to execute the unexecuted test cases until all test cases have been executed, at which point the test is considered complete. This avoids the problem of missing test items.

[0133] As an example, see Figure 4 This is a schematic diagram of the overall testing process of the host computer during the automatic testing of the vehicle body controller.

[0134] like Figure 4As shown, when testing the vehicle body controller under test, the host computer first parses the resource mapping table to generate the correspondence between variables in the test cases and resource interfaces of the lower-level machine. Then, it checks if there are any unexecuted test cases. If not, the entire testing process ends. If there are unexecuted test cases, individual test cases are processed one by one. All test steps for a single test case are obtained, forming a step list. It checks if there are any unexecuted test steps. If there are no unexecuted test steps, the current test case ends, and the process returns to checking for unexecuted test cases. If there are unexecuted test steps, the test step content is read, and it is determined whether the current test step belongs to an operation execution class, a result detection class, or a script interface class.

[0135] If the current test step is a result detection type, and the variables it contains are digital, PWM, or analog, the host computer sends the corresponding serial port read command to the slave computer and obtains the data returned by the slave computer through serial communication. Then, it determines whether the slave computer has executed the test successfully based on the returned data. If execution fails, the test failure information is recorded in the test report. If execution is successful, it continues to determine whether the read data value meets expectations. If it meets expectations, the test success information is recorded in the test report; otherwise, the test failure information is recorded in the test report. If the host computer is executing a result detection type test, and the variables are CAN or LIN signals, the host computer reads the CAN or LIN signal values ​​from the CAN / LIN bus monitoring device in the slave computer. If the read is successful, it continues to determine the read data value. If it meets expectations, the test success information is recorded in the report; otherwise, the test failure information is recorded. If the read fails, the test failure information is recorded in the test report. If a variable that does not belong to any of the digital, PWM, analog, CAN, or LIN signals is parsed during the result detection test step, the step failure will be recorded directly in the report.

[0136] If the current test step is an operation execution type, and the variables it contains are of digital, analog, or resistor type, the host computer sends the corresponding serial port setting command to the slave computer and obtains the data returned by the slave computer through serial communication. The host computer then determines whether the slave computer executed the test successfully based on the returned data. If successful, the test report records the step's successful execution; otherwise, it records the step's failure. If the current test step is an operation execution type, and the variables it contains are of CAN or LIN signal type, the host computer sets the CAN or LIN signal value in the CAN / LIN bus monitoring device on the slave computer. If the setting is successful, the test report records the step's successful execution; otherwise, it records the execution failure. Similarly, if a variable in an operation execution type test step is not of any type (digital, analog, resistor, CAN, or LIN signal), the report directly records the step's failure.

[0137] If the current step belongs to a script interface class, the corresponding function (or method) in the script will be executed based on the script name, function (method) name, and input parameters, and information will be recorded in the test report according to the script code. If the current step does not belong to any of the operation execution class, result detection class, or script interface class, it is considered an abnormal step, and the test will terminate.

[0138] After a single test step is completed, it is checked whether there are any unexecuted test steps. This process continues until all test steps have been executed, at which point the current test case is considered complete. The test ends when all test cases have been executed.

[0139] In some embodiments, the lower-level machine mainly includes two control systems. One control system is used to implement functions such as digital quantity setting, digital quantity reading, analog quantity setting, analog quantity reading, PWM reading, and resistor setting command forwarding; this is called the main system. The other control system is mainly used to set the resistor according to the received resistor setting command; therefore, it is called the resistor subsystem. See also Figure 5 This is a schematic diagram of the overall testing process of the lower-level main system during the automatic testing of the body controller.

[0140] like Figure 5As shown, the lower-level master system first performs a series of initial configurations, including GPIO (General-purpose input / output) initialization, serial port initialization (including serial port 1 for communication with the host computer and serial port 2 for communication with the resistor subsystem), timer initialization, enabling serial port receive interrupt, and enabling input capture function. When the serial port receives a complete data frame, it first checks whether the data verification passes according to the custom serial communication protocol. If it fails, it sends a retransmission command to the host computer to retransmit the command. If the data verification passes, it first checks whether the command sent by the host computer is a retransmission command instructing the lower-level master system to resend the data to the host computer. If so, it retransmits the data to the host computer; otherwise, it continues to check whether it belongs to one of the following categories: digital quantity setting, digital quantity reading, PWM reading, analog quantity setting, analog quantity reading, or resistor setting. If none of these apply, it sends a "command error" serial port data to the host computer.

[0141] If it's a digital setting command, the corresponding GPIO pin is set to the specified level, and a confirmation message (whether the setting was successful) is sent to the host computer. If it's a digital reading command, the level of the specified GPIO pin is read, and a confirmation message (whether the reading was successful) and the read level value are sent to the host computer. If it's a PWM reading command, the duty cycle and frequency of the corresponding PWM channel are calculated, and a confirmation message (whether the reading was successful) and the PWM data are sent to the host computer. If it's an analog setting command, communication with the DA converter according to the IIC protocol is used to construct the output voltage of the corresponding DA channel, and a confirmation message (whether the setting was successful) is sent to the host computer. If it's an analog reading command, communication with the AD converter according to the IIC protocol is used to obtain the acquisition data of the corresponding AD channel, and a confirmation message (whether the reading was successful) and the AD acquisition data are sent to the host computer.

[0142] The handling of resistor setting commands is somewhat unique. The lower-level master system communicates with the host computer via serial port 1 and with the resistor subsystem via serial port 2. If serial port 1 receives a resistor setting command from the host computer, it forwards the data to serial port 2 to inform the resistor subsystem that resistor setting is required. After the resistor subsystem processes the command and returns a response indicating whether the setting was successful, the lower-level master system forwards the response data received from the resistor subsystem via serial port 2 to the host computer connected to serial port 1 to notify the host computer whether the setting was successful. Because the lower-level master system only forwards serial communication data between serial ports 1 and 2 in the resistor setting command process, it is equivalent to the host computer indirectly interacting with the resistor subsystem according to a custom serial protocol.

[0143] After the lower-level host system finishes processing the received command, it waits for the next complete data frame to be received by serial port 1 before continuing processing.

[0144] The test procedure for the lower-level computer resistor subsystem is as follows: Figure 6 As shown, a series of initial configurations are first performed, including GPIO initialization, serial port initialization, and enabling serial port receive interrupts. Upon receiving a complete data frame, the system first checks if the data verification is successful according to the custom serial communication protocol. If it fails, a retransmission command is sent to the lower-level master system to retransmit the data. If the data verification is successful, it checks if the command was sent by the lower-level master system to retransmit data from the resistor subsystem to the master system. If so, the data is retransmitted to the lower-level master system; otherwise, the resistance value in the received resistance setting command is parsed, and the corresponding resistance value is provided to the tested vehicle body controller based on the parsed resistance value. A response indicating whether the resistance setting was successful is then sent to the lower-level master system. After the resistance setting command is processed, the system waits again for a complete data frame to be received in order to process the next command.

[0145] As described above, the embodiments of this application provide an automatic testing method for a vehicle body controller. This method can perform various types of tests, including digital quantity setting, digital quantity reading, analog quantity setting, analog quantity reading, PWM reading, resistance setting, CAN signal setting, CAN signal reading, LIN signal setting, LIN signal reading, and script development interface functions. It meets the various input / output types required for testing the vehicle body controller, enabling automated testing. Compared to traditional manual testing, this method improves testing efficiency, enhances testing quality, and saves labor costs.

[0146] Based on the automatic testing method for the body controller provided in the above embodiments, this application also provides a specific implementation of an automatic testing device for the body controller applied to a host computer. Please refer to the following embodiments.

[0147] See Figure 7 The automatic testing device for the vehicle body controller provided in this application embodiment may include the following modules:

[0148] The test case step parsing module 701 is used to parse preset test cases to obtain test steps and resource mapping relationships. The test cases are used to test the vehicle body controller under test, and the resource mapping relationships are the correspondence between variables in the test cases and resource interfaces in the lower-level machine. The lower-level machine is a lower-level machine that communicates with the upper-level machine to execute tests on the vehicle body controller under test.

[0149] The test case execution module 702 is used to control the lower-level machine to test the vehicle body controller under test, based on whether the test step belongs to the result detection class or the operation execution class, according to the correspondence between the test steps and resources. Specifically, the test steps for the result detection class are used to read the values ​​of corresponding variables from the vehicle body controller under test, while the test steps for the operation execution class are used to set the values ​​of variables acting on the vehicle body controller under test.

[0150] Common module 703 is used to generate a test report for the vehicle body controller under test based on the execution status of the test steps.

[0151] The automatic testing device for vehicle body controllers in this application embodiment involves a host computer parsing test cases used to test the vehicle body controller under test. This allows the host computer to obtain the correspondence between test steps and variables within the test cases and resource interfaces in the slave computer (i.e., resource correspondence). Then, for test steps of the result detection or operation execution type, the host computer controls the slave computer to test the vehicle body controller under test based on the test steps and resource correspondence, and generates a test report for the vehicle body controller under test based on the execution status of the test steps. According to this application embodiment, by executing the automatic testing method for vehicle body controllers through the host computer, the slave computer can be controlled to automatically test the vehicle body controller under test and generate corresponding test reports. The entire testing process requires almost no manual intervention, resulting in higher testing efficiency, higher testing quality, and lower labor costs compared to traditional manual testing methods.

[0152] In some embodiments, the use case step parsing module 701 is specifically used for:

[0153] Obtain the configuration information for the test cases. This information includes the path to the test case file and the page name where the resource mapping table in the test case file is located. The resource mapping table contains the correspondence between multiple variables and resource interfaces in the lower-level machine.

[0154] Read the test steps of each test case one by one according to the path where the test case file is located.

[0155] The test steps are converted into list variables in the host computer program in tabular form, generating a step list. The elements of the step list include step type, variable name and / or variable value.

[0156] Based on the page name of the resource mapping table in the test case file, parse the resource mapping table to obtain the correspondence between the variables in the test cases and the resource interfaces in the lower-level machine.

[0157] In some embodiments, the test case execution module 702 is specifically used for:

[0158] Since the test type of the test step is a result detection class, the variables contained in the test step are used as target variables.

[0159] Based on the resource mapping relationship, the resource interface corresponding to the target variable is used as the target resource interface.

[0160] Generate the read command corresponding to the target resource interface.

[0161] The lower-level computer is controlled by a read command to read the value corresponding to the target variable in the vehicle body controller under test.

[0162] In some embodiments, the test case execution module 702 is specifically used for:

[0163] The test type corresponding to the test step is an operation execution class, and the variables contained in the test step are used as target variables.

[0164] Based on the resource mapping relationship, the resource interface corresponding to the target variable is used as the target resource interface.

[0165] Generate the configuration commands corresponding to the target resource interface.

[0166] The lower-level computer sets the value of the target variable that acts on the vehicle body controller under test based on the setting command.

[0167] In some embodiments, the test case execution module 702 is specifically used to: before generating a test report for the vehicle body controller under test based on the execution status of the test steps, in response to the test type being a script interface class, execute the script corresponding to the script information contained in the test steps, and obtain the script execution result.

[0168] In some embodiments, the common module 703 is specifically used for:

[0169] A test report is generated based on the script execution results for the tested vehicle body controller.

[0170] In some embodiments, the common module 703 is specifically used for:

[0171] Based on the execution status of the test steps, determine the execution result and corresponding level of the execution status for each test step. The level is used to reflect the quality of the test step's execution.

[0172] Write the execution results and execution status levels corresponding to the test steps in the test report, along with the content of the test steps.

[0173] In some embodiments, the data type of variables in test cases includes one or more of the following data types:

[0174] Digital signals, analog signals, pulse width modulation signals, CAN signals, LIN signals, and resistors.

[0175] In some embodiments, the public module 703 also provides a judgment function to determine whether the actual values ​​of variables obtained during the test process meet the expected values ​​of the test cases. If they do not meet the expected values, an error message is recorded in the report. The judgment function also supports setting whether to terminate the execution of the entire test process. When the host computer detects a serious problem, the entire test can be stopped to preserve the current state.

[0176] In some embodiments, the test case step parsing module 701 may also provide a script development interface, which can be used to call the corresponding script for test steps of the script interface class.

[0177] In some embodiments, the automatic testing device for the body controller may further include a configuration module, through which testers can set the configuration information of test cases. The configuration module may also include serial port configuration parameters and debug mode enable parameters. When the debug mode enable parameter is set to "on," the test report will contain more detailed information to facilitate human analysis of test phenomena.

[0178] In some embodiments, the automatic testing device for the body controller may further include a monitoring command module, which can obtain serial port information from the serial port configuration parameters in the configuration module in order to correctly perform serial port data transmission.

[0179] The automatic testing device for the body controller provided in this application can realize all the processes implemented in any of the above-described automatic testing method embodiments for the body controller. To avoid repetition, these processes will not be described again here.

[0180] Figure 8 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0181] Electronic devices may include a processor 801 and a memory 802 storing computer program instructions.

[0182] Specifically, the processor 801 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0183] Memory 802 may include mass storage for data or instructions. For example, and not limitingly, memory 802 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 802 may include removable or non-removable (or fixed) media. Where appropriate, memory 802 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 802 is non-volatile solid-state memory.

[0184] Memory 802 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory 802 includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it can perform the operations described in any of the automated body controller testing methods in the above embodiments.

[0185] The processor 801 reads and executes computer program instructions stored in the memory 802 to implement any of the automatic testing methods for the vehicle body controller in the above embodiments.

[0186] In one example, the electronic device may also include a communication interface 803 and a bus 810. For example, Figure 8 As shown, the processor 801, memory 802, and communication interface 803 are connected through bus 810 and complete communication with each other.

[0187] The communication interface 803 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0188] Bus 810 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 810 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0189] Furthermore, in conjunction with the automatic testing method for the body controller in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions, which, when executed by a processor, implement any of the automatic testing methods for the body controller in the above embodiments.

[0190] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0191] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0192] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0193] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0194] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method of automatically testing a body controller, characterized by, Applied to a host computer, the method includes: The preset test cases are parsed to obtain test steps and resource correspondences. The test cases are used to test the vehicle body controller under test. The resource correspondences are the correspondences between variables in the test cases and resource interfaces in the lower-level machine. The lower-level machine is a lower-level machine that communicates with the upper-level machine to perform tests on the vehicle body controller under test. The lower-level machine communicates with the vehicle body controller under test. In response to the test type of the test step being either result detection or operation execution, the lower-level machine is controlled to test the vehicle body controller under test according to the test step and the resource correspondence. Specifically, the result detection test step is used to read the values ​​of corresponding variables from the vehicle body controller under test, and the operation execution test step is used to set the values ​​of variables acting on the vehicle body controller under test. Based on the execution of the test steps, a test report is generated for the tested vehicle body controller. The data types of the variables in the test cases include one or more of the following data types: Digital signals, analog signals, pulse width modulation signals, CAN signals, LIN signals, and resistors.

2. The method according to claim 1, characterized in that, The parsing of the preset test cases includes: Obtain the configuration information of the test cases. The configuration information includes the path to the test case file and the page name of the resource mapping table in the test case file. The resource mapping table contains the correspondence between multiple variables and resource interfaces in the lower-level machine. Read the test steps of each test case one by one according to the path where the test case file is located. The test steps are converted into list variables in the host computer program in tabular form, generating a step list, wherein the elements of the step list include step type, variable name and / or variable value. Based on the page name of the resource mapping table in the test case file, the resource mapping table is parsed to obtain the correspondence between the variables in the test case and the resource interfaces in the lower-level machine.

3. The method according to claim 1, characterized in that, The step of controlling the lower-level machine to test the vehicle body controller under test according to the test steps and the resource correspondence includes: Since the test type to which the test step belongs is the result detection class, the variables contained in the test step are used as target variables. Based on the resource correspondence, the resource interface corresponding to the target variable is taken as the target resource interface. Generate the read command corresponding to the target resource interface. Based on the read command, the lower-level machine is controlled to read the value corresponding to the target variable in the vehicle body controller under test.

4. The method of claim 3, wherein, The step of controlling the lower-level machine to test the vehicle body controller under test according to the test steps and the resource correspondence includes: Since the test type described in the test step is an operation execution class, the variables included in the test step are used as target variables. Based on the resource correspondence, the resource interface corresponding to the target variable is taken as the target resource interface. Generate the configuration command corresponding to the target resource interface. Based on the setting command, the lower-level machine is controlled to set the value of the target variable acting on the vehicle body controller under test.

5. The method of claim 1, wherein, Before generating a test report for the tested vehicle body controller based on the execution status of the test steps, the method further includes: In response to the test type being a script interface class in the test step, the script corresponding to the script information contained in the test step is executed to obtain the script execution result. The step of generating a test report for the tested vehicle body controller based on the execution status of the test steps includes: A test report for the tested vehicle body controller is generated based on the script execution results.

6. The method of claim 1, wherein, The step of generating a test report for the tested vehicle body controller based on the execution status of the test steps includes: Based on the execution status of the test steps, the execution result of the test steps and the corresponding level of the execution status are determined. The level is used to reflect the quality of the execution status of the test steps. The execution results of the test steps and the corresponding levels of the execution status are written into the test report along with the content of the test steps.

7. A body controller automatic test apparatus characterized by comprising: Applied to a host computer, the device includes: The test case step parsing module is used to parse preset test cases to obtain test steps and resource correspondences. The test cases are used to test the vehicle body controller under test. The resource correspondences are the correspondences between variables in the test cases and resource interfaces in the lower-level machine. The lower-level machine is a lower-level machine that communicates with the upper-level machine to perform tests on the vehicle body controller under test. The lower-level machine communicates with the vehicle body controller under test. The test case execution module is used to control the lower-level machine to test the vehicle body controller under test, based on whether the test type of the test step is a result detection type or an operation execution type, according to the correspondence between the test step and the resource. Specifically, the result detection type test step is used to read the values ​​of corresponding variables from the vehicle body controller under test, and the operation execution type test step is used to set the values ​​of variables acting on the vehicle body controller under test. A common module is used to generate a test report for the vehicle body controller under test based on the execution status of the test steps. The data types of the variables in the test cases include one or more of the following data types: Digital signals, analog signals, pulse width modulation signals, CAN signals, LIN signals, and resistors.

8. An electronic device, comprising: The device includes: a processor and a memory storing computer program instructions. When the processor executes the computer program instructions, it implements the automatic testing method for the body controller as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the automatic testing method for the body controller as described in any one of claims 1-6.

Images