Automated testing method and system, electronic device

Abstract

The application belongs to the technical field of automobile electronic testing, and particularly relates to an automatic testing method and system and an electronic device, wherein the automatic testing method comprises the following steps: when a test triggering event is monitored, a continuous integration tool generates a starting signal to a test execution framework to trigger the test execution framework to start; when a predefined test case is executed, the test execution framework calls a corresponding interface in a function interface encapsulation layer to drive a test tool to send a test request to a device to be tested and receive test response data returned by the test tool; and the test execution framework verifies the test response data and generates a test report.

Description

Cross-reference to related applications

[0001] This application is based on and claims priority to Chinese Patent Application No. 2025105919951, filed May 9, 2025, and Chinese Patent Application No. 2025112051214, filed August 27, 2025. The entire contents of the above applications are incorporated herein by reference. Technical Field

[0002] This invention relates to the field of automotive electronics testing technology, and more particularly to an automated testing method and system, and electronic equipment. Background Technology

[0003] Currently, in automotive electronics development, testing tools are commonly used for ECU diagnostic function verification, CAN / LIN bus communication monitoring, and signal interaction testing. Existing solutions rely on manual operation, requiring testers to manually execute test steps through the diagnostic console and message sending module of the testing tool, including configuring hardware interfaces, loading the diagnostic database, sending diagnostic requests, and comparing response data. While this can meet the needs of basic function verification, troubleshooting, and on-site debugging, it has also revealed significant limitations and drawbacks in long-term project execution. Especially in high-volume, high-frequency, and long-term testing scenarios, manual testing exhibits problems such as poor test stability, large test errors, and lack of traceability in the test process.

[0004] Therefore, there is an urgent need to design a solution that can replace the existing manual testing.

[0005] It should be noted that the information disclosed in this background section is only for understanding the background technology of the present application concept, and therefore, the above description is not considered to constitute prior art information. Summary of the Invention

[0006] The purpose of this invention is to provide an automated testing method, system, and electronic device.

[0007] To address the aforementioned technical problems, this invention provides an automated testing method, comprising: When a test trigger event is detected by the continuous integration tool, the test execution framework is started. The test execution framework invokes corresponding interfaces in the functional interface encapsulation layer when executing predefined test cases, driving the test tool to send test requests to the device under test and receive test response data returned by the test tool; and The test execution framework is used to verify the test response data and generate a test result file.

[0008] In another aspect, the present invention also provides an automated testing system, including at least one computer device, wherein the at least one computer device is configured to include: The continuous integration tool is configured to generate a start signal to the test execution framework upon detecting a test trigger event, thereby triggering the test execution framework to start; and / or, The test execution framework is configured to start upon a start signal and, when executing predefined test cases, call the corresponding interfaces in the functional interface encapsulation layer to send test-driven signals to the test tool; and verify the test response data returned by the test tool and generate test result files; and / or, The testing tool is configured to send a test request to the device under test based on the test drive signal, and to send test response data back to the test execution framework.

[0009] Thirdly, the present invention also provides a non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the automated testing method as described above.

[0010] Fourthly, the present invention also provides an electronic device, comprising: Non-transitory computer-readable storage medium; processor; The non-transitory computer-readable storage medium stores instructions that, when executed by a processor, cause the processor to perform the automated testing method as described above.

[0011] Fifthly, the present invention also provides a computer program product, including instructions that, when executed by a processor, cause the processor to perform the automated testing method as described above.

[0012] The beneficial effects of this invention are that the automated testing method of this invention deeply integrates testing tools with test execution frameworks and continuous integration tools, and sets up a functional interface encapsulation layer between the test execution framework and testing tools. This abstracts the complex low-level operations of testing tools into standardized interfaces, providing a simple and unified operation entry point for the upper-level test execution framework. As a result, the entire process of test triggering, execution, and report generation is automated, completely replacing traditional manual testing. This significantly improves testing efficiency and consistency, and is especially suitable for high-volume, high-frequency, and long-term testing scenarios in the automotive electronics field.

