A test method, device, system, electronic device and readable storage medium

Abstract

The application discloses a test method, device, system, electronic equipment and readable storage medium. The method comprises the following steps: monitoring a network interface, wherein the network interface is an interface for network communication of a to-be-tested object; obtaining a request message sent by the to-be-tested object through the network interface through monitoring; searching for data corresponding to the request message in a pre-stored corresponding relationship according to attribute information carried in the request message; and returning the searched data to the to-be-tested object. The application solves the problem that the prior art mode of waiting for the code of all functional units to be completed before performing network request related test reduces development efficiency, and can send the pre-stored data corresponding to the request message to the to-be-tested object when network request test is needed, so that the to-be-tested object can be tested in time, and development efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of network technology, and more specifically, to a testing method, apparatus, system, electronic device, and readable storage medium. Background Technology

[0002] In software development, the software is divided into different functional units (or modules) for development. To ensure the proper functioning of each functional unit, unit testing is required after development is complete.

[0003] In actual unit testing, a functional unit may need to obtain data from other functional units via network interaction before the test can be completed. If other functional units are not yet completed or cannot provide data to the functional unit under test for other reasons, the test of that functional unit cannot be completed. Furthermore, considering factors such as code security, it is not recommended to test code in a real network environment during unit testing.

[0004] In existing technologies, when a functional unit involves network interaction, joint testing is typically conducted after the other functional units that interact with it through the network have been developed. While this testing method provides a realistic testing environment, if a code problem is discovered at this stage, it requires searching across multiple functional units, increasing the difficulty of pinpointing the issue. Furthermore, testing of a functional unit can only proceed after the development of other functional units is complete, wasting time in the process. Therefore, the current approach of waiting for the completion of code in all functional units before conducting network request-related tests reduces development efficiency. Summary of the Invention

[0005] This application provides a testing method, apparatus, system, electronic device, and readable storage medium to at least solve the problem that the prior art's method of waiting for the code of all functional units to be completed before performing network request-related tests reduces development efficiency.

[0006] According to one aspect of this application, a testing method is provided, comprising: monitoring a network interface, wherein the network interface is an interface for network communication of an object under test; acquiring a request message sent by the object under test through the network interface by monitoring, wherein the request message is used to request data; searching for data corresponding to the request message in a pre-saved correspondence based on attribute information carried in the request message, wherein the correspondence stores one or more attribute information corresponding to the data; and returning the found data to the object under test.

[0007] According to another aspect of this application, a testing apparatus is also provided, comprising: a monitoring module for monitoring a network interface, wherein the network interface is an interface for network communication of the object under test; an acquisition module for acquiring, through monitoring, a request message sent by the object under test through the network interface, wherein the request message is used to request data; a search module for searching for data corresponding to the request message in a pre-saved correspondence based on attribute information carried in the request message, wherein the correspondence stores one or more attribute information corresponding to the data; and a sending module for returning the found data to the object under test.

[0008] According to another aspect of this application, a testing system is also provided, comprising: an interception module and a test object, wherein the interception module is used to perform the above-described method.

[0009] According to another aspect of this application, an electronic device is also provided, including a memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the above-described method steps.

[0010] According to another aspect of this application, a readable storage medium is also provided, on which computer instructions are stored, wherein the computer instructions, when executed by a processor, implement the above-described method steps.

[0011] In this embodiment, network interface monitoring is employed, whereby the network interface is the interface through which the object under test conducts network communication. The monitoring acquires request messages sent by the object under test through the network interface, whereby the request messages request data. Based on the attribute information carried in the request messages, data corresponding to the request messages is searched in a pre-saved correspondence, whereby the correspondence stores one or more attribute information corresponding to the data. The searched data is then returned to the object under test. This application solves the problem of reduced development efficiency caused by the prior art's approach of waiting for the code of all functional units to be completed before performing network request-related tests. It enables timely testing of the object under test by sending pre-saved data corresponding to the request messages when network request testing is needed, thereby improving development efficiency. Attached Figure Description

[0012] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0013] Figure 1This is a flowchart of a test method according to an embodiment of this application; and,

[0014] Figure 2 This is an interactive schematic diagram of the data returned to the test object according to an embodiment of this application. Detailed Implementation

[0015] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0016] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0017] The following implementation involves network-related testing. The technical terms used in the following implementation are explained first.

