CN109150654B - Use case design method based on protocol consistency of path - Google Patents
Use case design method based on protocol consistency of path Download PDFInfo
- Publication number
- CN109150654B CN109150654B CN201810828823.1A CN201810828823A CN109150654B CN 109150654 B CN109150654 B CN 109150654B CN 201810828823 A CN201810828823 A CN 201810828823A CN 109150654 B CN109150654 B CN 109150654B
- Authority
- CN
- China
- Prior art keywords
- router
- switch
- address
- arp
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/24—Testing correct operation
- H04L1/242—Testing correct operation by comparing a transmitted test signal with a locally generated replica
- H04L1/244—Testing correct operation by comparing a transmitted test signal with a locally generated replica test sequence generators
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/18—Protocol analysers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/10—Mapping addresses of different types
- H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention is suitable for the field of case design methods, and provides a case design method based on protocol consistency of a path, which comprises the following steps: step S1: according to international standard regulation, a complete protocol interaction process is formulated; step S2: dividing an interaction process into three nodes, namely a first node, a second node and a third node in detail; step S3: analyzing and sorting corresponding paths of the first node, the second node and the third node; step S4: converting the routes of the first node, the second node and the third node after the sorting into test points; step S5: and designing the test points of the first node, the second node and the third node into test cases for testing. The problem that the number of the use cases is redundant, and each function point in the protocol is subjected to scattered test, so that omission is easily caused is solved; the design case takes more time and has low efficiency.
Description
Technical Field
The invention belongs to the field of case design methods, and particularly relates to a case design method based on protocol consistency of paths.
Background
The existing protocol consistency test method designs cases one by one for each requirement point in international standard to test. The defects of the test mode are as follows: the number of designed use cases is redundant; each function point in the protocol is subjected to decentralized testing, so that omission is easily generated; the method has the advantages of more time consumption and low efficiency in case design. .
Disclosure of Invention
The invention aims to provide a path-based case design method for protocol consistency, which aims to solve the problems of redundant case quantity and easy omission caused by the scattered test of each function point in a protocol; the design case takes more time and has low efficiency.
The invention is realized in this way, a use case design method based on protocol consistency of the route, the first switch/router, the second switch/router, the first PC connected with the first switch/router, the second PC connected with the second switch/router, the first switch/router and the second switch/router are connected in communication and are the same kind of equipment, the use case design method includes the following steps:
step S1: according to international standard regulation, a complete protocol interaction process is formulated;
step S2: extracting three nodes on the path of the interaction process, namely a first node, a second node and a third node;
step S3: analyzing and sorting the first node, the second node and the third node;
step S4: converting the sorted first node, second node and third node into test points;
step S5: and converting the test points of the first node, the second node and the third node into test cases for testing.
The further technical scheme of the invention is as follows: the step S2 further includes the steps of:
step S21: the first node is a node on the first switch/router, which is used for sending a data request, the second node is a node on the second switch/router, which is used for receiving and processing the data request sent by the first switch/router and performing corresponding data response, and the third node is a node on the first switch/router, which is used for receiving and performing corresponding processing on the data response of the second switch/router.
The further technical scheme of the invention is as follows: the step S3 further includes the steps of:
step S31: analyzing and sorting a first node, namely firstly, sending data to be sent to a first switch/router by a first PC (personal computer), then sending the data to a second switch/router by the first switch/router, and then sending the data to a second PC by the second switch/router; step S32: and sending data to the second switch/router by the first switch/router, wherein the second switch/router needs to be judged whether the address of the second switch/router exists in an arp table of the first switch/router, if so, the data is sent to the second switch/router, if not, an arp request message is sent to all ports of the first switch/router to search the address of the second switch/router, and the arp represents the corresponding relation between the IP address and the MAC address.
The further technical scheme of the invention is as follows: the step S3 further includes the steps of:
step S33: analyzing and sorting the second node, firstly, the second node receives an arp request message sent by the first node, and sets Merge _ tag: false;
step S34: judging whether the source IP address of the arp request message exists in the arp table of the second switch/router, if so, updating the MAC address of the arp request message to the MAC address corresponding to the IP address in the arp table of the second switch/router, and setting Merge _ flag: if not, checking the target protocol address of the arp request message;
step S35: judging whether the target protocol address of the arp request message is the IP address of the arp request message, if so, checking the Merge _ tag: if not, discarding the arp request message;
step S36: judging Merge _ flag: if so, writing the own IP address and MAC address into the original address of the arp request message, changing the target address into the address of the opposite side, changing the operation code field into replay, otherwise, writing the source IP address and source MAC address of the arp request message into the arp table of the second switch/router, writing the own IP address and MAC address into the original address of the arp request message, changing the target address into the address of the opposite side, and changing the operation code field into replay;
step S37: and after the analysis and the sorting, sending the arp reply message from the received port.
The further technical scheme of the invention is as follows: the step S3 further includes the steps of:
step S38: analyzing and sorting a third node, namely firstly, the third node receives an arp reply message sent by a second node, judges whether the target _ IP of the arp reply message is self, if so, checks the record of an arp table of the first switch/router, and if not, discards the arp reply message without changing the own arp table item;
step S39: and judging whether the records of the sender _ IP exist in the records of the arp table of the first switch/router, if so, updating the aging time of the records of the sender _ IP, and if not, writing the sender _ IP into the arp table of the first switch/router.
The further technical scheme of the invention is as follows: the step S4 further includes the steps of:
step S41: the first node is converted into two test points which are respectively a first test point: when the arp table of the target address exists, the target address is ping on the first switch/router, and when the arp table of the target address does not exist, the target address is ping on the first switch/router by the second test point;
step S42: the second node is converted into four test points which are respectively a third test point: when receiving an arp request message, a sender _ IP is an IP recorded in an arp table, but a target _ IP is not the own IP, updating the arp table, discarding the arp request message, and a fourth test point: when receiving an arp request message, a sender _ IP is an IP recorded in an arp table, a target _ IP is the own IP, sending an arp response, and a fifth test point: when receiving an arp request message, a sender _ IP is not in the arp table, but a target _ IP is self, writing the arp table, sending an arp response, and a sixth test point: when receiving an arp request message, if the sender _ IP is not in the arp table and the target _ IP is not self, discarding the arp request message;
step S43: the third node is converted into three test points which are respectively a seventh test point: when receiving the arp reply, the target _ IP is not self, abandoning the arp reply message, and the eighth test point: when receiving the arp reply, the target _ IP is itself, if the target _ IP is in the arp table, the arp table is updated, and the ninth test point: when receiving the arp reply, the target _ IP is the own, and if the target _ IP is not in the arp table, the target _ IP is written in the arp table.
The further technical scheme of the invention is as follows: the step S5 further includes the steps of:
step S51: respectively converting a first test point and a second test point of a first node into a first test case and a second test case, wherein the first test case is as follows: configuring the port IP address of the first switch/router to 192.168.20.1, configuring the network card IP address of the first PC to 192.168.20.111, ping the network card IP address of the first PC on the first switch/router, and then starting packet capture by the network card of the first PC, where the packet capture result is that the first PC can capture an arp request message sent by the first switch/router, and the second test case is: configuring a port IP address of the first switch/router to 192.168.20.1, configuring a network card IP address of the first PC to 192.168.20.111, pinging the network card IP address of the first PC on the first switch/router, stopping pinging the network card IP address of the first PC by the first switch/router, starting packet grabbing by the first PC, and pinging the network card IP address of the first PC again by the first switch/router, wherein the packet grabbing result of the network card of the first PC is that the network card of the first PC cannot grab an arp request message sent by the first switch/router and can only grab an icmp message;
step S52: respectively converting a third test point, a fourth test point, a fifth test point and a sixth test point of a second node into a third test case, a fourth test case, a fifth test case and a sixth test case, wherein the third test case is as follows: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, after the second PC pings the port IP address of the second switch/router, querying in an arp table of the second switch/router, if the arp table of the second switch/router has the network card IP address of the second PC, constructing an arp request message on the second PC, sending a sender _ IP address 192.168.20.111 and a target _ IP address 192.168.20.1 to the second switch/router, and querying in the arp table of the second switch/router, if the arp table of the second switch/router has the dynamic entry of the sender _ IP address 192.168.20.111, updating the aging time, and using a fourth test case: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, ping the port IP address of the second switch/router on the second PC, if the port IP address of the second switch/router can be ping, clearing the arp table on the second PC, and then ping the port IP address of the second switch/router on the second PC, where the second PC can receive an arp reply message sent by the second switch/router, and the fifth test case is: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, after the second PC pings the port IP address of the second switch/router, the second switch/router queries in an arp table, and when the arp table has a dynamic entry of the network card IP address of the second PC, the second switch/router sends an arp reply message, where a sixth test case is: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, starting packet capture by the second PC, constructing an arp request message on the second PC, and sending a sender _ IP address 192.168.20.101 and a target _ IP address 192.168.20.120 to the second switch/router, so that the second PC cannot capture a response message sent by the second switch/router;
step S53: respectively converting a seventh test point, an eighth test point and a ninth test point of the third node into a seventh test case, an eighth test case and a ninth test case, wherein the seventh test case is as follows: configuring 192.168.20.1 for the port IP address of the first switch/router, configuring 192.168.20.111 for the network card IP address of the first PC, constructing an arp reply message on the first PC, and sending a sender _ IP address 192.168.20.101 and a target _ IP address 192.168.20.120 to the first switch/router, where the first switch/router sends no message, and then querying an arp table of the first switch/router, where the arp table of the first switch/router does not have a sender _ IP address, and the eighth test case is: configuring 192.168.20.1 for the port IP address of the first switch/router, configuring 192.168.20.111 for the network card IP address of the first PC, constructing an arp reply message on the first PC, and sending a sender _ IP address 192.168.20.111 and a target _ IP address 192.168.20.1 to the first switch/router, where the first switch/router queries an arp table, and if the sender _ IP address exists in the arp table, the aging time is updated, in a ninth test case: configuring 192.168.20.1 for the port IP address of the first switch/router, configuring 192.168.20.111 for the network card IP address of the first PC, constructing an arp reply message on the first PC, sending a sender _ IP address 192.168.20.101 and a target _ IP address 192.168.20.1 to the first switch/router, querying an arp table by the first switch/router, and writing the sender _ IP address into the arp table if the sender _ IP address does not exist in the arp table.
The invention has the beneficial effects that: the case design method is suitable for most network protocols of the switch and the router; the end-to-end protocol implementation is considered, the use case redundancy is reduced, the use case effectiveness is improved, the path coverage is adopted, the design omission is avoided, and the use case design efficiency is improved.
Drawings
FIG. 1 is a flowchart of an embodiment of a use case design method for path-based protocol consistency;
fig. 2 is a flowchart of a first node of a use case design method based on path protocol consistency according to an embodiment of the present invention;
fig. 3 is a second node flowchart of a use case design method based on path protocol consistency according to an embodiment of the present invention;
fig. 4 is a third node flowchart of a use case design method based on path protocol consistency according to an embodiment of the present invention.
Detailed Description
Fig. 1 to 4 illustrate a use case design method based on path protocol consistency according to the present invention, where the use case design method includes a first switch/router, a second switch/router, a first PC connected to the first switch/router, and a second PC connected to the second switch/router, where the first switch/router is in communication connection with the second switch/router, and the first switch/router and the second switch/router are the same device, and the use case design method includes the following steps:
step S1: according to international standard regulation, a complete protocol interaction process is formulated;
step S2: extracting three nodes on the path of the interaction process, namely a first node, a second node and a third node;
step S21: the first node is a node on the first switch/router, which is used for sending a data request, the second node is a node on the second switch/router, which is used for receiving and processing the data request sent by the first switch/router and performing corresponding data response, and the third node is a node on the first switch/router, which is used for receiving and performing corresponding processing on the data response of the second switch/router.
Step S3: analyzing and sorting the first node, the second node and the third node;
step S31: analyzing and sorting a first node, namely firstly, sending data to be sent to a first switch/router by a first PC (personal computer), then sending the data to a second switch/router by the first switch/router, and then sending the data to a second PC by the second switch/router; step S32: and sending data to the second switch/router by the first switch/router, wherein the second switch/router needs to be judged whether the address of the second switch/router exists in an arp table of the first switch/router, if so, the data is sent to the second switch/router, if not, an arp request message is sent to all ports of the first switch/router to search the address of the second switch/router, and the arp represents the corresponding relation between the IP address and the MAC address.
Step S33: analyzing and sorting the second node, firstly, the second node receives an arp request message sent by the first node, and sets Merge _ tag: false;
step S34: judging whether the source IP address of the arp request message exists in the arp table of the second switch/router, if so, updating the MAC address of the arp request message to the MAC address corresponding to the IP address in the arp table of the second switch/router, and setting Merge _ flag: if not, checking the target protocol address of the arp request message;
step S35: judging whether the target protocol address of the arp request message is the IP address of the arp request message, if so, checking the Merge _ tag: if not, discarding the arp request message;
step S36: judging Merge _ flag: if so, writing the own IP address and MAC address into the original address of the arp request message, changing the target address into the address of the opposite side, changing the operation code field into replay, otherwise, writing the source IP address and source MAC address of the arp request message into the arp table of the second switch/router, writing the own IP address and MAC address into the original address of the arp request message, changing the target address into the address of the opposite side, and changing the operation code field into replay;
step S37: and after the analysis and the sorting, sending the arp reply message from the received port.
Step S38: analyzing and sorting a third node, namely firstly, the third node receives an arp reply message sent by a second node, judges whether the target _ IP of the arp reply message is self, if so, checks the record of an arp table of the first switch/router, and if not, discards the arp reply message without changing the own arp table item;
step S39: and judging whether the records of the sender _ IP exist in the records of the arp table of the first switch/router, if so, updating the aging time of the records of the sender _ IP, and if not, writing the sender _ IP into the arp table of the first switch/router.
Step S4: converting the sorted first node, second node and third node into test points;
step S41: the first node is converted into two test points which are respectively a first test point: when the arp table of the target address exists, the target address is ping on the first switch/router, and when the arp table of the target address does not exist, the target address is ping on the first switch/router by the second test point;
step S42: the second node is converted into four test points which are respectively a third test point: when receiving an arp request message, a sender _ IP is an IP recorded in an arp table, but a target _ IP is not the own IP, updating the arp table, discarding the arp request message, and a fourth test point: when receiving an arp request message, a sender _ IP is an IP recorded in an arp table, a target _ IP is the own IP, sending an arp response, and a fifth test point: when receiving an arp request message, a sender _ IP is not in the arp table, but a target _ IP is self, writing the arp table, sending an arp response, and a sixth test point: when receiving an arp request message, if the sender _ IP is not in the arp table and the target _ IP is not self, discarding the arp request message;
step S43: the third node is converted into three test points which are respectively a seventh test point: when receiving the arp reply, the target _ IP is not self, abandoning the arp reply message, and the eighth test point: when receiving the arp reply, the target _ IP is itself, if the target _ IP is in the arp table, the arp table is updated, and the ninth test point: when receiving the arp reply, the target _ IP is the own, and if the target _ IP is not in the arp table, the target _ IP is written in the arp table.
Step S5: and converting the test points of the first node, the second node and the third node into test cases for testing.
Step S51: respectively converting a first test point and a second test point of a first node into a first test case and a second test case, wherein the first test case is as follows: configuring the port IP address of the first switch/router to 192.168.20.1, configuring the network card IP address of the first PC to 192.168.20.111, ping the network card IP address of the first PC on the first switch/router, and then starting packet capture by the network card of the first PC, where the packet capture result is that the first PC can capture an arp request message sent by the first switch/router, and the second test case is: configuring a port IP address of the first switch/router to 192.168.20.1, configuring a network card IP address of the first PC to 192.168.20.111, pinging the network card IP address of the first PC on the first switch/router, stopping pinging the network card IP address of the first PC by the first switch/router, starting packet grabbing by the first PC, and pinging the network card IP address of the first PC again by the first switch/router, wherein the packet grabbing result of the network card of the first PC is that the network card of the first PC cannot grab an arp request message sent by the first switch/router and can only grab an icmp message;
step S52: respectively converting a third test point, a fourth test point, a fifth test point and a sixth test point of a second node into a third test case, a fourth test case, a fifth test case and a sixth test case, wherein the third test case is as follows: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, after the second PC pings the port IP address of the second switch/router, querying in an arp table of the second switch/router, if the arp table of the second switch/router has the network card IP address of the second PC, constructing an arp request message on the second PC, sending a sender _ IP address 192.168.20.111 and a target _ IP address 192.168.20.1 to the second switch/router, and querying in the arp table of the second switch/router, if the arp table of the second switch/router has the dynamic entry of the sender _ IP address 192.168.20.111, updating the aging time, and using a fourth test case: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, ping the port IP address of the second switch/router on the second PC, if the port IP address of the second switch/router can be ping, clearing the arp table on the second PC, and then ping the port IP address of the second switch/router on the second PC, where the second PC can receive an arp reply message sent by the second switch/router, and the fifth test case is: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, after the second PC pings the port IP address of the second switch/router, the second switch/router queries in an arp table, and when the arp table has a dynamic entry of the network card IP address of the second PC, the second switch/router sends an arp reply message, where a sixth test case is: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, starting packet capture by the second PC, constructing an arp request message on the second PC, and sending a sender _ IP address 192.168.20.101 and a target _ IP address 192.168.20.120 to the second switch/router, so that the second PC cannot capture a response message sent by the second switch/router;
step S53: respectively converting a seventh test point, an eighth test point and a ninth test point of the third node into a seventh test case, an eighth test case and a ninth test case, wherein the seventh test case is as follows: configuring 192.168.20.1 for the port IP address of the first switch/router, configuring 192.168.20.111 for the network card IP address of the first PC, constructing an arp reply message on the first PC, and sending a sender _ IP address 192.168.20.101 and a target _ IP address 192.168.20.120 to the first switch/router, where the first switch/router sends no message, and then querying an arp table of the first switch/router, where the arp table of the first switch/router does not have a sender _ IP address, and the eighth test case is: configuring 192.168.20.1 for the port IP address of the first switch/router, configuring 192.168.20.111 for the network card IP address of the first PC, constructing an arp reply message on the first PC, and sending a sender _ IP address 192.168.20.111 and a target _ IP address 192.168.20.1 to the first switch/router, where the first switch/router queries an arp table, and if the sender _ IP address exists in the arp table, the aging time is updated, in a ninth test case: configuring 192.168.20.1 for the port IP address of the first switch/router, configuring 192.168.20.111 for the network card IP address of the first PC, constructing an arp reply message on the first PC, sending a sender _ IP address 192.168.20.101 and a target _ IP address 192.168.20.1 to the first switch/router, querying an arp table by the first switch/router, and writing the sender _ IP address into the arp table if the sender _ IP address does not exist in the arp table.
The IP configuration addresses used in the first test case, the second test case, the third test case, the fourth test case, the fifth test case, the sixth test case, the seventh test case, the eighth test case and the ninth test case are all IP configuration addresses used by way of example, and the IP configuration addresses can be replaced and need to be in the same network segment.
The case design method is suitable for most network protocols of the switch and the router; the end-to-end protocol implementation is considered, the use case redundancy is reduced, the use case effectiveness is improved, the path coverage is adopted, the design omission is avoided, and the use case design efficiency is improved.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents and improvements made within the spirit and principle of the present invention are intended to be included within the scope of the present invention.
Claims (2)
1. A use case design method based on protocol consistency of a path, comprising a first switch/router, a second switch/router, a first PC connected with the first switch/router, a second PC connected with the second switch/router, wherein the first switch/router is in communication connection with the second switch/router and the first switch/router and the second switch/router are the same kind of equipment, and the use case design method comprises the following steps:
step S1: according to international standard regulation, a complete protocol interaction process is formulated;
step S2: extracting three nodes on the path of the interaction process, namely a first node, a second node and a third node; the first node is a node on the first switch/router, which is used for sending a data request, the second node is a node on the second switch/router, which is used for receiving, processing and performing corresponding data response on the data request sent by the first switch/router, and the third node is a node on the first switch/router, which is used for receiving and performing corresponding processing on the data response of the second switch/router;
step S3: analyzing and sorting the first node, the second node and the third node;
the step S3 further includes the steps of:
step S31: analyzing and sorting a first node, namely firstly, sending data to be sent to a first switch/router by a first PC (personal computer), then sending the data to a second switch/router by the first switch/router, and then sending the data to a second PC by the second switch/router;
step S32: sending data to the second switch/router by the first switch/router, wherein the second switch/router needs to be judged whether the address of the second switch/router exists in an arp table of the first switch/router, if so, sending the data to the second switch/router, and if not, sending an arp request message to all ports of the first switch/router to search the address of the second switch/router, wherein the arp represents the corresponding relation between an IP address and an MAC address;
step S33: analyzing and sorting the second node, firstly, the second node receives an arp request message sent by the first node, and sets Merge _ tag: false;
step S34: judging whether the source IP address of the arp request message exists in the arp table of the second switch/router, if so, updating the MAC address of the arp request message to the MAC address corresponding to the IP address in the arp table of the second switch/router, and setting Merge _ flag: if not, checking the target protocol address of the arp request message;
step S35: judging whether the target protocol address of the arp request message is the IP address of the arp request message, if so, checking the Merge _ tag: if not, discarding the arp request message;
step S36: judging Merge _ flag: if so, writing the own IP address and MAC address into the original address of the arp request message, changing the target address into the address of the opposite side, changing the operation code field into replay, otherwise, writing the source IP address and source MAC address of the arp request message into the arp table of the second switch/router, writing the own IP address and MAC address into the original address of the arp request message, changing the target address into the address of the opposite side, and changing the operation code field into replay;
step S37: after the analysis and the sorting, sending the arp reply message from the received port;
step S38: analyzing and sorting a third node, namely firstly, the third node receives an arp reply message sent by a second node, judges whether the target _ IP of the arp reply message is self, if so, checks the record of an arp table of the first switch/router, and if not, discards the arp reply message without changing the own arp table item;
step S39: judging whether the records of the sender _ IP exist in the records of the arp table of the first switch/router, if so, updating the aging time of the records of the sender _ IP, and if not, writing the sender _ IP into the arp table of the first switch/router;
step S4: converting the sorted first node, second node and third node into test points;
the step S4 further includes the steps of:
step S41: the first node is converted into two test points which are respectively a first test point: when the arp table of the target address exists, the target address is ping on the first switch/router, and when the arp table of the target address does not exist, the target address is ping on the first switch/router by the second test point;
step S42: the second node is converted into four test points which are respectively a third test point: when receiving an arp request message, a sender _ IP is an IP recorded in an arp table, but a target _ IP is not the own IP, updating the arp table, discarding the arp request message, and a fourth test point: when receiving an arp request message, a sender _ IP is an IP recorded in an arp table, a target _ IP is the own IP, sending an arp response, and a fifth test point: when receiving an arp request message, a sender _ IP is not in the arp table, but a target _ IP is self, writing the arp table, sending an arp response, and a sixth test point: when receiving an arp request message, if the sender _ IP is not in the arp table and the target _ IP is not self, discarding the arp request message;
step S43: the third node is converted into three test points which are respectively a seventh test point: when receiving the arp reply, the target _ IP is not self, abandoning the arp reply message, and the eighth test point: when receiving the arp reply, the target _ IP is itself, if the target _ IP is in the arp table, the arp table is updated, and the ninth test point: when receiving the arp response, the target _ IP is the own IP, and if the target _ IP is not in the arp table, the target _ IP is written into the arp table;
step S5: and converting the test points of the first node, the second node and the third node into test cases for testing.
2. The use case design method according to claim 1, wherein the step S5 further comprises the steps of:
step S51: respectively converting a first test point and a second test point of a first node into a first test case and a second test case, wherein the first test case is as follows: configuring the port IP address of the first switch/router to 192.168.20.1, configuring the network card IP address of the first PC to 192.168.20.111, ping the network card IP address of the first PC on the first switch/router, and then starting packet capture by the network card of the first PC, where the packet capture result is that the first PC can capture an arp request message sent by the first switch/router, and the second test case is: configuring a port IP address of the first switch/router to 192.168.20.1, configuring a network card IP address of the first PC to 192.168.20.111, pinging the network card IP address of the first PC on the first switch/router, stopping pinging the network card IP address of the first PC by the first switch/router, starting packet grabbing by the first PC, and pinging the network card IP address of the first PC again by the first switch/router, wherein the packet grabbing result of the network card of the first PC is that the network card of the first PC cannot grab an arp request message sent by the first switch/router and can only grab an icmp message;
step S52: respectively converting a third test point, a fourth test point, a fifth test point and a sixth test point of a second node into a third test case, a fourth test case, a fifth test case and a sixth test case, wherein the third test case is as follows: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, after the second PC pings the port IP address of the second switch/router, querying in an arp table of the second switch/router, if the arp table of the second switch/router has the network card IP address of the second PC, constructing an arp request message on the second PC, sending a sender _ IP address 192.168.20.111 and a target _ IP address 192.168.20.1 to the second switch/router, and querying in the arp table of the second switch/router, if the arp table of the second switch/router has the dynamic entry of the sender _ IP address 192.168.20.111, updating the aging time, and using a fourth test case: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, ping the port IP address of the second switch/router on the second PC, if the port IP address of the second switch/router can be ping, clearing the arp table on the second PC, and then ping the port IP address of the second switch/router on the second PC, where the second PC can receive an arp reply message sent by the second switch/router, and the fifth test case is: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, after the second PC pings the port IP address of the second switch/router, the second switch/router queries in an arp table, and when the arp table has a dynamic entry of the network card IP address of the second PC, the second switch/router sends an arp reply message, where a sixth test case is: configuring the port IP address of the second switch/router to 192.168.20.1, configuring the network card IP address of the second PC to 192.168.20.111, starting packet capture by the second PC, constructing an arp request message on the second PC, and sending a sender _ IP address 192.168.20.101 and a target _ IP address 192.168.20.120 to the second switch/router, so that the second PC cannot capture a response message sent by the second switch/router;
step S53: respectively converting a seventh test point, an eighth test point and a ninth test point of the third node into a seventh test case, an eighth test case and a ninth test case, wherein the seventh test case is as follows: configuring 192.168.20.1 for the port IP address of the first switch/router, configuring 192.168.20.111 for the network card IP address of the first PC, constructing an arp reply message on the first PC, and sending a sender _ IP address 192.168.20.101 and a target _ IP address 192.168.20.120 to the first switch/router, where the first switch/router sends no message, and then querying an arp table of the first switch/router, where the arp table of the first switch/router does not have a sender _ IP address, and the eighth test case is: configuring 192.168.20.1 for the port IP address of the first switch/router, configuring 192.168.20.111 for the network card IP address of the first PC, constructing an arp reply message on the first PC, and sending a sender _ IP address 192.168.20.111 and a target _ IP address 192.168.20.1 to the first switch/router, where the first switch/router queries an arp table, and if the sender _ IP address exists in the arp table, the aging time is updated, in a ninth test case: configuring 192.168.20.1 for the port IP address of the first switch/router, configuring 192.168.20.111 for the network card IP address of the first PC, constructing an arp reply message on the first PC, sending a sender _ IP address 192.168.20.101 and a target _ IP address 192.168.20.1 to the first switch/router, querying an arp table by the first switch/router, and writing the sender _ IP address into the arp table if the sender _ IP address does not exist in the arp table.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810828823.1A CN109150654B (en) | 2018-07-25 | 2018-07-25 | Use case design method based on protocol consistency of path |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810828823.1A CN109150654B (en) | 2018-07-25 | 2018-07-25 | Use case design method based on protocol consistency of path |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109150654A CN109150654A (en) | 2019-01-04 |
| CN109150654B true CN109150654B (en) | 2021-08-17 |
Family
ID=64798290
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810828823.1A Active CN109150654B (en) | 2018-07-25 | 2018-07-25 | Use case design method based on protocol consistency of path |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109150654B (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1540928A (en) * | 2003-10-27 | 2004-10-27 | 中国科学院计算技术研究所 | Method for designing cases for testing consistency with protocol of internet of next generation |
| CN1750512A (en) * | 2005-09-27 | 2006-03-22 | 杭州华为三康技术有限公司 | Single broadcast reverse path repeating method |
| CN102177683A (en) * | 2008-08-08 | 2011-09-07 | 惠普开发有限公司 | End-to-end network access analysis |
| CN105763392A (en) * | 2016-02-19 | 2016-07-13 | 中国人民解放军理工大学 | Industrial control protocol fuzzing test method based on protocol state |
| CN105824753A (en) * | 2016-03-17 | 2016-08-03 | 浪潮通用软件有限公司 | Method for designing object-oriented test case |
| CN107395391A (en) * | 2017-06-06 | 2017-11-24 | 中国电力科学研究院 | A kind of low-voltage power line bandwidth carrier system for testing unification of communication protocol and method |
| CN108270640A (en) * | 2017-09-09 | 2018-07-10 | 国网浙江省电力公司杭州供电公司 | A kind of intelligence battalion is with information integrated system Information Interoperability conformance test method |
-
2018
- 2018-07-25 CN CN201810828823.1A patent/CN109150654B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1540928A (en) * | 2003-10-27 | 2004-10-27 | 中国科学院计算技术研究所 | Method for designing cases for testing consistency with protocol of internet of next generation |
| CN1750512A (en) * | 2005-09-27 | 2006-03-22 | 杭州华为三康技术有限公司 | Single broadcast reverse path repeating method |
| CN102177683A (en) * | 2008-08-08 | 2011-09-07 | 惠普开发有限公司 | End-to-end network access analysis |
| CN105763392A (en) * | 2016-02-19 | 2016-07-13 | 中国人民解放军理工大学 | Industrial control protocol fuzzing test method based on protocol state |
| CN105824753A (en) * | 2016-03-17 | 2016-08-03 | 浪潮通用软件有限公司 | Method for designing object-oriented test case |
| CN107395391A (en) * | 2017-06-06 | 2017-11-24 | 中国电力科学研究院 | A kind of low-voltage power line bandwidth carrier system for testing unification of communication protocol and method |
| CN108270640A (en) * | 2017-09-09 | 2018-07-10 | 国网浙江省电力公司杭州供电公司 | A kind of intelligence battalion is with information integrated system Information Interoperability conformance test method |
Non-Patent Citations (1)
| Title |
|---|
| 面向需求覆盖的航天软件测试用例优化方法;王红园，郭永飞，姬琪;《光学精密工程》;20140131;正文第1栏-第10栏及图2 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109150654A (en) | 2019-01-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7096264B2 (en) | Network analyzer having distributed packet replay and triggering | |
| KR101574167B1 (en) | Network system and method of controlling path | |
| CN108173691B (en) | Cross-device aggregation method and device | |
| CN108011746B (en) | IP-level global Internet topology mapping method based on Traceroute and SNMP protocol | |
| CN101155072B (en) | Method, device, and system for detecting layer 2 loop | |
| EP3905622A1 (en) | Botnet detection method and system, and storage medium | |
| WO2019037738A1 (en) | Method and apparatus for detecting network fault | |
| CN101272291A (en) | Network appliance testing method and system | |
| US9137305B2 (en) | Information processing device, computer-readable recording medium, and control method | |
| US20020059169A1 (en) | System for quickly collecting operational data for internet destinations | |
| WO2006068112A1 (en) | Sensor device, retrieval device, and relay device | |
| US9825855B2 (en) | Information processing apparatus and route setting method | |
| CN101729391A (en) | Method, node and system for acquiring link aggregation group information | |
| JP2007228382A (en) | Topology information collection program, apparatus, and method | |
| CN111245969B (en) | Large-scale network alias analysis method oriented to IP positioning | |
| US8472420B2 (en) | Gateway device | |
| US20130329572A1 (en) | Misdirected packet statistics collection and analysis | |
| CN105306368A (en) | Data message transmission method and device | |
| JP2016167799A (en) | Network monitoring method and apparatus, and packet filtering method and apparatus | |
| CN109150654B (en) | Use case design method based on protocol consistency of path | |
| US20240022507A1 (en) | Information flow recognition method, network chip, and network device | |
| JP3943581B1 (en) | Apparatus and method for detecting a load balancing system. | |
| CN107222359B (en) | Link abnormity detection method and system in IS-IS network | |
| US8811233B2 (en) | Topology detection method and topology detection apparatus | |
| CN112543142B (en) | Method and device for realizing RSTP ring network protocol based on FPGA |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |