Protocol test method, device, terminal equipment and computer readable storage medium

Abstract

The application discloses a protocol testing method and device, terminal equipment and a computer readable storage medium, and relates to the technical field of communication. According to the application, a test object instance is created according to a test case by a main thread, and a sending thread, a connecting thread and a receiving thread corresponding to the test object instance are started; a long connection is established with a tested server according to a tested long connection protocol by the connecting thread; a first tested long connection protocol message corresponding to the test object instance is generated by the main thread; the first tested long connection protocol message is provided to the connecting thread by the sending thread, and is sent to the tested server by the connecting thread; a second tested long connection protocol message from the tested server received by the connecting thread is provided to the main thread by the receiving thread; and a test result of the tested long connection protocol is obtained by the main thread according to the second tested long connection protocol message. The application can improve the test efficiency of the protocol test on the long connection protocol.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a protocol testing method, a protocol testing apparatus, a terminal device, and a computer-readable storage medium. Background Technology

[0002] In communication networks, communication between two parties is based on underlying communication connection protocols. Depending on the persistence of the established communication connection, protocols are divided into long-connection protocols (such as Extensible Messaging and Preservation Protocol, WebSockets Protocol, and Advanced Message Queuing Protocol) and short-connection protocols (such as Hypertext Transfer Protocol, Secure Hypertext Transfer Protocol, and File Transfer Protocol). Generally, long-connection protocols are suitable for applications that require maintaining a long connection, such as real-time chat applications and online games, while short-connection protocols are suitable for applications that only require a short connection, such as web browsing applications and file transfer applications.

[0003] In related technologies, to ensure the proper functioning of application services provided by a server, it is necessary to test the communication connection protocols upon which these services depend. Testing long-connection protocols typically involves manual interaction between the communication terminal and the server, with test results obtained by analyzing the logs output by the terminal. However, this heavily manual testing method negatively impacts the efficiency of long-connection protocol testing. Summary of the Invention

[0004] This application provides a protocol testing method, a protocol testing apparatus, a terminal device, and a computer-readable storage medium, which can improve the testing efficiency of long-connection protocols.

[0005] Firstly, the protocol testing method provided in this application includes:

[0006] The main thread creates test object instances based on test cases and starts the sending thread, connection thread, and receiving thread corresponding to the test object instances.

[0007] A long connection is established with the server under test through a connection thread in accordance with the long connection protocol under test;

[0008] The main thread generates the first long-connection protocol message corresponding to the test object instance.

[0009] The first long connection protocol message under test is obtained by the sending thread and provided to the connection thread, which then sends it to the server under test.

[0010] The receiving thread provides the main thread with the second long-connection protocol message received from the server under test by the connection thread.

[0011] The test results of the long connection protocol under test are obtained by the main thread based on the message of the second long connection protocol under test.

[0012] Secondly, the protocol testing apparatus provided in this application includes:

[0013] The thread startup module is used to create test object instances based on test cases through the main thread, and start the sending thread, connection thread and receiving thread corresponding to the test object instance;

[0014] The connection establishment module is used to establish a long connection with the server under test through the connection thread in accordance with the long connection protocol under test;

[0015] The message generation module is used to generate the first long-connection protocol message corresponding to the test object instance through the main thread;

[0016] The message sending module is used to obtain the first long connection protocol message under test through the sending thread and provide it to the connection thread, which then sends it to the server under test.

[0017] The message receiving module is used to provide the main thread with the second long-connection protocol messages received by the connection thread from the server under test through the receiving thread;

[0018] The test analysis module is used to obtain the test results of the long-connection protocol under test through the main thread based on the message of the second long-connection protocol under test.

[0019] Optionally, in one embodiment, the message generation module is used to call the protocol message encapsulation function with the message content corresponding to the test object instance as the calling parameter through the main thread, and to write the message content into the protocol message structure of the specified protocol service through the protocol message encapsulation function to obtain the first tested long connection protocol message.

[0020] Optionally, in one embodiment, the message generation module is used to determine the specified protocol service corresponding to the test object instance through the main thread; determine the target protocol message encapsulation function corresponding to the specified protocol service through the main thread according to the one-to-one correspondence between the protocol service and the protocol message encapsulation function; and call the target protocol message encapsulation function with the message content as the calling parameter through the main thread.

[0021] Optionally, in one embodiment, the message generation module is used to obtain the protocol message identifier corresponding to the test object instance through the main thread; and to call the protocol message encapsulation function through the main thread with the protocol message identifier and the message content corresponding to the test object instance as calling parameters, wherein the protocol message identifier and the message content are used by the protocol message encapsulation function to write the protocol message structure of the specified protocol service to obtain the first tested long connection protocol message;

[0022] The message receiving module is used to store the second tested long connection protocol message into the first buffer for the main thread to retrieve if the second tested long connection protocol message carries a protocol message identifier; otherwise, it stores the second tested long connection protocol message into the second buffer for the main thread to retrieve.

[0023] Optionally, in one embodiment, the thread startup module is used to, if there are multiple test object instances, start the sending thread, connection thread, and receiving thread corresponding to the test object instance through the main thread for each test object instance.

[0024] Optionally, in one embodiment, the message generation module is used to determine the message sending and receiving order of multiple test object instances through the main thread based on test cases; for each test object instance, based on the message sending and receiving order, the main thread determines whether it is necessary to block the main thread; if so, the main thread calls the protocol message encapsulation function with the message content corresponding to the test object instance and the blocking indication information as calling parameters; the protocol message encapsulation function writes the message content into the protocol message structure of the specified protocol service to obtain the first tested long connection protocol message; and according to the blocking indication information, the main thread is blocked through the protocol message encapsulation function; if the connection thread receives a response protocol message from the server under test corresponding to the first tested long connection protocol message, the blocking of the main thread is released through the protocol message encapsulation function according to the blocking indication information.

[0025] Optionally, in one embodiment, the connection establishment module is further configured to determine the current target I / O multiplexing mechanism through the connection thread, and add the socket object corresponding to the long connection to the target I / O multiplexing mechanism; and configure the response rules corresponding to the socket object to the target I / O multiplexing mechanism through the connection thread, wherein the response rules include response operations corresponding to different send and receive states of the socket object.

[0026] Thirdly, the terminal device provided in this application includes a memory and a processor. The memory stores a computer program, and the processor runs the computer program in the memory to implement the steps in the protocol testing method provided in this application.

[0027] Fourthly, the computer-readable storage medium provided in this application stores a computer program adapted for execution by a processor to implement the steps in the protocol testing method provided in this application.

[0028] The protocol testing scheme provided in this application first creates a test object instance based on the test cases using the main thread, and starts the sending thread, connection thread, and receiving thread corresponding to the test object instance. Then, the connection thread establishes a long connection with the server under test according to the long connection protocol under test. Next, the main thread generates a first long connection protocol message corresponding to the test object instance. On one hand, the sending thread obtains the first long connection protocol message under test and provides it to the connection thread, which then sends it to the server under test. On the other hand, the connection thread receives a second long connection protocol message under test from the server under test, formats the second long connection protocol message under test into a format readable by the main thread, and provides it to the main thread. Finally, the main thread obtains the test result of the long connection protocol under test based on the formatted second long connection protocol message under test. In this way, not only is automated protocol testing achieved, but also a multi-threaded model consisting of a sending thread, a connection thread, and a receiving thread is used to handle the establishment and maintenance of long connections and the sending / receiving of protocol messages during the testing process. This decouples the protocol message sending / receiving logic from the long connection, ensuring that all the running logic does not interfere with each other, avoiding the main thread being blocked at the test case level, and allowing the main thread to focus more on the upper-level execution of the test cases, thereby comprehensively improving the testing efficiency of long connection protocol testing. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1a This is a schematic diagram of the application environment for the protocol testing method provided in the embodiments of this application;

[0031] Figure 1b This is a flowchart illustrating the protocol testing method provided in an embodiment of this application;

[0032] Figure 1c This is a schematic diagram of the multi-threaded model provided in the embodiments of this application;

[0033] Figure 1d This is an example diagram illustrating the addition of a long-connection socket object to the I / O multiplexing mechanism in this embodiment of the application;

[0034] Figure 1e This is a schematic diagram of a one-to-many relationship between the protocol message encapsulation function and the protocol message structure in the embodiments of this application;

[0035] Figure 1f This is a schematic diagram illustrating the one-to-one relationship between the protocol message encapsulation function and the protocol message structure in the embodiments of this application;

[0036] Figure 1g This is an example diagram illustrating the execution logic of the protocol message encapsulation function in the embodiments of this application;

[0037] Figure 1h This is an example diagram illustrating the sending of the first tested long connection protocol message in the order of message sending and receiving in this application embodiment;

[0038] Figure 2a This is another schematic flowchart of the protocol testing method provided in the embodiments of this application;

[0039] Figure 2b This is a test architecture example diagram of the protocol testing method provided in the embodiments of this application;

[0040] Figure 3 This is a schematic diagram of the protocol testing device provided in an embodiment of this application;

[0041] Figure 4 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0042] It should be noted that the principles of this application are illustrated by example in a suitable computing environment. The following description is based on the specific embodiments of this application that are illustrated, and should not be regarded as limiting other specific embodiments not detailed herein.

[0043] In the following description of this application, "some embodiments" are referred to, which describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subset of all possible embodiments, and may be combined with each other without conflict.

[0044] In the following description of this application, the terms "first, second, third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0045] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0046] To improve the testing efficiency of long-connection protocols, this application provides a protocol testing method, a protocol testing apparatus, a server, a computer-readable storage medium, and a computer program product. The protocol testing method can be executed by the protocol testing apparatus or by a terminal device integrating the protocol testing apparatus.

[0047] Please refer to Figure 1a , Figure 1a This is a schematic diagram illustrating an application environment for the protocol testing method provided in this application. As one implementation, the protocol testing method provided in this application can be applied to a terminal device 200. The server 100 and the terminal device 200 are connected via a network. The server 100 provides application services based on a long-connection protocol to the terminal device 200. The network, used as a medium to provide a communication link between the server 100 and the terminal device 200, can include various connection types, such as wired communication links, wireless communication links, etc., and this application embodiment does not limit this.

[0048] It should be noted that, Figure 1a The server 100, network, and terminal device 200 shown are merely illustrative. Depending on actual needs, there can be any number of servers, networks, and terminal devices. For example, the terminal device 200 can be any device such as a mobile phone, tablet, desktop computer, or laptop; the server 100 can be a standalone physical server, a server cluster composed of multiple servers, or a distributed system.

[0049] In some embodiments, the terminal device 200 can create a test object instance according to test cases through the main thread, and start a sending thread, a connection thread, and a receiving thread corresponding to the test object instance; establish a long connection with the server under test through the connection thread according to the long connection protocol under test; generate a first long connection protocol message corresponding to the test object instance through the main thread; obtain the first long connection protocol message under test through the sending thread and provide it to the connection thread, which then sends it to the server under test; provide the second long connection protocol message under test received from the server under test by the connection thread to the main thread through the receiving thread; and obtain the test result of the long connection protocol under test according to the second long connection protocol message under test through the main thread.

[0050] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] The following sections provide detailed descriptions of each example. It should be noted that the sequence numbers of the following embodiments are not intended to limit the preferred order of the embodiments.

[0052] Please refer to Figure 1b This embodiment provides a protocol testing method, such as... Figure 1b As shown, the process of this protocol testing method can be as follows:

[0053] In 110, the main thread creates test object instances based on test cases and starts the sending thread, connection thread, and receiving thread corresponding to the test object instances.

[0054] In this embodiment, the test cases are automated test cases, which differ from ordinary test cases. Automated test cases are typically written in a programming language and run based on a test framework. The test framework can be a software tool or library that provides a set of structures and functions to help write, execute, and manage automated test cases. The automated test cases are written according to the testing requirements of the long-connection protocol under test; no specific restrictions are imposed here. The main thread refers to the thread that runs the automated test cases.

[0055] Understandably, the long-connection protocol under test can be any long-connection protocol, depending on the testing requirements. For example, if a server provides a real-time chat application (also known as an instant messaging application) based on the Extensible Messaging and Presence Protocol (XMPP), then when protocol testing is required on the real-time chat application provided by this server, this server is the server under test, and the Extensible Messaging and Presence Protocol used by the real-time chat application provided by this server under test is the long-connection protocol under test.

[0056] To decouple the dependency between sending / receiving protocol messages and long-lived connections, and to prevent the main thread from being blocked, this application provides a multi-threaded model. Please refer to... Figure 1c This multithreaded model includes a sending thread, a connection thread, and a receiving thread.

[0057] The connection thread is configured to establish a long connection with the server under test according to the long connection protocol under test, and to implement protocol message transmission with the server under test based on the long connection, as well as maintain the established long connection.

[0058] The sending thread is configured to receive the long-connection protocol messages from the main thread and provide them to the connection thread for sending.

[0059] The receiving thread is configured to format the long-connection protocol messages received by the connection thread from the server under test into a format readable by the main thread and then provide them to the main thread.

[0060] As shown above, this multi-threaded model decouples the entire logic of sending and receiving protocol messages from the long connection, ensuring that all the operational logic does not interfere with each other, thereby preventing the main thread from being blocked and improving the testing efficiency of the protocol.

[0061] Accordingly, in this embodiment, a test object instance is first created by the main thread according to the test cases. This test object instance can be regarded as a simulated client object of the server under test. Then, the multi-threaded model corresponding to the test object instance is started, that is, the sending thread, connection thread and receiving thread corresponding to the test object instance are started. Then, based on the protocol message sending / receiving capability between the client object and the server under test provided by the multi-threaded model, the interaction of protocol messages between the client object and the server under test is simulated, thereby completing the protocol test of the server under test.

[0062] Optionally, in one embodiment, starting the sending thread, connection thread, and receiving thread corresponding to the test object instance includes:

[0063] If there are multiple test object instances, then for each test object instance, the sending thread, connection thread, and receiving thread corresponding to that test object instance will be started by the main thread.

[0064] In this embodiment of the application, for a test scenario where the main thread creates multiple test object instances based on test cases, for each test object instance, the main thread starts the multi-threaded model corresponding to that test object instance, that is, the main thread starts the sending thread, connection thread and receiving thread corresponding to that test object instance.

[0065] In this way, by starting a multi-threaded model for each test object instance, the multiple test object instances created by the main thread can be prevented from interfering with each other, thereby simulating the interaction of protocol messages between multiple client objects and the server under test, and realizing protocol testing in multi-client object scenarios.

[0066] In step 120, a long connection is established with the server under test through a connection thread in accordance with the long connection protocol under test.

[0067] As described above, after starting the multi-threaded model corresponding to the test object instance, a long connection is established with the server under test through the connection thread in this multi-threaded model, according to the protocol specification of the long connection protocol under test. The protocol specification depends on the actual long connection protocol being tested, and will not be elaborated here.

[0068] For example, the following uses Extensible Message and Existence Protocol (EMP) as the long-lived connection protocol under test to illustrate the long-lived connection establishment process of EMP:

[0069] 1. Establish Transmission Control Protocol (TCP) connection

[0070] First, a Transmission Control Protocol (TCP) first socket object is created through a connection thread and connected to the network address and port of the server under test (e.g., the default port is 5222). In response to the connection request, the server under test creates a second socket object that is paired with the first socket object. The first and second socket objects enable communication between the terminal device and the server under test.

[0071] 2. Start the stream

[0072] After establishing a Transmission Control Protocol (TCP) connection, a stream header is sent to the server under test via the connection thread to initiate an Extensible Markup Language (XML) stream. The server under test responds to this stream header by returning a stream property element, listing available stream properties such as Transport Layer Security (TLS) encryption and authentication mechanisms.

[0073] 3. Enable Transport Layer Security (TLS) encryption.

[0074] If the server under test requires enabling Transport Layer Security (TLS) encryption, a TLS encryption enablement request is sent to the server under test via the connection thread. After receiving an agreement response from the server under test confirming the request, the TLS encryption handshake process is initiated via the connection thread to establish an encrypted connection with the server under test.

[0075] 4. Perform Simple Authentication and Security Layer (SASL) authentication.

[0076] After establishing an encrypted connection, a simple verification and security layer authentication are initiated through the connection thread. If the server under test is successfully authenticated, a success response will be returned.

[0077] 5. Restart the stream

[0078] After successful authentication, a new flow header is sent to the server under test via the connection thread. The server under test responds to this new flow header by returning new flow characteristic elements.

[0079] 6. Bind resources

[0080] A binding request is sent to the server under test via a connection thread. This binding request includes the resource name of the resource to be bound. After completing the resource binding, the server under test returns the Jabber identifier (JID, also known as the Extensible Message and Existence Protocol address) to which the resource is bound.

[0081] 7. Set up the session

[0082] Finally, a session setup request is sent to the server under test via the connection thread. After the server under test completes the session setup, it returns a session identifier, indicating that the session has been set.

[0083] As shown above, a long connection based on scalable messaging and existence protocol is established between the terminal device and the server under test.

[0084] It should be noted that after establishing a long-lived connection with the server under test through the connection thread, the connection thread also periodically sends heartbeat packets to the server under test to maintain the established long-lived connection. For example, a heartbeat packet generator can periodically generate heartbeat packets and provide the generated heartbeat packets to the connection thread, which then sends them to the server under test to maintain the established long-lived connection.

[0085] Optionally, in one embodiment, after establishing a long connection with the server under test via a connection thread according to the long connection protocol under test, the method further includes:

[0086] The current target I / O multiplexing mechanism is determined by the connection thread, and the socket object corresponding to the long connection is added to the target I / O multiplexing mechanism;

[0087] The connection thread configures the response rules corresponding to the socket object to the target I / O multiplexing mechanism. The response rules include response operations corresponding to different send and receive states of the socket object.

[0088] I / O multiplexing is a technique for managing multiple I / O events simultaneously. Common I / O multiplexing mechanisms include select, poll, and epoll. They allow multiple file descriptors (such as socket objects) to be managed at the same time to determine which descriptors can be used for I / O operations (such as read, write, or exceptions).

[0089] For example, the connection thread can determine the operating system used by the terminal device, identify the optimal I / O multiplexing mechanism suitable for that operating system as the target I / O multiplexing mechanism, and add the socket object corresponding to the established long connection to the target I / O multiplexing mechanism for management. In this way, the connection thread does not need to focus on the state of the socket object; instead, the target I / O multiplexing mechanism notifies the connection thread of state changes. When a protocol message is available to be received or sent, or when an error occurs, the I / O multiplexing mechanism notifies the connection thread.

[0090] For example, please refer to Figure 1dFor Windows operating systems, the select mechanism can be used as the target I / O multiplexing mechanism for managing socket objects. For macOS operating systems, the poll mechanism can be used as the target I / O multiplexing mechanism for managing socket objects. For Linux operating systems, the epoll mechanism can be used as the target I / O multiplexing mechanism for managing socket objects.

[0091] Furthermore, to prevent socket objects from blocking when sending / receiving protocol messages, this embodiment of the application also configures the response rules corresponding to the socket object to the target I / O multiplexing mechanism through the connection thread. These response rules include response operations corresponding to different send / receive states, enabling the target I / O multiplexing mechanism to execute the corresponding response operations based on the send / receive state of the socket object. The response rules can be set according to actual needs, and no specific limitations are imposed here.

[0092] For example, for a socket object, the response rule can be set as follows: if the socket object does not receive a response protocol message (i.e., send / receive status) within the waiting time threshold after sending a protocol message, then switch to the next socket object to send the protocol message (i.e., response operation).

[0093] As shown above, by entrusting the socket object of the long connection to the I / O multiplexing mechanism and configuring the response rules in the application embodiment, the sending / receiving efficiency of the connection thread can be improved, thereby improving the efficiency of protocol testing.

[0094] In step 130, the first long-connection protocol message corresponding to the test object instance is generated by the main thread.

[0095] After establishing a long-lived connection with the server under test through the connection thread, the main thread further generates protocol messages corresponding to the test object instance and conforming to the protocol specifications of the long-lived connection protocol under test. These are denoted as the first long-lived connection protocol message under test. It should be noted that the type and number of the first long-lived connection protocol messages created depend on the test cases running in the main thread.

[0096] For example, taking a real-time chat application provided by the server under test as an example, assuming the test case defines a test object instance that includes a step of requesting the list of contacts from the server under test, then the main thread will generate a protocol message for requesting the list of contacts from the server under test, which will be denoted as the first long connection protocol message under test.

[0097] Optionally, in one embodiment, generating the first tested long-connection protocol message corresponding to the test object instance via the main thread includes:

[0098] The main thread calls the protocol message encapsulation function with the message content corresponding to the test object instance as the call parameter. The protocol message encapsulation function writes the message content into the protocol message structure of the specified protocol business to obtain the first long connection protocol message under test.

[0099] To improve the efficiency of protocol message generation and thus further enhance protocol testing efficiency, this application maintains protocol message structures corresponding to different protocol services and predefines functions for writing message content into these structures, denoted as protocol message encapsulation functions. These protocol message encapsulation functions can correspond to multiple protocol message structures, implementing protocol message encapsulation for their respective structures, such as... Figure 1e As shown, where n is a positive integer.

[0100] For example, taking the Extensible Messaging and Existence Protocol as an example, the following illustrates a protocol message structure for implementing real-time messaging services in the Extensible Messaging and Existence Protocol:

[0101]

[0102] In this structure, MESSAGE_TEMPLATE indicates that the structure is a protocol message structure for implementing real-time messaging services (in this case, one-to-one real-time messaging services). {from_jid} is a placeholder used to fill in the Jabber identifier of the message sender, {to_jid} is a placeholder used to fill in the Jabber identifier of the message receiver, {message_id} is a placeholder used to fill in the unique identifier of the protocol message, and {body} is a placeholder used to fill in the message content of the real-time message to be sent.

[0103] Based on the above protocol message structure for implementing message services, the main thread calls the preset protocol message encapsulation function with the above message content as a call parameter. The protocol message encapsulation function can then write the message content into the protocol message structure of the specified protocol service, generating the expected first long-connection protocol message.

[0104] For example, a test case might include a step where a test instance sends a one-to-one real-time message to another test instance. The test instance's Jabber identifier is "testuser@domain.com", the other test instance's Jabber identifier is "otheruser@domain.com", the protocol message identifier is "msg-001" (this identifier can be generated by the main thread using a pre-defined identifier generator), and the real-time message content is "Hello, World!". The main thread can then call the protocol message encapsulation function: `Encapsulation("MESSAGE_TEMPLATE","testuser@domain.com","otheruser@do main.com","msg-001","Hello, World!")`. By using "MESSAGE_TEMPLATE", the `Encapsulation` function replaces the placeholders in the protocol message structure that implements the real-time message service with the corresponding message content, resulting in the first long-connection protocol message in text form.

[0105]

[0106]

[0107] It should be noted that when writing test cases, it is necessary to write the message content for testing and specify the protocol message structure. Furthermore, when the first long-connection protocol message in text form is subsequently sent, the connection thread needs to parse the text-based first long-connection protocol message into an actual message object according to the protocol specifications of extensible messages and existing protocols before sending it.

[0108] Optionally, in one embodiment, a preset protocol message encapsulation function is called by the main thread to write the message content corresponding to the test object instance into the protocol message structure of the specified protocol service, thereby obtaining the first tested long connection protocol message, including:

[0109] The main thread determines the specified protocol service corresponding to the test object instance.

[0110] Based on the one-to-one correspondence between protocol services and protocol message encapsulation functions, the target protocol message encapsulation function corresponding to a specified protocol service is determined through the main thread.

[0111] The main thread calls the target protocol message encapsulation function by using the message content corresponding to the test object instance as a calling parameter.

[0112] In this embodiment of the application, in order to further improve the efficiency of protocol message generation and thus improve the efficiency of protocol testing, a protocol message encapsulation function is provided for each protocol message structure of different protocol services, for encapsulating the protocol message structure into a protocol message, such as... Figure 1f As shown, n is a positive integer. The protocol message encapsulation function is used to write the message content of the corresponding protocol service into the corresponding protocol message structure, thereby encapsulating the protocol message that implements the protocol service.

[0113] Accordingly, firstly, the main thread determines the specified protocol service corresponding to the test object instance based on the test cases. Depending on the actual test requirements, this specified protocol service can be either an extensible message or any protocol service supported by the existing protocol. Then, based on the one-to-one correspondence between the protocol service and the protocol message encapsulation function, the main thread determines the protocol message encapsulation function corresponding to the specified protocol service, denoted as the target protocol message encapsulation function. Finally, the main thread calls the target protocol message encapsulation function with the message content corresponding to the test object instance as the calling parameter.

[0114] Continuing with the example above, which illustrates a protocol message structure for implementing real-time messaging services within an extensible messaging and existence protocol, the protocol message encapsulation function corresponding to this protocol message structure can be defined as follows:

[0115]

[0116] Protocol message encapsulation can be achieved by calling the protocol message encapsulation function `send_message` on the main thread as follows:

[0117] send_message("testuser@domain.com","otheruser@domain.com","msg-001","Hello, World!").

[0118] Correspondingly, the protocol message encapsulation function `send_message` replaces the placeholders in the protocol message structure that implements real-time messaging with the corresponding message content, thus obtaining the first tested long-connection protocol message in text form:

[0119]

[0120] As can be seen, since the protocol message encapsulation function corresponds one-to-one with the protocol message structure protocol business, there is no need to specify the protocol message structure in the calling parameters. It is only necessary to pass the actual message content to the protocol message encapsulation function. In other words, when writing test cases, only the message content for testing needs to be written, which can also reduce the difficulty of writing test cases.

[0121] As shown above, in this embodiment of the application, each protocol service is maintained independently and only one protocol message structure is maintained, which can reduce usage and maintenance costs. Even if a protocol service changes, the test cases written based on the original message structure corresponding to that protocol service will not be affected. Only the corresponding protocol message structure of that protocol service needs to be modified. Even if a protocol service is removed from the long-term connection protocol being tested, only the content of the protocol message encapsulation function corresponding to that protocol service needs to be set to null, which will also have no impact on the test case level.

[0122] Optionally, in one embodiment, the main thread creates multiple test object instances. The main thread calls the protocol message encapsulation function with the message content corresponding to the test object instance as a call parameter. The protocol message encapsulation function writes the message content into the protocol message structure of the specified protocol service to obtain the first tested long connection protocol message, including:

[0123] The main thread determines the message sending and receiving order of multiple test object instances based on the test cases.

[0124] For each test object instance, based on the message sending and receiving order, the main thread determines whether it needs to block the main thread. If so, the main thread calls the protocol message encapsulation function with the message content and blocking indication information corresponding to the test object instance as calling parameters. The protocol message encapsulation function writes the message content into the protocol message structure of the specified protocol business to obtain the first tested long connection protocol message. Based on the blocking indication information, the main thread is blocked by the protocol message encapsulation function.

[0125] The first long-connection protocol message under test is obtained by the sending thread and provided to the connection thread. After the connection thread sends it to the server under test, the following steps are also included:

[0126] If a response protocol message corresponding to the first long-connection protocol message under test is received from the server under test through the connection thread, the blocking of the main thread is released through the protocol message encapsulation function according to the blocking indication information.

[0127] In this embodiment, the ability of the protocol message encapsulation function to block the main thread is also provided to ensure that protocol messages are sent and received in a specified message sending and receiving order. Specifically, the main thread first determines the message sending and receiving order of multiple test object instances based on test cases. For each test object instance, the main thread determines whether the calling parameters corresponding to that test object instance contain blocking indication information in addition to the message content corresponding to that test object instance, based on the message sending and receiving order. The protocol message encapsulation function is then called using the calling parameters corresponding to that test object instance. The blocking indication information instructs the protocol message encapsulation function to block the main thread, ensuring that the sending thread corresponding to each test object instance sends its corresponding first long-connection protocol message to the server under test in the message sending and receiving order.

[0128] For example, please refer to Figure 1g This illustrates the execution logic of the protocol message encapsulation function:

[0129] The protocol message encapsulation function first receives the call parameters (including message content and blocking indication information) from the main thread corresponding to a test object instance;

[0130] The protocol message encapsulation function extracts the protocol message structure of a specified protocol service;

[0131] The protocol message encapsulation function writes the message content into the protocol message structure to obtain the protocol message in text form.

[0132] Protocol message encapsulation functions objectify protocol messages in text form;

[0133] The protocol message encapsulation function writes the objectified protocol message into the sending queue, which the sending thread then provides to the connection thread to send to the server under test through the established long connection.

[0134] The protocol message encapsulation function determines whether the main thread needs to be blocked based on the blocking indication information in the call parameters, waiting for the server under test to return a response protocol message for the sent protocol message. In this case, the main thread is blocked, and other long-lived connections corresponding to other test object instances are suspended until the message query function finds a response protocol message (i.e., the protocol message returned by the server under test in response to the sent protocol message) in the receive queue. Once this is found, the blocking is released, allowing the main thread to continue execution. If the call parameters do not include blocking indication information, an instruction not to block the main thread is received, and the main thread continues execution. This achieves synchronization between multiple long-lived connections, ensuring that protocol messages are sent and received according to a specified message sending and receiving order.

[0135] For example, please refer to Figure 1hAssume that three test object instances are created by the main thread based on the test cases: Test Object Instance A, Test Object Instance B, and Test Object Instance C. The message sending and receiving order of these three test object instances is determined as follows: Test Object Instance A sends the first long-connection protocol message 1; Test Object Instance B sends the first long-connection protocol message 2; Test Object Instance C sends the first long-connection protocol message 3; Test Object Instance C sends the first long-connection protocol message 4; Test Object Instance A sends the first long-connection protocol message 5 after Test Object Instance C receives the second long-connection protocol message returned by the server in response to the first long-connection protocol message 4; Test Object Instance B sends the first long-connection protocol message 6 after Test Object Instance A receives the second long-connection protocol message returned by the server in response to the first long-connection protocol message 5; Test Object Instance C sends the first long-connection protocol message 7; Test Object Instance A sends the first long-connection protocol message 8; Test Object Instance B sends the first long-connection protocol message 9.

[0136] Following the message sending and receiving order described above, the main thread calls the protocol message encapsulation function in the following manner:

[0137] 1. The main thread calls the protocol message encapsulation function to encapsulate the first long-connection protocol message 1 corresponding to the test object instance A, and writes the first long-connection protocol message 1 corresponding to the test object instance A into the sending queue. The sending thread corresponding to the test object instance A retrieves the first long-connection protocol message 1 from the sending queue and provides it to the connection thread corresponding to the test object instance A to send to the server under test.

[0138] 2. The main thread calls the protocol message encapsulation function to encapsulate the first long-connection protocol message 2 corresponding to the test object instance B, and writes the first long-connection protocol message 2 to the sending queue corresponding to the test object instance B. The sending thread corresponding to the test object instance B retrieves the first long-connection protocol message 2 from the sending queue and provides it to the connection thread corresponding to the test object instance B to send to the server under test.

[0139] 3. The main thread calls the protocol message encapsulation function to encapsulate the first long-connection protocol message 3 corresponding to the test object instance C, and writes the first long-connection protocol message 3 to the sending queue corresponding to the test object instance C. The sending thread corresponding to the test object instance C retrieves the first long-connection protocol message 3 from the sending queue and provides it to the connection thread corresponding to the test object instance C to send to the server under test.

[0140] 4. The main thread calls the protocol message encapsulation function to encapsulate the first long-connection protocol message 4 corresponding to the test object instance C, and writes the first long-connection protocol message 4 into the sending queue corresponding to the test object instance C. The sending thread corresponding to the test object instance C retrieves the first long-connection protocol message 4 from the sending queue and provides it to the connection thread corresponding to the test object instance C to send to the server under test. In addition, the main thread is blocked until the connection thread corresponding to the test object instance C receives the second long-connection protocol message returned by the server under test in response to the first long-connection protocol message 4 (that is, the response protocol message of the first long-connection protocol message 4).

[0141] 5. After the connection thread corresponding to test object instance C receives the second long connection protocol message returned by the server under test in response to the first long connection protocol message 4, the main thread's blocking is released. At this time, the main thread continues to call the protocol message encapsulation function to encapsulate and obtain the first long connection protocol message 5 corresponding to test object instance A, and writes the first long connection protocol message 5 into the sending queue corresponding to test object instance A. The sending thread corresponding to test object instance A retrieves the first long connection protocol message 5 from the sending queue and provides it to the connection thread corresponding to test object instance A to send to the server under test. The main thread is blocked until the connection thread corresponding to test object instance A receives the second long connection protocol message returned by the server under test in response to the first long connection protocol message 5 (that is, the response protocol message of the first long connection protocol message 5).

[0142] 6. After the connection thread corresponding to test object instance A receives the second long connection protocol message returned by the server under test in response to the first long connection protocol message 5, the main thread's blocking is released. At this time, the main thread continues to call the protocol message encapsulation function to encapsulate and obtain the first long connection protocol message 6 corresponding to test object instance B, and writes the first long connection protocol message 6 to the sending queue corresponding to test object instance B. The sending thread corresponding to test object instance B retrieves the first long connection protocol message 6 from the sending queue and provides it to the connection thread corresponding to test object instance B to send to the server under test.

[0143] 7. The main thread calls the protocol message encapsulation function to encapsulate the first long-connection protocol message 7 corresponding to the test object instance C, and writes the first long-connection protocol message 7 to the sending queue corresponding to the test object instance C. The sending thread corresponding to the test object instance C retrieves the first long-connection protocol message 7 from the sending queue and provides it to the connection thread corresponding to the test object instance C to send to the server under test.

