CN110798371A - Testing method of private communication protocol - Google Patents
Testing method of private communication protocol Download PDFInfo
- Publication number
- CN110798371A CN110798371A CN201810874224.3A CN201810874224A CN110798371A CN 110798371 A CN110798371 A CN 110798371A CN 201810874224 A CN201810874224 A CN 201810874224A CN 110798371 A CN110798371 A CN 110798371A
- Authority
- CN
- China
- Prior art keywords
- test
- data
- communication protocol
- private communication
- correct
- 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.)
- Withdrawn
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
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
-
- 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/14—Arrangements for monitoring or testing data switching networks using software, i.e. software packages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/26—Special purpose or proprietary protocols or architectures
Abstract
The invention relates to a testing method of a private communication protocol, which is used for testing the private communication protocol of a tested end according to the designed private communication protocol, and comprises the following steps: generating a test configuration file, wherein the test configuration file comprises an embedded script and a data message consisting of correct data fields; running the embedded script, and sequentially generating each data field value, thereby dynamically generating a test data message; running a script and dynamically generating a test data stream according to the test data message; and the generated test data stream is sent to the tested end, and whether the private communication protocol of the tested end passes the test or not is judged according to the data message returned after the private communication protocol of the tested end analyzes the test data stream. The testing method provided by the invention solves the problem that the private communication protocol has no unified and perfect testing method.
Description
Technical Field
The invention belongs to the field of computer communication, and particularly relates to a testing method of a private communication protocol.
Background
In distributed software development, data exchange between systems is an essential and important component. Data exchange is accomplished primarily by means of communications, which must rely on communication protocols. Communication protocols generally fall into two broad categories, one being the public communication protocol, generally defined by RFC, e.g., HTTP, FTP, DNS, etc.; the other type is a private communication protocol which has the characteristics of confidential format, specific use environment, various types, variable formats and the like.
For a public communication protocol, the communication protocol is fixed and public, so that a plurality of users exist, and a plurality of special test software or test instruments can complete the test work in the market. But for a larger number of proprietary communication protocols, conventional test tools or meters cannot perform testing.
The design and development of the private communication protocol are technically demanding works, and the level of design and the quality of development directly affect the availability, performance and safety of the whole system, so complete testing means are required.
In the design and development of actual proprietary communication protocols, there are usually several common problems or errors:
1. the design of the designer is not perfect, for example, the problems of packet loss, packet disorder and the like are not considered, so that the communication process is unstable, some abnormalities are caused, and unpredictable results are caused.
2. The deviation of the understanding of the protocol between the designer and the code writer or between developers of different software modules occurs, including the basic format of the protocol message, the receiving and sending sequence of the protocol message, and the like, and as a result, the communication result is abnormal and is not in line with the expected result, so that the software developed among different departments cannot be communicated.
3. A code writer has mistakes or negligence in understanding each field of the basic message, and the value of the basic field is not protected, so that unexpected problems occur in communication, and even the whole software module is crashed, and the safety of the whole system is endangered. This is also the method used by most network attacks.
4. The communication message sequence processing, including packet loss and packet retransmission processing, by a code writer is deviated in understanding or neglected in code writing, so that the communication result is abnormal.
5. The algorithm of concurrent processing of communication data streams is unreasonable for a code writer, and as a result, no problem exists in processing a small amount of concurrent communication.
6. Errors occurring in communication are difficult to track and position, because data messages or data streams causing the errors are hidden in a large number of communication messages, when the errors are found, original data messages are discarded, error fields cannot be directly recovered, corresponding software modules cannot be effectively positioned and modified, and development efficiency is reduced.
7. The code writer has insufficient understanding on the network communication principle, such as unpacking and packet sticking problems of the TCP protocol, packet loss and disorder problems of the UDP protocol, and the like. Unforeseen packet loss problems occur in actual communication, and communication abnormity is caused.
8. For professional testers, there is currently no uniform, efficient and standardized method for testing proprietary communication protocols. Testers typically test proprietary communication protocols in two ways: one is to manually write test programs for basic conformance testing, which requires special test software to be written for different proprietary protocols. And analyzing whether each field is correct or not by a software programming method, or capturing the test data stream in a network packet capturing mode and manually analyzing whether each field is correct or not. To construct different test data messages or data streams requires modification of the test software. This approach requires testers to write test programs, and different testers have different levels and understanding of communication tests, and the test function of the test software has uncertainty. And the test program is special, has no reusability, and can not be further tested. Therefore, the method has high requirements on testers and low efficiency, consumes a lot of time of the testers, and is not sound in testing. Another method is to manually construct each data packet through some transceiving package software to perform a simple transceiving test. And capturing the test data stream in a network packet capturing mode, and manually analyzing whether each field is correct or not. To construct different test data packets or data streams, the data packets need to be modified manually. This approach can only perform some of the most basic tests, is less efficient, is not able to perform more complex tests, and is not robust. In addition, the communication process is composed of a series of data messages, each data message is composed of a series of fields, the value range of each data field is huge, and a large number of test cases need to be designed for discovering hidden problems in communication. Execution of each test case is also difficult, requiring the tester to write the test code itself. It follows that it is difficult to perform effective testing using conventional manual testing methods.
At present, interface testing mainly depends on manual construction of testing data by testers, and whether data values are correct or not is directly observed, or testing scripts are manually written for implementation, and comprehensive automatic testing tool support is lacked. As software systems become larger and more complex, and proprietary communication protocols become more and more complex, relying on manual construction of test data has not been able to meet current test needs in terms of workload and time.
Therefore, a new definition and testing method for the private communication protocol is needed, which can adapt to various different private communication protocols, can generate test cases rapidly and intelligently, and help development or testing personnel to perform complete testing on the private communication protocol.
Disclosure of Invention
The invention provides a testing method of a private communication protocol, which can automatically generate data messages conforming to the private communication protocol and generate data streams, automatically check whether the communication result is correct, and carry out comprehensive tests on the consistency, performance and robustness of the tested communication equipment or software, thereby solving the technical problems.
The invention has the beneficial effects that:
the universal definition and test method of the private communication protocol can completely and accurately describe the changeable private communication protocol, and simultaneously provides a complete test scheme. The invention can save and recover the definition and test scheme of the private communication protocol by the way of the configuration file, can test rapidly and repeatedly, greatly improve the development and test efficiency of the communication software, shorten the development and test period of the communication software, solve the problems that the private communication protocol is complex and changeable and has no unified definition method and the private communication protocol has no unified and perfect test method.
Drawings
Fig. 1 is a flow chart of a testing method of the private communication protocol proposed by the present invention;
fig. 2 is a schematic diagram of a data packet generation and access method in the testing method of the private communication protocol proposed by the present invention;
fig. 3 is a schematic diagram of a script operation flow in the testing method of the private communication protocol according to the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to specific embodiments and the accompanying drawings. It will be appreciated by those skilled in the art that the present invention is not limited to the figures and the following examples.
The invention provides a testing method of a private communication protocol, which is used for testing the private communication protocol of a tested end according to the designed private communication protocol. The testing method is shown in fig. 1 and comprises the following steps:
step S101: generating a test configuration file;
the configuration file for testing comprises an embedded script and a data message consisting of correct data fields, wherein the correct data fields conform to the definition of the designed private communication protocol on the data fields, and the correct data message conforms to the definition of the designed private communication protocol on the data message.
The embedded script runs based on the data field and is used for dynamically generating a test data message and checking the correctness of the data field.
The definition of the data field includes: defining the type of data fields according to the designed private communication protocol, defining the initial correct values of the data fields through the embedded scripts, defining the logic relationship among the data fields through the embedded scripts, and defining the correctness checking rules of the data field values through the embedded scripts.
The plurality of data field definitions form a data message definition. The data messages include two categories, namely data messages to be sent and data messages to be received.
The data field definition in the invention is compatible with C/C + +, which is convenient to import into the data field definition and the data message definition in the form of C/C + + header file, and after the data message is defined, the data field is defined in the data message. Table 1 below shows the type of data field, the bit or byte length, and the maximum length thereof.
| Data field type | C/C + + type | Bit length | Length of Byte | Maximum length |
| char | char | √ | 8 | |
| uchar | unsiged char | √ | 8 | |
| short | short | √ | 16 | |
| ushort | unsigned short | √ | 16 | |
| int | int | √ | 32 | |
| uint | unsigned int | √ | 32 | |
| string | char* | √ | 2048 | |
| bin | unsigned char* | √ | 2048 |
TABLE 1 definition of data fields
The data field access method in the invention is based on XPATH data field access method, as shown in Table 2.
Table 2 XPATH data field access method
For the above C/C + + compatible data field types, each data packet is represented by an n-ary tree. The data packet is composed of a root node, a series of lower nodes and a final data field, and the lower nodes can also comprise a series of lower nodes and a final data field. Each data field must be a leaf node. Each leaf node can be accurately located by XPATH.
XPATH is used to access data fields within a data message tree. The root node of the data message tree, and each lower layer node and leaf node (data field) have a name, and the names of the nodes in the same layer are required to be unique. Any data field of any data message can be conveniently accessed through a series of names.
Fig. 2 shows a data packet generating and accessing method according to the present invention, in which logical relationships between data fields can be summarized into three main categories:
(1) fixing structure
All attributes of each field of such messages are predefined.
(2) TLV (type + length + content) structure
This type of packet consists of a series of sub-TLV structures, the length of V being dynamic and specified by the value of L.
(3) TV (type + content) architecture
This type of message consists of a series of sub-TV structures, the length of V is dynamic, and the specific value is related to T.
Any one of the data fields can be accurately read, written, or generated through XPATH. All data fields of the data message tree are sequentially generated and spliced together to generate a complete data message. Similarly, the data message tree can be obtained by sequentially reading the received data content into each data field.
In the present invention, the embedded scripting language supports basic assignments, comparisons, judgments, and expressions, as shown in Table 3 below.
| ＝ | Endowing straight |
| ＝＝ | Compare equal |
| ！＝ | Are relatively unequal |
| ？＝ | Calling C/C + + extended function |
TABLE 3 Embedded script supported operators
A complete embedded script format is as follows:
[Domain：：]+XPATH+Operator+Express+[condition]
wherein an Operator (Operator) supports "═ -", "═ and"! Is equal to "and"? =.
The expression (Express) supports "+", "-", "/", "()" and "@". Where @ denotes a regular expression. For example: here, "http. response. result @" 200OK "means that whether or not the http protocol response result includes a" 200OK "string is determined.
The conditional expression [ condition ] supports "if", and the previous statement is executed when [ condition ] is true.
The embedded script of the invention can adopt a Cobra embedded script, the Cobra embedded script supports C/C + + extension function, and the operator is? =. The format is as follows:
XPATH？＝ExampleExtFunc(index)
example extfunc: the name of the extension function.
index: arbitrary numbers, used for example extfunc to distinguish between different call points.
The invention can provide additional functions through C/C + + extension functions, and the extension mode provides a flexible framework, so that various complex functions can be conveniently added.
Extension function prototype definition:
and returning a value: true indicates success; false indicates failure and an error message is returned by the parameter info _ out _ buf.
Step S102: generating a test data stream;
running an embedded script, sequentially generating each data field value according to the definition of a designed private communication protocol on the data field, splicing the data field values into a complete data message, and dynamically generating a test data message; and running the running script, and dynamically generating a test data stream according to the test data message.
The running script runs based on the data message and is used for dynamically generating a test data stream and controlling the operations of sending, receiving, circulating, delaying and the like of the data message in the data stream.
In the running script, parameters such as circulation, receiving and sending of data messages, sending and retransmitting of different data messages, receiving overtime and the like are defined. And controlling a receiving and sending sequence by running a script, and combining a plurality of data messages together to form a basic data stream.
The runtime scripting language of the present invention supports the configuration of data streams by running the scripting language, as shown in table 4. And 6 specific commands of send, receive, sleep, exhaust, pipe and loop are supported. Different commands have different additional parameters. And the back-end test core reads and executes the command to complete the actual test.
Table 4 running script supported commands
The script running flow of the present invention is shown in fig. 3, the test data message and the data stream are both dynamically generated along with the running of the script, and the running script includes the running script and the embedded script. The running script runs based on the data message, and the embedded script runs based on the data field in the data message. The embedded scripts are classified into two types according to calling time points:
(1) data field front point call: invoked before generating or receiving a data field.
(2) Data field post-point call: invoked after generating or receiving a data field.
The test software combines the run script and the embedded script in an intersecting manner to form a complete basic test logic.
In fig. 3, taking the data message basic definition Send _1 as an example, the running script runs the data message basic definition Send _1 embedded script through the Send command, generates a test data message, and sends the test data message to the device under test. The tested equipment receives the data message and sends back the Rcv _1 data message, a Receive command is operated to Receive the data message, the embedded script is operated according to the basic definition of the Rcv _1 data message to generate a data field, and whether the data field meets the expectation is checked. Other data message flows within the data stream are similar.
Step S103: testing the private communication protocol of the tested end;
and the generated test data stream is sent to the tested end, and whether the private communication protocol of the tested end passes the test or not is judged according to the data message returned after the private communication protocol of the tested end analyzes the test data stream.
The embedded script receives each data field value in the returned data message in turn according to the definition of the designed private communication protocol to the data field, and checks whether the data field value is correct according to the data field check rule.
The test comprises a consistency test of the private communication protocol of the tested end, and is used for testing whether the definition of the private communication protocol of the tested end is consistent with the designed private communication protocol.
The consistency test is to generate real (correct) data messages and data streams according to the logic relation between the basic definition of the data messages and the data streams and the data fields defined by the embedded scripts according to the designed private communication protocol, and carry out the consistency test; and checking whether the data message returned by the tested end has errors according to the data field correctness checking rule defined by the embedded script. Wherein the real data message and data flow in the consistency test is the correct data message and data flow.
Before the consistency test is carried out, consistency test rules such as a correct data field value, an acceptable range of timeout, an expected test quantity and the like need to be configured.
When the consistency test is performed, in the step S102, the test data packet is an embedded script that generates a correct test data packet according to the correct data field, the running script generates a test data stream according to the correct test data packet, and only one test data stream is generated at a time; in step S103, the generated test data stream is sent to the tested end, and a single consistency test only initiates a single communication test to the tested end; if the data message returned by the tested end is analyzed by the embedded script and accords with the expected consistency test, the private communication protocol of the tested end passes the consistency test; and then, regenerating the test data flow, and carrying out consistency test on the private communication protocol of the tested end again until the private communication protocol of the tested end fails to pass a certain consistency test or the number of times of the consistency test reaches the expected test number, wherein the correct data messages used in each consistency test are different, and the generated test data flow is different.
Expected results of the conformance test include: and successfully receiving and transmitting the test data message, if overtime exists in a defined acceptable range, checking the correctness of data fields in all returned data messages according to the correctness checking rule of the data fields defined by the embedded script.
The test also comprises a performance test of the private communication protocol of the tested end, and the performance test is used for testing whether the private communication protocol of the tested end can process the multi-path concurrent test data stream.
The performance test is to generate real data message and data flow according to the basic definition of the data message and data flow and the logic relation between the fields defined by the embedded script, and perform the performance test after performing multi-path expansion; and checking whether the data message returned by the tested end has errors according to the data field correctness checking rule. Wherein, the real data message and data flow in the performance test are the correct data message and data flow.
Before performance testing, performance testing rules such as the concurrency number and the concurrency number extremum of the test data flow increasing along with time need to be configured.
The performance test is performed after the consistency test is passed.
When performing a performance test, in the step S102, the test data packet is an embedded script that generates a correct test data packet according to the correct data field, the running script generates a basic test data stream according to the correct test data packet, only one basic test data stream is generated at a time, and the generated basic test data stream is expanded into multiple concurrent data streams; in step S103, the multiple paths of concurrent data streams are sent, and a performance test only initiates a communication test to the tested end, that is, the multiple paths of concurrent data streams are sent to the tested end at the same time; if the data message returned by each path of concurrent data flow at the tested end is analyzed by the embedded script and accords with the expected performance test, the private communication protocol of the tested end passes the performance test; and then, increasing the concurrency number of the data streams, and performing performance test on the private communication protocol of the tested end again until the private communication protocol of the tested end fails the performance test of a certain time or the concurrency number of the data streams reaches the concurrency number extreme value.
The expected results of the performance tests include: and (4) successfully receiving and transmitting all the data messages, if the overtime is within the defined acceptable range, checking the correctness of the data fields in all the returned data messages according to the data field correctness checking rule defined by the embedded script.
Further, the private communication protocol of the tested end can be subjected to multiple performance tests, the correct data messages used in each performance test are different, the generated test data flows are different, and the concurrent number and the extreme value of the concurrent number of the test data flows increasing along with time can also be different.
The test also comprises a robustness test of the private communication protocol of the tested end, which is used for testing whether the private communication protocol of the tested end can bear the attack of the error data flow.
The robustness test is to automatically and sequentially insert errors into different fields according to the basic definition of the data message and the data stream and the logic relation between the fields defined by the embedded script, generate a real data message and a real data stream, and perform the robustness test, wherein the real data message and the real data stream in the robustness test are the wrong data message and the wrong data stream. During the robustness test, the embedded script ignores the checking rule of the correctness of the data field.
Before the robustness test is carried out, robustness test rules such as data fields needing to be automatically inserted with errors, inserted error value ranges and test case generation numbers need to be configured.
The robustness test is performed after the conformance test passes, or after the performance test passes.
When performing the robustness test, in the step S102, the test data packet includes a correct test data packet and a test data packet containing an error, where the correct test data packet is a test data packet generated by the embedded script according to the correct data field; the test data messages containing errors are generated by automatically inserting errors into correct data fields by the embedded script according to test rules, the quantity of the test data messages containing errors is the quantity generated by the test cases, and the inserted error data fields of the test data messages containing errors are different and/or the inserted error values are different; the running script generates a correct test data stream according to a correct test data message, and the running script generates a test data stream containing an error according to a test data message containing the error; in step S103, the generated test data stream is sent to the tested end in a manner that a test data stream containing an error and a correct test data stream are alternated, and if the data packet returned by the tested end to each correct test data stream is analyzed by the embedded script and meets the expectation of the robustness test, the private communication protocol of the tested end passes the robustness test.
Generally, the robustness test is performed only once, but in order to improve the test accuracy, the robustness test may be performed on the private communication protocol of the tested end for multiple times, and the correct data message used in each robustness test is different, the value of the error data field may be different, and the position of the error insertion may be different.
Expected results of the robustness test include: the tested end can ignore the test data flow containing the error and correctly respond to the subsequent correct test data flow; and (3) not checking the correctness of the data field of the test data stream containing the error, and completely checking the correct test data stream, wherein the check comprises that all data messages are successfully transmitted and received, the overtime is in a defined acceptable range, and the data field of all returned data messages is checked to be correct according to the data field correctness checking rule defined by the embedded script. And judging the state of the tested end according to the checking result of the correct test data stream to finish the robustness test.
The embodiments of the present invention have been described above. However, the present invention is not limited to the above embodiment. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (10)
1. A testing method of private communication protocol is used for testing the private communication protocol of a tested end according to the designed private communication protocol, and is characterized in that the testing method comprises the following steps:
step S101: generating a test configuration file;
the test configuration file comprises an embedded script and a data message consisting of correct data fields, the correct data fields conform to the definition of the designed private communication protocol on the data fields, and the correct data message conforms to the definition of the designed private communication protocol on the data message;
the embedded script runs based on the data field and is used for dynamically generating a test data message and checking the correctness of the data field;
the definition of the data field comprises: defining the type of data fields according to a designed private communication protocol, defining initial correct values of the data fields through embedded scripts, defining logic relations among the data fields through the embedded scripts, and defining data field value correctness checking rules through the embedded scripts;
step S102: running an embedded script, sequentially generating each data field value according to the definition of a designed private communication protocol on the data field, splicing the data field values into a complete data message, and dynamically generating a test data message; running the running script, and dynamically generating a test data stream according to the test data message;
step S103: and the generated test data stream is sent to the tested end, and whether the private communication protocol of the tested end passes the test or not is judged according to the data message returned after the private communication protocol of the tested end analyzes the test data stream.
2. The testing method according to claim 1, wherein the testing comprises a conformance test of the private communication protocol of the tested terminal for testing whether the definition of the private communication protocol of the tested terminal conforms to the designed private communication protocol;
in step S102, the test data packet is an embedded script that generates a correct test data packet according to the correct data field, the running script generates a test data stream according to the correct test data packet, and only one test data stream is generated at a time;
in step S103, the generated test data stream is sent to the tested end, and a single consistency test only initiates a single communication test to the tested end; if the data message returned by the tested end is analyzed by the embedded script and accords with the expected consistency test, the private communication protocol of the tested end passes the consistency test; and then, regenerating the test data stream, and performing consistency test on the private communication protocol of the tested end again until the private communication protocol of the tested end fails a certain consistency test or the number of times of the consistency test reaches the expected test number.
3. The testing method of claim 2, wherein the expected results of the conformance test comprise: and successfully receiving and transmitting the test data message, if overtime exists in a defined acceptable range, checking the correctness of data fields in all returned data messages according to the correctness checking rule of the data fields defined by the embedded script.
4. The testing method according to claim 3, wherein the testing further comprises a performance test of the private communication protocol of the tested terminal, for testing whether the private communication protocol of the tested terminal can process multiple concurrent test data streams; the performance test is performed after the conformance test;
when performing a performance test, in the step S102, the test data packet is an embedded script that generates a correct test data packet according to the correct data field, the running script generates a basic test data stream according to the correct test data packet, only one basic test data stream is generated at a time, and the generated basic test data stream is expanded into multiple concurrent data streams;
in step S103, the multiple paths of concurrent data streams are sent, and a performance test only initiates a communication test to the tested end, that is, the multiple paths of concurrent data streams are sent to the tested end at the same time; if the data message returned by each path of concurrent data flow at the tested end is analyzed by the embedded script and accords with the expected performance test, the private communication protocol of the tested end passes the performance test; and then, increasing the concurrency number of the data streams, and performing performance test on the private communication protocol of the tested end again until the private communication protocol of the tested end fails the performance test of a certain time or the concurrency number of the data streams reaches the concurrency number extreme value.
5. The test method of claim 4, wherein the expected results of the performance test comprise: and (4) successfully receiving and transmitting all the data messages, if the overtime is within the defined acceptable range, checking the correctness of the data fields in all the returned data messages according to the data field correctness checking rule defined by the embedded script.
6. The testing method according to claim 5, wherein the testing further comprises a robustness test of the private communication protocol of the tested end for testing whether the private communication protocol of the tested end can withstand the attack of the error data stream; the robustness test is performed after the conformance test or after the performance test;
when performing the robustness test, in the step S102, the test data packet includes a correct test data packet and a test data packet containing an error, where the correct test data packet is a test data packet generated by the embedded script according to the correct data field; the test data messages containing errors are generated by automatically inserting errors into correct data fields by the embedded script according to test rules, the quantity of the test data messages containing errors is the quantity generated by the test cases, and the inserted error data fields of the test data messages containing errors are different and/or the inserted error values are different; the running script generates a correct test data stream according to a correct test data message, and the running script generates a test data stream containing an error according to a test data message containing the error;
in step S103, the generated test data stream is sent to the tested end in a manner that a test data stream containing an error and a correct test data stream are alternated, and if the data packet returned by the tested end to each correct test data stream is analyzed by the embedded script and meets the expectation of the robustness test, the private communication protocol of the tested end passes the robustness test.
7. The testing method of claim 6, wherein the expected results of the robustness testing comprise: the tested end can ignore the test data flow containing the error and correctly respond to the subsequent correct test data flow; and (3) not checking the correctness of the data field of the test data stream containing the error, and completely checking the correct test data stream, wherein the check comprises that all data messages are successfully transmitted and received, the overtime is in a defined acceptable range, and the data field of all returned data messages is checked to be correct according to the data field correctness checking rule defined by the embedded script.
8. The test method according to any one of claims 1 to 7, wherein the data field definitions are compatible with C/C + +, wherein the data field access method is an XPATH-based data field access method, wherein each data packet is represented by an n-ary tree, wherein each data field is a leaf node, and wherein each leaf node is located by XPATH.
9. The test method of claim 8, wherein the logical relationship between the data fields comprises the following three categories:
(1) the fixing structure comprises: all attributes of each data field of the data message are predefined;
(2) TLV structure: the data message is composed of a series of sub TLV structures, wherein T represents type, L represents length, V represents content, and the length of V is dynamic and is specified by the value of L;
(3) the TV structure: the data message is composed of a series of sub TV structures, the length of V is dynamic, and the specific value is related to T.
10. The test method according to claim 9, wherein the run script language supports configuring data streams by running script language, supporting 6 specific commands: send, receive, sleep, exhaust, pipe, loop;
the embedded scripts are classified into two types according to calling time points:
(1) data field front point call: invoked before generating or receiving a data field;
(2) data field post-point call: invoked after generating or receiving a data field.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810874224.3A CN110798371A (en) | 2018-08-03 | 2018-08-03 | Testing method of private communication protocol |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810874224.3A CN110798371A (en) | 2018-08-03 | 2018-08-03 | Testing method of private communication protocol |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110798371A true CN110798371A (en) | 2020-02-14 |
Family
ID=69426187
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810874224.3A Withdrawn CN110798371A (en) | 2018-08-03 | 2018-08-03 | Testing method of private communication protocol |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110798371A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111737097A (en) * | 2020-06-05 | 2020-10-02 | 浪潮电子信息产业股份有限公司 | Performance test method and related device of stream processing system |
| CN114338487A (en) * | 2021-12-17 | 2022-04-12 | 国网电力科学研究院有限公司 | Low-voltage intelligent circuit breaker communication protocol testing device and testing method |
-
2018
- 2018-08-03 CN CN201810874224.3A patent/CN110798371A/en not_active Withdrawn
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111737097A (en) * | 2020-06-05 | 2020-10-02 | 浪潮电子信息产业股份有限公司 | Performance test method and related device of stream processing system |
| CN111737097B (en) * | 2020-06-05 | 2022-06-07 | 浪潮电子信息产业股份有限公司 | Performance test method and related device of stream processing system |
| CN114338487A (en) * | 2021-12-17 | 2022-04-12 | 国网电力科学研究院有限公司 | Low-voltage intelligent circuit breaker communication protocol testing device and testing method |
| CN114338487B (en) * | 2021-12-17 | 2023-06-20 | 国网电力科学研究院有限公司 | Communication protocol testing device and method for low-voltage intelligent circuit breaker |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Tappler et al. | Model-based testing IoT communication via active automata learning | |
| US8336102B2 (en) | Delivering malformed data for fuzz testing to software applications | |
| CA2670231C (en) | Automated testing and control of networked devices | |
| US20080301813A1 (en) | Testing Software Applications with Schema-based Fuzzing | |
| CN100570580C (en) | The proving installation of simple network management protocol software and method of testing thereof | |
| CN110933095A (en) | Message parsing method and device | |
| CN111399828B (en) | Model-driven logic device modeling method and terminal | |
| CN110266554B (en) | Testing method of private communication protocol | |
| CN110798371A (en) | Testing method of private communication protocol | |
| CN101656642B (en) | Method, device and system for testing authentication performance of network access equipment | |
| CN104899134A (en) | Automatic domain name registration server testing system and method | |
| CN112583663B (en) | Automatic network performance testing method based on domestic operating system | |
| WO2021128936A1 (en) | Message processing method and apparatus | |
| CN114024871B (en) | Chip verification method, system, computer equipment and readable storage medium | |
| CN107579871B (en) | Method and system for generating distributed test script based on model detection | |
| CN111314805B (en) | Debugging method and device for intercommunication OMCI (OMCI) messages of GPON (gigabit passive optical network) system | |
| CN115357513A (en) | Program fuzzing test method, device, equipment and storage medium | |
| Hogrefe | Validation of SDL systems | |
| CN114416597A (en) | Test case record generation method and device | |
| Vizovitin et al. | Verifying UCM specifications of distributed systems using colored Petri nets | |
| CN110377463A (en) | Interface test method, device, terminal and computer readable storage medium | |
| Deussen et al. | Formal test purposes and the validity of test cases | |
| US10191826B2 (en) | Methods, systems, and computer readable media for providing an anticipated data integrity check | |
| CN114531335B (en) | Method, equipment and device for detecting management information base data | |
| CN117596126B (en) | Monitoring method for high-speed network abnormality in high-performance cluster |
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 | ||
| WW01 | Invention patent application withdrawn after publication | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20200214 |