Uds diagnostic service automated testing method, apparatus and device

Abstract

This disclosure provides an automated testing method, apparatus, and device for UDS diagnostic services. The method includes: acquiring a test case file corresponding to the ECU under test; wherein the test case file includes at least one test case, and the test case includes test case identification information and diagnostic instructions for each test step; reading the test case file based on a parameterized decorator of the Pytest testing framework, determining the test cases to be executed according to the test case identification information, extracting the diagnostic instructions for each test step from the test cases to be executed, converting the extracted diagnostic instructions into CAN messages conforming to the UDS protocol, and sending the CAN messages to the ECU under test through CAN hardware; receiving a response message returned by the ECU under test based on the CAN messages, obtaining the judgment result of the corresponding test step according to the response message, and generating a test report corresponding to the ECU under test based on the judgment results of each test step after all test steps of the test cases to be executed have been completed.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle testing technology, and more specifically, to an automated testing method, apparatus, and equipment for UDS diagnostic services. Background Technology

[0002] During the research and development and testing phase of automotive electronic control systems, Unified Diagnostic Services (UDS) serves as the core protocol for diagnosing onboard electronic control units (ECUs), and the effectiveness of its diagnostic services directly impacts the functional reliability of the ECUs.

[0003] In related technologies, UDS diagnostic service testing often relies on manual operation or semi-automated scripts. Test cases are usually stored in unstructured form, requiring manual parsing and execution of diagnostic instructions one by one. This is not only inefficient but also prone to human error leading to biased test results. Furthermore, the UDS diagnostic requirements of ECUs vary across different vehicle models. Existing testing solutions have poor hardware adaptability and scalability, making it difficult to quickly adapt to different CAN hardware devices and ECU diagnostic scenarios, and thus unable to meet the needs of large-scale, automated UDS diagnostic service testing. Summary of the Invention

[0004] One objective of this disclosure is to provide a new technical solution for automated testing of UDS diagnostic services.

[0005] According to a first aspect of this disclosure, an automated testing method for UDS diagnostic services is provided, comprising: Obtain the test case file corresponding to the ECU under test; wherein, the test case file includes at least one test case, and the test case includes test case identification information and diagnostic instructions for each test step; The parameterized decorator based on the Pytest testing framework reads the test case file, determines the test cases to be executed according to the test case identification information, extracts the diagnostic instructions for each test step from the test cases to be executed, converts the extracted diagnostic instructions into CAN messages conforming to the UDS protocol, and sends the CAN messages to the ECU under test through CAN hardware. The system receives a response message returned by the ECU under test based on the CAN message, obtains the judgment result of the corresponding test step according to the response message, and generates a test report corresponding to the ECU under test based on the judgment result of each test step after all test steps of the test case to be executed have been completed; wherein the test report includes the execution result of each test case to be executed.

[0006] Optionally, obtaining the use case file corresponding to the ECU under test includes: Obtain a list of test cases corresponding to the ECU under test; wherein the list of test cases includes at least one test case; The test case list is parsed into a JSON format test case file using a conversion tool.

[0007] Optionally, the test case may also include expected response data for the test steps. The step of receiving the response message returned by the ECU under test based on the CAN message, and obtaining the judgment result corresponding to the test step based on the response message, includes: Receive the response message returned by the ECU under test based on the CAN message; Parse the response message to obtain the actual response data; The actual response data is compared with the corresponding expected response data to obtain the judgment result for each test step.

[0008] Optionally, the test case may also include the waiting time for the test step. The method further includes: Wait according to the waiting time corresponding to the current test step; When the waiting time is reached, the step of converting the extracted diagnostic instructions into CAN messages conforming to the UDS protocol is executed.

[0009] Optionally, the test report includes a first test report and a second test report. The first test report includes at least one of the following: the total number of test cases executed, the number of skipped test cases, the number of passed test cases, the number of failed test cases, the execution result of each test case, the reason for failure of each failed test case, and the overall test execution time; The second test report includes at least one of the following: test case execution trend chart, failed test case classification statistics chart, test step-level log details, test case pass rate statistics chart, and test case execution time distribution chart.