[0144] 8. The main thread calls the protocol message encapsulation function to encapsulate the first long-connection protocol message 8 corresponding to the test object instance A, and writes the first long-connection protocol message 8 into the sending queue corresponding to the test object instance A. The sending thread corresponding to the test object instance A retrieves the first long-connection protocol message 8 from the sending queue and provides it to the connection thread corresponding to the test object instance A to send to the server under test.

[0145] 9. The main thread calls the protocol message encapsulation function to encapsulate the first long-connection protocol message 7 corresponding to the test object instance 9, and writes the first long-connection protocol message 7 into the sending queue corresponding to the test object instance 9. The sending thread corresponding to the test object instance 9 retrieves the first long-connection protocol message 7 from the sending queue and provides it to the connection thread corresponding to the test object instance 9 to send to the server under test.

[0146] On the other hand, such as Figure 1h As shown, the server under test will receive the first long connection protocol message 1, the first long connection protocol message 2, the first long connection protocol message 3, the first long connection protocol message 4, the first long connection protocol message 5, the first long connection protocol message 6, the first long connection protocol message 7, the first long connection protocol message 8, and the first long connection protocol message 9 in sequence.

[0147] In step 140, the first long-connection protocol message under test is obtained by the sending thread and provided to the connection thread, which then sends it to the server under test.

[0148] As described above, in this embodiment, the sending thread is responsible for sending the protocol message. Accordingly, after the main thread generates the first long-connection protocol message corresponding to the test object instance, the sending thread further obtains the first long-connection protocol message and provides it to the connection thread, which then sends it to the server under test based on the established long connection. There are no specific restrictions on the transmission method of the first long-connection protocol message between the sending thread and the main thread. For example, a message queue can be used to implement the transmission of the first long-connection protocol message between the sending thread and the main thread. First, a message queue is created to cache the first long-connection protocol message, denoted as the sending queue. After the main thread generates the first long-connection protocol message corresponding to the test object instance, the generated message is written to the sending queue. The sending thread then retrieves the written first long-connection protocol message from the sending queue. The sending thread can periodically retrieve the written first long-connection protocol message from the sending queue, or it can automatically retrieve the written first long-connection protocol message from the sending queue according to the configured callback logic.

[0149] Furthermore, this embodiment of the application does not impose specific restrictions on how the sending thread provides the first long-connection protocol message to the connection thread. For example, the connection thread can provide a function for sending protocol messages that the sending thread can call, denoted as the message sending function. Correspondingly, the sending thread can call this message sending function provided by the connection thread, ultimately sending the first long-connection protocol message to the server under test through the established long connection.

[0150] In 150, the receiving thread provides the main thread with the second long-connection protocol message received by the connection thread from the server under test.

[0151] In this embodiment of the application, the protocol message from the server under test is denoted as the second long-connection protocol message under test. The second long-connection protocol message under test may be actively pushed by the server under test, or it may be returned by the server under test in response to the first long-connection protocol message under test.

[0152] For example, continuing with the test case definition above, which includes a step of requesting a contact list from the server under test, the expected result of the test case for this step is: the server under test returns the contact list. After sending the first long-connection protocol message used to request the contact list from the server under test to the server under test, if the long-connection protocol is working normally, the test case will receive a second long-connection protocol message from the server under test in response to the first long-connection protocol message, which carries the contact list, through the connection thread.

[0153] For example, suppose a test case defines two test object instances, test object instance A and test object instance B, and includes a step where test object instance A sends an instant message to test object instance B. Then, the first long-connection protocol message carrying the instant message from test object instance A will be obtained by the sending thread of test object instance A and provided to the connection thread of test object instance A, which will then send it to the server under test. On the other hand, the connection thread of test object instance B will receive the first long-connection protocol message pushed by the server under test; at this point, the first long-connection protocol message also becomes the second long-connection protocol message.

[0154] After the connection thread receives the second long-term connection protocol message from the server under test, the receiving thread provides this message to the main thread. There are no specific restrictions on the transmission method of the second long-term connection protocol message between the connection thread and the receiving thread. For example, a message queue can be used to implement the transmission of the second long-term connection protocol message between the connection thread and the receiving thread. First, a message queue is created to cache the second long-term connection protocol message, denoted as the receiving queue. Correspondingly, after receiving the second long-term connection protocol message from the server under test through the connection thread, the received message is written to the receiving queue. The receiving thread then retrieves the written second long-term connection protocol message from the receiving queue. The receiving thread can periodically retrieve the written second long-term connection protocol message from the receiving queue, or it can automatically retrieve the written message according to the configured callback logic.

[0155] Furthermore, this application embodiment does not impose specific restrictions on the transmission method of the second tested long connection protocol message between the receiving thread and the main thread. For example, shared memory can be used to implement the transmission of the second tested long connection protocol message between the main thread and the receiving thread. In this case, a memory space is first allocated as a buffer for caching the second tested long connection protocol message; correspondingly, the receiving thread writes the second tested long connection protocol message into the buffer so that the main thread can retrieve the second tested long connection protocol message from the buffer.

[0156] It should be noted that the original protocol messages are not readable and are usually in the form of meaningless strings. In order to enable the main thread to perform subsequent analysis, in this embodiment, the receiving thread also performs parsing and formatting operations on the second long-connection protocol message from the server under test according to the protocol specification of the long-connection protocol under test, converting the second long-connection protocol message into a format readable by the main thread before providing it to the main thread. For example, assuming that the main thread supports JSON format information, the receiving thread can convert the second long-connection protocol message from the server under test into JSON format before providing it to the main thread.

[0157] Optionally, in one embodiment, the protocol message encapsulation function is invoked via the main thread using the message content corresponding to the test object instance as a calling parameter, including:

[0158] Obtain the protocol message identifier corresponding to the test object instance through the main thread;

[0159] The protocol message encapsulation function is called by the main thread with the protocol message identifier and the message content corresponding to the test object instance as call parameters. The protocol message identifier and message content are used by the protocol message encapsulation function to write the protocol message structure of the specified protocol business to obtain the first long connection protocol message under test.

[0160] The receiving thread provides the main thread with the second long-connection protocol messages received from the server under test by the connection thread, including:

[0161] If the second long-connection protocol message under test carries a protocol message identifier corresponding to the test object instance, then the receiving thread stores the second long-connection protocol message under test into the first buffer for the main thread to retrieve; otherwise, the receiving thread stores the second long-connection protocol message under test into the second buffer for the main thread to retrieve.

[0162] In this embodiment, a protocol message identifier corresponding to the test object instance can be generated by calling an identifier generator through the main thread. This protocol message identifier, along with the message content corresponding to the test object instance, is then used as a calling parameter. A protocol message encapsulation function is called to write the protocol message identifier and the message content into the protocol message structure of the specified protocol service to obtain the first tested long-connection protocol message. For details, please refer to the relevant descriptions in the above embodiments; they will not be repeated here. Furthermore, the protocol message identifier is also written to the identifier cache area through the main thread.

[0163] It should be noted that, in order to facilitate the extraction of the second long-connection protocol message by the main thread, the embodiments of this application pre-divide a first cache area and a second cache area, wherein the first cache area is used to cache the second long-connection protocol message returned by the server under test in response to the first long-connection protocol message, and the second cache area is used to cache the second long-connection protocol message actively pushed by the server under test.

[0164] Correspondingly, when the receiving thread provides the main thread with the second long-connection protocol message received from the server under test by the connection thread, the receiving thread first identifies whether the protocol message identifier carried by the second long-connection protocol message is located in the identifier cache. If so, it is determined that the protocol message identifier carried by the second long-connection protocol message is the protocol message identifier corresponding to the above test object instance, that is, the second long-connection protocol message is returned by the server under test in response to the first long-connection protocol message sent by the connection thread. At this time, the receiving thread stores the second long-connection protocol message in the first cache for the main thread to retrieve. Otherwise, it is determined that the protocol identifier carried by the second long-connection protocol message is not the protocol message identifier corresponding to the above test object instance, that is, the second long-connection protocol message is actively pushed by the server under test. At this time, the receiving thread stores the second long-connection protocol message in the second cache for the main thread to retrieve.

[0165] In version 160, the test results of the long connection protocol under test are obtained by the main thread based on the second long connection protocol message under test.

[0166] Finally, the main thread can assert the formatted second long-connection protocol message provided by the connection thread according to the test case, thereby verifying whether the server under test meets the expected results of the test case based on the formatted second long-connection protocol message, and finally obtain the test result of the long-connection protocol under test. The test result describes whether the long-connection protocol under test can run normally on the server under test.

[0167] For example, continuing with the test case definition above, which includes a step of requesting a contact list from the server under test, the expected result of this test case for this step is as follows: the server under test returns the contact list. For the second long-connection protocol message formatted by the connection thread, the main thread identifies whether the formatted second long-connection protocol message includes the contact list. If it does, the test result is successful, indicating that the contact list service of the long-connection protocol can run normally on the server under test. If it does not include the contact list, the test result is unsuccessful, indicating that the contact list service of the long-connection protocol cannot run normally on the server under test.

[0168] As can be seen from the above, the protocol testing method provided in this application firstly creates a test object instance based on the test cases through the main thread, and starts the sending thread, connection thread, and receiving thread corresponding to the test object instance. Then, the connection thread establishes a long connection with the server under test according to the long connection protocol under test. Next, the main thread generates a first long connection protocol message corresponding to the test object instance. On the one hand, the sending thread obtains the first long connection protocol message under test and provides it to the connection thread, which then sends it to the server under test. On the other hand, the connection thread receives a second long connection protocol message under test from the server under test, formats the second long connection protocol message under test into a format readable by the main thread, and provides it to the main thread. Finally, the main thread obtains the test result of the long connection protocol under test based on the formatted second long connection protocol message under test. In this way, not only is automated protocol testing achieved, but also a multi-threaded model consisting of a sending thread, a connection thread, and a receiving thread is used to handle the establishment and maintenance of long connections and the sending / receiving of protocol messages during the testing process. This decouples the protocol message sending / receiving logic from the long connection, ensuring that all the running logic does not interfere with each other, avoiding the main thread being blocked at the test case level, and allowing the main thread to focus more on the upper-level execution of the test cases, thereby comprehensively improving the testing efficiency of long connection protocol testing.

[0169] Please refer to the reference. Figure 2a and Figure 2b Taking the terminal device as the execution subject of the protocol testing method provided in this application, and the long-connection protocol under test as Extensible Message Protocol (EPP), the process of this protocol testing method can also be as follows:

[0170] In 201, the terminal device creates a test object instance based on the test case through the main thread, and starts the sending thread, connection thread and receiving thread corresponding to the test object instance.

[0171] In this embodiment, the test cases are automated test cases, which differ from ordinary test cases. Automated test cases are typically written in a programming language and run based on a test framework. The test framework can be a software tool or library that provides a set of structures and functions to help write, execute, and manage automated test cases. The automated test cases are written based on the testing requirements for extensible messages and existence protocols; no specific limitations are imposed here. The main thread refers to the thread that runs the automated test cases.

[0172] To decouple the sending / receiving of scalable messages from the dependencies between existing protocol segments and long-lived connections, and to prevent the main thread from being blocked, this application provides a multi-threaded model. This multi-threaded model includes a sending thread, a connection thread, and a receiving thread.

[0173] The connection thread is configured to establish a long connection with the server under test according to the Extensible Message and Existence Protocol (EELP), and to transmit EELP segments with the server under test based on the long connection, as well as maintain the established long connection.

[0174] The sending thread is configured to retrieve the extensible message and existence protocol section from the main thread and provide it to the connection thread for sending.

[0175] The receiving thread is configured to provide the main thread with formatted extensible messages and existing protocol sections received from the server under test by the connection thread.

[0176] As shown above, this multi-threaded model can decouple the entire sending / receiving logic of scalable messages and existing protocol sections from long connections, so that all the running logic does not interfere with each other, and thus the main thread will not be blocked, thereby improving the testing efficiency of protocol testing.

[0177] Accordingly, in this embodiment, the terminal device first creates a test object instance based on the test cases through the main thread. This test object instance can be regarded as a simulated client object of the server under test. Then, it starts the multi-threaded model corresponding to the test object instance, that is, it starts the sending thread, connection thread and receiving thread corresponding to the test object instance. Then, based on the ability of the multi-threaded model to send and receive scalable messages and existing protocol segments between the client object and the server under test, it simulates the interaction between the client object and the server under test, thereby completing the protocol test of the server under test.

[0178] In 202, the terminal device establishes a long connection with the server under test through the connection thread according to the extensible message and existence protocol, and adds the socket object of the long connection to the current target I / O multiplexing mechanism.

[0179] As described above, after starting the multi-threaded model corresponding to the test object instance, the terminal device establishes a long connection with the server under test through the connection thread in the multi-threaded model, in accordance with the protocol specifications of Extensible Messages and Existence Protocols. This includes the following main processes: establishing a Transmission Control Protocol connection, starting a stream, starting Transport Layer Security Protocol encryption, performing simple verification and security layer authentication, restarting the stream, binding resources, and setting up a session. For details, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0180] I / O multiplexing is a technique for managing multiple I / O events simultaneously. Common I / O multiplexing mechanisms include select, poll, and epoll. They allow multiple file descriptors (such as socket objects) to be managed at the same time to determine which descriptors can be used for I / O operations (such as read, write, or exceptions).

[0181] For example, the connection thread can determine the operating system used by the terminal device, identify the optimal I / O multiplexing mechanism suitable for that operating system as the current target I / O multiplexing mechanism, and add the socket object corresponding to the established long connection to the target I / O multiplexing mechanism for management. In this way, the connection thread does not need to focus on the state of the socket object; instead, the target I / O multiplexing mechanism notifies the connection thread of state changes. When there are extensible messages, protocol segments that can be received or sent, or when an error occurs, the I / O multiplexing mechanism notifies the connection thread.

[0182] For example, such as Figure 2b As shown, when the terminal device uses the Linux operating system, the epoll mechanism is selected as the target I / O multiplexing mechanism; when the terminal device uses the Mac operating system, the poll mechanism is selected as the target I / O multiplexing mechanism; and when the terminal device uses the Windows operating system, the select mechanism is selected as the target I / O multiplexing mechanism.

[0183] Furthermore, to prevent socket objects from blocking when sending / receiving extensible messages and when protocol segments exist, the terminal device also configures the response rules corresponding to the socket object to the target I / O multiplexing mechanism through the connection thread. These response rules instruct the target I / O multiplexing mechanism how to perform response operations based on the send / receive status of the socket object. The response rules can be set according to actual needs; no specific restrictions are imposed here.

[0184] For example, for a socket object, the response rule can be set as follows: if the socket object does not receive a response to the extensible message and existence protocol section within the waiting time threshold after sending the extensible message and existence protocol section (i.e., send / receive status), then it switches to the next socket object to send the extensible message and existence protocol section (i.e., response operation).

[0185] As shown above, by entrusting the socket object of the long connection to the I / O multiplexing mechanism and configuring the response rules in the application embodiment, the sending / receiving efficiency of the connection thread can be improved, thereby improving the efficiency of protocol testing.

[0186] In section 203, the terminal device determines the specified protocol service corresponding to the test object instance through the main thread.

[0187] To improve the efficiency of generating extensible messages and existing protocol segments, thereby further enhancing protocol testing efficiency, this application maintains extensible message and existing protocol segment structures corresponding to different protocol services. It also predefines functions for writing message content and protocol message identifiers into these structures, denoted as protocol message encapsulation functions. Specifically, for each extensible message and existing protocol segment structure corresponding to different protocol services, a protocol message encapsulation function is provided to encapsulate that structure into an extensible message and existing protocol segment.

[0188] Correspondingly, the terminal device determines the specified protocol service corresponding to the test object instance through the main thread based on the test cases. Depending on the actual test requirements, the specified protocol service can be either scalable messaging or any protocol service supported by the existing protocol.

[0189] In 204, the terminal device determines the target protocol message encapsulation function corresponding to the specified protocol service through the main thread, based on the one-to-one correspondence between the protocol service and the protocol message encapsulation function.

[0190] Based on the one-to-one correspondence between protocol services and protocol message encapsulation functions, the terminal device determines the protocol message encapsulation function corresponding to a specified protocol service through the main thread, which is denoted as the target protocol message encapsulation function.

[0191] In 205, the terminal device obtains the protocol message identifier corresponding to the test object instance through the main thread.

[0192] Terminal devices can use the main thread to call the identifier generator to generate protocol message identifiers corresponding to the test object instance.

[0193] In 206, the terminal device calls the target protocol message encapsulation function through the main thread, using the protocol message identifier and message content as call parameters. The protocol message identifier and message content are used by the target protocol message encapsulation function to write the extensible message and existing protocol section structure of the specified protocol service to obtain the first extensible message and existing protocol section, and then store the first extensible message and existing protocol section into the sending queue.