[0018] Unit testing refers to the inspection and verification of testable units within software. The meaning of "unit" in unit testing generally depends on the specific context. For example, in C, a unit refers to a function; in Java, it refers to a class; and in graphical software, it could refer to a window or a menu. In general, a unit is a pre-defined functional module to be tested. Developers can define the contents of a unit according to their needs; it may include only one function or class, or it may be a functional module composed of multiple functions or classes. Unit testing involves testing the part to be tested (which can be called a unit or module) in isolation from other parts of the program during the software development process. The focus of unit testing is to verify whether the unit or module performs as expected.

[0019] Functional testing: Functional testing verifies each function of a product, testing each function against the product's specifications to check if the product meets the expected requirements. Functional testing can be performed on a complete product or on a part of a product. For example, verifying the functionality of a unit or module can be called functional testing. The difference between unit testing and functional testing is that unit testing is defined from the perspective of the test object, while functional testing is defined from the perspective of the test objective. Therefore, functional testing can also be performed within unit testing.

[0020] HTTP Protocol: HTTP stands for Hyper Text Transfer Protocol, a protocol used to transfer hypertext from World Wide Web (WWW) servers to local browsers. HTTP is a data transfer protocol (HTML files, image files, query results, etc.) based on the TCP / IP communication protocol. HTTP is an application-layer, object-oriented protocol, suitable for distributed hypermedia information systems due to its simplicity and speed. Proposed in 1990, it has been continuously improved and expanded over the years. Currently, HTTP / 1.0 and HTTP / 2.0 are used on the WWW. The following implementation uses a request message in the HTTP protocol as an example, but it is not limited to this; other network protocols are also applicable.

[0021] Network interface: Whether it is a complete software product or a functional unit, it needs to interact with the network through hardware devices such as network cards. These hardware devices provide the physical connection to the network. The interface through which these hardware devices interact with the network is called the network interface. The network interface can refer to the physical interface on the hardware device or the logical interface defined at the software level.

[0022] Network Request: The network provides a connection method that allows two parties to exchange data even if they are not on the same physical device. Generally, the party sending the network request is called the client, and the party receiving the network request and providing data is called the server. It should be noted that the client can be a software product or a functional unit within a software product. For example, a client can be an application running on a mobile terminal or a page displayed through a browser. In the following implementation, the party capable of sending a network request (or request message) is called the client, and the party capable of responding to the request message and providing data is called the server. The client typically obtains the server's network address information (e.g., network address and / or the port number providing the service) in advance, and then sends a request message based on the obtained network address information to retrieve data from the server.

[0023] Virtual server: The opposite of a real server is a virtual server. A real server is the server that actually interacts with the client. After receiving a request message from the client, it processes the request message and returns data to the client. A virtual server is a simulation of a real server. Unlike a real server, it does not process request messages; instead, it directly simulates a real server returning data to the client. Therefore, this type of server that simulates a real server is called a virtual server.

[0024] In existing technologies, when a functional unit needs to retrieve data from the server, joint testing is usually conducted after the server-side functional unit has been developed. This testing method requires waiting for the development of other functional units to be completed, and it is not easy to determine whether the problem lies with the client-side or server-side functional unit during testing, thus reducing development efficiency.

[0025] To address this issue, a virtual server is typically used. This virtual server simulates the processing of a request message received from a functional unit and returns data to that unit. While this solves the data acquisition problem for the functional unit, the virtual server has its own network address. During testing, the code in the functional unit under test that involves requesting data from the network needs to be modified to use the virtual server's address. After testing, when the functional unit is deployed, the virtual server's network address is changed back to the real address. Therefore, using a virtual server for testing requires modifying the functional unit's code. This modification can be considered an intrusion, potentially causing the code to work correctly when tested on the virtual server but malfunction in a real environment. Therefore, a testing solution is needed that does not require modification of the functional unit's code.

[0026] The following implementation provides a testing method. Figure 1 This is a flowchart of a test method according to an embodiment of this application, such as... Figure 1 As shown below, Figure 1 The steps involved will be explained.

[0027] Step S102: Monitor the network interface, wherein the network interface is the interface through which the object under test performs network communication.

[0028] In this step, the object to be tested can be a complete software product or a functional unit within the software. The steps described below can be used for both unit testing and functional testing. When testing the object to be tested, the network interface of the device on which the object is running can be obtained, and then that network interface can be monitored. Alternatively, the address information of the network interface used by the object to send messages can be obtained, and then the messages sent through that address information can be monitored.

[0029] Step S104: The request message sent by the object under test through the network interface is obtained by monitoring, wherein the request message is used to request data.