[0010] Optionally, the method further includes: During the test execution, log information is recorded in real time; wherein, the log information includes at least one of the following: timestamp information of the time when the operation occurs, log level, CAN bus status, UDS request message sent to the ECU under test, UDS response message received from the ECU under test, and the judgment result of each test step; The recorded log information is stored in the corresponding log files according to the date attribute.

[0011] Optionally, the method further includes: After the test is completed, delete the Pytest cache directory and Python compilation cache files generated during this test. Based on the preset log retention policy, clean up historical log files or expired test reports before a set date.

[0012] Optionally, the step of sending the CAN message to the ECU under test via CAN hardware and receiving the response message returned by the ECU under test is performed by a communication adapter module. The communication adaptation module includes a wrapper layer for the CAN hardware dynamic library. The wrapper layer provides standardized message sending and receiving interfaces to adapt to different CAN hardware.

[0013] According to a second aspect of this disclosure, an automated testing apparatus for UDS diagnostic services is provided, comprising: The acquisition module is used to acquire the test case file corresponding to the ECU under test; wherein, the test case file includes at least one test case, and the test case includes test case identification information and diagnostic instructions for each test step; The test module is used to read the test case file based on the parameterized decorator of the Pytest test framework, determine the test cases to be executed according to the test case identification information, extract the diagnostic instructions for each test step from the test cases to be executed, convert the extracted diagnostic instructions into CAN messages conforming to the UDS protocol, and send the CAN messages to the ECU under test through CAN hardware. The generation module is configured to receive the response message returned by the ECU under test based on the CAN message, obtain the judgment result of the corresponding test step according to the response message, and generate a test report corresponding to the ECU under test based on the judgment result of each test step after all test steps of the test case to be executed have been completed; wherein, the test report includes the execution result of each test case to be executed.

[0014] According to a third aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory being used to store an executable computer program; the computer program being used to control the processor to perform the method according to a first aspect of this disclosure.

[0015] The automated testing method for UDS diagnostic services in this embodiment relies on the Pytest testing framework to achieve automated testing of UDS diagnostic services. By reading and filtering test case files with identification information through parameterized decorators, it achieves standardized, structured management and precise invocation of test cases, reduces operational errors caused by manual intervention, and significantly improves test execution efficiency. At the same time, it converts diagnostic commands into CAN messages that conform to the UDS protocol and sends them through CAN hardware, ensuring the standardization and adaptability of communication with the ECU under test, adapting to the UDS diagnostic testing needs of different ECUs, and meeting the large-scale and batch testing needs of vehicle ECU UDS diagnostic services.

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

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

[0018] Figure 1 A block diagram illustrating a hardware configuration of an electronic device that can implement embodiments of the present disclosure is shown; Figure 2 This is a flowchart illustrating an automated testing method for UDS diagnostic services according to an embodiment of the present disclosure; Figure 3 This is a block diagram of an automated testing apparatus for UDS diagnostic services according to an embodiment of the present disclosure; Figure 4 This is a block diagram of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0019] Various exemplary embodiments of the present invention 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 invention.

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

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

[0022] 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.

[0023] 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.

[0024] <Hardware Configuration> Figure 1 A block diagram of the hardware configuration of an electronic device 1000 that can implement embodiments of the present disclosure is shown.

[0025] Electronic device 1000 can be a portable computer, desktop computer, mobile phone, tablet computer, etc. For example... Figure 1 As shown, the electronic device 1000 may include a processor 1100, a memory 1200, an interface device 1300, a communication device 1400, a display device 1500, an input device 1600, a speaker 1700, a microphone 1800, etc. The processor 1100 may be a central processing unit (CPU), a microprocessor (MCU), etc. The memory 1200 may include, for example, ROM (Read-Only Memory), RAM (Random Access Memory), or non-volatile memory such as a hard disk. The interface device 1300 may include, for example, a USB interface, a headphone jack, etc. The communication device 1400 may be capable of wired or wireless communication, specifically including Wi-Fi communication, Bluetooth communication, 2G / 3G / 4G / 5G communication, etc. The display device 1500 may be, for example, an LCD screen, a touch screen, etc. The input device 1600 may include, for example, a touch screen, a keyboard, motion input, etc. Users can input / output voice information through the speaker 1700 and the microphone 1800.

