WO2019134113A1

WO2019134113A1 - Automated test method and system

Info

Publication number: WO2019134113A1
Application number: PCT/CN2018/071522
Authority: WO
Inventors: 王明亮; 余维应; 朱明�; 谢龙
Original assignee: 深圳市汇顶科技股份有限公司
Priority date: 2018-01-05
Filing date: 2018-01-05
Publication date: 2019-07-11
Also published as: CN110235393A

Abstract

The present application relates to the technical field of testing. Provided are an automated test method and system. The automated test method comprises: identifying a communication path of each device to be tested connected to a test host; acquiring, from pre-set test configuration information, several devices to be tested which correspond to at least one test task; burning, by means of the communication path of each device to be tested, the test task into each device to be tested which corresponds to the test task; controlling each device to be tested so that same executes the burned test task; and acquiring, by means of the communication path of each device to be tested, feedback data generated by each device to be tested executing the test task. Further provided is an automated test system. In the present application, multi-task testing of multiple devices to be tested can be implemented, thereby improving testing efficiency and saving development and testing costs of the devices to be tested.

Description

Automated test method and system

Technical field

The present application relates to the field of testing technology, and in particular, to an automated testing method and system.

Background technique

Microcontroller Unit (MCU), also known as Single Chip Microcomputer or Single Chip Microcomputer, has a wider range of applications as MCU control functions continue to improve. When designing an MCU development board, designers need to test their functions through the test host.

The inventor has found that at least the following problems exist in the prior art: (1) it is necessary to manually check the connection status between the test host and the MCU development board and issue a test task, and manually identify the serial port number corresponding to the MCU development board to obtain the test result; 2) Each test host can only test one MCU development board. If you need to test multiple development boards, you need multiple test hosts.

Summary of the invention

The purpose of some embodiments of the present application is to provide an automated test method and system, which can implement multi-task testing of multiple devices to be tested, thereby improving test efficiency and saving development and testing costs of the device under test.

An embodiment of the present application provides an automated test method, which is applied to a test host. The automated test method includes: identifying a communication path of each device to be tested connected to the test host; and obtaining at least one test from the preset test configuration information. a plurality of devices to be tested corresponding to the task; the test task is burned to each device to be tested corresponding to the test task through the communication path of each device to be tested; and each test device is controlled to execute the burned test task; The feedback data generated by each test device to perform the test task is obtained through the communication path of each device under test.

The embodiment of the present application further provides an automated test system, including: a test host having multiple connection ports and a plurality of intermediate connection modules, and each intermediate connection module has a burning function; the number of connection ports is the same as the number of intermediate connection modules. And each connection port is connected to a device under test through an intermediate connection module; the test host is configured to perform the automated test method of any one of claims 1 to 11.

Compared with the prior art, the embodiment of the present application can automatically identify the communication path between the test host and each device under test, and burn the test task to each of the test tasks through the communication path of each device under test. The device to be tested; that is, supports multi-tasking, and allows multiple devices to be tested to perform testing at the same time; realizes multi-task testing of multiple devices to be tested, thereby improving test efficiency and saving development and testing of devices to be tested cost.

In addition, the communication path includes a burn-in path and a data feedback path; the test task is burned to each device to be tested corresponding to the test task through the communication path of each device to be tested, specifically: through each device to be tested Burning the path, burning the test task to each device to be tested corresponding to the test task; obtaining the feedback data generated by each test device to perform the test task through the communication path of each device to be tested, specifically: passing each The data feedback path of the device under test acquires the feedback data generated by each test device to perform the test task. This embodiment provides a specific implementation manner of a communication path.

In addition, the feedback data includes a test log; before controlling each device under test to perform the burned test task, the method further includes: determining whether the data feedback path of each device to be tested is in a normal communication state; when the judgment result is yes, entering The step of controlling each test device to perform a burned test task. In this embodiment, after the data feedback path is confirmed to be normal, the test task is allowed to be executed on the device to be tested, so that the test log generated in real time when the device under test performs the test task cannot be fed back to the test host in time.

In addition, before acquiring the at least one device to be tested corresponding to the at least one test task, the method further includes: generating an executable file of the test task according to the test configuration information; and adopting a communication path of each device to be tested The test task is burned to each device to be tested corresponding to the test task, specifically: the executable file of the test task is burned to each device to be tested corresponding to the test task through the communication path of each device to be tested. In this embodiment, the executable file of the test task can be automatically generated according to the test configuration information.

