Method, apparatus, and medium for testing an electronic control module for a vehicle

Abstract

The method comprises the following steps: in the case of listening to a set state change event, obtaining a test file associated with the set state change event; wherein the test file comprises identification information of a vehicle-mounted electronic control module to be tested and a test case, the test case comprises a corresponding test script execution path and an expected result; according to the identification information, determining each test instrument corresponding to the vehicle-mounted electronic control module to be tested, and establishing a test link between each test instrument; according to the test script execution path, obtaining the corresponding test script, and based on the test script, controlling each test instrument through each test link to test the vehicle-mounted electronic control module to be tested to obtain test data; comparing the test data with the corresponding expected result to generate a test result of the vehicle-mounted electronic control module to be tested.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle electronic control module testing technology, and more specifically, to a testing method, equipment, and medium for vehicle electronic control modules. Background Technology

[0002] In the field of automotive electronics, the development and testing of in-vehicle electronic control modules, such as power amplifiers, requires frequent functional verification, performance verification, and reliability verification tests. Currently, testing largely relies on specialized testing instruments combined with manual operation, and tasks such as test management and instrument scheduling also depend on manual intervention. This fragmented approach leads to low testing efficiency. Summary of the Invention

[0003] The purpose of this disclosure is to provide a new technical solution for testing vehicle-mounted electronic control modules.

[0004] According to a first aspect of the present disclosure, a method for testing an on-board electronic control module is provided, the method comprising: Upon detecting a setting state change event, obtain the test file associated with the setting state change event; wherein, the test file includes the identification information of the vehicle electronic control module under test and test cases, and the test cases include the corresponding test script execution path and expected results; Based on the identification information, each test instrument corresponding to the vehicle electronic control module under test is identified, and a test link is established between each test instrument. According to the test script execution path, the corresponding test script is obtained, and based on the test script, each of the test instruments is controlled through each of the test links to test the vehicle electronic control module under test and obtain test data. The test data is compared with the corresponding expected results to generate the test results for the vehicle electronic control module under test.

[0005] Optionally, the step of obtaining the test file associated with the setting state change event upon detecting a setting state change event includes: Upon detecting a state change event, a trigger request is generated; Based on the trigger request, the test file is obtained from the test management platform.

[0006] Optionally, the step of determining each test instrument corresponding to the vehicle electronic control module under test based on the identification information, and establishing a test link with each of the test instruments, includes: Acquire the set mapping data; wherein the mapping data reflects the correspondence between the identification information of different vehicle electronic control modules and the communication parameters of their corresponding test instruments; The mapping data is queried based on the identification information to obtain the communication parameters of the test instrument corresponding to the vehicle electronic control module under test; A test link is established with the corresponding test instrument using the communication parameters.

[0007] Optionally, the communication parameters include the communication protocol and hardware address. The step of establishing a test link with the corresponding test instrument through the communication parameters includes: Load the corresponding protocol conversion driver according to the communication protocol; Based on the hardware address, a communication connection is established with the test instrument through the protocol conversion driver, forming the test link.

[0008] Optionally, the step of obtaining the corresponding test script according to the test script execution path, and controlling each of the test instruments through each of the test links to test the vehicle electronic control module under test and obtain test data based on the test script, includes: According to the test script execution path, the corresponding test script is obtained. Based on the test script, the corresponding test instrument is controlled through each test link to test the vehicle electronic control module under test, and multi-source test data is obtained. The multi-source test data is preprocessed to obtain the test data.

[0009] Optionally, comparing the test data with the corresponding expected results to generate the test results for the vehicle electronic control module under test includes: The test data is compared with the expected results to obtain the comparison results; Based on the comparison results, a structured result set of the vehicle electronic control module under test is generated; The test results are generated based on the structured result set.

[0010] Optionally, generating the test results based on the structured result set includes: Based on the structured result set, identify the abnormal test items; Obtain the reproduction path logs corresponding to the abnormal test items; The abnormal test items and their corresponding reproduction path logs are encapsulated into defect information; The test results are generated based on the defect information and the structured result set.

[0011] Optionally, after generating the test results for the vehicle electronic control module under test, the method further includes: The test results are transmitted back to the test management platform through an encrypted channel, so as to establish the association between the test results and the test cases through the test management platform.

[0012] According to a second aspect of the present disclosure, an electronic device is provided, comprising: a memory for storing executable computer instructions; and a processor for executing a test method for an in-vehicle electronic control module according to the first aspect above, under the control of the executable computer instructions.

[0013] According to a third aspect of the present disclosure, a computer-readable storage medium is provided, characterized in that a computer program is stored on the computer-readable storage medium, the computer program implementing the test method for the vehicle electronic control module according to the first aspect above when executed by a processor.

[0014] One beneficial effect of this disclosure is that by listening to and setting state change events, the test process is automatically triggered, and the corresponding test instrument is automatically determined and a test link is established based on the identification information of the vehicle electronic control module under test. This realizes the automatic association and state synchronization between test files, test cases and test instruments, without the need for manual task creation, environment configuration or instrument switching, which significantly improves test efficiency.

[0015] Other features and advantages of this specification will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of this specification and, together with their description, serve to explain the principles of this specification.

[0017] Figure 1 This is a block diagram of the hardware configuration of a test system for implementing a test method for an on-board electronic control module, as provided in this embodiment of the disclosure. Figure 2 This is a flowchart illustrating the testing method for an in-vehicle electronic control module provided in this embodiment of the disclosure; Figure 3 This is a flowchart illustrating a test method for an example of an in-vehicle electronic control module. Figure 4 This is a schematic block diagram of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0018] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the embodiments of the present disclosure.

[0019] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0020] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0021] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0022] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0023] <Hardware Configuration> Figure 1 This is a block diagram of the hardware configuration of a test system 1000 for implementing a test method for an on-board electronic control module, as provided in this embodiment of the disclosure.

[0024] The test system 1000 of this embodiment may include a test management platform 1100 and a continuous integration engine 1200. The test management platform 1100 may be, for example, JIRA, and the continuous integration engine may be, for example, Jenkins. The test management platform 1100 may be deployed on a first electronic device, and the continuous integration engine 1200 may be deployed on a second electronic device. The first electronic device and the second electronic device are communicatively connected. The test management platform 1100 is used to manage test orders and test cases, and the continuous integration engine 1200 is used to test the vehicle electronic control module under test according to the set state change events and test cases.

[0025] In embodiments of this disclosure, the continuous integration engine 1200 may include a processor and a memory, the memory being used to store executable computer instructions, and the processor being used to execute the testing method of the vehicle electronic control module of the present disclosure according to the control of the executable computer instructions.

[0026] In addition, the test system 1000 may also include test instruments that are communicatively connected to the continuous integration engine 1200, the test instruments being used to test the on-board electronic control module under the control of the continuous integration engine 1200.

[0027] Those skilled in the art will understand that although multiple devices are involved in the embodiments of this disclosure, the core processing logic is completed by the continuous integration engine 1200. Those skilled in the art can design instructions based on the scheme disclosed in this disclosure; how these instructions control the processor to operate is well known in the art, and therefore will not be described in detail here.

[0028] <Method Implementation> Figure 2 This is a flowchart illustrating a testing method for an in-vehicle electronic control module provided in this embodiment. This testing method can be executed by a continuous integration engine, which can be... Figure 1 The continuously integrated engine 1200 shown can include, for example, an onboard electronic control module such as a power amplifier. Figure 2 As shown, the testing method for the vehicle-mounted electronic control module in this embodiment may include the following steps S210 to S240: Step S210: If a setting state change event is detected, obtain the test file associated with the setting state change event.

