A method and system for generating a test packet of a communication protocol based on a tag field

Abstract

The application provides a kind of communication protocol test message generation method and system based on mark field, it is related to communication protocol test technical field.The application receives the protocol message template string embedded with mark field, so that the user can describe message structure in an intuitive, non-programming way;Parsing process can automatically identify these mark fields defined by preset mark syntax, and extract their attribute information;Subsequently, according to the attribute information, the dynamic value generation logic associated with it is automatically executed, so as to obtain accurate filling value;Finally, these filling values are automatically filled into the corresponding positions of the mark field in the protocol message template string, to generate a complete protocol test message.Under the synergistic effect of the above technical effects, the automatic and deterministic construction of the protocol message containing complex dynamic fields is realized, thereby significantly improving the efficiency and accuracy of the protocol test message generation, and greatly enhancing the generality and reusability of the message template.

Description

Technical Field

[0001] This invention relates to the field of communication protocol testing technology, and in particular to a method and system for generating communication protocol test messages based on a tag field. Background Technology

[0002] In the field of communication protocol conformance testing, test engineers need to construct various messages that conform to protocol specifications and verify whether the device under test's (DUT) responses to these messages meet expectations. In existing technologies, protocol test messages are typically generated using the following methods: The first method is manual framing. Test engineers need to construct the protocol message byte by byte. For dynamic fields in the message, such as timestamps, sequence numbers, and checksums, the specific values ​​of these fields in the current context need to be calculated manually. This method is inefficient, and the manual calculation and filling process is prone to human error, especially when the message structure is complex or dynamic fields have dependencies.

[0003] The second approach is programmatic implementation. Test engineers use programming languages ​​to write test scripts, which automatically construct protocol messages. This method requires test engineers to have programming skills, making the technical threshold for testing work relatively high. Furthermore, specific test code needs to be written for each communication protocol or test scenario, resulting in high maintenance complexity and poor reusability of the test scripts.

[0004] The third approach is to use dedicated testing tools. Dedicated protocol testing tools are developed to provide a graphical interface for test engineers. However, dedicated testing tools have long development cycles, and their internal message construction logic is usually hard-coded for specific protocols, resulting in poor versatility and difficulty in flexibly adapting to various communication protocols or rapidly changing testing needs.

[0005] Furthermore, existing protocol testing methods have inherent flaws in handling dynamic fields. When a message template contains multiple interrelated dynamic fields (e.g., the value of a length field depends on the length of another data field, and a checksum field needs to cover all the aforementioned fields), existing technologies struggle to decouple and calculate these fields using a unified and concise mechanism, leading to complex and error-prone processing logic. Simultaneously, when verifying the response messages of the device under test, complex comparison logic is required to ignore certain variable fields in the response message whose exact values ​​are unpredictable (such as the receive timestamp and echo sequence number), further increasing the complexity of the testing and verification process. Summary of the Invention

[0006] In view of this, the core technical problem to be solved by the present invention is: how to solve the technical problems of high skill requirements, low efficiency, poor universality, and difficulty in using a unified mechanism to handle dynamic fields with complex dependencies in the generation of protocol test messages.

[0007] On one hand, the present invention provides a method for generating communication protocol test messages based on a tag field, comprising: S1, receiving a protocol message template string input by a user, the protocol message template string including a tag field; S2, identifying the tag field defined by a preset tag syntax by parsing the protocol message template string, the tag syntax being used to describe the attribute information of the tag field; S3, executing dynamic value generation logic associated with the attribute information according to the identified attribute information of the tag field to obtain the corresponding fill value; S4, filling the fill value into the corresponding position of the tag field in the protocol message template string to generate a complete protocol test message.

[0008] Optionally, the tag field is defined by a preset tag syntax, which includes using a delimiter to enclose the attribute information of the tag field; the attribute information includes a field name indicating the logical type of the dynamic value generation, a field length indicating the number of bytes occupied by the tag field, and a field format indicating the generation rules or format of the tag field.

[0009] Optionally, in step S3, a two-stage processing procedure is used to execute dynamic value generation logic associated with attribute information to obtain the corresponding fill value. The two-stage processing procedure includes: in the first stage, traversing the protocol message template string, identifying all the marker fields, and replacing each marker field with a placeholder data body of the same length as the field to generate a message skeleton of the same length as the protocol message template string; in the second stage, on the message skeleton, for each marker field, dynamic value generation logic is executed according to its corresponding attribute information, and the generated fill value is written to the position of the placeholder data body that was replaced by the marker field in the first stage.

[0010] Optionally, the field name is used to identify the type or purpose of the field; the field format includes a start position indicator and an end position indicator for defining the calculation range; the steps of executing the dynamic value generation logic associated with the attribute information include: within the byte range defined by the start position indicator and the end position indicator, executing a preset verification algorithm to generate a checksum value as a filler value.

[0011] Optionally, the start position indicator or end position indicator can be defined using a negative offset, which is used to represent the offset position calculated from the end of the protocol test message.

