CN116032810A - A Test Topology and Analysis Method of Bus Equipment - Google Patents

Abstract

The present invention proposes a test topology and analysis method of a bus device, relates to the technical field of bus automation testing, and includes the following steps: S1, building a physical test environment for a bus device, and configuring the working mode of the device to be tested; S2, configuring the bus side of the device to be tested Baud rate, operate the TCP/UDP tool to start sending packets; S3, after reaching the packet sending time, the TCP/UDP tool stops sending packets, collect data and record the final results, clear the data of each node, and analyze the final results; S4, judge whether to traverse all waves baud rate, if so, end the test, otherwise repeat step S2-S3. By adopting the method provided by the present invention, all tests can be completed only by setting up a test environment once before the start of the test, and there is no need to re-build the test environment or modify parameters in the environment during the process, reducing repeated labor.

Description

A Test Topology and Analysis Method of Bus Equipment

technical field

The invention relates to the technical field of bus automation testing, in particular to a test topology and analysis method of bus equipment.

Background technique

With the rapid development of industrial automation, various industrial equipment and other embedded devices have more and more demands for interconnection, but there are various interfaces and protocols on the bus, making it difficult to communicate directly. However, Ethernet is mature and widely used, and can be used as an intermediary to convert various industrial bus protocols and interfaces. How to verify whether the bus equipment can work normally and reliably is also a problem faced by equipment manufacturers and users.

Chinese patent CN105306292A "An Automated Test System" discloses a kind of automation. The test equipment is tested by controlling the test script through the control unit, and the test case results are recorded by the recording unit, so that the test equipment can be automatically tested. However, the above technical testing steps are cumbersome, and the test environment setup needs to be repeated, and the efficiency is too low.

Contents of the invention

In view of this, the present invention proposes a test topology and analysis method for bus equipment, which is used to solve the problems of cumbersome testing of bus equipment in the prior art, the need to repeatedly modify the test environment, and low efficiency.

The technical scheme of the present invention is achieved in that the present invention provides a kind of test topology and analysis method of bus equipment, comprising the following steps:

S1, build a physical test environment for the bus device, and configure the working mode of the device under test;

S2, configure the baud rate on the bus side of the device under test, and operate the TCP/UDP tool to start sending packets;

S3, after the packet sending time is reached, the TCP/UDP tool stops sending packets, collects data and records the final result, clears the data of each node, and analyzes the final result;

S4, judging whether to traverse all baud rates, if so, end the test, otherwise repeat steps S2-S3.

Preferably, step S1 specifically includes:

Use 4 devices under test DUT-1, DUT-2, DUT-3 and DUT-4 to cascade, configure the IP of the device, and use the PC side to include TCP/UDP sending tool 1 and TCP/UDP sending tool 2.

Preferably, step S1 also includes:

When the number of network ports of the device under test is greater than or equal to 2, the connection and working mode configuration of the bus is as follows:

TCP/UDP contract sending tool 1 and TCP/UDP contract sending tool 2, the working mode is udp multicast;

The working mode of the bus 1 network side of the device under test DUT-1 is udp multicast, the bus side of the bus 1 is shorted with the bus 2, the working mode of the bus 2 network side is tcp-server, and the bus side of the bus 2 is shorted with the bus 1;

The working mode of the bus 1 network side of the device under test DUT-2 is tcp-client, the bus side of the bus 1 is shorted with the bus 2, the working mode of the bus 2 network side is udp, and the bus side of the bus 2 is shorted with the bus 1;

The working mode of the bus 1 network side of the device under test DUT-3 is udp, the bus side of the bus 1 is shorted to the bus 2, the working mode of the bus 2 network side is tcp-client, and the bus side of the bus 2 is shorted to the bus 1;

The working mode of the bus 1 network side of the device under test DUT-4 is tcp-server, the bus side of the bus 1 is shorted with the bus 2, the working mode of the bus 2 network side is udp multicast, and the bus side of the bus 2 is shorted with the bus 1.

Preferably, step S1 also includes:

When the number of network ports of the device under test is 1, 4 devices under test are cascaded through an auxiliary device switch.

