Service testing method and device, storage medium and electronic equipment

Abstract

The application provides a service test method and device, a storage medium and an electronic device, the method comprising: when a test request is received, analyzing the test request to obtain a test case described based on a domain-specific language (DSL); performing semantic conversion processing on the test case to obtain an operation set; the operation set comprising a plurality of operation instructions arranged in sequence; determining whether the operation set meets a preset execution condition; if the operation set meets the execution condition, performing service test on a service system service according to the operation set to obtain a test result; performing packet conversion on the test result to obtain a response packet; and performing request response on the test request based on the response packet to end the service test process. According to the method, a tester can initiate a request based on a test case described by DSL to implement service test, without the need to configure a MATIP session program, so that the test efficiency is improved and the convenience of test work is improved.

Description

Technical Field

[0001] This invention relates to the field of testing technology, and in particular to a service testing method and apparatus, storage medium and electronic device. Background Technology

[0002] In the air transport industry, staff typically handle various tasks through different business systems. Many of these systems utilize MATIP services, which are services developed based on the MATIP protocol. The MATIP protocol refers to the Mapping of Airline Reservation, Ticketing and Messaging Traffic Coverage IP (MATIP) protocol, a proprietary protocol used in the air transport industry.

[0003] In the development and maintenance of business systems, testing of the MATIP service is typically required. Current MATIP service testing primarily employs a custom program approach. Testers set startup parameters for the test scenario to configure the session policy, implement message exchange between the server and client using a custom program, store the exchange messages in a database, and then review the messages in the database to identify the test results.

[0004] In actual testing, MATIP service testing involves numerous testing scenarios. Based on existing service testing methods, testers need to set different startup parameters for different scenarios, resulting in poor scenario adaptability of the testing methods, a heavy workload for testers, and relatively low testing efficiency. Secondly, testers need to be thoroughly familiar with the MATIP protocol, placing high demands on them and reducing the convenience of conducting testing work. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a service testing method and apparatus, storage medium and electronic device to solve the problems in the existing service testing process, which require testers to customize programs for the test scenario, resulting in low testing efficiency, and require testers to master the MATIP protocol, which is not conducive to convenient testing.

[0006] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0007] The first aspect of this invention provides a service testing method, comprising:

[0008] When a test request to test a business system service is received, the test request is parsed to obtain the test cases corresponding to the test request; the business system service is a service built on the Air Traffic Service IP Group Protocol; the test request is a request created based on the Hypertext Transfer Protocol; and the test cases are test cases describing the test scenario based on the Domain-Specific Language (DSL).

[0009] The test cases are semantically transformed to obtain the operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence.

[0010] Determine whether the set of operations meets the preset execution conditions;

[0011] If the set of operations meets the execution conditions, then the business system service is tested based on the set of operations to obtain the test results corresponding to the test cases;

[0012] The test results are processed by message conversion to obtain the response message corresponding to the test results;

[0013] Based on the response message, the test request is responded to, and the service test process corresponding to the test request is terminated.

[0014] A second aspect of the present invention provides a service testing apparatus, comprising:

[0015] The message parsing unit is used to parse the test request when a test request for testing a business system service is received, and to obtain the test cases corresponding to the test request; the business system service is a service built based on the Air Traffic Service IP Group Protocol; the test request is a request created based on the Hypertext Transfer Protocol; and the test cases are test cases describing the test scenario based on the Domain-Specific Language (DSL).

[0016] A semantic conversion unit is used to perform semantic conversion processing on the test cases to obtain an operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence.

[0017] The judgment unit is used to determine whether the set of operations meets the preset execution conditions;

[0018] The testing unit is used to perform service testing on the business system service based on the operation set if the operation set meets the execution conditions, and obtain the test results corresponding to the test cases.

[0019] A message conversion unit is used to convert the test results into messages to obtain a response message corresponding to the test results.

[0020] The response unit is used to respond to the test request based on the response message and end the service test process corresponding to the test request.

[0021] A third aspect of the present invention provides a storage medium comprising stored instructions, wherein, when the instructions are executed, the device in which the storage medium resides executes the service testing method described above.

[0022] A fourth aspect of the present invention provides an electronic device, including a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described above for service testing.

[0023] This invention provides a service testing method, apparatus, storage medium, and electronic device. The method includes: upon receiving a test request to test a business system service, parsing the test request to obtain test cases corresponding to the test request; the business system service is a service built based on the Air Traffic Service IP Group Protocol; the test request is a request created based on the Hypertext Transfer Protocol; the test cases are test cases describing test scenarios based on Domain-Specific Language (DSL); performing semantic conversion processing on the test cases to obtain an operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence; determining whether the operation set meets preset execution conditions; if the operation set meets the execution conditions, performing service testing on the business system service based on the operation set to obtain test results corresponding to the test cases; performing message conversion on the test results to obtain a response message corresponding to the test results; responding to the test request based on the response message to end the service testing process. Using the method provided by this invention, testers can initiate test requests based on the Hypertext Transfer Protocol (HTTP) interface. The service testing system can convert test cases into operation instructions for the MATLAB service through semantic conversion, then execute the operation instructions to implement service testing, and provide test results through request-response feedback. Testers only need to prepare DSL-based test cases to achieve automated service testing, without the need to configure the actual MATIP session program. Furthermore, the DSL language has a declarative nature, which simplifies the writing of test cases, reduces the workload of testers, and has low requirements for mastering the MATIP protocol, which helps to improve testing efficiency and the convenience of testing work. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0025] Figure 1 A flowchart of a service testing method provided in an embodiment of the present invention;

[0026] Figure 2 A module example diagram of a service testing system provided in an embodiment of the present invention;

[0027] Figure 3 This is another example diagram of a service testing system provided in an embodiment of the present invention;