[0026] Figure 1 The electronic devices shown are merely illustrative and in no way intended to limit this disclosure, its application, or use. In embodiments applied to this disclosure, the memory 1200 of the electronic device 1000 is used to store instructions for controlling the processor 1100 to operate and execute any of the UDS diagnostic service automated testing methods provided in embodiments of this disclosure. Figure 1 The electronic device 1000 is shown with multiple devices shown; however, this disclosure may relate only to some of these devices. For example, electronic device 1000 may only relate to processor 1100 and storage device 1200. Those skilled in the art can design instructions based on the schemes disclosed herein. How the instructions control the processor to operate is well known in the art and will not be described in detail here.

[0027] <Method Implementation> This disclosure provides an automated testing method for UDS diagnostic services, applied to electronic devices, which may be... Figure 1The electronic device shown is 1000. (For example...) Figure 2 As shown, the automated testing method for the UDS diagnostic service includes the following steps S2100 to S2300.

[0028] Step S2100: Obtain the test case file corresponding to the ECU under test.

[0029] The test case file may include at least one test case. The test case file may be a structured file that stores all UDS diagnostic test cases of the ECU under test, usually in JSON (JavaScript Object Notation) format.

[0030] Each test case may include test case identification information and diagnostic instructions for each test step.

[0031] The aforementioned test case identification information can be a unique identifier for each test case. This test case identification information can, for example, reflect the UDS diagnostic service type, test scenario, and test case number corresponding to the test case. It can serve as the basis for subsequent screening of test cases to be executed, enabling test cases to be executed on demand.

[0032] The diagnostic instructions for the above test steps can be segmented operation flows of a single test case, and a test case can contain at least one test step. The diagnostic instructions are the UDS protocol instructions that need to be sent to the ECU under test in each test step. The diagnostic instructions of different test steps are executed according to preset logic to jointly complete the full process test of the corresponding UDS diagnostic service.

[0033] The test cases described above may also include the expected response data for each test step and the waiting time for each test step. The waiting time for each test step can be a dedicated delay parameter configured for a single test step of the ECU under test.

[0034] In one embodiment, step S2100, obtaining the test case file corresponding to the ECU under test, may further include: obtaining a list of test cases corresponding to the ECU under test; and parsing the list of test cases into a JSON format test case file by setting a conversion tool.

[0035] The test case list is an Excel-formatted spreadsheet file (testcase.xlsx) compiled based on the UDS diagnostic protocol specification and diagnostic service test requirements of the ECU under test. It is a visually editable test case file. This test case list can include at least one UDS diagnostic service test case for the ECU under test, and each test case can be configured with test case identification information, diagnostic instructions for each test step, expected response data for the corresponding test step, and waiting time. It can fully cover all execution requirements of a single UDS diagnostic service test and adapt to different types of UDS diagnostic service test requirements of the ECU under test, such as 0x10 diagnostic session control and 0x22 reading data by identifier.

[0036] In this embodiment, the test case management module can use a conversion tool such as excel_to_json.py to read all test cases from an Excel-formatted test case list. Following a structured rule of key-value pairs and nested arrays, it converts the test case list into a JSON-formatted test case file. This format conversion between the Excel test case list and the JSON test case file achieves a balance between the convenience of manual writing and the adaptability of program execution, while ensuring the consistency of the test case data.

[0037] After executing step S2100 to obtain the test case file corresponding to the ECU under test, proceed to: Step S2200: The parameterized decorator based on the Pytest testing framework reads the test case file, determines the test cases to be executed according to the test case identification information, extracts the diagnostic instructions for each test step from the test cases to be executed, converts the extracted diagnostic instructions into CAN messages conforming to the UDS protocol, and sends the CAN messages to the ECU under test through CAN hardware.

[0038] In this embodiment, this step is the core execution link of the UDS diagnostic automated test, which is completed by the test execution module and the communication adaptation module in collaboration to realize the full-process automation of test case retrieval, instruction conversion and message sending.

[0039] In one embodiment, the above steps read the test case file based on the parameterized decorator of the Pytest testing framework, determine the test cases to be executed according to the test case identification information, and extract the diagnostic instructions for each test step from the test cases to be executed, which can be executed through the test execution model.

[0040] Specifically, the main test file `test_uds.py` of the test execution module reads the JSON-formatted test case file through the parameterized decorator `@pytest.mark.parametrize` of the Pytest testing framework, and accurately selects the test cases to be executed by combining this with the test case identification information. The `simple_test_runner.py` script of the Pytest testing framework triggers this execution flow, realizing the on-demand retrieval of test cases.

[0041] In one embodiment, the above steps of sending CAN messages to the ECU under test via CAN hardware and receiving response messages returned by the ECU under test can be performed by a communication adapter module.

[0042] In this embodiment, the communication adaptation module includes a wrapper layer for the CAN hardware dynamic library. The wrapper layer can provide standardized message sending and receiving interfaces to adapt to CAN hardware from different manufacturers.

[0043] Specifically, the main test file `test_uds.py` of the test execution module extracts the diagnostic instructions for each test step in the test cases to be executed. It then calls the communication adaptation module to complete a two-layer conversion: the first layer is based on the UDS protocol structure defined in the Python module `zuds_structure.py`, encapsulating the diagnostic instructions into standardized UDS data packets via the dynamic link library `zuds.dll`; the second layer converts the UDS data packets into CAN messages conforming to the CAN bus specification by calling the encapsulation interface provided by the dynamic link library `zlgcan.dll` through the Python module `zlgcan.py`. Subsequently, the communication adaptation module sends the CAN messages to the ECU under test via the message sending interface provided by `zlgcan.py` to execute the current test step.

[0044] After executing the above steps, S2200 reads the test case file based on the parameterized decorator of the Pytest test framework, determines the test cases to be executed according to the test case identification information, extracts the diagnostic instructions for each test step from the test cases to be executed, converts the extracted diagnostic instructions into CAN messages conforming to the UDS protocol, and sends the CAN messages to the ECU under test through CAN hardware, then proceeds to: Step S2300: Receive the response message returned by the ECU under test based on the CAN message, obtain the judgment result of the corresponding test step according to the response message, and after all test steps of the test case to be executed are completed, generate a test report corresponding to the ECU under test based on the judgment result of each test step.

[0045] The test report includes the execution results of each test case to be executed.

[0046] In one embodiment, the test case further includes expected response data for the test steps. This step S2300, receiving the response message returned by the ECU under test based on the CAN message and obtaining the judgment result corresponding to the test step based on the response message, can be implemented in the following way: receiving the response message returned by the ECU under test based on the CAN message; parsing the response message to obtain the actual response data; comparing the actual response data with the corresponding expected response data to obtain the judgment result for each test step.

[0047] Specifically, when the ECU under test executes the test steps and returns a response message, the communication adaptation module captures the response message through the message receiving interface provided by zlgcan.py, then calls zuds.dll to parse the response message into standardized UDS response data, and then sends it back to the main test file test_uds.py of the test execution module to parse the response message to obtain the actual response data, and compares the actual response data with the expected response data corresponding to the test step, thereby obtaining the judgment result of the test step.

[0048] Once all test steps within a test case have been executed, the test execution module sends the evaluation results of each test step to the report generation module. After all pending test cases have been executed, the report generation module, based on the received evaluation results of each test step, comprehensively determines the execution result of each test case (e.g., pass, fail, or skip), and generates a complete test report. This test report includes the identification information of each pending test case and its corresponding execution result, allowing testers to quickly understand the overall status of the test.

[0049] Through the embodiments disclosed herein, automated testing of UDS diagnostic services is achieved based on the Pytest testing framework. By reading and filtering test case files with identification information through parameterized decorators, standardized and structured management and precise invocation of test cases are realized, reducing operational errors caused by manual intervention and significantly improving test execution efficiency. At the same time, diagnostic commands are uniformly converted into CAN messages conforming to the UDS protocol and sent through CAN hardware, ensuring the standardization and adaptability of communication with the ECU under test, adapting to the UDS diagnostic testing needs of different ECUs, and meeting the large-scale and batch testing needs of vehicle ECU UDS diagnostic services.