Preferably, step S2 specifically includes:

Configure the baud rate of the device under test, and configure the baud rate of each bus of each device under test to the same value in each round of testing.

Preferably, step S2 also includes:

Fill in the content and duration of the packet according to the requirements of the device under test, and use the TCP/UDP packet sending tool 1 to send the packet.

Preferably, step S3 specifically includes:

Log in to the web page of the device under test, the windows of TCP/UDP sending tool 1 and TCP/UDP sending tool 2, and count the number of bytes sent by TCP/UDP sending tool 1, the number of bytes received by TCP/UDP sending tool 2, and the pending Measure the number of bytes received and sent by the network side and bus side of each bus of the device, and record the statistical results.

Preferably, step S3 also includes:

The final results of the analysis include:

When the number of bytes sent by the TCP/UDP packet sending tool 1 is not equal to the number of bytes received by the network side of the DUT-1 bus 1 of the device under test, record "there is a problem with the physical link between the PC and DUT-1";

When the number of bytes received by the DUT-1 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-1 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in udp multicast mode";

When the number of bytes sent by the DUT-1 bus 1 side of the device under test is not equal to the number of bytes received by the DUT-1 bus 2 side of the device under test, record "there is a problem with the physical link between DUT-1 bus 1 and bus 2";

When the number of bytes received by the DUT-1 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-1 bus 2 network side of the device under test, record "there is a problem in forwarding from the bus side to the network side in tcp-server mode";

When the number of bytes sent by the DUT-1 bus 2 network side of the device under test is not equal to the number of bytes received by the DUT-2 bus 1 network side of the device under test, record "there is a problem with the physical link between DUT-1 and DUT-2";

When the number of bytes received by the DUT-2 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-2 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in tcp-client mode";

When the number of bytes sent by the DUT-2 bus side of the device under test is not equal to the number of bytes received by the DUT-2 bus side of the device under test, record "there is a problem with the physical link between DUT-2 bus 1 and bus 2";

When the number of bytes received by the DUT-2 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-2 bus 2 network side of the device under test, record "there is a problem in the forwarding from the bus side to the network side in udp mode";

When the number of bytes sent by the DUT-2 bus 2 network side of the device under test is not equal to the number of bytes received by the DUT-3 bus 1 network side of the device under test, record "there is a problem with the physical link between DUT-2 and DUT-3".

Preferably, step S3 also includes:

When the number of bytes received by the DUT-3 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-3 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in udp mode";

When the number of bytes sent by the DUT-3 bus 1 side of the device under test is not equal to the number of bytes received by the DUT-3 bus 2 side of the device under test, record "there is a problem with the physical link between DUT-3 bus 1 and bus 2";

When the number of bytes received by the DUT-3 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-3 bus 2 network side of the device under test, record "there is a problem in forwarding from the bus side to the network side in tcp-client mode";

When the number of bytes sent by the DUT-3 bus 2 network side of the device under test is not equal to the number of bytes received by the DUT-4 bus 1 network side of the device under test, record "there is a problem with the physical link between DUT-3 and DUT-4";

When the number of bytes received by the DUT-4 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-4 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in tcp-server mode";

When the number of bytes sent by the DUT-4 bus 1 side of the device under test is not equal to the number of bytes received by the DUT-4 bus 2 side of the device under test, record "there is a problem with the physical link between DUT-4 bus 1 and bus 2";

When the number of bytes received by the DUT-4 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-4 bus 2 network side of the device under test, record "there is a problem in the forwarding from the bus side to the network side in udp multicast mode";

When the number of bytes sent by the network side of the DUT-4 bus 2 of the device under test is not equal to the number of bytes received by the TCP/UDP packet sending tool 2, record "there is a problem with the forwarding link between DUT-4 and pc".

Preferably, step S4 specifically includes:

Each round of testing covers one baud rate, and when all the baud rates to be tested are covered, the test ends.

Compared with the prior art, the test topology and analysis method of a bus device of the present invention have the following beneficial effects:

(1) It is only necessary to build a test environment once before the test starts to complete all the tests, and there is no need to re-build the test environment or modify the parameters in the environment during the process, reducing duplication of labor;