[0012] Optionally, when the field name is a serial number field, the steps of executing the dynamic value generation logic associated with the attribute information include: reading the current count value from the session-level counter as the fill value, and after generating the fill value, incrementing the count value of the session-level counter by an increment step.

[0013] Optionally, the method further includes the following steps: S5, receiving the protocol test message and a preset response message comparison template, wherein the response message comparison template includes precise comparison bytes and non-comparison positions identified by wildcard fields; comparing the protocol test message and the response message comparison template byte by byte, ignoring byte differences at non-comparison positions; and requiring that the precise comparison bytes are completely consistent with the bytes at the corresponding positions in the protocol test message.

[0014] Optionally, the method further includes the following steps: S5', providing a programmable logic execution environment, which is used to receive and execute user-defined script code; exposing predefined interface functions to the script code, the interface functions including at least a function for sending protocol test messages and a function for receiving protocol test messages, so as to realize user-defined test process control.

[0015] On the other hand, the present invention provides a communication protocol test message generation system based on a tag field, used to implement the above-described communication protocol test message generation method based on a tag field, comprising: a template parsing module, used to receive a protocol message template string input by a user, the protocol message template string including a tag field, and to identify the tag field defined by a preset tag syntax by parsing the protocol message template string, the tag syntax being used to describe the attribute information of the tag field; a field processing module, communicatively connected to the template parsing module, used to execute dynamic value generation logic associated with the attribute information identified by the template parsing module to obtain the corresponding fill value; and a message generation module, communicatively connected to the field processing module, used to fill the fill value into the corresponding position of the tag field in the protocol message template string to generate a complete protocol test message.

[0016] Optionally, the field processing module includes at least one of the following units: a timestamp value generation unit, used to process the marker field whose field name is timestamp type, and call the system clock to generate a timestamp value as a fill value; a checksum calculation unit, used to process the marker field whose field name is used to identify the type or purpose of the field, and calculate the checksum value within a specified byte range as a fill value; and a sequence number value generation unit, used to process the marker field whose field name is sequence number type, and generate an incrementing sequence number value as a fill value.

[0017] Implementing this invention offers the following advantages: By receiving a protocol message template string embedded with marker fields, this invention enables users to describe the message structure in an intuitive, non-programming manner, thus solving the problems of high skill requirements and poor versatility in existing technologies. The parsing process automatically identifies these marker fields defined by preset marker syntax and extracts their attribute information. Subsequently, based on the attribute information, the associated dynamic value generation logic is automatically executed to obtain accurate fill values. Finally, these fill values ​​are automatically filled into the corresponding positions of the marker fields in the protocol message template string, generating a complete protocol test message. Through the synergistic effect of the above-mentioned technical effects, users are freed from tedious manual calculations and programming. Users only need to focus on describing "what" the message "is" using a marker language, without needing to worry about "how" the dynamic values ​​are calculated. This achieves automated and deterministic construction of protocol messages containing complex dynamic fields without requiring user programming, significantly improving the efficiency and accuracy of protocol test message generation and greatly enhancing the versatility and reusability of message templates. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a method for generating communication protocol test messages based on a tag field, as shown in one embodiment. Figure 2 This is a schematic diagram of the architecture of a communication protocol test message generation system based on a tag field, as shown in one embodiment. Detailed Implementation

[0019] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. The step numbers in the following embodiments are only for ease of explanation and do not limit the order of the steps. The execution order of each step in the embodiments can be adapted according to the understanding of those skilled in the art.

[0020] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the embodiments of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0021] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0022] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0023] Example 1 In this embodiment, as Figure 1 The method for generating communication protocol test messages based on a tag field, as shown, includes: S1. Receive the protocol message template string input by the user. The protocol message template string includes a flag field. S2. By parsing the protocol message template string, identify the tag fields defined by the preset tag syntax. The tag syntax is used to describe the attribute information of the tag fields. S3. Based on the attribute information contained in the identified marker field, execute the dynamic value generation logic associated with the attribute information to obtain the corresponding fill value; S4. Fill the values ​​into the corresponding positions of the marker fields in the protocol message template string to generate a complete protocol test message (i.e., response message).

[0024] In this embodiment, the user inputs a protocol message template string through an operable user interface module. The protocol message template string includes fixed fields and marker fields. The fixed fields are represented using hexadecimal strings, and the marker fields are represented using a preset marker syntax.

[0025] In one specific embodiment, the protocol message template string input by the user can be represented in the following form: 681200000606010606E8

"time",6,YMDhms,"little"

"CS",1,3:-2,"little"

[0026] In this embodiment, the tagging syntax includes using delimited tags to enclose attribute information; the attribute information includes a field name indicating the logical type of dynamic value generation, a field length indicating the number of bytes occupied by the tag field, a field format indicating the generation rule or format of the tag field, and a byte order indicating the byte arrangement order of multi-byte fields.