[0194] The terminal device uses the obtained protocol message identifier along with the message content corresponding to the test object instance as calling parameters. It then calls the target protocol message encapsulation function to write the protocol message identifier and the message content into the extensible message and existing protocol section structure of the specified protocol service, obtaining the first extensible message and existing protocol section. Specific details can be found in the relevant descriptions in the above embodiments, and will not be repeated here. Furthermore, the terminal device also writes the above protocol message identifier into the identifier cache area through the main thread.

[0195] In step 207, the terminal device sends the first extensible message in the sending queue and the existence protocol section to the server under test by calling the message sending function provided by the connection thread through the sending thread.

[0196] In this embodiment of the application, the connection thread provides a function for sending extended messages and existence protocol sections that can be called by the sending thread, denoted as the message sending function. Accordingly, the terminal device can send the first extended message and existence protocol section in the sending queue to the server under test through the established long connection by calling the message sending function provided by the connection thread through the sending thread.

[0197] In step 208, the terminal device receives the second scalable message and existence protocol section from the server under test through the connection thread and stores it in the receive queue.

[0198] In this embodiment of the application, the scalable message and existence protocol section from the server under test is referred to as the second scalable message and existence protocol section. The second scalable message and existence protocol section may be actively pushed by the server under test, or it may be returned by the server under test in response to the first scalable message and existence protocol section.

[0199] After receiving the second extensible message and existence protocol section from the server under test through the connection thread, the terminal device stores the second extensible message and existence protocol section into the receiving queue.

[0200] In step 209, if the second extensible message and the existence protocol section in the receiving queue carry a protocol message identifier corresponding to the test object instance, the terminal device formats the second extensible message and the existence protocol section and stores it in the first buffer for the main thread to retrieve. Otherwise, the terminal device formats the second extensible message and the existence protocol section and stores it in the second buffer for the main thread to retrieve.

[0201] To facilitate the extraction of the second extensible message and existence protocol section by the main thread, the embodiments of this application pre-divide a first cache area and a second cache area, wherein the first cache area is used to cache the second extensible message and existence protocol section returned by the server under test in response to the first extensible message and existence protocol section, and the second cache area is used to cache the second extensible message and existence protocol section actively pushed by the server under test.

[0202] Correspondingly, when the terminal device provides the main thread with the second extensible message and existence protocol segment received from the server under test by the connection thread through the receiving thread, it first identifies whether the protocol message identifier carried by the second extensible message and existence protocol segment is located in the identifier cache. If so, it is determined that the protocol message identifier carried by the second extensible message and existence protocol segment is the protocol message identifier corresponding to the above test object instance, that is, the second extensible message and existence protocol segment is returned by the server under test in response to the first extensible message and existence protocol segment sent by the connection thread. At this time, the receiving thread stores the second extensible message and existence protocol segment into the first cache for the main thread to retrieve. Otherwise, it is determined that the protocol identifier carried by the second extensible message and existence protocol segment is not the protocol message identifier corresponding to the above test object instance, that is, the second extensible message and existence protocol segment is actively pushed by the server under test. At this time, the receiving thread stores the second extensible message and existence protocol segment into the second cache for the main thread to retrieve.

[0203] It should be noted that the original Extensible Message and Existence Protocol (EEP) section is not readable and is usually a meaningless string. To enable the main thread to perform subsequent analysis, in this embodiment, the receiving thread formats the second Extensible Message and Existence Protocol (EEP) section from the server under test according to the EEP protocol specification. This converts the second EEP section into a format readable by the main thread before providing it to the first or second cache. For example, assuming the main thread supports JSON format information, the terminal device can use the receiving thread to convert the second EEP section from the server under test into JSON format and store it in the first / second cache before the main thread retrieves it.

[0204] In 210, the terminal device obtains the test results of the extensible message and existence protocol based on the formatted second extensible message and existence protocol section through the main thread.

[0205] Finally, the terminal device can assert the formatted second extensible message and existence protocol section provided by the connection thread through the main thread according to the test case. In this way, it can verify whether the server under test meets the expected results of the test case based on the formatted second extensible message and existence protocol section, and finally obtain the test result of the extensible message and existence protocol. The test result describes whether the extensible message and existence protocol can run normally on the server under test.

[0206] To facilitate better implementation of the above protocol testing methods, this application also provides a corresponding protocol testing apparatus. The meanings of the terms used are the same as in the above protocol testing methods; for specific implementation details, please refer to the descriptions in the above method embodiments.

[0207] Please refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of a protocol testing device provided in an embodiment of this application. The protocol testing device may include a thread startup module 310, a connection establishment module 320, a message generation module 330, a message sending module 340, a message receiving module 350, and a test analysis module 360.

[0208] The thread startup module 310 is used to create test object instances based on test cases through the main thread, and start the sending thread, connection thread and receiving thread corresponding to the test object instance;

[0209] The connection establishment module 320 is used to establish a long connection with the server under test through the connection thread in accordance with the long connection protocol under test;

[0210] The message generation module 330 is used to generate the first long-connection protocol message corresponding to the test object instance through the main thread;

[0211] The message sending module 340 is used to obtain the first long connection protocol message under test through the sending thread and provide it to the connection thread, which then sends it to the server under test.

[0212] The message receiving module 350 is used to provide the main thread with the second long connection protocol message received by the connection thread from the server under test through the receiving thread;

[0213] The test analysis module 360 ​​is used to obtain the test results of the long connection protocol under test through the main thread based on the message of the second long connection protocol under test.

[0214] Optionally, in one embodiment, the message generation module 330 is used to call the protocol message encapsulation function with the message content corresponding to the test object instance as the calling parameter through the main thread, and write the message content into the protocol message structure of the specified protocol service through the protocol message encapsulation function to obtain the first tested long connection protocol message.

[0215] Optionally, in one embodiment, the message generation module 330 is used to determine the specified protocol service corresponding to the test object instance through the main thread; determine the target protocol message encapsulation function corresponding to the specified protocol service through the main thread according to the one-to-one correspondence between the protocol service and the protocol message encapsulation function; and call the target protocol message encapsulation function with the message content as the calling parameter through the main thread.

[0216] Optionally, in one embodiment, the message generation module 330 is used to obtain the protocol message identifier corresponding to the test object instance through the main thread; and to call the protocol message encapsulation function through the main thread with the protocol message identifier and the message content corresponding to the test object instance as calling parameters, wherein the protocol message identifier and the message content are used by the protocol message encapsulation function to write the protocol message structure of the specified protocol service to obtain the first tested long connection protocol message;

[0217] The message receiving module 350 is used to store the second tested long connection protocol message into the first buffer for the main thread to retrieve if the second tested long connection protocol message carries a protocol message identifier; otherwise, it stores the second tested long connection protocol message into the second buffer for the main thread to retrieve.

[0218] Optionally, in one embodiment, the thread startup module 310 is used to, if there are multiple test object instances, start the sending thread, connection thread and receiving thread corresponding to the test object instance through the main thread for each test object instance.

[0219] Optionally, in one embodiment, the message generation module 330 is used to determine the message sending and receiving order of multiple test object instances through the main thread based on the test cases; for each test object instance, according to the message sending and receiving order, the main thread determines whether it is necessary to block the main thread; if so, the main thread calls the protocol message encapsulation function with the message content corresponding to the test object instance and the blocking indication information as calling parameters; the protocol message encapsulation function writes the message content into the protocol message structure of the specified protocol service to obtain the first tested long connection protocol message; and according to the blocking indication information, the main thread is blocked through the protocol message encapsulation function; if the connection thread receives a response protocol message from the server under test corresponding to the first tested long connection protocol message, the blocking of the main thread is released through the protocol message encapsulation function according to the blocking indication information.

[0220] Optionally, in one embodiment, the connection establishment module 320 is further configured to determine the current target I / O multiplexing mechanism through the connection thread, and add the socket object corresponding to the long connection to the target I / O multiplexing mechanism; and configure the response rules corresponding to the socket object to the target I / O multiplexing mechanism through the connection thread, wherein the response rules include response operations corresponding to different send and receive states of the socket object.