(2) Through the analysis method, analyze which working mode and which forwarding direction of the equipment under test have problems, so as to quickly locate the problem;

(3) Two physical topology environments are provided, which can not only satisfy the equipment under test with multiple network ports, but also adapt to the equipment under test with only one network port, with strong adaptability.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some embodiments of the present invention. Those skilled in the art can also obtain other drawings based on these drawings without creative work.

Fig. 1 is the test topology and analysis method flowchart of a kind of bus equipment of the present invention;

Fig. 2 is the schematic diagram of each stage of the test topology and analysis method of a kind of bus equipment of the present invention;

Fig. 3 is the test topology diagram of the test topology and analysis method of a kind of bus equipment of the present invention;

Fig. 4 is another test topology diagram of the test topology and analysis method of a bus device of the present invention;

Fig. 5 is the topology diagram of traditional method testing network side working mode tcp-server sending a packet to the bus side;

Fig. 6 is the topological diagram of traditional method testing network side working mode tcp-server receiving bus side to send packets;

Fig. 7 is the topology diagram of traditional method testing network side working mode tcp-client sending packets to the bus side;

Fig. 8 is the topology diagram of traditional method testing network side working mode tcp-client receiving bus side sending packets;

Fig. 9 is a topology diagram of traditional method testing network side working mode udp sending packets to the bus side;

Fig. 10 is the topology diagram of traditional method testing network side working mode udp receiving bus side sending packets;

Fig. 11 is the topology diagram of traditional method testing network side working mode udp multicast sending packets to the bus side;

Fig. 12 is a topology diagram of traditional method testing network side working mode udp multicast receiving bus side sending packets.

Detailed ways

The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the implementation manners in the present invention, all other implementation manners obtained by persons of ordinary skill in the art without making creative efforts belong to the scope of protection of the present invention.

Example

A test topology and analysis method of a bus device are provided, as shown in Figure 1, comprising the following steps:

S1, build a physical test environment for the bus device, and configure the working mode of the device under test;

S2, configure the baud rate on the bus side of the device under test, and operate the TCP/UDP tool to start sending packets;

S3, after the packet sending time is reached, the TCP/UDP tool stops sending packets, collects data and records the final result, clears the data of each node, and analyzes the final result;

S4, judging whether to traverse all baud rates, if so, end the test, otherwise repeat steps S2-S3.

As shown in FIG. 2 , it is a schematic diagram of each stage of a bus device test topology and analysis method of the present invention, including a preparation stage, an execution stage, an analysis stage and an end stage.

The preparatory stage, that is, step S1 specifically includes:

Use 4 devices under test DUT-1, DUT-2, DUT-3 and DUT-4 to cascade, configure the IP of the device, and use the PC side to include TCP/UDP sending tool 1 and TCP/UDP sending tool 2.

There may be multiple devices to be tested, and the four devices used in this embodiment are only examples.

When the number of network ports of the device under test is greater than or equal to 2, the topology diagram is shown in Figure 3, and the connection and working mode of the bus are configured as follows:

TCP/UDP contract sending tool 1 and TCP/UDP contract sending tool 2, the working mode is udp multicast;

The working mode of the bus 1 network side of the device under test DUT-1 is udp multicast, the bus side of the bus 1 is shorted with the bus 2, the working mode of the bus 2 network side is tcp-server, and the bus side of the bus 2 is shorted with the bus 1;

The working mode of the bus 1 network side of the device under test DUT-2 is tcp-client, the bus side of the bus 1 is shorted with the bus 2, the working mode of the bus 2 network side is udp, and the bus side of the bus 2 is shorted with the bus 1;

The working mode of the bus 1 network side of the device under test DUT-3 is udp, the bus side of the bus 1 is shorted to the bus 2, the working mode of the bus 2 network side is tcp-client, and the bus side of the bus 2 is shorted to the bus 1;

The working mode of the bus 1 network side of the device under test DUT-4 is tcp-server, the bus side of the bus 1 is shorted with the bus 2, the working mode of the bus 2 network side is udp multicast, and the bus side of the bus 2 is shorted with the bus 1.