[0029] Specifically, a state change event is an event triggered when the state machine of a test task in the test management platform transitions from a first state to a second state, and is used to trigger the test process. For example, the state machine is configured to trigger a state change event when the test task's state transitions from "Approved" to "Pending Execution". The state machine can also include other states such as "Executing", "Completed", and "Failed", but the test process is only triggered when the state transitions from "Approved" to "Pending Execution"; other state transitions do not trigger the test process.

[0030] The test files include the identification information and test cases of the on-board electronic control module under test. The test cases include the corresponding test script execution path and expected results.

[0031] This identification information is used to uniquely identify the vehicle electronic control module under test. For example, the identification information can be the model number of the vehicle electronic control module under test. Through this identification information, the test instrument corresponding to the vehicle electronic control module under test can be accurately matched from the mapping data, avoiding errors introduced by manual configuration.

[0032] This test case defines the test content to be performed on the vehicle electronic control module under test, including the test script execution path and expected results. The test script execution path points to the test scripts stored in the test management platform's test case library. The expected results include the test standards corresponding to each test item.

[0033] In some examples, step S210, upon detecting a setting state change event, may further include: generating a trigger request upon detecting a setting state change event; and retrieving the test file from the test management platform based on the trigger request.

[0034] In this example, when the state machine of a test task in the test management platform transitions from "Approved" to "Pending Execution," the continuous integration engine's state machine mapping engine captures this state change event via a built-in webhook and generates a trigger request. This trigger request can include a task identifier (e.g., task id), a test case identifier (e.g., test_type), a test type (e.g., audio test, thermal test, and load cycle test), and environmental constraint parameters such as temperature (temp) and voltage (voltage). These environmental constraint parameters are used to control the test environment conditions during subsequent test execution.

[0035] For example, the triggering request is: {"ticket_id": "A", "case_set": "FUNC_PERF_RELI_32CH", "test_type": ["audio", "thermal", "load_cycle"], "env_params": {"temp": "-40~85°C", "voltage": "9~16V"}}.

[0036] Here, `ticket_id` is the task identifier, with a value of "A", used to uniquely identify this test task, facilitating subsequent association with test results and updating task status. `case_set` is the test case set identifier, with a value of "FUNC_PERF_RELI_32CH", specifying the set of test cases to be executed. `test_type` is the test type, with values ​​of ["audio", "thermal", "load_cycle"], used to filter the test case set to be executed from the test case set. `env_params` are environmental constraint parameters, with values ​​of {"temp": "-40~85°C", "voltage": "9~16V"}, used to set the environmental conditions during test execution. It should be noted that a test file can contain one or more test cases. When multiple test cases are included, they constitute a test case set (`case_set`). The continuous integration engine can filter and execute matching test cases from the test case set based on the `test_type` field in the trigger request.

[0037] Subsequently, based on the task identifier and test case identifier in the trigger request, the continuous integration engine initiates a data retrieval request to the test management platform via a RESTful API interface to obtain the test files associated with the test task. These test files may include the identification information of the vehicle electronic control module under test, test cases, communication configuration information, and environmental constraint parameters. The test cases include the corresponding test script execution path and expected results. The communication configuration information includes a list of instrument types required for this test task. In these examples, by automatically retrieving test files via a RESTful API interface driven by standardized trigger requests, loosely coupled data interaction between the test requirements management platform and the continuous integration engine can be achieved, avoiding data transmission errors caused by manual intervention and ensuring that test tasks receive timely and accurate responses after changes in their configuration states.

[0038] Step S220: Based on the identification information, determine each test instrument corresponding to the vehicle electronic control module under test, and establish a test link with each test instrument.

[0039] The testing instruments are used to perform various tests on the on-board electronic control module under test. These instruments include, but are not limited to, audio analyzers, DC power supplies, load cells, and oscilloscopes. Different models of the on-board electronic control module under test may require different combinations of testing instruments, which can be dynamically determined based on the identification information.

[0040] The test link refers to the communication connection established between the continuous integration engine and each test instrument. After the test link is established, the continuous integration engine can send control commands to the corresponding test instrument and receive the collected data from it, thereby realizing automated test control of the on-board electronic control module under test.

[0041] It should be noted that after establishing the test link with each test instrument, the continuous integration engine notifies the test management platform to update the status of the test task from "pending execution" to "in execution".

[0042] In some examples, step S220, which identifies the test instruments corresponding to the on-board electronic control module under test based on the identification information and establishes test links with each test instrument, may further include the following steps S221 to S223: Step S221: Obtain the set mapping data.

[0043] The mapping data reflects the correspondence between the identification information of different vehicle electronic control modules and the communication parameters of their corresponding test instruments. These communication parameters may include the communication protocol and hardware address. The communication protocol specifies the protocol type used for communication between the continuous integration engine and the test instruments. The hardware address is used to locate a specific test instrument instance, such as the test instrument's IP address.

[0044] For example, the mapping data can be in JSON format, and one record in the mapping data can be as follows: { “AMP_MODEL”:“A” “NSTRUMENT_MAP”:{ "AP": {"protocol": "SCPI", "ip": "192.168.1.10", "channels": 32}, "LOAD": { "protocol": "MODBUS", "ip": "192.168.1.20", "load_options": [2, 4]}, "POWER":{"protocol":"SCPI","ip":"192.168.1.30"} } } In other words, the continuous integration engine can query the mapping data based on the model of the module under test (e.g., "A") to obtain a list of test instruments and their communication parameters. For example, model "A" requires an audio analyzer (SCPI protocol, IP 192.168.1.10), a load bank (MODBUS protocol, IP 192.168.1.20), and a DC power supply (SCPI protocol, IP 192.168.1.30). The continuous integration engine can load the corresponding protocol conversion driver (SCPI protocol → SCPI parser, MODBUS protocol → Modbus gateway) according to the communication protocol, and then establish communication connections with each instrument through the protocol conversion driver based on the hardware address (IP address), forming a test link.

[0045] Step S222: Query the mapping data based on the identification information to obtain the communication parameters of the test instrument corresponding to the on-board electronic control module under test.

[0046] In this example, the continuous integration engine queries the mapping data based on the identification information of the vehicle electronic control module under test, and can then obtain the communication parameters of each corresponding test instrument.

[0047] Step S223: Establish a test link with the corresponding test instrument through communication parameters.

[0048] In this example, step S223, which establishes a test link with the corresponding test instrument through communication parameters, may further include: loading the corresponding protocol conversion driver according to the communication protocol; and establishing a communication connection with the test instrument through the protocol conversion driver based on the hardware address, thereby forming a test link.

[0049] Through steps S221 to S223 above, the system can automatically determine the matching test instrument combination and establish a communication link based on the identification information of the vehicle electronic control module under test, thereby improving the deployment efficiency of the test system. Furthermore, when adding a new vehicle electronic control module or replacing test instruments, only the mapping data needs to be updated; no modification to the test logic is required, significantly reducing system expansion costs.

[0050] Step S230: Obtain the corresponding test script according to the test script execution path, and control each test instrument through each test link to test the vehicle electronic control module under test and obtain test data based on the test script.

[0051] In this embodiment, the test script refers to the automated test program stored in the test case library of the test management platform, which encapsulates the specific test logic for the vehicle electronic control module under test. The continuous integration engine loads the corresponding test script from the test case library into the execution sandbox according to the test script execution path, and sequentially issues control commands to each test instrument through the established test links, driving each test instrument to execute the test on the vehicle electronic control module under test, and collecting the raw data stream output by each test instrument in real time.

[0052] In some examples, step S230, which obtains the corresponding test script based on the test script execution path and controls each test instrument through each test link to test the on-board electronic control module under test and obtain test data, may further include the following steps S231 to S232: Step S231: Obtain the corresponding test script according to the test script execution path, and control the corresponding test instruments through each test link to test the vehicle electronic control module under test based on the test script, so as to obtain multi-source test data.