[0013] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0014] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0015] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 The steps of the automated testing method involved in some embodiments are shown in the diagram; Figure 2 A schematic diagram of an automated testing system according to some embodiments is shown; Figure 3 A schematic block diagram of an automated testing system according to another implementation of some embodiments is shown; Figure 4 A schematic block diagram of an electronic device involved in some embodiments is shown. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Currently, in automotive electronics development, testing tools are commonly used for ECU diagnostic function verification, CAN / LIN bus communication monitoring, and signal interaction testing. Existing solutions rely on manual operation, requiring testers to manually execute test steps through the diagnostic console and message sending module of the testing tool, including configuring hardware interfaces, loading the diagnostic database, sending diagnostic requests, and comparing response data. While this can meet the needs of basic function verification, troubleshooting, and on-site debugging, it has also revealed significant limitations and drawbacks in long-term project execution. Especially in high-volume, high-frequency, and long-term testing scenarios, manual testing exhibits problems such as poor test stability, large test errors, and lack of traceability in the test process.

[0019] Therefore, at least one embodiment provides an automated testing method, including: generating a start signal to a test execution framework when a test trigger event is detected by a continuous integration tool, triggering the test execution framework to start; calling the corresponding interface in the functional interface encapsulation layer when executing predefined test cases through the test execution framework, so as to drive the test tool to send a test request to the device under test and receive test response data returned by the test tool; and verifying the test response data and generating a test report through the test execution framework.

[0020] The automated testing method in this embodiment deeply integrates testing tools with test execution frameworks and continuous integration tools, and sets up a functional interface encapsulation layer between the test execution framework and testing tools. This abstracts the complex low-level operations of testing tools into standardized interfaces, providing a simple and unified operation entry point for the upper-level test execution framework. As a result, the entire process of test triggering, execution, and report generation is automated, completely replacing traditional manual testing. This significantly improves testing efficiency and consistency, and is especially suitable for high-volume, high-frequency, and long-term testing scenarios in the automotive electronics field.

[0021] The various non-limiting embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings.

[0022] like Figure 1 As shown, this embodiment provides an automated testing method, including: Step S101: When the continuous integration tool detects a test trigger event, it generates a start signal to the test execution framework, triggering the test execution framework to start. Step S102: When executing predefined test cases, the test execution framework calls the corresponding interface in the functional interface encapsulation layer to drive the test tool to send test requests to the device under test and receive test response data returned by the test tool; and Step S103: Verify the test response data and generate a test result file using the test execution framework.

[0023] Specifically, this embodiment sets up a functional interface encapsulation layer between the test execution framework and the test tools, abstracting the complex low-level operations of the test tools into standardized interfaces. This provides a simple and unified operation entry point for the upper-level test execution framework, achieving complete decoupling between test logic and tool implementation. Furthermore, with deep integration of the test tools, test execution framework, and continuous integration tools, the entire process of test triggering, execution, and report generation is automated.

[0024] In some embodiments, the test execution framework is the Pytest test execution framework; the continuous integration tool is the Jenkins continuous integration tool.

[0025] In some embodiments, the testing tool is the TSMaster testing tool.

[0026] In some embodiments, the functional interface encapsulation layer includes one or more of the following: a file loading and initialization interface, a communication control interface, a diagnostic service processing interface, a signal reading and writing interface, and an abnormal scenario simulation interface.

[0027] Specifically, a functional interface encapsulation layer is introduced between the TSMaster testing tool and the test execution framework. This layer abstracts various functional operations of the TSMaster testing tool into unified, callable interfaces. The functional interface encapsulation layer includes: 1) File loading and initialization interface: It is used to load existing TSMaster project files according to the specified path and initialize the test environment.

[0028] The following is a partial pseudocode example of calling the interface for file loading and initialization: def open_tsmaster(self,ProjectPath,timeout=20): projectpath = ProjectPath if os.path.exists(projectpath): commond = f'cmd / c start "" "{projectpath}"' subprocess.run(commond, shell=True) # subprocess.run(['cmd', ' / c', 'start',self.GetTypedProperty('TSMaster_Project_Path')]) ACount = 0 while (not self.tsmaster_is_open(ProjectPath)) and (ACount <timeout): ACount += 1 time.sleep(1) self.tsmaster_is_open(ProjectPath) time.sleep(WAITTIME) return True return False Where ProjectPath is the project path; Timeout is the startup wait time.