In addition, generating the executable file of the test task according to the test configuration information, specifically: obtaining at least one test case corresponding to the test task from the test configuration information; obtaining the program code of the test case from the code base; and generating the test by using the test code of the test case The set of test cases for the task; compile the test case set for the test task to generate the executable file for the test task. The embodiment provides a specific implementation manner of generating an executable file according to the test configuration information, that is, if the test case is pre-established with the program code of the test case in the code base, the test case can be automatically obtained. The program code to generate a test case set of the test task, thereby generating an executable file of the test task; without manually integrating the program code of each test case to generate a test case set as in the prior art, thereby saving labor costs and improving The efficiency.

In addition, the test configuration information is obtained by the following methods, including: providing a test configuration interface; and receiving test configuration information through the test configuration interface. This embodiment provides an acquisition manner of test configuration information.

In addition, the test configuration information is obtained by: setting, when the preset task trigger event occurs, setting the test configuration information according to the task trigger event. This embodiment provides another method for obtaining test configuration information, which can automatically generate test configuration information.

In addition, the task triggering event includes at least one of the following events: a code upload event, a code merge event, and a regression test event. This embodiment provides a specific type of task triggering event.

In addition, the test task is N, and N is an integer greater than 1. The test task is burned to each device to be tested corresponding to the test task through the communication path of each device to be tested, and includes: each test task Put into the task queue of each device to be tested corresponding to the test task; wherein the task queue of each device to be tested includes K test tasks arranged in sequence; wherein K is an integer and 0<K≤N; The communication path of the device under test, the test task is burned to each device to be tested corresponding to the test task, specifically: the K in the task queue of each device under test through the communication path of each device under test The test tasks are sequentially burned to the device under test. This embodiment provides a specific implementation manner of performing testing of multiple test tasks on the device to be tested.

In addition, after obtaining the feedback data generated by each device under test to perform the test task, the method further includes: generating a test report of each device to be tested according to the feedback data of each device to be tested. In this embodiment, a test report of each device to be tested is generated according to the feedback data, which facilitates comparison of differences between multiple devices to be tested.

In addition, before the test task is burned to each device to be tested corresponding to the test task by using the communication path of the device to be tested, the method further includes: initializing each device to be tested corresponding to the test task. In this embodiment, the device to be tested is initialized before burning, and the previously stored data in the device under test is prevented from affecting the obtained feedback data of the test.

DRAWINGS

The one or more embodiments are exemplified by the accompanying drawings in the accompanying drawings, and FIG. The figures in the drawings do not constitute a scale limitation unless otherwise stated.

1 is a detailed flow chart of an automated test method in accordance with a first embodiment of the present application;

2 is a flow chart showing specific details of an automated test method in accordance with a first embodiment of the present application;

3 is a specific flowchart of an executable file for generating a test task according to the first embodiment of the present application;

4 is a specific flowchart of a method for generating test configuration information according to a second embodiment of the present application;

FIG. 5 is a specific flowchart of an automated test method according to a third embodiment of the present application; FIG.

Figure 6 is a block schematic diagram of an automated test system in accordance with a fourth embodiment of the present application.

Detailed ways

In order to make the objects, the technical solutions and the advantages of the present application more clear, some embodiments of the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting.

The first embodiment of the present application relates to an automated test method, which is applied to a test host, and the test host is used to test a plurality of devices to be tested. The device under test may be an MCU-based development board or an MCU-based terminal.

The specific process of the automated test method in this embodiment is as shown in FIG. 1 and includes the following steps:

Step 101: Identify a communication path of each device to be tested connected to the test host.

Step 102: Obtain, from the preset test configuration information, a plurality of devices to be tested corresponding to at least one test task.

Step 103: Burn the test task to each device to be tested corresponding to the test task by using the communication path of each device to be tested.

Step 104: Control each test device to perform a burned test task.

Step 105: Obtain feedback data generated by each test device to perform a test task by using a communication path of each device to be tested.

Compared with the prior art, the embodiment can automatically identify the communication path between the test host and each device under test, and burn the test task to each test corresponding to the test task through the communication path of each device under test. In the test equipment; that is, support multi-tasking, and allow multiple devices to be tested to test at the same time; achieve multi-task test of multiple devices under test, thereby improving test efficiency and saving development and test costs of the device under test .