[0028] Figure 4 An example diagram illustrating a service testing process provided in an embodiment of the present invention;

[0029] Figure 5 Another example diagram of a service testing process provided in an embodiment of the present invention;

[0030] Figure 6 Another example diagram illustrating a service testing process provided in an embodiment of the present invention;

[0031] Figure 7 Another example diagram of a service testing process provided in an embodiment of the present invention;

[0032] Figure 8 Another example diagram illustrating a service testing process provided in an embodiment of the present invention;

[0033] Figure 9 This is a schematic diagram of the structure of a service testing device provided in an embodiment of the present invention;

[0034] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0036] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0037] It should be noted that the concepts of "first" and "second" mentioned in the embodiments of the present invention are only used to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0038] It should be noted that the terms "a" and "a plurality of" mentioned in the embodiments of the present invention are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0039] This invention provides a service testing method, which can be applied to a service testing system. The execution subject of the method can be the system's server. The method flowchart is shown below. Figure 1 As shown, it includes:

[0040] S101: When a test request to test a business system service is received, the test request is parsed to obtain the test cases corresponding to the test request; the business system service is a service built based on the Air Traffic Service IP Group Protocol; the test request is a request created based on the Hypertext Transfer Protocol; the test cases are test cases describing the test scenario based on the Domain-Specific Language (DSL).

[0041] The method provided in this invention is applied to the testing scenario of MATIP services. The service testing system exposes a Hypertext Transfer Protocol (HTTP) interface on the front end. Testers can initiate test requests by calling the HTTP interface from the front end, and the requests carry test cases configured based on a Domain-Specific Language (DSL). A Domain-Specific Language (DSL) is a computer language focused on a specific application domain; it is an existing language and will not be described in detail here. In the method provided in this invention, testers abstract the MATIP session model using the DSL, and perform declarative semantic descriptions of test scenarios such as session establishment and maintenance, heartbeat maintenance, and message sending and receiving for the MATIP service to obtain test cases. Test requests are then initiated based on these test cases. The DSL can be defined using JSON data format.

[0042] In the method provided by this embodiment of the invention, when the server of the service testing system receives a test request, it can parse the test request and obtain test cases from it.

[0043] S102: Perform semantic transformation processing on the test cases to obtain the operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence;

[0044] The method provided in this embodiment of the invention has a pre-configured semantic conversion mechanism for DSL. By establishing a semantic model of the MATIP service, the test scenarios described in the test cases can be converted into operation commands for the test process.

[0045] During the semantic transformation of test cases, lexical and syntactic analysis are performed on the test cases in sequence, and then a semantic model is established. The semantic model is used to generate the corresponding operation instruction sequence, and the operation set corresponding to the test case is composed of the operation instructions arranged in sequence.

[0046] S103: Determine whether the set of operations meets the preset execution conditions;

[0047] In the method provided by the embodiments of the present invention, execution conditions are preset according to the requirements of instruction execution, that is, the conditions that the operation set needs to meet to execute normally, such as whether the data source is available, etc.

[0048] An executability analysis is performed on a set of operations based on preset execution conditions. If the set of operations passes the executability analysis, it is considered to meet the execution conditions; otherwise, it is considered to fail. For example, if an operation in the set involves sending data based on a certain data source, but the database connection to that data source is abnormal, the data to be sent cannot be loaded, and thus the set is considered to fail the execution conditions.

[0049] S104: If the operation set meets the execution conditions, then perform service testing on the business system service based on the operation set to obtain the test results corresponding to the test cases;

[0050] In the method provided by this embodiment of the invention, if the operation set is determined to meet the preset execution conditions, then each operation command in the operation set is executed sequentially to perform service testing on the corresponding MATIP service and obtain the test result. This test result may be the service test result obtained after completing the test process, or it may be an exception feedback result obtained when an exception occurs during execution.

[0051] S105: Perform message conversion on the test results to obtain the response message corresponding to the test results;

[0052] In the method provided by the embodiments of the present invention, the test result is converted into a message by a preset response message conversion strategy. Specifically, the test result can be encapsulated into a JSON format message to obtain the response message corresponding to the test result.

[0053] S106: Based on the response message, respond to the test request and end the service test process corresponding to the test request.

[0054] In the method provided by this embodiment of the invention, the response message is sent back to the requester via an HTTP interface to respond to the test request and complete the service test process.

[0055] Based on the method provided in this embodiment of the invention, when a test request for testing a business system service is received, the test request is parsed to obtain the test cases corresponding to the test request; the business system service is a MATIP service; the test request is a request created based on the Hypertext Transfer Protocol; the test cases are test cases describing the test scenario based on the Domain-Specific Language (DSL); the test cases are semantically converted to obtain the operation set corresponding to the test cases, including multiple operation instructions arranged in sequence; it is determined whether the operation set meets the preset execution conditions; if the operation set meets the execution conditions, the business system service is tested according to the operation set to obtain the test results corresponding to the test cases; the test results are message converted to obtain the response message corresponding to the test results; the test request is responded to based on the response message, and the service test process corresponding to the test request ends. Using the method provided in this embodiment of the invention, testers can initiate test requests based on an HTTP interface. The service test system can convert test cases into operation instructions for the MATIP service through semantic conversion, and then implement service testing by executing the operation instructions, and provide test results through request and response. Testers only need to prepare DSL-based test cases to achieve automated service testing, without the need to configure the actual MATIP session program. Furthermore, the DSL language has a declarative nature, which simplifies the writing of test cases, reduces the workload of testers, and has low requirements for mastering the MATIP protocol, which helps to improve testing efficiency and the convenience of testing work.

[0056] exist Figure 1 Based on the method shown, the method provided in this embodiment of the invention, in step S101, involves parsing the test request to obtain the test cases corresponding to the test request, including:

[0057] The test request is converted into a message format to obtain the request data corresponding to the test request.

[0058] Obtain the request body data from the request data, and use the request body data as the test case corresponding to the test request.

[0059] In the method provided by this embodiment of the invention, the test request is a JSON format message, and the test cases are carried in the request body of the test request, i.e., the request body part. Through a preset request message conversion strategy, the test request is converted from a JSON format message into request data corresponding to the data format of the system application, and the request body data is obtained from the request data to obtain the test cases.

[0060] exist Figure 1 Based on the method shown, in the method provided by this embodiment of the invention, the process mentioned in step S104 of performing service testing on the business system service according to the operation set and obtaining the test results corresponding to the test cases includes:

[0061] Determine whether there is a worker coroutine among the pre-created worker coroutines that matches the test case;

[0062] In the method provided by this invention, corresponding MATIP sessions are processed through worker coroutines to test the MATIP service. Since the service testing system is a public system capable of handling different testing processes, worker coroutines are created in response to other testing requests. Furthermore, when the service testing system acts as the server for the MATIP service and tests the client side of the MATIP service, testers can send a session establishment request to the service testing system through the client. Normally, in response to this session establishment request, the service testing system will also create corresponding worker coroutines to process the corresponding MATIP sessions.

[0063] In the method provided by this invention, the testing process relies on a MATIP session, and a corresponding MATIP session must first be established during the testing process. First, it is determined whether there is a working coroutine that matches the current test case among the various pre-created working coroutines, that is, whether the MATIP session established by each working coroutine is the same as the MATIP session required by the current test case.

[0064] If there is a coroutine in each of the coroutines that matches the test case, then the coroutine in each of the coroutines that matches the test case is taken as the target coroutine.

[0065] In the method provided by the embodiments of the present invention, if there is a working coroutine in each working coroutine that matches the test case, that is, the MATIP session required for the test case has been established, then the working coroutine that matches the test case is taken as the target working coroutine.

[0066] Invoke the target worker coroutine to execute the command operation corresponding to the operation set, and obtain the execution result of the target worker coroutine;

[0067] The execution result of the target working coroutine is used as the test result corresponding to the test case.

[0068] In the method provided by this invention, a target worker coroutine executes command operations corresponding to the operation set, such as sending a message, receiving a message, sending a heartbeat signal, etc. After the target worker coroutine completes the command operation instruction, the execution result of the command operation can be obtained. The execution result of the target worker coroutine is used as the test result corresponding to the test case.

[0069] Based on the method provided in the above embodiments, the method provided in this embodiment of the invention includes the process of determining whether there is a working coroutine matching the test case among the pre-created working coroutines, comprising:

[0070] Determine the first session identifier group corresponding to the test case; the first session identifier group includes the connection mode, remote identifier, and session identifier of the service session corresponding to the test case.

[0071] In the method provided by this invention, each MATIP session, i.e., a service session, is identified using a session identifier group. The session identifier group is a triple, including three attribute data: connection mode, remote identifier, and session identifier. The connection mode refers to the mode in which the service test system connects to the object under test (DUT), representing whether the service test system connects as a server or as a client. Its specific value can be either "client" or "server." The remote identifier refers to the identifier of the DUT. When the system acts as a client, the remote identifier can be the server's IP address and port address; when the system acts as a server, the remote identifier can be the IP address and port address of the client connected to this server. The session identifier refers to H1H2, which is the session identifier for the MATIP connection. Each attribute data in the session identifier group must be carried in the test scenario described by the test cases. It can be understood that the corresponding information will also be carried in the operation set parsed from the test cases.

[0072] In the method provided by the embodiments of the present invention, the session identifier group corresponding to the test case, namely the first session identifier group, can be obtained based on the data in the test case or the operation set.

[0073] Determine a second session identifier group corresponding to each of the worker coroutines; each second session identifier group includes the connection mode, remote identifier, and session identifier of the service session corresponding to its worker coroutine.

[0074] In the method provided by the embodiments of the present invention, for each working coroutine, data such as connection mode, remote identifier and session identifier corresponding to the MATIP session can be obtained from the session information of the MATIP session processed by the working coroutine, thereby obtaining the session identifier group of the MATIP session, and using the session identifier group as the second session identifier group corresponding to the working coroutine.

[0075] Compare each second session identifier group with the first session identifier group;

[0076] If a second session identifier group exists that is the same as the first session identifier group, then it is determined that among each of the worker coroutines, there is a worker coroutine that matches the test case;

[0077] In the method provided by this embodiment of the invention, each second session identifier group is compared with a first session identifier group to identify whether each second session identifier group is the same as the first session identifier group. The second session identifier group being the same as the first session identifier group means that the data of each attribute in both groups are identical. If there is a second session identifier group that is the same as the first session identifier group, then it is determined that there is a work coroutine in each work coroutine that matches the test case. The work coroutine corresponding to the second session identifier group that is the same as the first session identifier group is the work coroutine that matches the test case.

[0078] If each of the second session identifier groups is different from the first session identifier group, then it is determined that there is no working coroutine that matches the test case in each of the working coroutines.

[0079] In the method provided by the embodiments of the present invention, if each second session identifier group is different from the first session identifier group, that is, there is no second session identifier group in each second session identifier group that is the same as the first session identifier group, then it is considered that there is no working coroutine in each working coroutine that matches the test case.

[0080] Based on the methods provided in the above embodiments, the methods provided in the embodiments of the present invention further include:

[0081] If none of the worker coroutines match the test case, then the test connection mode is determined;

[0082] In the method provided by the embodiments of the present invention, if it is determined that there is no work coroutine matching the current test case among the various pre-created work coroutines, then the test connection mode is determined according to the data in the test case or operation set, that is, the connection mode in the first session identifier group mentioned in the above embodiments, which is the data that characterizes whether the current system needs to act as a client or a server to test the object under test.