[0029] 2) Communication control interface: Its function is to control the start and stop of physical or virtual bus communication throughout the entire test process.

[0030] The following is a partial pseudocode example of using the communication control interface to start and stop communication: s32 rpc_tsmaster_cmd_start_simulation(const native_int AHandle){ return internal_rpc_tsmaster_cmd_start_simulation(FObj, AHandle); } s32 rpc_tsmaster_cmd_stop_simulation(const native_int AHandle){ return internal_rpc_tsmaster_cmd_stop_simulation(FObj, AHandle); } AHandle is the TSMaster RPC client handle; rpc_tsmaster_cmd_start_simulation is the communication startup function; rpc_tsmaster_cmd_stop_simulation is the communication stop function.

[0031] 3) Diagnostic service processing interface: Its function is to provide the standard UDS diagnostic request and response processing process, including service ID setting, data field population, sending and receiving, and parsing of returned data.

[0032] The following is a partial pseudocode example of calling the diagnostic service processing interface: s32 tstp_request_and_get_response(const s32 ADiagModuleIndex, constpu8 AReqDataArray,const s32 AReqDataSize, const pu8 AResponseDataArray,constps32 AResponseDataSize){ return internal_can_request_and_get_response(FObj, ADiagModuleIndex,AReqDataArray, AReqDataSize, AResponseDataArray,AResponseDataSize); } Where ADiagModuleIndex is the UDS module handle; AReqDataArray is a pointer to the data source of the request; AReqDataSize is the size (in bytes) of the data source array; AResponseDataArray is a pointer to the data buffer of the response data; and AResponseDataSize is a pointer to an integer value used to store the size of the response data.

[0033] 4) Signal read / write interface: Its function is to read the current signal value by name and write the target signal value.

[0034] The following is a partial pseudocode example of implementing signal writing using the signal read / write interface: s32 rpc_tsmaster_cmd_write_signal(const native_int AHandle, constTLIBApplicationChannelType ABusType, char* AAddr, const double AValue){ return internal_rpc_tsmaster_cmd_write_signal(FObj, AHandle,ABusType, AAddr, AValue); } Where AHandle is the TSMaster RPC client handle; ABusType is the bus type; AAddr is the address of the signal in the database; and AValue is the value to be written.

[0035] The following is a partial pseudocode example of implementing signal reading using the signal read / write interface: s32 rpc_tsmaster_cmd_read_signal(const native_int AHandle, constTLIBApplicationChannelType ABusType, char* AAddr, pdouble AValue){ return internal_rpc_tsmaster_cmd_read_signal(FObj, AHandle, ABusType,AAddr, AValue); } Where AHandle is the TSMaster RPC client handle; ABusType is the bus type; AAddr is the address of the signal in the database; and Avalue is the value read.

[0036] 5) Interface for simulating abnormal scenarios: Its function is to simulate specific error states by calling the fault injection or interference function of the TSMaster testing tool in a parameterized manner.

[0037] The following is a partial pseudocode example of calling the interface for simulating abnormal scenarios: import time import threading import random flag = 0 def busy_work(): while True: if flag == 1: break a = random.randint(10**1000, 10**1001 - 1) b = random.randint(10**1000, 10**1001 - 1) c = a * b if __name__ == "__main__": processes = [] for i in range(4): p = threading.Thread(target=busy_work) processes.append(p) p.start() time.sleep(3600) flag = 1 for p in processes: p.join() Specifically, the functional interface encapsulation layer also includes a resource release interface; wherein the resource release interface is used to close communication, unload the project and release COM objects when the test ends or exits abnormally, ensuring that system resources are properly reclaimed.

[0038] In some embodiments, when the test execution framework calls the corresponding interface in the functional interface encapsulation layer while executing predefined test cases, the functional interface encapsulation layer communicates with the test tool through the COM interface of the test tool.

[0039] Specifically, this embodiment mainly relies on the COM interface provided by the TSMaster testing tool, enabling the functional interface encapsulation layer to communicate with the TSMaster testing tool through the COM interface, thereby realizing remote control of the functions of the TSMaster testing tool. That is, it can directly access the core capabilities of the TSMaster testing tool, such as bus communication management, diagnostic service calls, signal acquisition, and device interaction.