The implementation details of the automated testing method of this embodiment are specifically described below. Please refer to FIG. 2, and the following content is only for the implementation details provided for convenience of understanding, and is not necessary for implementing the solution.

In step 101, specifically, the test host is connected to a plurality of devices to be tested, and the communication path between the test host and each device to be tested includes a burn path and a data feedback path, and the test host can identify each to be connected thereto. Test the device's burning path and data feedback path. After the test host identifies the burn path and the data feedback path, communication is established between the test host and the device under test.

Preferably, after step 101, the method further includes:

Step 101', generating an executable file of the test task according to the test configuration information.

Specifically, test configuration information is pre-stored in the test host, and the test configuration information includes N test tasks, where N is an integer greater than 1. Each test task includes at least the test case to be executed and the device under test to perform the test task. Preferably, the test task also includes a code base in which the test case is located. It should be noted that when each test case is stored in the same code base, it is not necessary to mark the code base for each test case in the test task (the system can set the code base by default); however, when each test case is stored in a different When you use the code base, you need to tag the code base for each test case in the test task.

The test configuration information may be generated by: the test host provides a test configuration interface, and the designer inputs test configuration information through the test configuration interface. For example, the designer selects all the test cases that need to be used in the test configuration interface (each test case has a corresponding code); then, the designer creates each test task; that is, sets the name of each test task (for example, Test task 1, test task 2, etc.), and set the test cases required for each test task and the device under test to perform the test task; preferably, the designer also sets the code base for the test case. .

Preferably, after the test configuration information is obtained, the test configuration information is integrated into a document and the document is serialized for storage.

It should be noted that only the execution sequence of step 101' and step 101 is schematically illustrated in Fig. 2, that is, before step 101, step 101' may be executed to generate an executable file of the test task based on the test configuration information.

In this embodiment, referring to FIG. 3, step 101' generates an executable file of the test task according to the test configuration information, which specifically includes:

Sub-step 1011' obtains at least one test case corresponding to the test task from the test configuration information.

Specifically, each test task includes a test case to be executed, so that the test host can obtain at least one test case corresponding to the test task from the test configuration information.

Sub-step 1012' obtains the program code of the test case from the code base.

Specifically, when the code library is not marked in each test case in the test task, the code library of the system default setting may be entered and the program code of each test case may be obtained; if each test case in the test task has been marked with the code base , enter the code base corresponding to each test case and obtain the program code of each test case.

Sub-step 1013' generates a test case set for the test task using the program code of the test case.

Specifically, the test host automatically pulls the program code of the test case corresponding to the test task from the code base, and assembles the program code of each test case as a test case set of the test task.

It should be noted that, in the prior art, the test case set of the test task is manually collected by manually assembling the program codes of the test cases; therefore, the technical solution in the embodiment saves labor compared to the prior art. Cost and increase efficiency.

Sub-step 1014' compiles the test case set of the test task to generate an executable file of the test task.

Specifically, the test case set of the test task is compiled and packaged to generate an executable file of the test task.

In the step 102, the test configuration information includes a device to be tested that performs each test task, so that the test host can acquire a plurality of devices to be tested corresponding to each test task.

Preferably, after step 102, the method further includes:

In step 102', each test task is placed in the task queue of each device to be tested corresponding to the test task.

Specifically, each device to be tested corresponds to several test tasks, that is, each device under test needs to perform K test tasks to complete the test of its own function, where K is an integer and 0<K≤N; each The type and quantity (K value) of the test task corresponding to the device to be tested is determined by the function required for the device to be tested. The test host allocates a task queue for each device to be tested, and puts each test task into the task queue of the object to be tested corresponding to the test task, that is, the task queue of each device to be tested includes K tests arranged in sequence. task.

It should be noted that the task queue in this embodiment includes K test tasks arranged in sequence, and the task queue is dynamically maintained by the test host, and the order of the K test tasks can be put into the test queue according to the task priority and the test task. The time of the task is arranged. The priority of the task priority is greater than the task creation time. The specific arrangement is as follows: the test tasks are arranged in order according to the task priority, and the test tasks with high task priority are arranged in front of the task queue, and the priority is executed; If the priorities are the same, the test tasks are placed in the test queue. The test tasks that are placed in the test queue are listed in the front and are executed first.

In step 103, specifically, the test host issues a programming command, and sequentially executes the executable files of the K test tasks according to the programming path of each of the K test tasks in the task queue through the burning path of each device under test. Recorded in each corresponding device to be tested. The executable file of the test task can be burned to the running memory or flash memory of the device under test.