[0030] Monitoring a network interface allows you to obtain all request messages sent through that interface. If only the object under test is using that network interface, the intercepted request messages can be processed in the following steps. If the network interface is used by more than just the object under test, the request messages sent by the object under test can be filtered out from the intercepted request messages based on the network address information used by the object under test when sending the request messages. For example, if the object under test uses 100.100.100.100 as the source address when sending request messages, then request messages with the source address of 100.100.100.100 can be filtered from the intercepted request messages to proceed with the following steps. It should be noted that the intercepted request messages can also come from multiple objects under test. The distinction between request messages sent by multiple objects under test can also be made based on the network address and / or port number used by each object under test.

[0031] In the two steps described above, the test object no longer needs to modify the address of the server providing data in the code during testing. Instead, it can directly use the real address to send request messages. Because the network interface is monitored, the request message can be intercepted regardless of which server address the test object requests data from. Therefore, these two steps avoid the need to modify the real server address in the code to a virtual server address during testing and then modify the virtual server address back to the real server address after testing. This avoids code intrusion caused by modification and reduces potential risks arising from testing.

[0032] Step S106: Based on the attribute information carried in the request message, search for the data corresponding to the request message in the pre-saved correspondence, wherein the correspondence stores one or more attribute information corresponding to the data.

[0033] In this step, the request message can carry various attribute information. The attributes that a request message can carry are related to the protocol used by the request message; different protocols include different attributes. The request message sent by the object under test can use an existing protocol or a dedicated protocol, which refers to a protocol specifically developed for a particular need. Regardless of whether an existing protocol or a dedicated protocol is used, as long as the receiver of the request message can parse the protocol used by the request message, the attribute information carried in the request message can be obtained through parsing the protocol.

[0034] In the pre-saved mapping between attribute information and data, different attribute information can correspond to different data. For example, attribute information A corresponds to data A, attribute information B and attribute information C correspond to data B, attribute information A and attribute information C correspond to data C, and so on. It should be noted that different attribute information may have different values. A request address is one type of attribute information; when the request address is address one, it corresponds to data A1, when the request address is address two, it corresponds to data A2, and so on. Therefore, the data and one or more attribute information mentioned in this step refer to two aspects: firstly, different combinations of attribute information can correspond to different data; secondly, the same attribute information can correspond to different data if its value is different. All these data and attribute information mappings are pre-saved. After monitoring the request message sent by the object under test, the data corresponding to the request message can be directly found from the pre-saved data.

[0035] Step S108: Return the found data to the object to be tested.

[0036] In this step, the data found can be the data itself, not a complete message. In this case, the found data can be constructed into a response message according to the protocol format in the request message. That is, the found data is carried in the response message corresponding to the request message and sent to the object under test. Alternatively, the data saved in step S106 can be a completed response message. After finding the data, since it is already a constructed response message, the found data can be directly sent to the object under test.

[0037] In the above steps, all request messages sent by the object under test are obtained by monitoring the network interface. This method eliminates the need to modify the code in the object under test. Developers can directly test after writing the code according to the real environment, thus avoiding the unknown risks brought about by modifying the code for testing. It also avoids the need to wait for the server-side functional units to be developed before testing; instead, the data provided by the server-side functional units and the attribute information of the request messages can be associated and saved in advance. Therefore, the above steps solve the problem of reduced development efficiency caused by waiting for the code of all functional units to be completed before conducting network request-related tests in existing technologies. By sending the pre-saved data corresponding to the request messages to the object under test when network request testing is needed, timely testing of the object under test can be performed, improving development efficiency.

[0038] exist Figure 1The steps shown involve data matching based on attribute information. Different protocol formats can carry different attributes in request messages. Considering that a request message is also a type of network message, regardless of the protocol format, it can carry at least one of the following attribute information: request address, request method, request parameters, and data requirements. The request address is the destination address to which the request message is sent; the request method indicates the mode of data interaction with the receiving party; the data requirements indicate the requirements of the object under test for the received data; and the request parameters are used to obtain the response data corresponding to those parameters. Examples of these attribute information are given below.

[0039] Request Address: The request address is the address of the server that processes the request message and returns data; that is, the destination address of the request message. In network requests, to ensure that the message reaches the corresponding server, the destination network (IP) address must be included in the message. Alternatively, the server's domain name may also be included. In some protocols, the server's port number may also be included. In the following implementation, the domain name, IP address, and / or port number are collectively referred to as the network address. For example, if the server provides Hypertext Transfer Protocol (HTTP) service on port 80, and the server's domain name is www.testing-only.com, then the request message would include HTTP: / / www.testing-only.com:80 as the destination address. Alternatively, if the server's IP address is 100.100.100.100, then the request message would include HTTP: / / 100.100.100.100:80 as the destination address.