[0050] In one embodiment, the test case also includes a waiting time for the test step. The UDS diagnostic service automated testing method of this disclosure embodiment may further include: waiting according to the waiting time corresponding to the current test step; and when the waiting time is reached, performing the step of converting the extracted diagnostic instructions into CAN messages conforming to the UDS protocol.

[0051] This embodiment introduces a test step-level waiting time configuration mechanism, which can adapt to ECU response timing requirements and enhance the flexibility and maintainability of test cases.

[0052] In one embodiment, the test report may include a first test report and a second test report. The first test report may be an HTML report generated by the HTML plugin of the Pytest testing framework, such as test_report_*.html. The second test report may be an Allure report generated by the Allure framework, such as allure-report, which is typically a visual report.

[0053] The first test report shall include at least one of the following: the total number of test cases executed, the number of skipped test cases, the number of passed test cases, the number of failed test cases, the execution result of each test case, the reason for failure of each failed test case, and the overall test execution time; The second test report includes at least one of the following: test case execution trend chart, failed test case classification statistics chart, test step-level log details, test case pass rate statistics chart, and test case execution time distribution chart.

[0054] It should be noted that when generating the second test report, the report generation module will automatically back up the previously generated Allure reports to prevent the newly generated report from overwriting the previous report and causing data loss.

[0055] Through the aforementioned dual-reporting mechanism, this embodiment provides both a concise and intuitive summary of test results and multi-dimensional visual analysis data, making it easier for testers to quickly locate problems and analyze test trends.

[0056] In one embodiment, the UDS diagnostic service automated testing method of this disclosure may further include: recording log information in real time during test execution; and storing the recorded log information into corresponding log files according to date attributes.

[0057] The log information includes at least one of the following: timestamp information of the time when the operation occurred, log level, CAN bus status, UDS request message sent to the ECU under test, UDS response message received from the ECU under test, and the judgment result of each test step.

[0058] In this embodiment, during the test execution process, log information can be recorded through the log module, and the recorded log information can be stored in the corresponding log files according to the date attribute, which facilitates retrieval and tracing by time period.

[0059] The logging module can be implemented using the Python module log_utils.py, and it typically supports logging levels, which can include DEBUG, INFO, WARNING, and ERROR. Generally, DEBUG can record the finest-grained debugging information, critical process information of test execution, WARNING can record abnormal situations that may affect the test results but do not cause the test to fail, and ERROR can record serious errors that cause test steps to fail.

[0060] Through the aforementioned logging mechanism, key operations and communication data during the testing process are fully preserved, facilitating testers' ability to review the test execution process. When an anomaly occurs during testing, the log files can be used to quickly pinpoint the time of the problem, the specific request and response messages, and the failure steps, thereby effectively improving troubleshooting efficiency. Furthermore, storing log files by date avoids the difficulty of searching due to excessively large single log files and also facilitates long-term storage and retrieval of historical test records by time period.

[0061] In one embodiment, the UDS diagnostic service automated testing method of this disclosure may further include: after the test is completed, deleting the Pytest cache directory and Python compilation cache files generated during the test; and cleaning up historical log files or expired test reports before a set date according to a preset log retention policy.

[0062] In this embodiment, after the test is completed, the Pytest cache directory and Python compilation cache files generated during the test can be deleted through the environment cleanup module, and historical log files or expired test reports before a set date can be cleaned up according to the preset log retention policy.

[0063] Specifically, the environment cleanup module can be implemented by cleanup_unnecessary_files.py, which supports one-click cleanup of the test environment. This module can automatically delete the Pytest cache directory (.pytest_cache) and Python compilation cache files (pycache). At the same time, users can configure cleanup strategies according to their needs to regularly clean up historical log files and expired test reports, thereby freeing up disk space and keeping the project directory clean and orderly.

[0064] <Device Embodiment> This disclosure also provides an automated testing device 300 for UDS diagnostic services, such as... Figure 3 As shown, the UDS diagnostic service automated testing device 300 includes an acquisition module 310, a testing module 320, and a generation module 330.