[0027] In one specific embodiment, the marker field uses square brackets (i.e., "[]") as delimiters. In this embodiment, the syntax structure of the marker field includes: [Field name, field length, field format, byte order]; The field name indicates the type or purpose of the field, such as "time" for timestamp and "CS" for checksum. Field length indicates the number of bytes occupied by the field; Field format representation: the rules or format for generating field values; Byte order representation: The order in which bytes are arranged in a multi-byte field. For example, "big" indicates big-endian mode and "little" indicates little-endian mode.

[0028] In this embodiment, when the protocol message template string contains both a length-type field (LEN) and a variable-length data-type field (DATA), a circular dependency problem exists: the value of the LEN field depends on the length of the DATA field, and the length of the DATA field may in turn be determined by the value of the LEN field. Specifically, LEN determines whether 00s are padded after DATA, and the actual length of DATA determines the specific value of LEN; they are interrelated and depend on two points: When the len value is greater than the actual length of DATA, DATA is padded with 00s to complete the length. When the len value is less than the actual length of DATA, LEN is padded according to the actual length.

[0029] To solve this problem, the present invention employs a two-stage processing procedure of "first placeholder replacement, then precise calculation" to execute dynamic value generation logic associated with attribute information in order to obtain the corresponding fill value; The two-stage processing includes: In the first stage, the protocol message template string is traversed, all the marker fields are identified, and each marker field is replaced with a placeholder data body of the same length as the field to generate a message skeleton of the same length as the protocol message template string. In the second stage, for each marker field on the message skeleton, dynamic value generation logic is executed based on its corresponding attribute information, and the generated fill value is written to the position of the placeholder data body that was replaced in the first stage.

[0030] In this embodiment, the field name is used to identify the type or purpose of the field; The field format includes start and end position indicators for defining the calculation range; The steps for executing the dynamic value generation logic include: within the byte range defined by the start position indicator and the end position indicator, executing a preset checksum algorithm to generate a checksum value as the padding value.

[0031] In this embodiment, the start position indication or end position indication can be defined using a negative offset, which is used to represent the offset position calculated from the end of the protocol test message.

[0032] In this embodiment, the dynamic value generation logic specifically includes at least one of timestamp field processing, checksum field processing, serial number field processing, and address field processing.

[0033] In this embodiment, when the field name is a timestamp field (such as time, timestamp), the timestamp must be generated first to replace the time tag field, and then the checksum value must be generated immediately to fill the CS tag field.

[0034] In one specific embodiment, the timestamp field is processed as follows: when the field name is "time", the current system time is obtained, and a timestamp value is generated according to a specified format (such as YMDhms representing year-month-day-hour-minute-second). Then, the timestamp value is converted into a byte sequence according to a specified byte order (big-endian or little-endian).

[0035] For example, for the tag ["time", 6, YMDhms, "little"], the system generates a 6-byte timestamp, arranged in little-endian mode.

[0036] In this embodiment, when the field name is a checksum field (such as CS, CRC16, CRC32, etc.), the timestamp field is processed as follows: First, the position of the current tag field itself is replaced with the timestamp calculated from the current time to ensure that the total number of bytes in the range to be checked is correct; then, the check value is calculated byte by byte within the specified range (defined by the start:end parameter); and the check value is written to the tag field position.

[0037] In one specific embodiment, the checksum field is processed as follows: when the field name is "CS", a checksum within a specified range is calculated. The range of the checksum calculation is defined by a start position and an end position, and negative numbers are supported to represent the offset position starting from the end of the protocol message template string.

[0038] For example, for the tag ["CS", 1, 3: -2, "little"], calculate the checksum of all bytes from the 3rd byte to the 2nd to 3rd byte (excluding -2 itself), and the result is 1 byte, padded in little-endian mode.

[0039] In this embodiment, when the field name is a sequence number field (such as SEQ, COUNTER), the steps of the dynamic value generation logic include: reading the current count value from the session-level counter as the fill value, and after generating the fill value, incrementing the count value of the session-level counter by an increment step.

[0040] In one specific embodiment, the serial number field is processed as follows: when the field name is "SEQ", an incrementing serial number is automatically generated. The serial number supports specifying an initial value and an increment step size.

[0041] For example, for the tag ["SEQ", 2, 0, "little"], a 2-byte sequence number is generated, with an initial value of 0, which is incremented by 1 with each call.

[0042] In one specific embodiment, the address field is processed as follows: when the field name is "ADDR", a preset address value is automatically filled in. The address value can be specified through a configuration file or by user input.

[0043] In this embodiment, the field values ​​calculated or generated in step S3 are filled into the corresponding marker field positions in the protocol message template string, the marker field is replaced, and a complete protocol test message is generated.

[0044] For example, the protocol message template string is: 681200000606010606E8

"time",6,YMDhms,"big"

"CS",1,3:-2,"little"

[0045] In this embodiment, independent fields (such as time, SEQ, RAND) are independent of each other and can be calculated in any order in the second stage; when the field name is a checksum field (CS, CRC16, etc.), the correct value is calculated based on the byte sequence determined in the first stage; when the field name is a length field (LEN), the length of the data range determined in the first stage is relied upon; thus, circular dependencies between fields are completely eliminated.

[0046] In this embodiment, placeholder clearing is the core mechanism of the two-stage algorithm. Placeholder clearing refers to writing the generated fill value into the position of the placeholder data body that was replaced in the first stage of the marker field.

[0047] In the first stage, regular expressions are used to match all marked fields in the template—the matching pattern is "[^]+]", which matches any content that begins with a Chinese square bracket

and ends with a Chinese square bracket 【

[0048] In this embodiment, for each matched tag field, its internal parameters are parsed to obtain the field size s (integer, number of bytes), and then the tag field is replaced with s "00" (hexadecimal zero) characters. For example, the protocol test message template string "68 12 00 00

"time",6,YMDhms,"little"

"CS",1,3:-2,"little"

[0049] In this embodiment, during the second stage of verification calculation, the placeholders of the verification field itself are also set to zero bytes to ensure the correct verification range. In the case of multiple flag fields, each verification field calculates its own value independently, without interference.

[0050] In this embodiment, the tag syntax supports both big-endian and little-endian byte order to indicate the byte arrangement order of multi-byte fields. For multi-byte integer values ​​(such as LEN, SEQ, timestamp, etc.), when encoding the value into a byte array in the second stage, the byte arrangement is determined by the endian parameter: in big-endian, the most significant byte is placed first; in little-endian, the least significant byte is placed first. The endianness also applies to BCD time fields: in big-endian, the order is "year-month-day-hour-minute-second"; in little-endian, the order is reversed from "second-minute-hour-day-month-year". The endianness parameter is optional, with a default value of big-endian. Users should select the appropriate endianness according to the requirements of the target communication protocol.

[0051] In this embodiment, the checksum field and length field use the syntax "start position:end position" to define the calculation range. The position index uses a 1-based index (i.e., the index of the first byte is 1). Negative numbers are supported to indicate counting from the end of the message: -1 represents the last byte, -2 represents the second-to-last byte, and so on. For example, "3:-2" represents the range from the third byte to the second-to-last byte. "1:-3" represents the range from the first byte to the third-to-last byte. ": " (empty range) represents the entire range from the beginning to the end of the message.

[0052] In this embodiment, the wildcard matching algorithm for response message comparison is as follows: Step 1: Convert both the response message template and the actual received response message into a uniform uppercase hexadecimal string (remove spaces).

[0053] Step 2: Check if the length of the response message template and the actual received response message are equal. If they are not equal, it is directly determined as a mismatch.

[0054] Step 3: Character-by-character comparison. When two consecutive characters "XX" appear in the response message template, they are treated as a wildcard byte, and the two characters at the corresponding positions in the response message are skipped and not compared. The remaining positions are compared precisely.

[0055] Step 4: If all non-wildcard positions are exactly matched, the match is considered successful.

[0056] In this embodiment, some examples of tag keywords are listed below: Category 1: Timestamp Fields Keyword time: Syntax ["time", number of bytes, "format", "endian"].

[0057] Parameters: number of bytes (1~12), format (time components separated by YMDhms, Y=two digits after the year, M=month, D=day, h=hour, m=minute, s=second), endian (big-endian / little-endian).

[0058] Algorithm: Call the system clock API to get the current time -> Convert each component to BCD encoding (0x00~0x99) according to the format -> Arrange the bytes according to endianness.

[0059] Example:

"time", 6, "YMDhms", "little"

[0060] Keyword timestamp: Syntax ["timestamp", number of bytes, "unit", "endian"].

[0061] Parameters: number of bytes (4 or 8), unit ("s" = Unix timestamp in seconds / "ms" = Unix timestamp in milliseconds), endian (big-endian / little-endian).

[0062] Algorithm: Call the system clock API -> Calculate the number of seconds / milliseconds since 1970-01-01 -> Encode by byte count and endianness.

[0063] Example:

"timestamp", 4, "s", "little"

[0064] Keyword date: Syntax ["date", number of bytes, "format", "endian"].

[0065] Parameters: Same as time, but only include year, month and day components.

[0066] Example: ["date", 3, "YMD", "big"].

[0067] Applicable scenarios: Messages that only require the date and not the time (hours, minutes, and seconds).

[0068] Category 2: Checksum / CRC fields Keyword CS: Syntax ["CS", number of bytes, "start:end"].

[0069] Algorithm: Byte-by-byte summation within a specified range -> Take the lower 8 bits (& 0xFF) -> Fill into the byte number byte.

[0070] Applicable protocols: China Southern Power Grid (Q / CSG1209021), State Grid Corporation of China (Q / GDW 10376.2), DLT645.

[0071] Keyword CRC16: Syntax ["CRC16", number of bytes, "start:end"].

[0072] Algorithm: CRC16-CCITT, polynomial 0x1021, initial value 0xFFFF, final XOR 0xFFFF -> padding to byte number byte.

[0073] Applicable protocols: HDLC / DLMS (IEC 62056-46), PLC RF.

[0074] Keyword CRC16_X25: Syntax ["CRC16_X25", number of bytes, "start:end"].