[0040] Request method: The request method refers to the data interaction method indicated by the object under test to the server providing the data. This interaction method may involve the object under test simply retrieving specified data from the server, or it may involve the object under test passing data to the server in the request message. Different protocols have different request methods. Taking the HTTP protocol as an example, it provides the following request methods:

[0041] GET: Requests the specified page information and returns the entity body, where the entity host is the page information packaged using the HTTP protocol.

[0042] head: Similar to a GET request, except that the returned data does not include the entity body, but only the HTTP header information.

[0043] POST: Submits data to the server and requests processing of the submitted data (such as submitting a form or uploading a file). The submitted data is contained in the request message. A POST request may result in the server creating new resources or modifying existing resources.

[0044] `put`: Replaces the content of a specified document with data sent from the client to the server.

[0045] delete: Requests the server to delete the specified page.

[0046] options: Allows clients to view server performance.

[0047] trace: Echoes requests received by the server, primarily used for testing or diagnosis.

[0048] Upon receiving a request message, the request method carried in the message can be obtained. The data requested in the request message is then processed according to the requested method, and a processing result is returned. The request method can be at least one of those described above; of course, other request methods may be added as technology advances. Regardless of the request method, the data is processed according to the method indicated and a result is returned.

[0049] Data Requirements: Data requirements can be used to indicate the types of data the tested object can receive, etc. These requirements can be explicit, such as clearly instructing the server to provide text-formatted data instead of other formats; or they can be implicit, such as indicating to the server the types of protocols supported by the tested object. Taking the HTTP protocol as an example, in the HTTP protocol, the data requirements are reflected in the header. The HTTP header can include the following:

[0050] User-Agent: Provides the server with information such as the browser types and versions, operating system and version, and browser kernel supported by the object to be tested.

[0051] Accept information: This represents the data type that the object under test expects to accept. For example, Accept: text / xml means that the object under test expects to accept Extensible Markup Language (XML) data types.

[0052] Accept-Encoding: Declares the browser-supported encoding type for the object being tested.

[0053] Language type (Accept-Language): Indicates the language type supported by the browser of the object being tested.

[0054] Transfer encoding: Informs the server what encoding method was used to encode the request message in order to ensure reliable message transmission.

[0055] It can retrieve the data requirements carried in the request message and return data that conforms to the requirements to the object under test. It should be noted that the data requirements are not limited to the types described above, and may also include other requirements not listed here.

[0056] Request parameters: These are the various parameters carried in the request message. The server receives these parameters and retrieves the data corresponding to them. These parameters are passed to the server. For example, in the HTTP protocol, parameters can be passed as follows: http: / / www.testing-only.com?key1=value1&key2=value2, where key1 and key2 are the parameter names, and value1 and value2 are the values ​​of parameters key1 and key2.

[0057] When there are multiple types of attribute information, multiple data entries may be matched when matching against pre-saved correspondences. For example, a request message may contain the request address http: / / www.testing-only.com and the language type CN (Chinese). The pre-saved correspondences may contain multiple data entries: the first entry corresponds to the attribute information http: / / www.testing-only.com; the second entry corresponds to the attribute information CN; and the third entry corresponds to the attribute information http: / / www.testing-only.com and the language type CN (Chinese). In this case, the first and second entries only cover a portion of the attribute information in the request message, while the third entry covers the most. In this case, the third entry is returned to the object to be tested. If the request message contains the request address http: / / www.testing-only.com, the language type CN (Chinese), and the encoding type Unicode Transformation Format (UTF)-8 (8 represents 8 bits), then... At this point, the attribute information corresponding to the three pre-saved data entries cannot cover all the attribute information carried in the request message. In this case, the third data entry covers two types of attribute information and is the data with the most covered attribute information. Therefore, the third data entry can be returned to the test object. If a fourth data entry is pre-saved, and the attribute information corresponding to the fourth data entry is http: / / www.testing-only.com, the language type is CN, and the encoding type is UTF-8, then the fourth data entry covering the most attribute information in the request message is returned. That is, in this optional implementation, searching for the data corresponding to the request message in the correspondence based on the attribute information carried in the request message may include the following steps: searching for the correspondence that covers the most attribute information carried in the request message in the correspondence; and using the data in the found correspondence as the data corresponding to the request message. Through this optional implementation, on the one hand, the data covering the most attribute information can be sent to the test object to achieve the greatest possible match with the request message; on the other hand, it can also avoid the situation where the pre-saved data cannot be returned to the test message because it does not completely match the attribute information in the request message.

[0058] In actual testing, another scenario exists where the request message sent by the object under test only carries the request address http: / / www.testing-only.com. In this case, there are four data entries that match the attribute information carried in the request message. In this situation, the data entry that completely matches the attribute information in the request message can be returned to the object under test; that is, the first data entry is returned. Alternatively, priorities can be assigned to these four data entries. For example, the priority of the first data entry could be 1, the priority of the second data entry 2, the priority of the third data entry 3, and the priority of the fourth data entry 4. If multiple data entries in the pre-saved correspondence completely cover the attribute information carried in the request message, the data entry with the highest priority among these multiple data entries is selected and returned to the object under test. In this example, the fourth data entry has the highest priority, so it is returned to the object under test. If multiple data entries contain data with the same priority, such as the third and fourth data entries both having a priority of 3, then you can randomly select one of the data entries, or you can select the data entry with a more recent storage time, such as the third data entry being stored 2 days ago and the fourth data entry being stored 1 day ago. In this case, return the fourth data entry to the test object.

[0059] The request address and request parameters in the attribute information have their own characteristics, which will be explained below. The request address may include a subdomain. For example, if the request message carries the request address http: / / web1.testing-only.com / , and if there is a piece of data in the pre-saved data whose corresponding attribute information is http: / / web1.testing-only.com / , then that data can be returned to the object to be tested. Suppose that the pre-saved data only contains data with the attribute information http: / / www.testing-only.com. In this case, web1.testing-only.com is actually a subdomain of www.testing-only.com, and both belong to the same website. Returning data with the attribute information http: / / www.testing-only.com will also meet the testing requirements. In this case, regular expressions can be used for querying. For example, you can query the saved data for data whose attribute information includes testing-only.com, represented by the regular expression: \<testing-only\> The expression `<` indicates that the attribute information of the characters contained within the given symbol is being searched. Using regular expressions, the four data entries mentioned above can be found. In this example, `<` is used.<testing-only\> Other symbols in regular expressions can also be used in queries. Below is an introduction to some commonly used regular expression matching symbols.

[0060] x|y: Matches either x or y. For example, "z|food" matches either "z" or "food". "[z|f]ood" matches either "zood" or "food".

[0061] [xyz]: Matches any single character contained within the specified string. For example, "[abc]" matches the "a" in "plain".

[0062] [az]: Character range. Matches any character within the specified range. For example, "[az]" can match any lowercase letter character from "a" to "z".

[0063] Note: A hyphen can only represent a range of characters when it is inside a character group and appears between two characters; if it is outside the beginning of a character group, it can only represent the hyphen itself.

[0064] \b: Matches the boundary of a word, that is, the position between a word and a space (i.e., there are two concepts of "matching" in regular expressions: matching characters and matching positions; \b here matches positions). For example, "er\b" can match "er" in "never" but not "er" in "verb"; "\b1_" can match "1_" in "1_23" but not "1_" in "21_3".

[0065] \d: Matches a single digit character. Equivalent to [0-9].

[0066] \D: Matches a non-digit character. Equivalent to [^0-9].

[0067] There are other symbols used in regular expressions for matching operations, which will not be elaborated here.

[0068] Using regular expressions requires various matching operators, which can be relatively complex. As an alternative, fuzzy search can be used. In fuzzy search, the asterisk (*) symbol is used to represent characters that do not need to be matched. For example, you can search for data matching http: / / *.testing-only.com in the attribute information corresponding to the saved data. This will match data with the attribute information http: / / www.testing-only.com. Whether using regular expressions or fuzzy search, the essence is matching partial characters. In this optional implementation, finding data corresponding to the request message based on the attribute information carried in the request message can include the following steps: obtaining the request address and / or request parameters carried in the request message; finding data that completely matches the request address and / or request parameters, or finding data that matches some characters in the request address and / or request parameters. In practice, you can first use all characters in the request address and / or request parameters to search for corresponding data. If no match is found, then use the search function in the request address and / or request parameters to find data that matches that partial character. This optional implementation can avoid the inability to return data to the test object.

[0069] In the above implementation, the corresponding data can be found based on the attribute information carried in the request message, and then the found data can be returned to the object under test. Since the object under test may need different returned data for testing, the data returned to the object under test includes at least one of the following: string, image, audio, and video.