[0053] In this example, multi-source test data refers to the raw data streams collected and output by multiple test instruments, such as audio waveform data collected by an audio analyzer, voltage and current data collected by a DC power supply, load impedance data collected by a load box, and ambient temperature data collected by a temperature sensor.

[0054] It's important to note that when a test task involves multiple test channels or various test types, the continuous integration engine uses a pipeline mechanism to break down the test task into multiple parallel subtasks and assigns them to corresponding distributed execution nodes. Execution nodes allocate tasks using a tag matching mechanism; for example, a node labeled "amp_test_node_01" is assigned to perform audio tests. The execution nodes synchronize the test data warehouse status through shared storage, ensuring data consistency and traceability during multi-node execution. Hardware resources employ a semaphore locking mechanism to prevent multiple tasks from competing for the same instrument channel, ensuring the timing determinism of multi-channel testing.

[0055] Step S232: Perform data preprocessing on the multi-source test data to obtain the test data.

[0056] In this example, because each test instrument has an independent clock source, the multi-source test data has deviations on the time axis and may contain noise data caused by abnormal test instrument status or communication interference. Data preprocessing includes data alignment and anomaly filtering. Data alignment can use a Network Time Protocol (NTP) synchronization benchmark, combined with a software interpolation algorithm, to resample the multi-source test data to a unified time axis, with an alignment window accuracy of no more than 10ms. Anomaly filtering identifies and removes abnormal sampling points that exceed a reasonable range, ensuring the accuracy of the test data used for subsequent comparative analysis.

[0057] Based on steps S231 to S232 above, by performing timestamp synchronization and anomaly filtering on the multi-source test data, the time deviation introduced by the independent clock sources of each test instrument is eliminated, and noise data caused by abnormal instrument status or communication interference is removed, ensuring the accuracy and consistency of the test data used in subsequent comparative analysis, and providing a data foundation for the reliability of the test results.

[0058] Step S240: Compare the test data with the corresponding expected results to generate the test results of the vehicle electronic control module under test.

[0059] In this embodiment, the continuous integration engine compares the preprocessed test data with the expected results of each corresponding test item to determine whether each test item passes or fails, and then summarizes the test results for the vehicle electronic control module under test. The test results can be output in the form of structured data tables or displayed in the form of visual charts, making it easy for users to intuitively understand the entire testing process.

[0060] In some examples, this step S240, which compares the test data with the corresponding expected results to generate the test results for the vehicle electronic control module under test, may further include the following steps S241 to S243: Step S241: Compare the test data with the expected results to obtain the comparison results.

[0061] Step S242: Based on the comparison results, generate a structured result set of the on-board electronic control module under test.

[0062] In this example, the structured result set records the execution status (pass / fail), actual value, expected value, and other information of each test item using a standardized data structure, which facilitates subsequent defect analysis and result feedback.

[0063] Step S243: Generate test results based on the structured result set.

[0064] In this example, step S243, which generates test results based on the structured result set, may further include: determining abnormal test items based on the structured result set; obtaining the reproduction path logs corresponding to the abnormal test items; encapsulating the abnormal test items and their corresponding reproduction path logs into defect information; and generating test results based on the defect information and the structured result set.

[0065] Through the above steps S241 to S243, the test data can be automatically compared with the expected results and a structured result set can be generated. When abnormal test items are identified, the reproduction path log is automatically extracted and encapsulated as defect information. There is no need to manually observe the waveform or manually enter the defect, which effectively improves the degree of test automation.

[0066] The method of this disclosure automatically triggers the test process by listening to set state change events, and automatically determines the corresponding test instrument and establishes a test link based on the identification information of the vehicle electronic control module under test. This realizes the automatic association and state synchronization between test files, test cases and test instruments, without the need for manual task creation, environment configuration or instrument switching, which significantly improves test efficiency.