[0075] Algorithm: CRC16 X.25 standard, polynomial 0x1021, initial value 0xFFFF, final XOR 0xFFFF, both input and output require reflection.

[0076] Applicable protocol: DL / T 698.45-2017.

[0077] Keyword CRC32: Syntax ["CRC32", number of bytes, "start:end", "end order"].

[0078] Algorithm: CRC32 IEEE 802.3, polynomial 0x104C11DB7, initial value 0x00000000, input reflection, output reflection, final XOR 0xFFFFFFFF.

[0079] Applicable protocols: New generation carrier (integrated sensing and communication), State Grid's new generation dual-mode communication interconnection.

[0080] Keyword CRC24: Syntax ["CRC24", number of bytes, "start:end", "end order"].

[0081] Algorithm: CRC24, polynomial 0x864CFB, initial value 0x555555.

[0082] Applicable protocol: Next-generation carrier FC header verification.

[0083] Keyword XOR: Syntax ["XOR", number of bytes, "start:end"].

[0084] Algorithm: XOR byte by byte within a specified range -> fill to the byte number byte.

[0085] Applicable Protocol: General.

[0086] Keyword SUM16: Syntax ["SUM16", number of bytes, "start:end", "end order"].

[0087] Algorithm: Accumulate byte by byte within the specified range -> Take the lower 16 bits (& 0xFFFF) -> Fill the bytes in endian order.

[0088] Applicable protocol: General 16-bit checksum.

[0089] Third category: Sequence / counting fields Keyword SEQ: Syntax ["SEQ", number of bytes, initial value, step size, "endian"].

[0090] Parameters: number of bytes, initial value (0~2ⁿ-1), step size (1~255).

[0091] Algorithm: Read the current value from the session-level auto-incrementing counter -> Write the value according to the number of bytes and endianness -> Counter += step size.

[0092] Example:

"SEQ", 2, 0, 1, "little"

[0093] Applicable scenario: Frame sequence number field.

[0094] Keyword COUNTER: Syntax ["COUNTER", "name", number of bytes, initial value, step size, "endian"].

[0095] Algorithm: Same as SEQ, but uses a named counter, where each name maintains an independent count value, suitable for scenarios where multiple independent counters are needed in the same message.

[0096] Example: ["COUNTER", "msg_id", 2, 1, 1, "big"].

[0097] Keyword RAND: Syntax ["RAND", number of bytes].

[0098] Algorithm: Call a cryptographically secure random number generator -> generate a specified number of random bytes -> hexadecimal encoding.

[0099] Example: ["RAND", 4].

[0100] Applicable scenario: Random load for testing.

[0101] Category 4: Address / Identifier Fields Keyword ADDR: Syntax ["ADDR", number of bytes, "endian"].

[0102] Algorithm: Read from configuration file or user-input preset address value -> Encode by byte count and endianness.

[0103] Example: ["ADDR", 6, "little"].

[0104] Applicable scenarios: Address fields of China Southern Power Grid / State Grid frames.

[0105] Keyword TEI: Syntax ["TEI", number of bytes, "endian"].

[0106] Algorithm: Read the Terminal Device Identifier (TEI) value from the configuration file -> Encode by byte count and endianness.

[0107] Example: ["TEI", 2, "little"].

[0108] Applicable scenarios: TEI domain of next-generation carrier / National Grid next-generation protocol.

[0109] Fifth category: Length / data manipulation fields Keyword LEN: Syntax: ["LEN", number of bytes, "start:end", "end order"]. Algorithm: After the placeholder replacement in Phase 1 is completed -> calculate the actual number of bytes within the specified range -> write according to the number of bytes and end order. Example: ["LEN", 2, "3:-2", "little"] (calculate the length from the 3rd byte to the 2nd to 3rd byte, 2-byte little-endian). Applicable scenarios: Southern Power Grid frame length field (2-byte little-endian), 698.45 link layer frame length field.

[0110] Keyword FILL: Syntax ["FILL", number of bytes, "hexadecimal value"].

[0111] Algorithm: Repeat the specified hexadecimal byte value a specified number of times.

[0112] Example: ["FILL", 3, "AA"] (3 bytes of padding 0xAA).

[0113] Applicable scenarios: Fixed padding bytes.

[0114] Keyword ZERO: Syntax ["ZERO", number of bytes].

[0115] Algorithm: Fill with a specified number of zero bytes (0x00).

[0116] Example: ["ZERO", 2].

[0117] Applicable scenario: Clearing reserved domains.

[0118] Category 6: Wildcard Matching Fields Wildcard XX: Used in response message matching rules, two consecutive characters "XX" represent a wildcard byte. The position of this byte is not included in the comparison, and the corresponding byte in the actual response message can be any value.

[0119] Applicable scenario: Ignoring matching of variable fields (such as sequence number, timestamp, checksum) in response messages.

[0120] In one possible embodiment, the tag-field-based communication protocol test message generation method of the present invention can be used for Modbus (Modbus Industrial Communication Protocol) protocol testing. The Modbus protocol is widely used in industrial automation. Using the tag-field-based communication protocol test message generation method of the present invention, Modbus request and response messages can be easily constructed.