[0070] For example, when testing code written in Flutter, if the code under test involves retrieving images, the image can be returned to the code under test based on the request message. Flutter is a user interface (UI) toolkit that helps developers efficiently build beautiful multi-platform applications with a single codebase, supporting mobile, web, desktop, and embedded platforms. Flutter components are built using a reactive framework, with the central idea being to build UIs using widgets. Components describe how they appear given their current configuration and state. When a component's state changes, the component refactors its description, and Flutter compares it to the previous description to determine the minimum changes required for the underlying rendering tree to transition from the current state to the next. Images used in user interfaces built with Flutter can be loaded locally or from the network. In Flutter, an image can be loaded from the network using the following command: `Image.network("http: / / www.testing-only.com / picture / test.jpg")`, where `Image.network` is the command used to retrieve the image, and `http: / / www.testing-only.com / picture / test.jpg` is the address of the image. When the code under test, written in Flutter, is running, it sends the `Image.network` command as a request message via a network interface. After intercepting this request message, the command name in the message can be used to determine which image needs to be returned. Therefore, the image address carried after the `Image.network` command can be ignored, and an image can be directly selected from the saved images and returned to the code under test. If multiple `Image.network` commands are received, multiple different images can be selected and returned to the code under test. This example can be used to test code using Flutter. The Flutter toolkit provides a unit testing environment, but images cannot be obtained from the network in the Flutter unit testing environment. By introducing the above implementation method into Flutter testing, code that loads images from the network can be tested. In this example, an image is returned. Based on the same principle, strings, audio files, or video files can also be returned to the code under test, which will not be elaborated here.

[0071] In the above implementation, the data corresponding to the attribute information is all pre-saved. This data can be pre-configured by developers based on experience. Developers can configure the data corresponding to various combinations of attribute information based on the attribute information carried in all request messages that the test object can send. Besides this configuration method, another optional implementation can use automatic configuration. The test object needs to send request messages over the network to obtain data. That is, if all the code is developed, at least one functional unit will act as a server to cooperate with the test object and provide data to it. During the testing phase, the pre-saved data can be provided by this functional unit because it knows the request messages it can handle and what data it returns after processing. Even if the functional unit is not yet fully developed, it can still provide the data and the corresponding attribute information. In this optional implementation, before obtaining the request message sent by the object under test through the network interface, the method may further include the following steps: receiving attribute information and corresponding data provided by a functional unit, wherein the functional unit is a server that provides data to the object under test, and the object under test obtains data from the server through a request message when it is used after the test is completed; and saving the attribute information sent by the functional unit and the corresponding data. Through this optional implementation, data corresponding to various attribute information is provided by a functional unit that cooperates with the object under test, thus ensuring that the pre-saved data better meets the needs of the object under test.

[0072] After the functional unit provides various data, it can also notify the object under test that testing can begin. In this case, after providing attribute information and the corresponding data, the functional unit sends a test command to the object under test. Upon receiving the test command, the object under test, knowing that testing can begin, sends a request message. This request message is intercepted, and the data is retrieved based on the attribute information in the request message and returned to the object under test. That is, in this optional implementation, the request message is sent by the object under test after receiving the test command; the test command is sent by the functional unit after saving the attribute information and the corresponding data. Through this optional implementation, the functional unit can start testing through the object under test after providing data, thus automating the testing process.

[0073] In addition to providing data, the functional unit also wants to understand the testing results when using this data for testing. Therefore, in one optional implementation, after returning the found data to the test object, the method may further include the following step: after the test object uses the data for testing, sending the test results to the functional unit that provided the data. Through this optional implementation, the functional unit that provides the data can obtain the test results and can also choose whether to provide new data or modify the provided data based on the test results.

[0074] As described above, in an optional embodiment, a testing system can also be provided. This testing system may include an interception module and a test object, with the interception module used to implement the above method steps. Optionally, the system may also include the above-described functional units. The following section discusses... Figure 2 The interactions between the various modules in this system are explained.