[0040] Specifically, the functional interface encapsulation layer only exposes business interfaces related to testing, hiding the complex details of the underlying interface calls of the TSMaster testing tool. When running test cases, the pytest test execution framework calls the business interfaces provided by the functional interface encapsulation layer to achieve standard calls to the COM interface of the TSMaster testing tool. The COM interface acts as a bridge for inter-process communication, passing instructions to the TSMaster testing tool. Ultimately, the TSMaster testing tool executes actual bus communication, diagnostic service processing, signal reading and writing, and other hardware interaction functions, allowing test logic writers to focus on test case design without having to worry about the specific implementation of the TSMaster testing tool.

[0041] In some embodiments, the test triggering events include: code commit events and scheduled task triggering events.

[0042] Specifically, the code commit event can be generated when test-related personnel commit the latest version of test case code to the Git code repository; the scheduled task trigger event can be pre-set by test-related personnel.

[0043] Specifically, the code commit event and the scheduled task trigger event will automatically trigger the Jenkins continuous integration tool to start the test execution framework through the task scheduling mechanism. The task scheduling mechanism includes: a task named `poll` queries the version management server's HTTP interface for version update information in a polling manner. After detecting a version update, it automatically triggers the execution of a task named `TSMaster`. The execution of the `TSMaster` task includes: sequentially running the `uninstall.py` task to uninstall the old version of TSMaster, running the `wgetPackage.py` task to download the latest version installation package, and running the `install.bat` task to install the new version. After the task scheduling is completed, the test trigger signal is sent to the test execution framework by running the `TSRunTestcases.py` task, thereby triggering the start of the test execution framework.

[0044] By monitoring test trigger events through Jenkins continuous integration tools, test results are directly linked to specific code commits, enabling rapid identification of "whose code" caused "which test" to fail, making the tracing and maintenance path very clear.

[0045] The following section describes in detail the automated testing process using the ECU (Electronic Control Unit) bus testing scenario in the automotive electronics field. Assume an automotive electronics R&D team is developing an engine control ECU and needs to automate the testing of its CAN bus communication function and diagnostic response logic. The complete application flow of the method in this embodiment is as follows: First, the developers submit the latest version of the ECU control program code to the Git code repository. The update event of the code repository automatically triggers the Jenkins continuous integration tool to immediately start the preset test job. The test job will automatically read the preset running parameters, including: the TSMaster project file path (corresponding to the CAN bus configuration project of the ECU), the test case filtering conditions (only execute the test cases related to "ECU diagnostic communication"), and the test result output directory (the specified report folder of the Jenkins server), and then start the task invocation.

[0046] After the Jenkins continuous integration tool completes task scheduling, it passes the test trigger signal to the pytest test execution framework. The pytest framework immediately starts and establishes a stable connection with the TSMaster test tool through the file loading and initialization interface of the functional interface encapsulation layer. Simultaneously, it loads the specified ECU bus configuration project, completing the initialization of the test environment. After initialization, the pytest framework calls each functional interface of the functional interface encapsulation layer according to the predefined test cases. First, it sends an "ECU wake-up" message to the TSMaster test tool through the communication control interface of the functional interface encapsulation layer. Upon receiving the command, the TSMaster test tool simulates the wake-up signal of the automotive CAN bus and sends a wake-up command to the ECU under test. The functional interface encapsulation layer collects the bus data fed back by the TSMaster test tool in real time and sends it back to the pytest framework. After verifying that the wake-up status of the ECU under test is normal, the pytest framework proceeds to the next test step. Next, the pytest framework initiates an ECU diagnostic ID read request to the TSMaster test tool through the diagnostic service processing interface of the functional interface encapsulation layer. The TSMaster test tool converts this request into a standard CAN diagnostic message and sends it to the ECU under test. After the ECU under test returns a diagnostic ID response, the TSMaster... The TSMaster test tool captures response data and sends it back through the functional interface encapsulation layer. The pytest test execution framework compares the response with the preset standard diagnostic ID to verify its correctness. Subsequently, the test cases continue to control the TSMaster test tool to send CAN signals under different operating conditions (such as engine speed signal and throttle opening signal) through the functional interface encapsulation layer, while monitoring the feedback signal values ​​of the ECU under test. The functional interface encapsulation layer sends the signal change data and bus communication logs collected by the TSMaster test tool back to the pytest test execution framework in real time, and the pytest test execution framework completes the real-time verification and recording of the signal values. During the test, if a signal value exceeds the preset range, the pytest test execution framework will immediately trigger breakpoint recording and notify the TSMaster test tool to pause bus signal transmission through the functional interface encapsulation layer, which will facilitate developers in locating the problem later. After all test cases are executed, the pytest test execution framework stops connecting with the TSMaster test tool. After the test is completed, the pytest test execution framework summarizes all test data and generates standardized result files according to the preset file format. The Jenkins continuous integration tool automatically collects the result files after detecting the completion of the test task and converts them into a visual report for publication, so that testers can view and analyze them later. This completes the entire automated testing process.