[0121] Specifically, the Modbus message requesting to read the holding register is as follows: 01 03 00 00 00 0A ["CRC", 2, 1:-2, "little"].

[0122] Where 01 is the slave address, 03 is the function code, 00 00 is the starting address, 00 0A is the number of registers, and

"CRC", 2, 1:-2, "little"

[0123] In another possible embodiment, the tag-field-based communication protocol test message generation method of the present invention can be used for DL / T645 protocol testing: DL / T645 is a Chinese power industry standard used for communication in electricity meters. Using the tag-field-based communication protocol test message generation method of the present invention, DL / T645 protocol messages can be easily constructed.

[0124] Specifically, DL / T645 read data request: 68 01 00 00 00 00 00 68 11 04 33 33 33 33 ["CS", 1, 1:-2, "little"] 16.

[0125] In yet another possible embodiment, the tag-field-based communication protocol test message generation method of the present invention can be used for CAN bus protocol testing: the CAN bus protocol is widely used in the automotive electronics field. Using the tag-field-based communication protocol test message generation method of the present invention, CAN frames can be easily constructed.

[0126] For example, CAN data frames:

"ID", 4, standard frame, "big"

[0127] Example 2 This embodiment provides a response message comparison method based on Embodiment 1.

[0128] In this embodiment, the communication protocol test message generation method based on the tag field further includes the following steps: S5, response message comparison method.

[0129] In this embodiment, the response message comparison method includes the following steps: Receive response message comparison template, which includes the exact comparison bytes and the non-comparison positions identified by wildcard fields; The actual received response message is compared byte by byte with the response message comparison template. Specifically, this includes ignoring byte differences at positions not included in the comparison and requiring that the precisely compared bytes be completely consistent with the bytes at the corresponding positions in the response message.

[0130] In this embodiment, the template string of the response message includes an exact match field and a wildcard field. After receiving the template string of the response message input by the user, the response message template is parsed to identify the wildcard field. The wildcard field is identified using a preset wildcard, such as "XX", which indicates that the value at that byte position can be any value and is not included in the comparison.

[0131] For example, the user enters the following response message template: 68 0C 00 C8 06 XX 01 06 06 E8 XX 16.

[0132] The actual received response message is compared byte by byte with the response message template to generate a comparison result. Based on the comparison result, a test report is generated, indicating which bytes matched successfully and which bytes failed to match.