[0075] Figure 2 This is an interactive schematic diagram of the data returned to the test object according to an embodiment of this application. Figure 2 The entity that executes the steps in the above implementation method is called an interceptor (or interception module). This is mainly because it is able to intercept the request messages sent by the object under test. Figure 2As shown, the functional unit (which can be unit code) provides data registration, registering the request messages and return data to be simulated. Registration allows mapping various attribute information in the request message to the data. For example, if the request message is `httpMock.open('http: / / exmaple.com')` (the request message is used to open `http: / / exmaple.com`, where `http: / / exmaple.com` is the attribute information of the request), and the data returned by this request message is "This is simulated return data", then this request message can be registered as `httpMock.open('http: / / exmaple.com').reply('This is simulated return data')`, where `Mock` means simulation and `reply` means response. Another example is `httpMock.open('http: / / test.exmaple.com').reply('This is simulated return data for a subdomain')`. After the data is registered and saved, the interceptor begins intercepting global network requests (because it can intercept all request messages sent through the network interface, it is called intercepting global network requests). After the object under test initiates a request message, it is intercepted. The interceptor then calls a function to parse the request message, obtaining relevant parameters such as the request address, request method (which may be included in the request header), data requirements (which may also be included in the request header), and request parameters. At least one of the obtained request address, request method, data requirements, and request parameters is then used to match registered mock data (this data is not the actual data returned by the server, hence the term "mock data"). When the request is closed, the matched mock data is returned to the code under test. Figure 2 In the illustrated process, network requests are intercepted globally to adapt to all network request libraries. In addition, the returned data can also be an image, thus ensuring compatibility with Flutter's network image component. When matching the attribute information of the request message, regular expressions can be used for the request address, and fuzzy matching can be used for the request parameters (as explained above, so I won't repeat it here). This can minimize the possibility of being unable to return data to the object under test, making it more convenient to use.

[0076] The above implementation method solves the problem that the existing technology of waiting for the code of all functional units to be completed before performing network request-related tests will reduce development efficiency. When network request testing is required, the pre-saved data corresponding to the request message can be sent to the object under test, so that the object under test can be tested in a timely manner, thereby improving development efficiency.

[0077] In this embodiment, an electronic device is provided, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to perform the methods described in the above embodiments.

[0078] The aforementioned program can run on a processor or be stored in memory (or computer-readable medium). Computer-readable medium includes both permanent and non-permanent, removable and non-removable media, and information storage can be achieved by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable medium does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0079] These computer programs may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes can be implemented using different modules, and different steps can be implemented using different modules.

[0080] This embodiment provides such a device. This device, referred to as a testing device, includes: a monitoring module for monitoring a network interface, wherein the network interface is the interface through which the object under test performs network communication; an acquisition module for acquiring request messages sent by the object under test through the network interface, wherein the request messages are for requesting data; a search module for searching for data corresponding to the request message in a pre-saved correspondence based on attribute information carried in the request message, wherein the correspondence stores one or more attribute information corresponding to the data; and a sending module for returning the found data to the object under test.

[0081] The system or apparatus is used to implement the functions of the methods in the above embodiments. Each module in the system or apparatus corresponds to each step in the method, as has been described in the method and will not be repeated here.

[0082] Optionally, the attribute information carried in the request message includes at least one of the following: request address, request method, request parameters, and data requirements, wherein the request address is the destination address to which the request message is sent, the request method is used to indicate the method of data interaction with the party receiving the request message, the data requirements are used to indicate the requirements of the object under test for the received data, and the request parameters are used to obtain response data corresponding to the request parameters.

[0083] Optionally, the search module is used to search for the correspondence that covers the most attribute information carried in the request message; and to use the data in the found correspondence as the data corresponding to the request message.

[0084] Optionally, the search module is used to obtain the request address and / or request parameters carried in the request message; search for data that completely matches the request address and / or request parameters, or search for data that matches some characters in the request address and / or request parameters.

[0085] Optionally, the search module is used to obtain the data requirements carried in the request message, search for data that matches the data requirements; and / or, obtain the request method carried in the request message, process the data to be processed in the request message according to the request method, and return the processing result.

[0086] Optionally, it further includes: a storage module, used to receive attribute information and data corresponding to the attribute information provided by the functional unit, wherein the functional unit is a server that provides data to the object under test, and the object under test obtains data from the functional unit through a request message when it is used after the test is completed; and to store the attribute information sent by the functional unit and the data corresponding to the attribute information.

[0087] Optionally, the request message is sent by the object to be tested after receiving the test command; the test command is sent by the functional unit after saving the attribute information sent by the functional unit and the data corresponding to the attribute information.

[0088] Optionally, it further includes: a providing module, configured to send test results to the functional unit that provides the data after the object under test has been tested using the data.

[0089] Optionally, the data returned to the test object includes at least one of the following: string, image, audio, and video.