[0083] If the test connection mode represents testing the server as a client, then a worker coroutine corresponding to the test case is created, and a service session connection is established through the worker coroutine corresponding to the test case.

[0084] In the method provided by the embodiments of the present invention, if the test connection mode characterization is to test the server as a client, that is, the system connects to the object under test as a client, a new working coroutine can be created according to the first session identifier group, and a session connection with the corresponding client can be established through the working coroutine.

[0085] If the worker coroutine corresponding to the test case successfully establishes a service session connection, then the command operation corresponding to the operation set is executed through the worker coroutine corresponding to the test case to obtain the execution result of the worker coroutine corresponding to the test case;

[0086] The execution result of the worker coroutine corresponding to the test case shall be used as the test result corresponding to the test case.

[0087] In the method provided by this embodiment of the invention, if the worker coroutine successfully establishes a session connection with the client, it executes the command operation corresponding to the operation set, obtains the execution result of the command operation, and uses the execution result as the test result. If the worker coroutine fails to establish a service session connection, it can return a connection exception result as the test result.

[0088] Based on the methods provided in the above embodiments, the methods provided in the embodiments of the present invention further include:

[0089] If the test connection mode represents a server testing a client, an abnormal result is generated; the abnormal result indicates that there is no session connection.

[0090] The abnormal result is taken as the test result corresponding to the test case.

[0091] In the method provided by this embodiment of the invention, if the test connection mode represents testing the client as a server, that is, the current system acts as a server connected to the object under test, in this scenario, the tester needs to first initiate a session establishment request from the client to the server. Under normal circumstances, the system responds to the client's session establishment request by establishing a corresponding worker coroutine to establish a session connection. If there is no pre-created worker coroutine corresponding to the test case in the system, it indicates that there is no session connection between the client and the server, which is considered an anomaly. Therefore, an abnormal result representing the absence of a session connection is generated and used as the test result.

[0092] exist Figure 1 Based on the method shown, the method provided in this embodiment of the invention further includes:

[0093] If the set of operations does not meet the execution conditions, an exception response message is generated; the exception response message is a response message indicating that there is an exception in the test case.

[0094] The test request is responded to based on the abnormal response message.

[0095] In the method provided by this embodiment of the invention, during the judgment process in step S103, if the judgment operation set does not meet the preset execution conditions, a response message indicating that the test case has an anomaly is generated, i.e., an abnormal response message. The abnormal response message is fed back to the requester through the HTTP interface to perform a request response.

[0096] To better illustrate the method provided in the embodiments of the present invention, based on the method provided in the above embodiments and combined with actual testing scenarios, the embodiments of the present invention provide yet another service testing method. The method provided in the embodiments of the present invention can be implemented through a service testing system, which is designed for... Figure 1 An instantiation of the method shown is illustrated in the module example diagram as follows. Figure 2 As shown, the system specifically includes modules such as the HTTP access layer 201, message processing component 202, DSL interpreter 203, and MATIP processing component 204. The system interacts with the business counterpart, i.e., the server or client, to achieve service testing.

[0097] The main functions of each module in the system are as follows:

[0098] HTTP access layer: Provides REST API for receiving test requests for test cases and returning test results.

[0099] Message processing component: For test requests, it parses JSON format messages to obtain the operations involved in the test and the business request data carried. For responses, it assembles status codes according to the result status and converts the MATIP response into corresponding JSON format data for display.

[0100] DSL interpreter: Based on the input information, it performs lexical and syntactic analysis in sequence, then builds a semantic model, and translates the DSL statements describing the MATIP scenario into the corresponding operations of the MATIP processing components.

[0101] MATIP processing component: Encapsulates functions such as MATIP connection establishment, disconnection, connection maintenance, session opening, session acceptance, session rejection, and heartbeat processing. A module example diagram of the MATIP processing component can be seen as follows... Figure 3As shown, the component specifically includes: DSL collaboration component 301, MATIP listener 302, MATIP client connection pool 303, MATIP server connection pool 304, and MATIP work process 305, etc. Through the combination of module functions, many scenarios of interaction between MATIP server and client can be realized.

[0102] The method provided in this invention creates a DSL for describing MATIP scenarios, simplifying the creation of business scenarios (i.e., test scenarios). For convenient data display and HTTP interaction, the DSL is defined using JSON data format. The definition of the MATIP scenario DSL must satisfy the business scenarios of both the client and server. Each business scenario occurs within an independent MATIP session. During the establishment of a MATIP session, the MATIP client actively initiates a connection to the server. After the connection is established, a session establishment request (SessionOpen) is initiated. According to the MATIP protocol, the same connection supports multiple session management groups. The session establishment process requires not only the remote service IP and port but also the session identifier H1H2 information. The server also uses the H1H2 information in the SessionOpen request as an independent session identifier for session management. Each session is identified by a (connection mode, remote identifier, H1H2) session identifier triplet.

[0103] In the definition of DSL, a scenario needs to possess three key attributes: connection mode, remote identifier, and H1H2. To reduce the learning curve for business personnel, the abstraction of business actions within the scenario exposes only the truly business-related operations, such as sending one-way requests (sendOnly) and sending a request and receiving a response (sendAndReceive), while hiding the MATIP connection establishment process. Upon receiving the semantic information of the request, the MATIP processing component directly selects the existing connection if one exists; otherwise, it creates one based on the MATIP attribute information within the semantic information. For scenarios involving the continuous sending of multiple business requests, the request count (times) and sending interval (interval) attributes are added. The carrier of the request content can be selected as either raw data included in the HTTP request or originating from a specific file (file) or database (database).