[0047] The automated testing method in this embodiment ensures that the entire process, from code version release, test triggering, execution, result analysis to report output, is unattended while maintaining complete traceability.

[0048] like Figure 2 As shown, some embodiments provide an automated testing system, including at least one computer device configured to include: The continuous integration tool is configured to generate a start signal to the test execution framework upon detecting a test trigger event, thereby triggering the test execution framework to start; and / or, The test execution framework is configured to start upon a start signal and, when executing predefined test cases, call the corresponding interfaces in the functional interface encapsulation layer to send test-driven signals to the test tool; and verify the test response data returned by the test tool and generate test result files; and / or, The testing tool is configured to send test requests to the device under test based on the test drive signal, and to send test response data back to the test execution framework. Specifically, as one implementation of an automated testing system, the continuous integration tool, test execution framework, and test tools in this embodiment can be deployed on the same computer device. This method is simple to configure and suitable for scenarios with stable test environments and a large number of test tasks.

[0049] For details on the working methods or principles of continuous integration tools, test execution frameworks, and test tools, please refer to the previous description of automated testing methods; they will not be repeated here.

[0050] like Figure 3 As shown, as another implementation of the automated testing system, the continuous integration tool, test execution framework and test tool in this embodiment can also be deployed on different computer devices. Each computer device communicates and schedules tasks through network connection. After the computer devices form a communication connection, they can realize the corresponding test functions. This method has high resource utilization and supports large-scale parallel testing.

[0051] The electronic devices in the embodiments of this disclosure are described below from the perspective of hardware processing: The embodiments disclosed herein do not limit the specific implementation of the electronic device.

[0052] like Figure 4As shown, some embodiments also provide an electronic device, including: a processor, a non-transitory computer-readable storage medium, a communication bus, and a communication interface; wherein the processor, the non-transitory computer-readable storage medium, and the communication interface communicate with each other through the communication bus; the non-transitory computer-readable storage medium stores instructions that, when executed by the processor, cause the processor to perform the aforementioned automated testing method.

[0053] In some embodiments, computer devices, industrial control computers, and servers can also be considered as electronic devices.

[0054] Figure 4 The diagram shows a schematic structure of an electronic device, which is for illustration only and does not constitute a limitation on the electronic device. The electronic device may include fewer or more components than shown, or may combine components, or may use different component arrangements.

[0055] In some embodiments, the communication interface may include physical interfaces such as RS-232, RS-485, and USB (including Type-C) for connecting external devices or bus adapters; it may also include wired network interfaces such as Ethernet, or wireless network interfaces such as Wi-Fi and Bluetooth for establishing communication connections between computer devices and other electronic devices.

[0056] In some embodiments, non-transitory computer-readable storage media include, but are not limited to, flash memory, hard disks, magnetic storage, magnetic disks, optical disks, and card-type storage (e.g., multimedia cards, secure digital storage (SD) cards, etc.). In some embodiments, the storage medium can serve as an internal storage unit of a computer device, such as a built-in hard disk; in other embodiments, it can serve as an external storage device, such as a plug-in hard disk, a smart memory card (SMC), a secure digital storage (SD) card, a flash memory card, etc. Furthermore, the storage medium may also include both internal storage units and external storage devices. This storage medium can be used to store application software and various types of data (e.g., computer program code) installed on the computer device, and can also be used to temporarily store data that has been output or will be output.

[0057] In some embodiments, the processor may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip, used to run program code in a storage medium and / or process data, such as executing a computer program.