In addition, before the test task is burned into each corresponding device to be tested, each device to be tested corresponding to the test task is generally initialized, specifically: before the device to be tested for the first time is required to be burned. Initializing the device to be tested includes, for example, resetting the state of the device under test, starting the system clock of the device under test, and performing calibration, etc., to provide a basic environment for execution of the test task. Moreover, after the execution of the previous test task is completed, before the next test task is burned, the test host also resets the device to be tested, that is, the executable file of the previous test task is cleared, and the previous test task is executed when executed. Relevant data, etc., to avoid erroneous feedback data caused by interference in the burning and execution of the next test task.

In step 104, specifically, the test host issues a start test command to control the execution of the burned test task in each device under test.

In step 105, specifically, the test host obtains corresponding feedback data through the data feedback path when the device under test performs the test task, and the feedback data includes any one or any combination of the following: test log, test result, and device to be tested. Register value. The test log includes all the test operations performed by the device under test to perform the test task in real time, so as to track the positioning according to the test log; the test result may be the test success or the test failure; the register value of the device to be tested is the test host after obtaining the test result. , the obtained register value of the device under test.

Preferably, after step 105, the method further includes:

Step 105', generating a test report of each device to be tested according to the feedback data of each device under test.

Specifically, after the test device performs its corresponding test task, the test host summarizes the feedback data of each device to be tested, and generates a test report of each device to be tested, which is convenient for performing multiple test devices. Difference comparison. For each device to be tested, the test report corresponding to each test task may be generated immediately after each test task in the task queue is executed, or after all the test tasks in the task queue are tested. Perform a summary to obtain a test report corresponding to the device to be tested.

In this embodiment, the task queue of each device to be tested includes K test tasks. Taking any device under test as an example, the device under test executes one test task in the task queue in sequence, and is burned in one test task. After recording the device under test and executing it, the test host will receive the test result of the test task (you can confirm the test is completed); then, the test host checks the next test task in the task queue, clearing the device under test and the previous one. Test the task-related data (test file executable file, register value, etc.), then burn the next test task to the device under test and test until the test task in the task queue is tested.

The technical solution of this embodiment will be described below with a specific example. In this example, the test configuration information can be as shown in Table 1 below:

Table 1

In addition, the task queue of the device D1 to be tested is the test task 4, the test task 1, the test task 3; the task queue of the device D2 to be tested is the test task 1, the test task 2, the test task 3; the task queue of the device D3 to be tested is Test task 2, test task 3, test task 4.

During the test, the test host first identifies the communication path with the device under test D1, the device under test D2, and the device under test D3, and generates an executable file of test task 1 to test task 4; subsequently, obtains test task 1 to test The device to be tested corresponding to task 4, and put test task 1 to test task 4 into the task queue of the corresponding device under test.

Take the device D1 to be tested as an example to illustrate the specific process of the test host controlling the device under test to perform the test task. The task queue of the device D1 to be tested is test task 4, test task 1, and test task 3. After the test host initializes the device D1 to be tested, the executable file of the test task 4 is burned to the device under test D1, and is controlled. The test device D1 executes the test task 4, and simultaneously obtains the test log when the test task 4 is executed; after the test task 4 is executed, the test host receives the test result of the test task (the test can be confirmed); then, the test host checks The next test task (ie, test task 1) exists in the task queue, and the data related to the test task 4 in the device D1 to be tested (the executable file of the test task 4, the register value, etc.) is cleared, and then the test task 1 is burned. Recorded in the device under test D1 and tested until the test tasks in the task queue are tested.

The second embodiment of the present application relates to an automated testing method. The present embodiment is substantially the same as the first embodiment. The main difference is that in this embodiment, another method for generating test configuration information is provided.

In this embodiment, a specific process of the method for generating test test configuration information is shown in FIG. 4 .

Step 201: Detect whether a trigger event of a preset task occurs. If yes, go to step 202; otherwise, go back to step 201.

Specifically, the task triggering event includes at least one of the following events: a code upload event, a code merge event, and a regression test event. When the test host detects that the preset task triggering event occurs, the process proceeds to step 202; otherwise, the process returns to step 201 until it is detected that the preset task triggering event occurs.