When the number of network ports of the device under test is 1, the topology diagram is shown in Figure 4, and 4 devices under test are cascaded through an auxiliary device switch.

The execution stage, that is, step S2 specifically includes:

Configure the baud rate of the device under test, and configure the baud rate of each bus of each device under test to the same value in each round of testing.

Fill in the content and duration of the packet according to the requirements of the device under test, and use the TCP/UDP packet sending tool 1 to send the packet.

The analysis stage, that is, step S3 specifically includes:

Log in to the web page of the device under test, the windows of TCP/UDP sending tool 1 and TCP/UDP sending tool 2, and count the number of bytes sent by TCP/UDP sending tool 1, the number of bytes received by TCP/UDP sending tool 2, and the pending Measure the number of bytes received and sent by the network side and bus side of each bus of the device, and record the statistical results.

The final results of the analysis include:

When the number of bytes sent by the TCP/UDP packet sending tool 1 is not equal to the number of bytes received by the network side of the DUT-1 bus 1 of the device under test, record "there is a problem with the physical link between the PC and DUT-1";

When the number of bytes received by the DUT-1 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-1 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in udp multicast mode";

When the number of bytes sent by the DUT-1 bus 1 side of the device under test is not equal to the number of bytes received by the DUT-1 bus 2 side of the device under test, record "there is a problem with the physical link between DUT-1 bus 1 and bus 2";

When the number of bytes received by the DUT-1 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-1 bus 2 network side of the device under test, record "there is a problem in forwarding from the bus side to the network side in tcp-server mode";

When the number of bytes sent by the DUT-1 bus 2 network side of the device under test is not equal to the number of bytes received by the DUT-2 bus 1 network side of the device under test, record "there is a problem with the physical link between DUT-1 and DUT-2";

When the number of bytes received by the DUT-2 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-2 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in tcp-client mode";

When the number of bytes sent by the DUT-2 bus side of the device under test is not equal to the number of bytes received by the DUT-2 bus side of the device under test, record "there is a problem with the physical link between DUT-2 bus 1 and bus 2";

When the number of bytes received by the DUT-2 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-2 bus 2 network side of the device under test, record "there is a problem in the forwarding from the bus side to the network side in udp mode";

When the number of bytes sent by the DUT-2 bus 2 network side of the device under test is not equal to the number of bytes received by the DUT-3 bus 1 network side of the device under test, record "there is a problem with the physical link between DUT-2 and DUT-3".

When the number of bytes received by the DUT-3 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-3 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in udp mode";

When the number of bytes sent by the DUT-3 bus 1 side of the device under test is not equal to the number of bytes received by the DUT-3 bus 2 side of the device under test, record "there is a problem with the physical link between DUT-3 bus 1 and bus 2";

When the number of bytes received by the DUT-3 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-3 bus 2 network side of the device under test, record "there is a problem in forwarding from the bus side to the network side in tcp-client mode";

When the number of bytes sent by the DUT-3 bus 2 network side of the device under test is not equal to the number of bytes received by the DUT-4 bus 1 network side of the device under test, record "there is a problem with the physical link between DUT-3 and DUT-4";

When the number of bytes received by the DUT-4 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-4 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in tcp-server mode";

When the number of bytes sent by the DUT-4 bus 1 side of the device under test is not equal to the number of bytes received by the DUT-4 bus 2 side of the device under test, record "there is a problem with the physical link between DUT-4 bus 1 and bus 2";

When the number of bytes received by the DUT-4 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-4 bus 2 network side of the device under test, record "there is a problem in the forwarding from the bus side to the network side in udp multicast mode";

When the number of bytes sent by the network side of the DUT-4 bus 2 of the device under test is not equal to the number of bytes received by the TCP/UDP packet sending tool 2, record "there is a problem with the forwarding link between DUT-4 and pc".

The end stage, that is, step S4 specifically includes:

Each round of testing covers one baud rate, and when all the baud rates to be tested are covered, the test ends.