[0104] At the MATIP connection layer, to avoid the noise to test results caused by the time spent frequently establishing new links, connection maintenance is required after connection establishment based on connection attributes. For example, periodically sending keepAlive heartbeat messages and determining whether to close the connection and remove it from the connection pool based on heartbeat responses and link status. Therefore, two attributes, timeout and keepAlive, are added, in milliseconds.

[0105] For example, a scenario where a client sends a request to a server and receives a response can be illustrated as follows:

[0106] {“scenario”:{

[0107] “mode”:“client”,

[0108] "remote":"10.5.100.101:350",

[0109] “h1h2”:“EE01”,

[0110] "timeOut": 5000,

[0111] “keepAlive”:30000,

[0112] "action":"sendAndRecv",

[0113] "times":20,

[0114] "interval":3000},

[0115] “msg”:{

[0116] “dataSrc”:“rawData”,

[0117] "rawData":"thisisatestcase."}}.

[0118] The `scenario` field describes the scenario as a client sending requests to and receiving responses from a server, where the server instance is located at 10.5.100.101:350. This test scenario sends 20 requests to the server in a pipelined manner, with each request spaced 3 seconds apart, and attempts to receive responses, with a response timeout of 5 seconds. A heartbeat connection is maintained with the server, actively sending a heartbeat request every 30 seconds. The data source is the value of the `rawData` field in the request input. If `dataSrc` is `database`, data is read from the configured database; if it is `file`, data is read from the specified data file. After describing the scenario using DSL rules, when initiating an HTTP test, the request body contains the scenario information and request data described by the DSL.

[0119] After defining the DSL, a DSL interpreter needs to be implemented. The MATIPDSL definition uses JSON data format, and lexical and syntax analysis are supported by a general JSON parser. When the DSL needs to be extended, simply add the corresponding MATIP operation mapping for the new elements.

[0120] based on Figure 2 The architecture shown is for reference. Figure 4 The flowchart shown illustrates the service testing process provided in this embodiment of the invention, which mainly includes:

[0121] The system's HTTP access layer receives HTTP requests, i.e., requests initiated by testers. The request body contains scenario information defined using DSL.

[0122] The message processing component parses the request to obtain scenario information and interaction data, i.e., test cases. After parsing and formatting the message, the message processing component sends it to the DSL interpreter.

[0123] Run the DSL interpreter to perform semantic transformation on the test cases and obtain the semantics of the scenario model, that is, the operation commands to be executed in sequence;

[0124] The DSL interpreter determines whether it has successfully obtained available scene model semantics. If it has, the scene model semantics are sent to the MATIP processing component. If it has not, the HTTP access layer sends an HTTP response indicating a scene exception.

[0125] The MATIP processing component performs service testing based on the scenario model semantics sent by the DSL interpreter. The DSL coordination component inside the component executes the business scenario and obtains the MATIP response. The message processing component converts the MATIP response into JSON format data, and the HTTP access layer sends back the HTTP response.

[0126] The processing flow of the MATIP processing component will be further explained next. (Reference) Figure 5 The flowchart shows that after the service testing system starts, the background automatically loads the MATIP processing component. The main coroutine creates the MATIP server connection pool and the MATIP client connection pool, and starts the MATIP listener coroutine, DSL coordination component, and other related coroutines. Each MATIP session is identified by a session identifier triple consisting of connection mode, remote identifier, and H1H2. H1H2 is the identifier of this connection session and is carried when the client initiates SessionOpen to establish a session.

[0127] The main coroutine of the MATIP processing component listens for pipe information. A pipe refers to a system resource used when multiple coroutines interact, such as a pipe in the Linux operating system. If the pipe receives a termination signal to terminate a resource, the main coroutine releases the corresponding resource. If no termination signal is received, it performs the corresponding operation based on the pipe signal and continues to listen for pipe information.

[0128] To better illustrate the processing flow of the MATIP processing component, the following section describes the process by which the MATIP processing component responds to client requests and establishes a session connection when the system is tested as a server. (Reference) Figure 6 As shown in the flowchart, during the operation of the MATIP processing component, the MATIP listener monitors the connection interface. When the interface receives a request, it identifies whether the request is a connection request sent by a client. If the request is a client connection request, a session connection is established with the client, and session verification is performed. If the verification passes, a corresponding MATIP worker coroutine is created and placed into the MATIP server connection pool. If the verification fails, a rejection message is sent to the client.

[0129] To better illustrate the processing flow of the MATIP processing component, the workflow of the DSL coordination component will be further illustrated with examples below. (Reference) Figure 7 The flowchart shown primarily outlines the following workflow:

[0130] Listen for information from the collaborative pipeline. If an exit signal is detected, cancel the resource and terminate the corresponding goroutine.

[0131] If the detected signal is not an exit signal, determine whether it is a coordination signal. If it is not a coordination signal, continue listening to the coordination channel.

[0132] If it is a coordination signal, the coordination information is parsed, the MATIP working coroutine is obtained according to the MATIP session identifier group, and if a matching working coroutine exists, the MATIP working coroutine is called to process the data, including sending data and waiting to receive it, determining the response based on the data reception status (if the data reception times out, a timeout response is assembled), and the response is returned to the message processing component.

[0133] If no matching worker coroutine exists, the connection type (i.e., connection mode) is determined. If it is a client, a new MATIP worker coroutine is created, a MATIP link is established with the remote endpoint, and a session establishment (open session) request is sent. If the session establishment request is rejected by the server, a response message is assembled, indicating that the session connection was rejected, and the message processing component callback interface is called to return an HTTP response. If the session establishment request is accepted by the server, the MATIP worker coroutine is registered to the client connection pool, and the MATIP worker coroutine is called to process data.

[0134] If the connection type is not client but server, then assemble a response message to indicate that as a server, there is currently no client connection with a specified session identifier triplet, and the response is returned to the message processing component.