When the designer adds a certain function to the device to be tested, the development code of the device to be tested is uploaded to the code transfer space, which is a code upload event; when the development code uploaded into the code transfer space is confirmed The development code is incorporated into the code base, which is the code integration event; when the program code of a test case in the code library is modified, the test case needs to be re-executed to confirm that the modification does not introduce a new error or cause other The code generates an error, which is a regression test event.

Step 202: Set test configuration information according to the task trigger event.

Specifically, the test configuration information is generated by generating a test task according to the task trigger event and a test case corresponding to the test task and the device to be tested to be executed.

In this embodiment, the test host automatically generates test configuration information according to the task trigger event through the continuous integration tool; preferably, based on the continuous integration tool, the test host can also automatically send the generated test report to the test through the mail. Personnel and designers to enable testers and designers to obtain test reports in the first place.

Compared with the first embodiment, this embodiment provides another generation manner of test configuration information, which can automatically generate test configuration information.

The third embodiment of the present application relates to an automated test method. The present embodiment is an improvement on the basis of the first embodiment. The main improvement is: in this embodiment, whether the data feedback path of the device to be tested is in a normal communication state. Make a judgment.

In this embodiment, the feedback data includes a test log, and the specific process of the automated test method is shown in FIG. 5.

The steps 301 to 303 are substantially the same as the steps 101 to 103. The steps 305 to 306 ′ are substantially the same as the steps 104 to 105 ′, and are not described here. The main difference is that step 304 is added, as follows. :

Step 304: Determine whether the data feedback path of each device under test is in a normal communication state. If yes, go to step 305; if no, go to step 304 again.

After the test host identifies the data feedback path, it establishes communication with the device under test; when the establishment is completed, the device under test can perform data feedback through the data feedback path. Since the test log records the real-time data of the process of performing the test task on the device under test (that is, the test log starts to be generated when the device under test starts to execute the test task), if the test device starts to perform the test task, the test host and the test host If the devices under test have not been successfully established, some test logs will be lost.

Therefore, for each device to be tested, it is required to determine whether the data feedback path of the device under test is in a normal communication state before performing the burned test task. When the determination result is yes, proceed to step 305 to control the device to be tested. Executing the burned test task; otherwise, the communication connection of the data feedback path of the device under test has not been successfully established, and step 304 is performed again until the data feedback path of the device under test is in a normal communication state, and then proceeds to step 305. .

Compared with the first embodiment, the embodiment can confirm that the data feedback path can communicate normally, and then allow the test task to be executed on the device under test, so as to prevent the test log generated by the device under test from being executed in real time. Feedback to the test host in a timely manner. It should be noted that the present embodiment can also be used as an improvement on the basis of the second embodiment, and the same technical effects can be achieved.

The fourth embodiment of the present application relates to an automated test system. Referring to FIG. 6, the automated test system includes a test host 1 having a plurality of connection ports 11 and a plurality of intermediate connection modules. Among them, each intermediate connection module has a burning function. It should be noted that, in FIG. 6, the test host 1 has two connection ports 11 as an example, but this embodiment does not impose any limitation.

In this embodiment, each intermediate connection module includes a USB hub 21 and a writer 22, and the programming function is implemented by the programmer 22; the USB hub 21 has four USB ports, which are respectively a USB port 211, a USB port 212, and a USB. Port 213 and USB port 214.

The connection port 11 of the test host 1 is the same as the number of intermediate connection modules, and each connection port 11 is connected to one device under test 3 through an intermediate connection module. The connection between the test host, the intermediate connection module, and the device under test 3 is described by taking a connection port 11 of the test host 1 as an example. The connection port 11 of the test host 1 is connected to the USB port 211, and the USB port 212 is connected to the burn port. The USB port 221 and the USB port 213 of the recorder 22 are connected to the power supply terminal 31 of the device under test 3, the USB port 214 is connected to the UART universal serial data bus 32 of the device under test 3, and the programmer 22 and the device under test 3 pass. Jumper connection.

The communication path between the test host 1 and each device under test 3 includes a burn path and a data feedback path. The connection port 11 of the test host 1 is connected to the USB port 211, the USB port 212 of the USB hub 21 is connected to the USB port 221 of the programmer 22, and the programmer 22 and the device under test 3 are connected by a jumper to form a burn. The recording path of the test host 1 is connected to the USB port 211, and the USB port 214 of the USB hub 21 is connected to the UART universal serial data bus 32 to form a data feedback path. In addition, the test host 1 and each device under test 3 also have a power supply path, that is, the connection port 11 is connected to the USB port 211, and the USB port 213 of the USB hub 21 is connected to the power supply terminal 31 to form the power supply path.