Taking the baud rate of the bus side as 10K as an example, for the traditional method of testing the bus, the following scenarios need to be repeated for testing other baud rates. If there are several baud rates, it needs to be repeated several times, and the switching scene needs to modify the environment configuration and the device under test. DUT configuration;

Scenario 1 - The network side works in tcp-server mode, and the network side sends packets to the bus side. The topology diagram is shown in Figure 5.

Scenario 2 - The working mode of the network side is tcp-server, and the bus side sends packets to the network side. The topology diagram is shown in Figure 6.

Scenario 3 - The network side works in tcp-client mode, and the network side sends packets to the bus side. The topology diagram is shown in Figure 7.

Scenario 4 - The working mode of the network side is tcp-client, the bus side sends packets to the network side, and the topology diagram is shown in Figure 8.

Scenario 5 - The network side works in udp mode, and the network side sends packets to the bus side. The topology diagram is shown in Figure 9.

Scenario 6 - The network side works in udp mode, and the bus side sends packets to the network side. The topology diagram is shown in Figure 10.

Scenario 7 - network side working mode udp multicast, the network side sends packets to the bus side, the topology diagram is shown in Figure 11,

Scenario 8 - network side working mode udp multicast, the bus side sends packets to the network side, the topology diagram is shown in Figure 12,

And the traditional method of testing the bus includes the following steps:

1) Build a physical environment;

2) Configure the network side to work in a working mode;

3) Configure the TCP/UDP tool to work in the corresponding working mode;

4) Send a packet to the bus side using the TCP/UDP packet sending tool;

5) Record the number of packets sent by the network side and the number of packets received by the bus side;

6) Clear statistical results;

7) Use the bus contract sending tool to send the contract to the network side;

8) Record the number of packets sent by the bus side and the number of packets received by the network side;

9) Clear statistical results;

10) Analyze the test results of this round;

11) Modify the network side to work in another working mode, repeat steps 3-10;

12) Modify the bus baud rate, repeat steps 2-11.

Obviously, the traditional method of testing the bus is too cumbersome, requiring repeated modification of the test environment, and manual analysis of the results after each round of testing, making it difficult to guarantee efficiency and reliability.

And adopt the test topology and analysis method of a kind of bus equipment of the present invention, as shown in Figure 3, use 4 equipments to be tested to cascade, configure the IP of equipment, and for above-mentioned scene 1-8, for 10K baud rate, The present invention only needs to configure the environment once, and can test and obtain the number of bytes sent and received by TCP/UDP contract sending tools 1 and 2, and the number of bytes received and sent by each bus network side and bus side of 4 devices to be tested, thereby Determine whether the connection links between the PC, each device, and each device are normal. Each round of testing covers one baud rate, and when other baud rates need to be tested, just start a new round of testing.

Analysis of the results of the analysis phase can also be done using scripts, or using Excel formulas. The specific analysis algorithm is as follows:

IfTx1! =Rx11:

Print("there is a problem with the physical link between pc and DUT-1")

IfRx11! =Tx12:

Print("There is a problem in forwarding from the network side to the bus side in udp multicast mode")

IfTx12! =Rx13:

Print("There is a problem with the physical link between bus 1 and bus 2 of DUT-1")

IfRx13! =Tx14:

Print("There is a problem in forwarding from the bus side to the network side in tcp-server mode")

IfTx14! =Rx21:

Print("There is a problem with the physical link between DUT-1 and DUT-2")

IfRx21! =Tx22:

Print("There is a problem in forwarding from the network side to the bus side in tcp-client mode")

IfTx22! =Rx23:

Print("There is a problem with the physical link between DUT-2 bus 1 and bus 2")

IfRx23! =Tx24:

Print("There is a problem in forwarding from the bus side to the network side in udp mode")

IfTx24! =Rx31:

Print("There is a problem with the physical link between DUT-2 and DUT-3")

IfRx31! =Tx32:

Print("There is a problem in forwarding from the network side to the bus side in udp mode")

IfTx32! =Rx33:

Print("There is a problem with the physical link between bus 1 and bus 2 of DUT-3")

IfRx33! =Tx34:

Print("There is a problem in forwarding from the bus side to the network side in tcp-client mode")