[0133] In this embodiment, the method for generating communication protocol test messages based on the tag field further includes the following steps: S5` provides a programmable logic execution environment, which is used to receive and execute user-defined script code; exposes predefined interface functions to the script code, including at least functions for sending protocol test messages and functions for receiving response messages, so as to realize user-defined test process control.

[0134] Example 3 Based on the above embodiments, this embodiment provides a system for implementing the communication protocol test message generation method based on the tag field described above.

[0135] In this embodiment, as Figure 2 As shown, the communication protocol test message generation system based on the tag field includes: The template parsing module is used to receive the protocol message template string input by the user. The protocol message template string includes a tag field. By parsing the protocol message template string, the module identifies the tag fields defined by the preset tag syntax. The tag syntax is used to describe the attribute information of the tag fields. The field processing module is connected to the template parsing module. It is used to execute dynamic value generation logic associated with the attribute information based on the attribute information identified by the template parsing module in order to obtain the corresponding fill value. The message generation module, which is connected to the field processing module, is used to fill the values ​​into the corresponding positions of the marker fields in the protocol message template string to generate a complete protocol test message.

[0136] In this embodiment, the communication protocol test message generation system based on the tag field further includes: The template management module, which is connected to the message comparison module, is used to store, retrieve, and manage protocol message template strings. The message comparison module is connected to the message generation module and is used to compare the actual received response message with the preset response message template to generate a comparison result. The user interface module, which communicates with the template parsing module, provides a visual template editing interface, allowing users to define tag fields graphically.

[0137] In this embodiment, the field processing module includes at least one of the following units: The timestamp value generation unit is used to process the marker field whose field name is timestamp type, and call the system clock to generate a timestamp value as the fill value; The checksum calculation unit is used to process the marker field whose field name is used to identify the type or purpose of the field, and calculates the checksum value as the padding value within a specified byte range; The serial number value generation unit is used to process the marker field whose field name is of type serial number and generate an incrementing serial number value as the fill value.

[0138] In this embodiment, the field descriptor contains the following attributes: [field name (field_name, string attribute or type, such as "time" / "CS" / "CRC16" / "SEQ" etc.), field length (field_size, integer type, unit is bytes), data format (format, string type, such as "YMDhms" / "3:-2" / "0,1" etc.), byte order (endian, enumeration type, value is "big" or "little")].

[0139] In this embodiment, the structured response template is an ordered list, and each element in the list is one of the following two types: a fixed segment containing a hexadecimal byte array; or a field descriptor.

[0140] In this embodiment, the input of the template parsing module is: the protocol message template string (string type) entered by the user from the user interface module, such as "681200000606010606E8

"time",6,YMDhms,"little"

"CS",1,3:-2,"little"

[0141] The template parsing module's processing steps include: (a) Use regular expressions to identify marker fields in a string, where the marker field begins with the symbol "

" and ends with the symbol "

[0142] In this embodiment, the response message template is the output of the template parsing module.

[0143] In this embodiment, the input to the field processing module is: a tag field descriptor object and a context object (contains a byte array of the currently filled portion of the message and key-value pair mappings of other parsed fields) from the template parsing module.

[0144] In this embodiment, the processing procedure of the field processing module includes: The data is assigned to the corresponding processing unit based on the field name.

[0145] For example, the timestamp processing unit processes fields with the name type "time" / "timestamp". The timestamp processing unit calls the communication protocol test message to generate the system clock API (Application Programming Interface) to obtain the current time, formats it according to the format parameter, and converts it to BCD (Binary-Coded Decimal) or a binary byte array, and arranges the byte order according to the endian parameter. The field name types processed by the checksum calculation unit include "CS", "CRC16", "CRC16_X25", "CRC32", "CRC24", "XOR" and "SUM16": First, all marker fields in the test message template string are temporarily replaced with equal-length placeholders (zero bytes), and then the check value is calculated within the specified range; The serial number generation unit processes fields with the name type "SEQ" / "COUNTER". The serial number generation unit maintains a session-level auto-incrementing counter and increments the step size with each processing step. Other processing units include: an address padding unit, processing field names of types "ADDR" and "TEI"; a random number generation unit, processing field names of types "RAND"; a length calculation unit, processing field names of types "LEN"; a fixed padding unit, processing field names of types "FILL" and "ZERO"; and a byte reversal unit, processing field names of types "REV".

[0146] In this embodiment, the output of the field processing module includes: a calculated byte array (bytes type) with a length equal to field_size.

[0147] In this embodiment, the input objects of the message generation module include: the response message template StructuredTemplate output by the template parsing module and the list of calculated field values ​​output by the field processing module (each FieldDescriptor corresponds to one byte).

[0148] In this embodiment, the processing procedure of the field processing module includes: Iterate through each element in the order specified in the StructuredTemplate. If it is a FixedSegment, append its byte array directly to the output buffer. If it is a FieldDescriptor, retrieve the corresponding bytes from the list of calculated field values ​​and append them to the output buffer.

[0149] The output of the field processing module includes a byte array (bytes type) of the complete protocol message.

[0150] In this embodiment, the user interface module includes the following areas: The input area is used for users to input protocol message template strings; The tag field definition area is used by users to define the attributes of the tag field; The preview area is used to display the parsed message structure. The sending area is used to display the complete generated response message; The response comparison area displays the comparison results between the response message and the response message template.

[0151] In this embodiment, the template management module provides the following template management functions: Template storage stores protocol message templates containing tag fields as reusable template files; Templates are categorized and managed according to dimensions such as protocol type and test scenario; Template search, supporting keyword search, allows you to quickly locate the template file you need; Template import and export: Supports importing and exporting templates for easy team sharing; Template version control supports version management of template files and records the modification history of template files.

[0152] Example 4 In this embodiment, to address the needs for conditional judgment and custom calculation in complex testing scenarios, the present invention further provides a programmable extension scheme based on an embedded Lua script engine.

[0153] In this embodiment, Lua is selected as the programmable logic execution environment. Lua is a lightweight, embeddable scripting language widely used in extended programming scenarios requiring secure sandbox isolation. This invention embeds a Lua interpreter into the testing tool through the Python-Lua bridging library (lupa), providing an independent Lua execution environment for each test step. The runtime characteristics of the Lua execution environment include: (a) Sandbox isolation: Lua scripts run in a restricted environment and cannot access the file system, network or operating system APIs. They can only interact with the test framework through predefined API functions, which ensures security.

[0154] (b) Optional Dependency: The Lua scripting engine is an optional enhancement. When the runtime environment does not have the Lua support library installed, the system automatically downgrades to the basic mode that only uses the tag fields (time, CS, CRC16, SEQ, etc.), and the core functionality is unaffected.

[0155] In this embodiment, the testing framework exposes the following predefined API functions to Lua scripts: send(hex_string): Sends a hexadecimal protocol test message string to the device under test.

[0156] wait_for_response(timeout_ms): Waits for a response from the device under test, returns the response as a hexadecimal string, and returns nil if the timeout occurs.

[0157] wait(ms): Blocks and waits for the specified number of milliseconds.

[0158] log(message): Outputs a message to the test log.

[0159] hex_to_bytes(hex_string): Converts a hexadecimal string to a byte array.

[0160] bytes_to_hex(byte_array): Converts a byte array to a hexadecimal string.

[0161] get_last_response(): Retrieves the hexadecimal string of the most recently received response message.

[0162] set_test_var(name, value) / get_test_var(name): Set and get shared variables (key-value store) across steps.

[0163] In this embodiment, the Lua scripting engine supports the following data types: nil (empty value), boolean (boolean value), number (double-precision floating-point number), and string (string). All API function parameters and return values ​​are of the above types.

[0164] In this embodiment, the operators supported by the Lua scripting engine include: Arithmetic operators: + (addition), - (subtraction), * (multiplication), / (division), % (modulo), ^ (exponentiation).

[0165] Relational operators: == (equal to), ~= (not equal to), < (less than), > (greater than), <= (less than or equal to), >= (greater than or equal to).

[0166] Logical operators: and, or, not.

[0167] String operator: .. (concatenation).

[0168] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for generating communication protocol test messages based on a tag field, characterized in that, include: S1. Receive a protocol message template string input by the user, wherein the protocol message template string includes a flag field; S2. By parsing the protocol message template string, the tag field defined by the preset tag syntax is identified, and the tag syntax is used to describe the attribute information of the tag field; S3. Based on the attribute information contained in the identified marker field, execute the dynamic value generation logic associated with the attribute information to obtain the corresponding fill value; S4. Fill the padding value into the corresponding position of the marker field in the protocol message template string to generate a complete protocol test message.

2. The method for generating communication protocol test messages based on a tag field according to claim 1, characterized in that, The tag field is defined by the preset tag syntax, which includes the attribute information of the tag field being surrounded by a delimiter body. The attribute information includes a field name indicating the logical type of dynamic value generation, a field length indicating the number of bytes occupied by the tag field, a field format indicating the generation rule or format of the tag field, and a byte order indicating the byte arrangement order of the multi-byte field.

3. The method for generating communication protocol test messages based on a tag field according to claim 2, characterized in that, In step S3, a two-stage processing procedure is used to execute the dynamic value generation logic associated with the attribute information to obtain the corresponding fill value; The two-stage processing procedure includes: In the first stage, the protocol message template string is traversed to identify all the marked fields, and each marked field is replaced with a placeholder data body of the same length as the field to generate a message skeleton of the same length as the protocol message template string. In the second stage, on the message skeleton, for each of the marked fields, the dynamic value generation logic is executed according to its corresponding attribute information, and the generated fill value is written to the position of the placeholder data body where the marked field was replaced in the first stage.

4. The method for generating communication protocol test messages based on a tag field according to claim 2, characterized in that, The field name is used to identify the type or purpose of the field; The field format includes a start position indicator and an end position indicator for defining the calculation range; The steps of executing the dynamic value generation logic associated with the attribute information include: within the byte range defined by the start position indication and the end position indication, executing a preset verification algorithm to generate a checksum value as the padding value.

5. The method for generating communication protocol test messages based on a tag field according to claim 4, characterized in that, The start position indication or the end position indication can be defined using a negative offset, which is used to represent the offset position calculated from the end of the protocol test message.

6. The method for generating communication protocol test messages based on a tag field according to claim 2, characterized in that, When the field name is a serial number field, the steps of executing the dynamic value generation logic associated with the attribute information include: reading the current count value from the session-level counter as the fill value, and after generating the fill value, incrementing the count value of the session-level counter by an increment step.

7. The method for generating communication protocol test messages based on a tag field according to claim 1, characterized in that, It also includes the following steps: S5. Receive the protocol test message and a preset response message comparison template. The response message comparison template includes precise comparison bytes and non-comparison positions identified by wildcard fields. Compare the protocol test message and the response message comparison template byte by byte, ignoring byte differences at the non-comparison positions. The precise comparison bytes must be completely consistent with the bytes at the corresponding positions in the protocol test message.

8. The method for generating communication protocol test messages based on a tag field according to claim 1, characterized in that, It also includes the following steps: S5' Provide a programmable logic execution environment, which is used to receive and execute user-defined script code; expose predefined interface functions to the script code, the interface functions including at least a function for sending the protocol test message and a function for receiving the protocol test message, so as to realize user-defined test process control.

9. A communication protocol test message generation system based on a tag field, used to implement the communication protocol test message generation method based on a tag field as described in any one of claims 1 to 8, characterized in that, include: The template parsing module is used to receive a protocol message template string input by the user. The protocol message template string includes a tag field. By parsing the protocol message template string, the module identifies the tag field defined by a preset tag syntax. The tag syntax is used to describe the attribute information of the tag field. The field processing module is communicatively connected to the template parsing module and is used to execute dynamic value generation logic associated with the attribute information based on the attribute information identified by the template parsing module, so as to obtain the corresponding fill value; The message generation module is communicatively connected to the field processing module and is used to fill the padding value into the corresponding position of the marker field in the protocol message template string to generate a complete protocol test message.

10. The communication protocol test message generation system based on a tag field according to claim 9, characterized in that, The field processing module includes at least one of the following units: The timestamp value generation unit is used to process the marker field whose field name is timestamp type, and call the system clock to generate a timestamp value as the fill value; A checksum calculation unit is used to process the marker field whose field name is used to identify the type or purpose of the field, and to calculate the checksum value as the padding value within a specified byte range; The serial number value generation unit is used to process the marker field whose field name is of type serial number and generate an incrementing serial number value as the fill value.

Images