[0067] In some embodiments, after performing the above step S240 to compare the test data with the corresponding expected results and generate the test results of the vehicle electronic control module under test, the testing method of the vehicle electronic control module of this disclosure further includes: transmitting the test results back to the test management platform through an encrypted channel, so as to establish the correlation between the test results and test cases through the test management platform.

[0068] The encrypted channel refers to a secure communication channel established between the continuous integration engine and the test management platform using an encrypted transmission protocol. It is used to ensure the security and integrity of test result data during the transmission process and to prevent the data from being intercepted or tampered with.

[0069] In this embodiment, the continuous integration engine transmits test results back to the test management platform via an encrypted channel. The test management platform can update the status of the test task from "in progress" to "completed," achieving automatic status transition without manual intervention. Simultaneously, based on the transmitted test results, the test management platform automatically establishes an association index between the test results and corresponding test cases, supporting subsequent single-machine traceability, batch trend analysis, and defect tracking management.

[0070] In this embodiment, after the test results are generated, they are sent back to the test management platform through an encrypted channel. This enables the automatic updating of the test task status and the automatic establishment of the association index between test data and test cases. As a result, a complete automated link is built from the triggering of the test task to the closed-loop writing of the results. This eliminates the need for manual updating of the task status and manual association of test data, and further improves the automation level and quality traceability of the test process.

[0071] <Example> Figure 3 This is a flowchart illustrating a test method for an example of an in-vehicle electronic control module, such as... Figure 3 As shown, the test method for the vehicle electronic control module in this example includes the following steps S301 to S310: Step S301: The test management platform creates a test task.

[0072] In step S301, testers can create a test task in a test management platform (such as JIRA), fill in the identification information of the on-board electronic control module under test, and associate it with dedicated test cases. After creation, the test task enters the "approved" status.

[0073] Step S302: When the continuous integration engine detects a setting state change event in the test task, it generates a trigger request.

[0074] In step S302, the continuous integration engine (e.g., Jenkins) listens for status change events of test tasks in the test management platform. When the status of a test task changes from "approved" to "pending execution", the state machine mapping engine of the continuous integration engine captures the status change event through Webhook and generates a trigger request.

[0075] It should be noted that the transition of a test task from "approved" to "pending execution" can be triggered manually by the tester or automatically. That is, regardless of whether automatic or manual triggering is used, it can flexibly adapt to different testing scenario requirements. For example, automatic triggering is suitable for batch testing in the mass production stage, while manual triggering is suitable for single debugging tests in the R&D stage.

[0076] Step S303: The continuous integration engine retrieves test files from the test management platform based on the trigger request; the test files include test cases, and the test cases include the corresponding test script execution path and expected results.

[0077] In step S304, the continuous integration engine identifies the test instruments corresponding to the on-board electronic control module under test and establishes communication links with each test link.

[0078] In step S305, the continuous integration engine obtains the corresponding test script according to the test script execution path, and controls each test instrument through each test link to test the on-board electronic control module under test and obtain test data based on the test script.

[0079] Step S306: The continuous integration engine checks whether the test task is completed. If yes, proceed to step S307; otherwise, proceed to step 310.

[0080] Step S307: The continuous integration engine generates test results based on the test data.

[0081] In step S308, the continuous integration engine sends the test results back to the test management platform via an encrypted channel.

[0082] In step S309, the test management platform updates the status of the test tasks and establishes the correlation between test results and test cases, thus ending the process.

[0083] In step S310, the system automatically retryes or switches to a backup instrument and issues an alarm notification. Then, in step S305, the system controls each test instrument through each test link based on the test script to test the on-board electronic control module under test and obtain test data.

[0084] <Equipment Example> Figure 4 This is a schematic block diagram of the electronic device provided in the embodiments of this disclosure. For example... Figure 4 As shown, the electronic device 4000 includes a processor 4100 and a memory 4200.

[0085] The memory 4200 can be used to store executable computer instructions.

[0086] The processor 4100 can be used to execute the test method for the vehicle electronic control module according to the method embodiments of this disclosure, under the control of the executable computer instructions.