[0065] The acquisition module 310 is used to acquire the test case file corresponding to the ECU under test; wherein, the test case file includes at least one test case, and the test case includes test case identification information and diagnostic instructions for each test step; Test module 320 is used to read the test case file based on the parameterized decorator of the Pytest test framework, determine the test cases to be executed according to the test case identification information, extract the diagnostic instructions for each test step from the test cases to be executed, convert the extracted diagnostic instructions into CAN messages conforming to the UDS protocol, and send the CAN messages to the ECU under test through CAN hardware. The generation module 330 is configured to receive the response message returned by the ECU under test based on the CAN message, obtain the judgment result of the corresponding test step according to the response message, and generate a test report corresponding to the ECU under test based on the judgment result of each test step after all test steps of the test cases to be executed have been completed; wherein, the test report includes the execution result of each test case to be executed.

[0066] In one embodiment, the acquisition module 310 is specifically used to acquire a list of test cases corresponding to the ECU under test; wherein the list of test cases includes at least one test case; and the test case list is parsed into a test case file in JSON format by setting a conversion tool.

[0067] In one embodiment, the test case further includes expected response data for the test steps. A generation module 330 is specifically used to receive a response message returned by the ECU under test based on the CAN message; parse the response message to obtain actual response data; and compare the actual response data with the corresponding expected response data to obtain the judgment result for each test step.

[0068] In one embodiment, the test case further includes a waiting time for the test step, and the test module 320 is further configured to wait according to the waiting time corresponding to the current test step; when the waiting time is reached, the extracted diagnostic instructions are converted into CAN messages conforming to the UDS protocol.

[0069] In one embodiment, the test report includes a first test report and a second test report. The first test report includes at least one of the following: the total number of test cases executed, the number of skipped test cases, the number of passed test cases, the number of failed test cases, the execution result of each test case, the reason for failure of each failed test case, and the overall test execution time; The second test report includes at least one of the following: test case execution trend chart, failed test case classification statistics chart, test step-level log details, test case pass rate statistics chart, and test case execution time distribution chart.

[0070] In one embodiment, the device 300 further includes a log module (not shown in the figure). The log module is used to record log information in real time during test execution; wherein the log information includes at least one of the following: timestamp information of the time when the operation occurs, log level, CAN bus status, UDS request message sent to the ECU under test, UDS response message received from the ECU under test, and the judgment result of each test step; the recorded log information is stored in corresponding log files according to the date attribute.

[0071] In one embodiment, the device 300 further includes a cleanup module (not shown in the figure), which is used to delete the Pytest cache directory and Python compilation cache files generated during the test after the test is completed; and to clean up historical log files or expired test reports before a set date according to a preset log retention policy.

[0072] In one embodiment, the step of sending the CAN message to the ECU under test via CAN hardware and receiving the response message returned by the ECU under test is performed by a communication adapter module. The communication adaptation module includes a wrapper layer for the CAN hardware dynamic library. The wrapper layer provides standardized message sending and receiving interfaces to adapt to different CAN hardware.

[0073] <Electronic Devices> In this embodiment, an electronic device 400 is also provided, such as... Figure 4 As shown, it includes a memory 420 and a processor 410.

[0074] The memory 420 is used to store an executable computer program; the computer program is used to control the processor 410 to execute any of the UDS diagnostic service automated testing methods provided in this embodiment.

[0075] In this embodiment, the electronic device 400 may be Figure 1 The electronic device 1000 shown may also be a device with other hardware structures, which is not limited here.

[0076] In another embodiment, the electronic device 400 may include the above-mentioned UDS diagnostic service automated testing device 300.

[0077] Computer-readable storage media In this embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the method as described in any embodiment of this disclosure.

[0078] This invention 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 the invention.

[0079] 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.

[0080] 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.

[0081] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state 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 be executed 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 state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0082] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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.

[0083] 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.

[0084] 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.

[0085] 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 invention. 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 using a combination of software and hardware are equivalent.

[0086] The various embodiments of the present invention 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 the invention is defined by the appended claims.

Claims