[0135] In the method provided by this invention, the MATIP processing component listens to the coordination pipeline. Upon receiving the coordination signal of the scene model semantics, it reads the scene model semantics carried by the signal. It attempts to obtain a working coroutine from the connection pool according to the session identifier triplet for message processing. If no matching working coroutine exists, it needs to be processed according to the type of session connection. When the system acts as a client, it can attempt to establish a connection with the remote MATIP server, then assemble and send a SessionOpen message. If the server accepts this connection, it registers this coroutine in the client connection pool of the MATIP processing component, continues to execute the actions in the test scenario, performs message sending and receiving, and after completing the execution of the scene model semantics, calls back the message processing component interface to return the processing status and result. If the server rejects this connection, it reports to the message processing component and then returns an exception response to the request initiator through the HTTP access layer. When the system acts as a server, if the working coroutine for the session identifier triple does not exist, it means that the remote MATIP client has not initiated a connection with this server. Instead, it reports directly to the message processing component and returns an abnormal response to the requester through the HTTP access layer.

[0136] To better illustrate the method provided in the embodiments of the present invention, the processing procedure of the working coroutine will be described in the following example.

[0137] Taking the scenario of simulating a MATIP server sending 20 consecutive one-way requests to a specific client as an example, the test case description is as follows:

[0138] {“scenario”:{

[0139] “mode”:“server”,

[0140] “remote”:“10.5.100.102”,

[0141] “h1h2”:“EE01”,

[0142] “timeOut”:5000,

[0143] “keepAlive”:30000,

[0144] “action”:“sendOnly”,

[0145] “times”:20,

[0146] “interval”:3000},

[0147] “msg”:{

[0148] “dataSrc”:“file”,

[0149] “file”:“ / opt / matip / testcase / case01.dat”}}。

[0150] The DSL coordination component's processing involves calling MATIP worker coroutines to complete data jobs. Taking the above test scenario as an example, after the service test system starts, a MATIP listener coroutine is started in the background to listen for client connections. If the remote end 10.5.100.102 initiates a connection request and completes the session establishment with H1H2 as EE01, the MATIP listener will create an independent MATIP worker coroutine identified by the triple ("server", "10.5.100.102", "EE01") and register it in the server connection pool. After the simulated HTTP call begins, the DSL coordination component retrieves the MATIP worker coroutine from the server connection pool and sends a job command to it. Upon receiving the job command, the MATIP worker coroutine learns that the command is to send 20 one-way messages to the remote end, once every 3 seconds, with the data source being a data file located at / opt / matip / testcase / case01.dat. The MATIP worker coroutine first checks the cache for the existence of the configuration data file. If it exists, it means the file has already been loaded and is not expired, so it can be used directly. If it does not exist, the data is loaded and added to the cache. Then, it attempts to send the data according to the sending strategy and sends the status and result back to the message processing component interface.

[0151] refer to Figure 8 The flowchart shown illustrates the processing steps of the MATIP worker coroutine, which mainly include:

[0152] Listen for cooperative pipeline information; if an exit signal is detected, clean up resources, deregister from the connection pool, and terminate the coroutine.

[0153] If it's a heartbeat command, send a heartbeat request (i.e., a heartbeat message) to the remote end. If no heartbeat response is received after exceeding the configured number of attempts, or if sending the heartbeat fails, resources can be cleaned up. If the heartbeat is normal, you can continue listening on the coordination channel.

[0154] If the task is to execute a task command, determine the source of the task data. If the data source is the data provided in the request, proceed directly with data processing and subsequent procedures.

[0155] If the data source is a specific file, check if the file exists in the cache. If it does, perform data processing and subsequent procedures based on the cache. If the file does not exist in the cache, load the data from the specific file, store the data in the cache, and then perform data processing and subsequent procedures.

[0156] If the data source is a database, check if the specified data exists in the cache. If it does, proceed with data processing and subsequent steps. If the data does not exist in the cache, load the specified data from the database, store it in the cache, and then proceed with data processing and subsequent steps.

[0157] If the data source is not one of the above types of data, an error message will be displayed, an abnormal format message will be generated, the message processing component interface will be called back, an HTTP response will be generated, and the request will be returned to the caller.

[0158] The above data processing and subsequent processes include performing data processing and determining whether the processing count has been reached. If the processing count has not been reached, data processing continues until the processing count is reached. Based on the processing status and result, a response message is generated, the message processing component interface is called back, an HTTP response is generated, and the request caller is returned. Then, the system continues to listen for pipeline information.

[0159] Based on the method provided in this invention, the construction of business scenarios is simplified by defining a DSL applicable to MATIP scenarios. Using the DSL to abstract the MATIP session model, declarative semantic descriptions are provided for scenarios such as MATIP session establishment and maintenance, heartbeat maintenance, and message sending and receiving. This helps reduce repetitive work during business scenario construction, improves development efficiency, and lowers construction costs. Simultaneously, the DSL improves code readability, facilitates the formation of a unified internal language, promotes internal communication, allows testers to focus on the main business lines, reduces the learning cost for testers, and supports business experts in rapidly building new business scenarios. Through the DSL interpreter and DSL collaborative components, the mapping and execution of HTTP requests to MATIP tasks are completed, exposing the service externally as an HTTP service. This facilitates integration with DevOps tools. HTTP has the advantages of simplicity, flexibility, and strong scalability. HTTP-based services can be easily tested using mature and stable tools such as browsers, offering high support for automated testing and allowing testers to focus on testing business requirements. This reduces testing costs and improves testing efficiency. DevOps is a set of processes, methods, and systems used to facilitate communication, collaboration, and integration among development, technical operations, and quality assurance departments.

[0160] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0161] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0162] and Figure 1 Corresponding to the service testing method shown, this embodiment of the invention also provides a service testing apparatus for testing... Figure 1The specific implementation of the method shown in the embodiments of the present invention, the service testing device provided, can be applied to a computer terminal, and its structural schematic diagram is shown below. Figure 9 As shown, it includes:

[0163] The message parsing unit 401 is used to parse the test request when it receives a test request to test the business system service, and obtain the test cases corresponding to the test request; the business system service is a service built based on the Air Traffic Service IP Group Protocol; the test request is a request created based on the Hypertext Transfer Protocol; and the test cases are test cases based on the Domain-Specific Language (DSL) describing the test scenario.

[0164] The semantic conversion unit 402 is used to perform semantic conversion processing on the test cases to obtain the operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence.

[0165] The judgment unit 403 is used to determine whether the set of operations meets the preset execution conditions;

[0166] Test unit 404 is used to perform service testing on the business system service based on the operation set if the operation set meets the execution conditions, and obtain the test results corresponding to the test cases;

[0167] The message conversion unit 405 is used to convert the test result into a response message corresponding to the test result.

[0168] The response unit 406 is used to respond to the test request based on the response message and end the service test process corresponding to the test request.

[0169] Using the apparatus provided in this invention, testers can initiate test requests via an HTTP interface. The service testing system can convert test cases into MATIP service operation instructions through semantic conversion, and then perform service testing by executing the operation instructions, providing test results through request-response feedback. Testers only need to prepare DSL-based test cases to achieve automated service testing, without needing to configure the actual MATIP session program. Furthermore, the declarative nature of the DSL language simplifies test case writing, reduces the workload of testers, and has lower requirements for MATIP protocol proficiency, which helps improve testing efficiency and convenience.

[0170] exist Figure 9 Based on the device shown, the device provided in this embodiment of the invention can be further extended to include multiple units. The functions of each unit can be found in the descriptions of the various embodiments of the service testing method provided above, and will not be further illustrated here.

[0171] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0172] This invention also provides an electronic device for a service testing method, including a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described above for the service testing method. A schematic diagram of the electronic device can be shown below. Figure 10 As shown, Figure 10 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0173] like Figure 10 As shown, the electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0174] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 10 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0175] This invention also provides a storage medium that includes stored instructions, wherein the execution of the instructions controls the device where the storage medium is located to perform the above-described service testing method.

[0176] The aforementioned storage medium carries one or more programs. When these programs are executed by the electronic device, the electronic device performs the following actions: Upon receiving a test request to test a business system service, it parses the test request to obtain test cases corresponding to the test request; the business system service is a service built based on the Air Traffic Service IP Group Protocol; the test request is a request created based on the Hypertext Transfer Protocol; the test cases are test cases describing test scenarios based on Domain-Specific Language (DSL); it performs semantic conversion processing on the test cases to obtain an operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence; it determines whether the operation set meets preset execution conditions; if the operation set meets the execution conditions, it performs service testing on the business system service based on the operation set to obtain test results corresponding to the test cases; it performs message conversion on the test results to obtain response messages corresponding to the test results; it responds to the test request based on the response messages, ending the service testing process corresponding to the test request.

[0177] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

[0178] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this application. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0179] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

[0180] In the detailed description section, all the contents protected by the claims are repeated in the following form:

[0181] According to one or more embodiments disclosed in this application, Figure 1A service testing method is provided, comprising: upon receiving a test request to test a business system service, parsing the test request to obtain test cases corresponding to the test request; the business system service is a service built based on the Air Traffic Service IP Group Protocol; the test request is a request created based on the Hypertext Transfer Protocol; the test cases are test cases describing test scenarios based on Domain-Specific Language (DSL); performing semantic conversion processing on the test cases to obtain an operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence; determining whether the operation set meets preset execution conditions; if the operation set meets the execution conditions, performing service testing on the business system service based on the operation set to obtain test results corresponding to the test cases; performing message conversion on the test results to obtain response messages corresponding to the test results; responding to the test request based on the response messages to end the service testing process corresponding to the test request.

[0182] The test request is converted into a message format to obtain the request data corresponding to the test request; the request body data in the request data is obtained, and the request body data is used as the test case corresponding to the test request.

[0183] Determine whether there is a coroutine that matches the test case among the pre-created coroutines; if there is a coroutine that matches the test case, then take the coroutine that matches the test case as the target coroutine; call the target coroutine to execute the command operation corresponding to the operation set, and obtain the execution result of the target coroutine; take the execution result of the target coroutine as the test result corresponding to the test case.

[0184] A first session identifier group corresponding to the test case is determined; the first session identifier group includes the connection mode, remote identifier, and session identifier of the service session corresponding to the test case; a second session identifier group corresponding to each worker coroutine is determined; each second session identifier group includes the connection mode, remote identifier, and session identifier of the service session corresponding to its corresponding worker coroutine; each second session identifier group is compared with the first session identifier group; if there is a second session identifier group that is the same as the first session identifier group, then it is determined that there is a worker coroutine that matches the test case among each worker coroutine; if each second session identifier group is different from the first session identifier group, then it is determined that there is no worker coroutine that matches the test case among each worker coroutine.

[0185] If no worker coroutine matches the test case among the worker coroutines, a test connection mode is determined. If the test connection mode represents testing the server as a client, a worker coroutine corresponding to the test case is created, and a service session connection is established through the worker coroutine corresponding to the test case. If the worker coroutine corresponding to the test case successfully establishes a service session connection, the command operation corresponding to the operation set is executed through the worker coroutine corresponding to the test case to obtain the execution result of the worker coroutine corresponding to the test case. The execution result of the worker coroutine corresponding to the test case is taken as the test result corresponding to the test case.

[0186] If the test connection mode represents a server testing a client, an abnormal result is generated; the abnormal result indicates that there is no session connection; the abnormal result is used as the test result corresponding to the test case.