[0058] In some embodiments, the communication bus can be an input / output bus, such as a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. This bus can be categorized into an address bus, a data bus, and a control bus.

[0059] Optionally, the computer device also includes a user interface. The user interface may include a display, an input unit (e.g., a keyboard), and standard wired and / or wireless interfaces. Optionally, the display (or display module) may be an LED display, a liquid crystal display, a touch-screen liquid crystal display, or an OLED display. The display (or display module) may also be referred to as a screen or display unit, used to display information processed by the computer device and present a visual user interface.

[0060] When the processor executes the program, it implements the above. Figure 1 The steps in the automated testing method embodiments shown. Alternatively, the processor executes the computer program to implement the functions of each module or unit in the above-described device embodiments.

[0061] Some embodiments also provide a non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the automated testing method described above.

[0062] Please refer to the detailed description of the automated testing methods; they will not be repeated here.

[0063] Some embodiments also provide a computer program product including instructions that, when executed by a processor, cause the processor to perform the aforementioned automated testing method.

[0064] In some embodiments, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and embedded 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 code containing one or more executable instructions for implementing a specified logical function. It should also be noted that 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 a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action.

[0065] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0066] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This embedded software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of the present invention.

[0067] Based on the above-described preferred embodiments of the present invention, and through the foregoing description, those skilled in the art can make various changes and modifications without departing from the inventive concept. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. An automated testing method, characterized in that, include: When a test trigger event is detected by the continuous integration tool, a start signal is generated to the test execution framework to trigger the test execution framework to start. The test execution framework invokes corresponding interfaces in the functional interface encapsulation layer when executing predefined test cases, driving the test tool to send test requests to the device under test and receive test response data returned by the test tool; and The test execution framework is used to verify the test response data and generate a test result file.

2. The automated testing method according to claim 1, characterized in that, The functional interface encapsulation layer includes one or more of the following: file loading and initialization interface, communication control interface, diagnostic service processing interface, signal reading and writing interface, and abnormal scenario simulation interface.

3. The automated testing method according to claim 1, characterized in that, The test triggering events include: code submission events and scheduled task triggering events.

4. The automated testing method according to claim 1, characterized in that, The test execution framework is the pytest test execution framework; the continuous integration tool is the Jenkins continuous integration tool; and The testing tool is TSMaster.

5. The automated testing method according to claim 1, characterized in that, When the test execution framework calls the corresponding interface in the functional interface encapsulation layer during the execution of predefined test cases, the functional interface encapsulation layer communicates with the test tool process through the COM interface of the test tool.

6. An automated testing system, characterized in that, Includes at least one computer device, and the at least one computer device is configured to include: The continuous integration tool is configured to generate a start signal to the test execution framework upon detecting a test trigger event, thereby triggering the test execution framework to start; and / or, The test execution framework is configured to start upon a start signal and, when executing predefined test cases, call the corresponding interfaces in the functional interface encapsulation layer to send test-driven signals to the test tool; and verify the test response data returned by the test tool and generate test result files; and / or, The testing tool is configured to send a test request to the device under test based on the test drive signal, and to send test response data back to the test execution framework.

7. The automated testing system according to claim 6, characterized in that, The functional interface encapsulation layer includes one or more of the following: file loading and initialization interface, communication control interface, diagnostic service processing interface, signal reading and writing interface, and abnormal scenario simulation interface.

8. The automated testing system according to claim 6, characterized in that, The test triggering events include: code submission events and scheduled task triggering events.

9. The automated testing system according to claim 6, characterized in that, The test execution framework is the pytest test execution framework; the continuous integration tool is the Jenkins continuous integration tool; and The testing tool is TSMaster.

10. A non-transitory computer-readable storage medium, characterized in that, The system stores instructions that, when executed by a processor, cause the processor to perform the automated testing method according to any one of claims 1-5.

11. An electronic device, characterized in that, include: Non-transitory computer-readable storage medium; processor; The non-transitory computer-readable storage medium stores instructions that, when executed by a processor, cause the processor to perform the automated testing method according to any one of claims 1-5.

12. A computer program product, characterized in that, Includes instructions that, when executed by a processor, cause the processor to perform the automated testing method according to any one of claims 1-5.

Images