1. An automated testing method for UDS diagnostic services, characterized in that, include: Obtain the test case file corresponding to the ECU under test; wherein, the test case file includes at least one test case, and the test case includes test case identification information and diagnostic instructions for each test step; The parameterized decorator based on the Pytest testing framework reads the test case file, determines the test cases to be executed according to the test case identification information, extracts the diagnostic instructions for each test step from the test cases to be executed, converts the extracted diagnostic instructions into CAN messages conforming to the UDS protocol, and sends the CAN messages to the ECU under test through CAN hardware. The system receives a response message returned by the ECU under test based on the CAN message, obtains the judgment result of the corresponding test step according to the response message, and generates a test report corresponding to the ECU under test based on the judgment result of each test step after all test steps of the test case to be executed have been completed; wherein the test report includes the execution result of each test case to be executed.

2. The method according to claim 1, characterized in that, The step of obtaining the test case file corresponding to the ECU under test includes: Obtain a list of test cases corresponding to the ECU under test; wherein the list of test cases includes at least one test case; The test case list is parsed into a JSON format test case file using a conversion tool.

3. The method of claim 1, wherein, The test cases also include expected response data for the test steps. The step of receiving the response message returned by the ECU under test based on the CAN message, and obtaining the judgment result corresponding to the test step based on the response message, includes: Receive the response message returned by the ECU under test based on the CAN message; Parse the response message to obtain the actual response data; The actual response data is compared with the corresponding expected response data to obtain the judgment result for each test step.

4. The method according to any one of claims 1 to 3, characterized in that, The test cases also include the waiting time for the test steps. The method further includes: Wait according to the waiting time corresponding to the current test step; When the waiting time is reached, the step of converting the extracted diagnostic instructions into CAN messages conforming to the UDS protocol is executed.

5. The method according to any one of claims 1 to 3, characterized in that, The test report includes a first test report and a second test report. The first test report includes at least one of the following: the total number of test cases executed, the number of skipped test cases, the number of passed test cases, the number of failed test cases, the execution result of each test case, the reason for failure of each failed test case, and the overall test execution time; The second test report includes at least one of the following: test case execution trend chart, failed test case classification statistics chart, test step-level log details, test case pass rate statistics chart, and test case execution time distribution chart.

6. The method according to any one of claims 1 to 3, characterized in that, The method further includes: During the test execution, log information is recorded in real time; wherein, the log information includes at least one of the following: timestamp information of the time when the operation occurs, log level, CAN bus status, UDS request message sent to the ECU under test, UDS response message received from the ECU under test, and the judgment result of each test step; The recorded log information is stored in the corresponding log files according to the date attribute.

7. The method according to any one of claims 1 to 3, characterized in that, The method further includes: After the test is completed, delete the Pytest cache directory and Python compilation cache files generated during this test. Based on the preset log retention policy, clean up historical log files or expired test reports before a set date.

8. The method according to any one of claims 1 to 3, characterized in that, The process of sending the CAN message to the ECU under test via CAN hardware and receiving the response message returned by the ECU under test is executed through the communication adapter module. The communication adaptation module includes a wrapper layer for the CAN hardware dynamic library. The wrapper layer provides standardized message sending and receiving interfaces to adapt to different CAN hardware.

9. A UDS diagnostic service automation testing apparatus characterized by, include: The acquisition module is used to acquire the test case file corresponding to the ECU under test; wherein, the test case file includes at least one test case, and the test case includes test case identification information and diagnostic instructions for each test step; The test module is used to read the test case file based on the parameterized decorator of the Pytest test framework, determine the test cases to be executed according to the test case identification information, extract the diagnostic instructions for each test step from the test cases to be executed, convert the extracted diagnostic instructions into CAN messages conforming to the UDS protocol, and send the CAN messages to the ECU under test through CAN hardware. The generation module is configured to receive the response message returned by the ECU under test based on the CAN message, obtain the judgment result of the corresponding test step according to the response message, and generate a test report corresponding to the ECU under test based on the judgment result of each test step after all test steps of the test case to be executed have been completed; wherein, the test report includes the execution result of each test case to be executed.

10. An electronic device, comprising: include: Memory is used to store executable computer instructions; A processor configured to perform the method according to any one of claims 1-8, under the control of the executable computer instructions.

Images