IfTx34! =Rx41:

Print("There is a problem with the physical link between DUT-3 and DUT-4")

IfRx41! =Tx42:

Print("There is a problem in forwarding from the network side to the bus side in tcp-server mode")

IfTx42! =Rx43:

Print("There is a problem with the physical link between DUT-4 bus 1 and bus 2")

If Rx43! =Tx44:

Print("There is a problem in forwarding from the bus side to the network side in udp multicast mode")

IfTx44! =Rx2:

Print("There is a problem with the forwarding link between pc and DUT-4")

The parameters in the above algorithm can be obtained from Figure 3.

With the method provided by the present invention, all the tests can be completed only by setting up a test environment once before the test starts, and there is no need to re-build the test environment or modify the parameters in the environment in the process, reducing duplication of labor; in addition, the method provides two A physical topology environment, as shown in Figure 3 and Figure 4, can satisfy the equipment under test with multiple network ports, and can also adapt to the equipment under test with only one network port, and has strong adaptability; at the same time, combined with the The analysis method can analyze which working mode and which forwarding direction of the device under test have problems, so as to quickly locate the problem.

The above description is only a preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included in the scope of the present invention. within the scope of protection.

Claims (10)

1. a test topology and analysis method of bus equipment, is characterized in that, comprises the following steps: S1, build a physical test environment for the bus device, and configure the working mode of the device under test; S2, configure the baud rate on the bus side of the device under test, and operate the TCP/UDP tool to start sending packets; S3, after the packet sending time is reached, the TCP/UDP tool stops sending packets, collects data and records the final result, clears the data of each node, and analyzes the final result; S4, judging whether to traverse all baud rates, if so, end the test, otherwise repeat steps S2-S3. 2. the test topology and analysis method of a kind of bus equipment as claimed in claim 1, is characterized in that, described step S1 specifically comprises: Use 4 devices under test DUT-1, DUT-2, DUT-3 and DUT-4 to cascade, configure the IP of the device, and use the PC side to include TCP/UDP sending tool 1 and TCP/UDP sending tool 2. 3. the test topology and analysis method of a kind of bus equipment as claimed in claim 2, is characterized in that, described step S1 also comprises: When the number of network ports of the device under test is greater than or equal to 2, the connection and working mode configuration of the bus is as follows: TCP/UDP contract sending tool 1 and TCP/UDP contract sending tool 2, the working mode is udp multicast; The working mode of the bus 1 network side of the device under test DUT-1 is udp multicast, the bus side of the bus 1 is shorted with the bus 2, the working mode of the bus 2 network side is tcp-server, and the bus side of the bus 2 is shorted with the bus 1; The working mode of the bus 1 network side of the device under test DUT-2 is tcp-client, the bus side of the bus 1 is shorted with the bus 2, the working mode of the bus 2 network side is udp, and the bus side of the bus 2 is shorted with the bus 1; The working mode of the bus 1 network side of the device under test DUT-3 is udp, the bus side of the bus 1 is shorted to the bus 2, the working mode of the bus 2 network side is tcp-client, and the bus side of the bus 2 is shorted to the bus 1; The working mode of the bus 1 network side of the device under test DUT-4 is tcp-server, the bus side of the bus 1 is shorted with the bus 2, the working mode of the bus 2 network side is udp multicast, and the bus side of the bus 2 is shorted with the bus 1. 4. the test topology and analysis method of a kind of bus equipment as claimed in claim 3, is characterized in that, described step S1 also comprises: When the number of network ports of the device under test is 1, 4 devices under test are cascaded through an auxiliary device switch. 5. the test topology and analysis method of a kind of bus equipment as claimed in claim 1, is characterized in that, described step S2 specifically comprises: Configure the baud rate of the device under test, and configure the baud rate of each bus of each device under test to the same value in each round of testing. 6. the test topology and analysis method of a kind of bus equipment as claimed in claim 5, is characterized in that, described step S2 also comprises: Fill in the content and duration of the packet according to the requirements of the device under test, and use the TCP/UDP packet sending tool 1 to send the packet. 7. the test topology and analysis method of a kind of bus equipment as claimed in claim 6, is characterized in that, described step S3 specifically comprises: Log in to the web page of the device under test, the windows of TCP/UDP sending tool 1 and TCP/UDP sending tool 2, and count the number of bytes sent by TCP/UDP sending tool 1, the number of bytes received by TCP/UDP sending tool 2, and the pending Measure the number of bytes received and sent by the network side and bus side of each bus of the device, and record the statistical results. 8. the test topology and analysis method of a kind of bus equipment as claimed in claim 7, is characterized in that, described step S3 also comprises: The final results of the analysis include: When the number of bytes sent by the TCP/UDP packet sending tool 1 is not equal to the number of bytes received by the network side of the DUT-1 bus 1 of the device under test, record "there is a problem with the physical link between the PC and DUT-1"; When the number of bytes received by the DUT-1 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-1 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in udp multicast mode"; When the number of bytes sent by the DUT-1 bus 1 side of the device under test is not equal to the number of bytes received by the DUT-1 bus 2 side of the device under test, record "there is a problem with the physical link between DUT-1 bus 1 and bus 2"; When the number of bytes received by the DUT-1 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-1 bus 2 network side of the device under test, record "there is a problem in forwarding from the bus side to the network side in tcp-server mode"; When the number of bytes sent by the DUT-1 bus 2 network side of the device under test is not equal to the number of bytes received by the DUT-2 bus 1 network side of the device under test, record "there is a problem with the physical link between DUT-1 and DUT-2"; When the number of bytes received by the DUT-2 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-2 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in tcp-client mode"; When the number of bytes sent by the DUT-2 bus side of the device under test is not equal to the number of bytes received by the DUT-2 bus side of the device under test, record "there is a problem with the physical link between DUT-2 bus 1 and bus 2"; When the number of bytes received by the DUT-2 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-2 bus 2 network side of the device under test, record "there is a problem in the forwarding from the bus side to the network side in udp mode"; When the number of bytes sent by the DUT-2 bus 2 network side of the device under test is not equal to the number of bytes received by the DUT-3 bus 1 network side of the device under test, record "there is a problem with the physical link between DUT-2 and DUT-3". 9. the test topology and analysis method of a kind of bus equipment as claimed in claim 8, is characterized in that, described step S3 also comprises: When the number of bytes received by the DUT-3 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-3 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in udp mode"; When the number of bytes sent by the DUT-3 bus 1 side of the device under test is not equal to the number of bytes received by the DUT-3 bus 2 side of the device under test, record "there is a problem with the physical link between DUT-3 bus 1 and bus 2"; When the number of bytes received by the DUT-3 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-3 bus 2 network side of the device under test, record "there is a problem in forwarding from the bus side to the network side in tcp-client mode"; When the number of bytes sent by the DUT-3 bus 2 network side of the device under test is not equal to the number of bytes received by the DUT-4 bus 1 network side of the device under test, record "there is a problem with the physical link between DUT-3 and DUT-4"; When the number of bytes received by the DUT-4 bus 1 network side of the device under test is not equal to the number of bytes sent by the DUT-4 bus 1 bus side of the device under test, record "There is a problem in forwarding from the network side to the bus side in tcp-server mode"; When the number of bytes sent by the DUT-4 bus 1 side of the device under test is not equal to the number of bytes received by the DUT-4 bus 2 side of the device under test, record "there is a problem with the physical link between DUT-4 bus 1 and bus 2"; When the number of bytes received by the DUT-4 bus 2 bus side of the device under test is not equal to the number of bytes sent by the DUT-4 bus 2 network side of the device under test, record "there is a problem in the forwarding from the bus side to the network side in udp multicast mode"; When the number of bytes sent by the network side of the DUT-4 bus 2 of the device under test is not equal to the number of bytes received by the TCP/UDP packet sending tool 2, record "there is a problem with the forwarding link between DUT-4 and pc". 10. the test topology and analysis method of a kind of bus equipment as claimed in claim 1, is characterized in that, described step S4 specifically comprises: Each round of testing covers one baud rate, and when all the baud rates to be tested are covered, the test ends.

Images