[0087] The electronic device 4000 can be either the first electronic device or the second electronic device.

[0088] Computer-readable storage media This disclosure also provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, perform the testing method for the vehicle electronic control module provided in this disclosure.

[0089] This disclosure can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this disclosure.

[0090] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0091] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0092] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0093] Various aspects of this disclosure are described herein 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 of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0094] These computer-readable 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, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0095] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. It will be known to those skilled in the art that implementation in hardware, implementation in software, and implementation in a combination of software and hardware are equivalent.

[0097] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of this disclosure is defined by the appended claims.

Claims

1. A test method for an on-board electronic control module, characterized in that, The method includes: Upon detecting a setting state change event, obtain the test file associated with the setting state change event; wherein, the test file includes the identification information of the vehicle electronic control module under test and test cases, and the test cases include the corresponding test script execution path and expected results; Based on the identification information, each test instrument corresponding to the vehicle electronic control module under test is identified, and a test link is established between each test instrument. According to the test script execution path, the corresponding test script is obtained, and based on the test script, each of the test instruments is controlled through each of the test links to test the vehicle electronic control module under test and obtain test data. The test data is compared with the corresponding expected results to generate the test results for the vehicle electronic control module under test.

2. The method according to claim 1, characterized in that, The step of obtaining the test file associated with the setting state change event upon detecting a setting state change event includes: Upon detecting a state change event, a trigger request is generated; Based on the trigger request, the test file is obtained from the test management platform.

3. The method according to claim 1, characterized in that, The step of determining each test instrument corresponding to the vehicle electronic control module under test based on the identification information, and establishing a test link with each of the test instruments, includes: Acquire the set mapping data; wherein the mapping data reflects the correspondence between the identification information of different vehicle electronic control modules and the communication parameters of their corresponding test instruments; The mapping data is queried based on the identification information to obtain the communication parameters of the test instrument corresponding to the vehicle electronic control module under test; A test link is established with the corresponding test instrument using the communication parameters.

4. The method according to claim 3, characterized in that, The communication parameters include the communication protocol and hardware address. The step of establishing a test link with the corresponding test instrument through the communication parameters includes: Load the corresponding protocol conversion driver according to the communication protocol; Based on the hardware address, a communication connection is established with the test instrument through the protocol conversion driver, forming the test link.

5. The method according to claim 1, characterized in that, The step of obtaining the corresponding test script according to the test script execution path, and controlling each of the test instruments through each of the test links to test the vehicle electronic control module under test and obtain test data based on the test script includes: According to the test script execution path, the corresponding test script is obtained. Based on the test script, the corresponding test instrument is controlled through each test link to test the vehicle electronic control module under test, and multi-source test data is obtained. The multi-source test data is preprocessed to obtain the test data.

6. The method according to claim 1, characterized in that, The step of comparing the test data with the corresponding expected results to generate the test results for the vehicle electronic control module under test includes: The test data is compared with the expected results to obtain the comparison results; Based on the comparison results, a structured result set of the vehicle electronic control module under test is generated; The test results are generated based on the structured result set.

7. The method according to claim 6, characterized in that, The step of generating the test results based on the structured result set includes: Based on the structured result set, identify the abnormal test items; Obtain the reproduction path logs corresponding to the abnormal test items; The abnormal test items and their corresponding reproduction path logs are encapsulated into defect information; The test results are generated based on the defect information and the structured result set.

8. The method according to claim 1, characterized in that, After generating the test results for the vehicle electronic control module under test, the method further includes: The test results are transmitted back to the test management platform through an encrypted channel, so as to establish the association between the test results and the test cases through the test management platform.

9. An electronic device, characterized in that, include: Memory is used to store executable computer instructions; A processor, configured to execute the test method for the vehicle electronic control module according to any one of claims 1-8, under the control of the executable computer instructions.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the test method for the vehicle electronic control module according to any one of claims 1-8.

Images