The test host 1 is for performing the automated test method described in any of the first to third embodiments.

A person skilled in the art can understand that the above embodiments are specific embodiments of the present application, and various changes can be made in the form and details without departing from the spirit and scope of the application. range.

Claims

An automated test method is characterized in that it is applied to a test host, and the automated test method includes:

Identifying a communication path of each device to be tested connected to the test host;

Acquiring, by the preset test configuration information, a plurality of the devices to be tested corresponding to the at least one test task;

The test task is burned to each of the devices to be tested corresponding to the test task by using a communication path of each device to be tested;

Controlling each of the devices to be tested to perform the test task that has been burned;

Obtaining feedback data generated by each of the devices under test to perform the test task by using a communication path of each of the devices to be tested.
The automated testing method according to claim 1, wherein the communication path comprises a burning path and a data feedback path;

The test task is burned to each of the devices to be tested corresponding to the test task by using a communication path of each of the devices to be tested, specifically: burning through each of the devices to be tested Logging the path to burn the test task to each of the devices to be tested corresponding to the test task;

The obtaining, by the communication path of each of the devices to be tested, the feedback data generated by each of the devices under test to perform the test task, specifically: obtaining, by using a data feedback path of each device to be tested, The device under test performs feedback data generated by the test task.
The automated test method according to claim 2, wherein the feedback data comprises a test log; and the controlling each of the device under test before performing the test task that has been burned, further comprising:

Determining whether the data feedback path of each of the devices to be tested is in a normal communication state; when the determination result is yes, entering the step of controlling each of the devices to be tested to perform the test task that has been burned.
The automated testing method of claim 1, wherein the obtaining, by the preset test configuration information, the plurality of the devices to be tested corresponding to the at least one test task, further comprising:

Generating an executable file of the test task according to the test configuration information;

The test task is burned to each of the devices to be tested corresponding to the test task by using a communication path of each device to be tested, specifically: communication through each of the devices to be tested a path, the executable file of the test task is burned into each of the devices to be tested corresponding to the test task.
The automated test method according to claim 4, wherein the generating the executable file of the test task according to the test configuration information comprises:

Acquiring at least one test case corresponding to the test task from the test configuration information;

Obtaining program code of the test case from a code base;

Generating a test case set of the test task using program code of the test case;

Compiling the test case set of the test task to generate an executable file of the test task.
The automated test method according to claim 1, wherein the test configuration information is obtained by:

Provide a test configuration interface;

The test configuration information is received through the test configuration interface.
The automated test method according to claim 1, wherein the test configuration information is obtained by:

When it is detected that a preset task triggering event occurs, the test configuration information is set according to the task triggering event.
The automated testing method according to claim 7, wherein the task triggering event comprises at least one of the following events: a code upload event, a code merge event, and a regression test event.
The automated test method according to claim 1, wherein the test task is N, and N is an integer greater than 1. The test task is burned by the communication path of each of the devices to be tested. Before recording the device to be tested corresponding to the test task, the method further includes:

Each of the test tasks is placed in a task queue of each of the devices to be tested corresponding to the test task; wherein each of the test queues of the device to be tested includes K test tasks arranged in sequence Where K is an integer and 0 < K ≤ N;

The test task is burned to each of the devices to be tested corresponding to the test task by using a communication path of each device to be tested, specifically: communication through each of the devices to be tested a path, in which the K test tasks in the task queue of each device to be tested are sequentially burned into the device to be tested.
The automated test method according to claim 1, wherein the obtaining, by the communication path of each of the devices to be tested, the feedback data generated by each of the devices under test after performing the test task, further includes :

Generating a test report of each of the devices to be tested according to the feedback data of each of the devices to be tested.
The automated testing method according to claim 1, wherein the test task is burned to each of the devices to be tested corresponding to the test task by using a communication path of each device to be tested. Before, it also includes:

Initializing each of the devices to be tested corresponding to the test task.
An automated test system, comprising: a test host having a plurality of connection ports and a plurality of intermediate connection modules, and each of the intermediate connection modules has a burning function;

The connection port is the same as the number of the intermediate connection modules, and each of the connection ports is connected to a device to be tested through one of the intermediate connection modules;

The test host is for performing the automated test method of any one of claims 1 to 11.