[0221] As can be seen from the above, the protocol testing device provided in this application firstly uses the thread startup module 310 to create a test object instance according to the test cases through the main thread, and starts the sending thread, connection thread and receiving thread corresponding to the test object instance. Then, the connection establishment module 320 establishes a long connection with the server under test through the connection thread according to the long connection protocol under test. Then, the message generation module 330 generates the first long connection protocol message under test corresponding to the test object instance through the main thread. On the one hand, the message sending module 340 obtains the first long connection protocol message under test through the sending thread and provides it to the connection thread, which then sends it to the server under test. On the other hand, the message receiving module 350 receives the second long connection protocol message under test from the server under test through the connection thread, formats the second long connection protocol message under test into a format readable by the main thread and provides it to the main thread. Finally, the test analysis module 360 ​​obtains the test result of the long connection protocol under test according to the formatted second long connection protocol message under test through the main thread. In this way, not only is automated protocol testing achieved, but also a multi-threaded model consisting of a sending thread, a connection thread, and a receiving thread is used to handle the establishment and maintenance of long connections and the sending / receiving of protocol messages during the testing process. This decouples the protocol message sending / receiving logic from the long connection, ensuring that all the running logic does not interfere with each other, avoiding the main thread being blocked at the test case level, and allowing the main thread to focus more on the upper-level execution of the test cases, thereby comprehensively improving the testing efficiency of long connection protocol testing.

[0222] For details on the implementation of each of the above modules, please refer to the previous examples, which will not be repeated here.

[0223] This application also provides a terminal device, including a memory and a processor, wherein the processor executes the steps in the protocol testing method provided in the above embodiments by calling a computer program stored in the memory.

[0224] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application.

[0225] The terminal device may include components such as a processor 101 with one or more processing cores, a memory 102 with one or more computer-readable storage media, a power supply 103, and an input unit 104. Those skilled in the art will understand that... Figure 4 The terminal device structure shown does not constitute a limitation on the terminal device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0226] The processor 101 is the control center of the terminal device, connecting various parts of the terminal device through various interfaces and lines. It executes various functions and processes data by running or executing software programs and / or modules stored in the memory 102, and by calling data stored in the memory 102. Optionally, the processor 101 may include one or more processing cores; optionally, the processor 101 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 101.

[0227] The memory 102 can be used to store software programs and modules. The processor 101 executes various functional applications and data processing by running the software programs and modules stored in the memory 102. The memory 102 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 102 may also include a memory controller to provide the processor 101 with access to the memory 102.

[0228] The terminal device also includes a power supply 103 that supplies power to the various components. Optionally, the power supply 103 can be logically connected to the processor 101 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 103 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0229] The terminal device may also include an input unit 104, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0230] Although not shown, the terminal device may also include a display unit, an image acquisition component, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 101 loads one or more executable codes corresponding to computer programs into the memory 102, and the processor 101 executes the steps in the protocol testing method provided in this application, such as:

[0231] The main thread creates test object instances based on test cases and starts the sending thread, connection thread, and receiving thread corresponding to the test object instances.

[0232] A long connection is established with the server under test through a connection thread in accordance with the long connection protocol under test;

[0233] The main thread generates the first long-connection protocol message corresponding to the test object instance.

[0234] The first long connection protocol message under test is obtained by the sending thread and provided to the connection thread, which then sends it to the server under test.

[0235] The receiving thread provides the main thread with the second long-connection protocol message received from the server under test by the connection thread.

[0236] The test results of the long connection protocol under test are obtained by the main thread based on the message of the second long connection protocol under test.

[0237] It should be noted that the terminal device provided in this application embodiment and the protocol testing method in the above embodiment belong to the same concept. The specific implementation process can be found in the above related embodiments, and will not be repeated here.

[0238] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program stored thereon is executed on the processor of the terminal device provided in the embodiments of this application, the processor of the terminal device implements the steps in the protocol testing method provided in this application. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0239] This application also provides a computer program product, which includes a computer program that, when executed on a processor, causes the processor to implement the steps in the protocol testing method provided in this application.

[0240] The protocol testing method, protocol testing apparatus, terminal equipment, computer-readable storage medium, and computer program product provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0241] It should be noted that when the above embodiments of this application are applied to specific products or technologies, and user-related data is involved, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A method of protocol testing, characterized by, include: The main thread creates test object instances based on test cases and starts the sending thread, connection thread, and receiving thread corresponding to the test object instance. The connection thread establishes a long connection with the server under test according to the long connection protocol under test. The main thread generates the first long-connection protocol message corresponding to the test object instance. The first long connection protocol message under test is obtained by the sending thread and provided to the connection thread, which then sends it to the server under test. The receiving thread provides the main thread with the second long-connection protocol message received by the connection thread from the server under test. The main thread obtains the test results of the long connection protocol under test based on the second long connection protocol message.

2. The protocol testing method according to claim 1, characterized in that, The step of generating the first long-connection protocol message corresponding to the test object instance through the main thread includes: The main thread calls the protocol message encapsulation function with the message content corresponding to the test object instance as the calling parameter, and the protocol message encapsulation function writes the message content into the protocol message structure of the specified protocol business to obtain the first tested long connection protocol message.

3. The protocol testing method according to claim 2, characterized in that, The step of calling the protocol message encapsulation function via the main thread, using the message content corresponding to the test object instance as a calling parameter, includes: The main thread determines the specified protocol service corresponding to the test object instance. Based on the one-to-one correspondence between protocol services and protocol message encapsulation functions, the target protocol message encapsulation function corresponding to the specified protocol service is determined by the main thread. The main thread calls the target protocol message encapsulation function by passing the message content as a parameter.

4. The protocol testing method according to claim 2, characterized in that, The step of calling the protocol message encapsulation function via the main thread, using the message content corresponding to the test object instance as a calling parameter, includes: The protocol message identifier corresponding to the test object instance is obtained through the main thread; The main thread calls the protocol message encapsulation function with the protocol message identifier and the message content corresponding to the test object instance as call parameters. The protocol message identifier and the message content are used by the protocol message encapsulation function to write the protocol message structure of the specified protocol business to obtain the first tested long connection protocol message. The step of providing the main thread with the second long-connection protocol message received by the connection thread from the server under test through the receiving thread includes: If the second long-connection protocol message under test carries the protocol message identifier, then the receiving thread stores the second long-connection protocol message under test into the first buffer for the main thread to retrieve; otherwise, the receiving thread stores the second long-connection protocol message under test into the second buffer for the main thread to retrieve.

5. The protocol testing method according to claim 2, characterized in that, Starting the sending thread, connection thread, and receiving thread corresponding to the test object instance includes: If there are multiple test object instances, then for each test object instance, the main thread starts the sending thread, connection thread, and receiving thread corresponding to that test object instance.

6. The protocol testing method according to claim 5, characterized in that, The step of calling the protocol message encapsulation function via the main thread, using the message content corresponding to the test object instance as a call parameter, and then writing the message content into the protocol message structure of the specified protocol service through the protocol message encapsulation function to obtain the first tested long connection protocol message includes: The main thread determines the message sending and receiving order of multiple test object instances based on the test cases. For each test object instance, based on the message sending and receiving order, the main thread determines whether it needs to be blocked. If so, the main thread calls the protocol message encapsulation function with the message content corresponding to the test object instance and the blocking indication information as calling parameters. The protocol message encapsulation function writes the message content into the protocol message structure of the specified protocol service to obtain the first tested long connection protocol message. Based on the blocking indication information, the main thread is blocked by the protocol message encapsulation function. After the step of obtaining the first tested long connection protocol message through the sending thread and providing it to the connection thread, and then having the connection thread send it to the tested server, the process further includes: If a response protocol message corresponding to the first long-connection protocol message under test is received from the server under test through the connection thread, the blocking of the main thread is released through the protocol message encapsulation function according to the blocking indication information.

7. The protocol testing method according to claim 1, characterized in that, Before generating the first tested long-connection protocol message corresponding to the test object instance through the main thread, the method further includes: The current target I / O multiplexing mechanism is determined through the connection thread, and the socket object corresponding to the long connection is added to the target I / O multiplexing mechanism. The connection thread configures the response rules corresponding to the socket object to the target I / O multiplexing mechanism. The response rules include response operations corresponding to different send and receive states of the socket object.

8. A protocol testing device, characterized in that, include: The thread startup module is used to create test object instances based on test cases through the main thread, and start the sending thread, connection thread and receiving thread corresponding to the test object instance; The connection establishment module is used to establish a long connection with the server under test through the connection thread in accordance with the long connection protocol under test; The message generation module is used to generate the first long-connection protocol message corresponding to the test object instance through the main thread; The message sending module is used to obtain the first tested long connection protocol message through the sending thread and provide it to the connection thread, which then sends it to the tested server. The message receiving module is used to provide the main thread with the second long-connection protocol message received by the connection thread from the server under test through the receiving thread; The test analysis module is used to obtain the test results of the long connection protocol under test through the main thread based on the second long connection protocol message under test.

9. A terminal device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, implements the steps of the protocol testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for execution by a processor to implement the steps of the protocol testing method according to any one of claims 1 to 7.

Images