[0187] If the set of operations does not meet the execution conditions, an exception response message is generated; the exception response message is a response message indicating that there is an exception in the test case; the test request is responded to based on the exception response message.

[0188] According to one or more embodiments disclosed in this application, Figure 9 A service testing apparatus is provided, comprising: a message parsing unit, configured to parse a test request for testing a business system service received, and obtain test cases corresponding to the test request; the business system service is a service built based on the Air Traffic Service IP Group Protocol; the test request is a request created based on the Hypertext Transfer Protocol; the test cases are test cases describing test scenarios based on Domain-Specific Language (DSL); a semantic conversion unit, configured to perform semantic conversion processing on the test cases to obtain an operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence; a judgment unit, configured to judge whether the operation set meets preset execution conditions; a testing unit, configured to perform service testing on the business system service based on the operation set if the operation set meets the execution conditions, and obtain test results corresponding to the test cases; a message conversion unit, configured to perform message conversion on the test results to obtain a response message corresponding to the test results; and a response unit, configured to respond to the test request based on the response message, and end the service testing process corresponding to the test request.

[0189] According to one or more embodiments disclosed in this application, this application provides a storage medium including stored instructions, wherein, when the instructions are executed, the device where the storage medium is located is controlled to perform the above-described service testing method.

[0190] According to one or more embodiments disclosed in this application, Figure 10 An electronic device is provided, including a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors using the above-described service test method.

Claims

1. A service testing method, characterized in that, include: When a test request to test the business system service is received, the test request is parsed to obtain the test cases corresponding to the test request; The business system service is a service built on the Air Traffic Service IP Group Protocol. The test request is a request created based on the Hypertext Transfer Protocol; the test cases are test cases describing the test scenario based on the Domain-Specific Language (DSL). The test cases are semantically transformed to obtain the operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence. Determine whether the set of operations meets the preset execution conditions; If the set of operations meets the execution conditions, then the business system service is tested based on the set of operations to obtain the test results corresponding to the test cases; The test results are processed by message conversion to obtain the response message corresponding to the test results; Based on the response message, the test request is responded to, and the service test process corresponding to the test request is terminated.

2. The method according to claim 1, characterized in that, The step of parsing the test request to obtain the test cases corresponding to the test request includes: The test request is converted into a message format to obtain the request data corresponding to the test request. Obtain the request body data from the request data, and use the request body data as the test case corresponding to the test request.

3. The method according to claim 1, characterized in that, The step of performing service testing on the business system service based on the operation set and obtaining the test results corresponding to the test cases includes: Determine whether there is a worker coroutine among the pre-created worker coroutines that matches the test case; If there is a coroutine in each of the coroutines that matches the test case, then the coroutine in each of the coroutines that matches the test case is taken as the target coroutine. Invoke the target worker coroutine to execute the command operation corresponding to the operation set, and obtain the execution result of the target worker coroutine; The execution result of the target working coroutine is used as the test result corresponding to the test case.

4. The method according to claim 3, characterized in that, The determination of whether there is a matching work coroutine among the pre-created work coroutines includes: Determine the first session identifier group corresponding to the test case; the first session identifier group includes the connection mode, remote identifier, and session identifier of the service session corresponding to the test case. Determine a second session identifier group corresponding to each of the worker coroutines; each second session identifier group includes the connection mode, remote identifier, and session identifier of the service session corresponding to its worker coroutine. Compare each second session identifier group with the first session identifier group; If a second session identifier group exists that is the same as the first session identifier group, then it is determined that among each of the worker coroutines, there is a worker coroutine that matches the test case; If each of the second session identifier groups is different from the first session identifier group, then it is determined that there is no working coroutine that matches the test case in each of the working coroutines.

5. The method according to claim 3, characterized in that, Also includes: If none of the worker coroutines match the test case, then the test connection mode is determined; If the test connection mode represents testing the server as a client, then a worker coroutine corresponding to the test case is created, and a service session connection is established through the worker coroutine corresponding to the test case. If the worker coroutine corresponding to the test case successfully establishes a service session connection, then the command operation corresponding to the operation set is executed through the worker coroutine corresponding to the test case to obtain the execution result of the worker coroutine corresponding to the test case; The execution result of the worker coroutine corresponding to the test case shall be used as the test result corresponding to the test case.

6. The method according to claim 5, characterized in that, Also includes: If the test connection mode is used to test the client as a server, an abnormal result will be generated; The abnormal result indicates that there is no session connection; The abnormal result is taken as the test result corresponding to the test case.

7. The method according to claim 1, characterized in that, Also includes: If the set of operations does not meet the execution conditions, an exception response message is generated; The abnormal response message is a response message indicating that there is an abnormality in the test case; The test request is responded to based on the abnormal response message.

8. A service testing apparatus, characterized in that, include: The message parsing unit is used to parse the test request and obtain the test cases corresponding to the test request when a test request for testing the business system service is received. The business system service is a service built on the Air Traffic Service IP Group Protocol. The test request is a request created based on the Hypertext Transfer Protocol; the test cases are test cases describing the test scenario based on the Domain-Specific Language (DSL). A semantic conversion unit is used to perform semantic conversion processing on the test cases to obtain an operation set corresponding to the test cases; the operation set includes multiple operation instructions arranged in sequence. The judgment unit is used to determine whether the set of operations meets the preset execution conditions; The testing unit is used to perform service testing on the business system service based on the operation set if the operation set meets the execution conditions, and obtain the test results corresponding to the test cases. A message conversion unit is used to convert the test results into messages to obtain a response message corresponding to the test results. The response unit is used to respond to the test request based on the response message and end the service test process corresponding to the test request.

9. A storage medium, characterized in that, The storage medium includes stored instructions, wherein, when the instructions are executed, the device containing the storage medium is controlled to perform the service testing method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes a memory, and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described in any one of claims 1 to 7.

Images