[0090] Through the above implementation method, global network requests are intercepted, request messages of the object under test are obtained and matched, and specified data is returned. This achieves the goal of making the data simulation of network requests during unit testing more intelligent and convenient without intruding on the original code. It solves the problem that the existing technology of waiting for the code of all functional units to be completed before conducting network request-related tests will reduce development efficiency. When network request testing is needed, the pre-saved data corresponding to the request message can be sent to the object under test, so that the object under test can be tested in a timely manner, thereby improving development efficiency.

[0091] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A test method, comprising: monitoring a network interface, wherein the network interface is an interface for network communication of a to-be-tested object; receiving attribute information and data corresponding to the attribute information provided by a function unit, wherein the function unit is a server providing data to the to-be-tested object, and the to-be-tested object acquires data from the function unit through a request message when the to-be-tested object is used after test completion; storing the attribute information and the data corresponding to the attribute information sent by the function unit; obtaining a request message sent by the to-be-tested object through the network interface through monitoring, wherein the request message is used to request data; finding data corresponding to the request message in a pre-stored correspondence relationship according to attribute information carried in the request message, wherein the correspondence relationship stores one or more attribute information corresponding to the data; returning the found data to the to-be-tested object.

2. The method of claim 1, wherein, finding data corresponding to the request message in the correspondence relationship according to attribute information carried in the request message comprises: finding a correspondence relationship in the correspondence relationship that covers the attribute information carried in the request message most; taking the data in the found correspondence relationship as the data corresponding to the request message.

3. The method of claim 1, wherein, The attribute information carried in the request message comprises at least one of the following: a request address, a request mode, a request parameter, a data requirement, wherein the request address is a destination address of the request message, the request mode is used to indicate a mode of data interaction with a party receiving the request message, the data requirement is used to indicate a requirement of the to-be-tested object on received data, and the request parameter is used to acquire response data corresponding to the request parameter.

4. The method of claim 3, wherein, Finding data corresponding to the request message in the correspondence relationship according to attribute information carried in the request message comprises: acquiring the request address and / or the request parameter carried in the request message; finding data that completely matches the request address and / or the request parameter, or finding data that matches part of characters in the request address and / or the request parameter; and / or, acquiring the data requirement carried in the request message, and finding data that conforms to the data requirement; and / or, acquiring the request mode carried in the request message, processing data required to be processed in the request message according to the request mode, and returning a processing result.

5. The method of claim 1, wherein, The request message is sent by the to-be-tested object after receiving a test command; and the test command is sent by the function unit after storing the attribute information and the data corresponding to the attribute information.

6. The method of claim 1, wherein, After returning the found data to the to-be-tested object, the method further comprises: sending a test result to the function unit providing the data after the to-be-tested object uses the data for test.

7. The method of any one of claims 1 to 4, wherein, The data returned to the to-be-tested object comprises at least one of the following: a string, a picture, an audio, and a video. 8.A test device, comprising: A monitoring module is configured to monitor a network interface, wherein the network interface is an interface for network communication of a to-be-tested object. A saving module is configured to receive attribute information provided by a functional unit and data corresponding to the attribute information, wherein the functional unit is a service end providing data to the to-be-tested object, and the to-be-tested object acquires data from the functional unit through a request message when being used after test completion. An obtaining module is configured to obtain a request message sent by the to-be-tested object through the network interface through monitoring, wherein the request message is used to request data. A searching module is configured to search for data corresponding to the request message in a pre-stored correspondence relationship according to attribute information carried in the request message, wherein the correspondence relationship stores one or more kinds of attribute information corresponding to the data. A sending module is configured to return the searched data to the to-be-tested object.

9. A test system, wherein, The system comprises: an intercepting module and a to-be-tested object, the intercepting module is configured to execute the method in any one of claims 1 to 7.

10. The test system of claim 9, wherein, Further comprising: a functional unit configured to provide attribute information and data corresponding to the attribute information to the intercepting module, wherein the functional unit is a service end providing data to the to-be-tested object, and the to-be-tested object acquires data from the service end through a request message when being used after test completion.

11. The test system of claim 10, wherein, The functional unit is further configured to send a test command, wherein the test command is used to instruct the to-be-tested object to send the request message after receiving the test command; and / or the functional unit is further configured to receive a test result obtained after the to-be-tested object uses the data for test.

12. An electronic device comprising a memory and a processor; wherein, The memory is configured to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method steps in any one of claims 1 to 7.

13. A readable storage medium having stored thereon computer instructions, wherein, The computer instructions are executed by the processor to implement the method steps in any one of claims 1 to 7.

Images