Interface test method and device, electronic equipment and storage medium

Abstract

The present disclosure provides an interface test method and device, electronic equipment and storage medium, relates to the technical field of artificial intelligence, and particularly relates to the technical field of testing. The specific implementation scheme is: in response to receiving a test instruction, determining at least one target test case for a to-be-tested interface according to the test instruction; determining a test task according to the at least one target test case; determining whether the test task meets a remote processing condition according to local residual resource information and required resource information required for executing the test task; and in the case where it is determined that the test task meets the remote processing condition, calling a remote resource to process the test task to obtain test information for the to-be-tested interface.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, and more particularly to the field of testing technology. More specifically, this disclosure provides an interface testing method, apparatus, electronic device, storage medium, and computer program product. Background Technology

[0002] As software systems become increasingly complex, the limitations and delays of conventional functional testing lead to increased testing costs and a significant decrease in testing efficiency. Functional testing alone is no longer sufficient to guarantee project quality and schedule. In contrast, the application of interface testing allows the testing team to become involved in the project earlier and more deeply, enabling testers to discover deeper-level system issues early in the project and reducing the time and cost of fixing these problems. Summary of the Invention

[0003] This disclosure provides an interface testing method, apparatus, electronic device, storage medium, and computer program product.

[0004] According to one aspect of this disclosure, an interface testing method is provided, comprising: in response to receiving a test instruction, determining at least one target test case for the interface to be tested according to the test instruction; determining a test task according to the at least one target test case; determining whether the test task meets remote processing conditions according to local remaining resource information and required resource information for executing the test task; and, if it is determined that the test task meets the remote processing conditions, invoking remote resources to process the test task to obtain test information for the interface to be tested.

[0005] According to another aspect of this disclosure, an interface testing apparatus is provided, comprising: a first determining module, a second determining module, a third determining module, and a calling module. The first determining module is configured to, in response to receiving a test instruction, determine at least one target test case for the interface to be tested, based on the test instruction. The second determining module is configured to determine a test task based on the at least one target test case. The third determining module is configured to determine whether the test task meets remote processing conditions based on local remaining resource information and required resource information for executing the test task. The calling module is configured to, if it is determined that the test task meets the remote processing conditions, call remote resources to process the test task to obtain test information for the interface to be tested.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods provided in this disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods provided in this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods provided in this disclosure.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0011] Figure 1 This is a schematic diagram illustrating an application scenario of the interface testing method and apparatus according to embodiments of this disclosure;

[0012] Figure 2 This is a schematic flowchart of an interface testing method according to an embodiment of the present disclosure;

[0013] Figure 3 This is a schematic diagram of a single-interface testing method according to an embodiment of the present disclosure;

[0014] Figure 4 This is a schematic diagram of a multi-interface testing method according to an embodiment of the present disclosure;

[0015] Figure 5 This is a schematic structural block diagram of an interface testing apparatus according to embodiments of the present disclosure; and

[0016] Figure 6 This is a structural block diagram of an electronic device used to implement the interface testing method of the embodiments of this disclosure. Detailed Implementation

[0017] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0018] Figure 1 This is a schematic diagram illustrating an application scenario of the interface testing method and apparatus according to embodiments of this disclosure.

[0019] It is important to note that Figure 1 The examples shown are merely examples of system architectures that can be applied to the embodiments of this disclosure, in order to help those skilled in the art understand the technical content of this disclosure, but do not mean that the embodiments of this disclosure cannot be used in other devices, systems, environments or scenarios.

[0020] like Figure 1 As shown, the system architecture 100 according to this embodiment may include terminal devices 101, 102, and 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the terminal devices 101, 102, and 103 and the server 105. The network 104 may include various connection types, such as wired and / or wireless communication links, etc.

[0021] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0022] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using terminal devices 101, 102, and 103 (for example only). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as test information generated based on the configuration information of the frontend page) to the terminal devices.

[0023] It should be noted that the interface testing method provided in this disclosure embodiment can generally be executed by server 105. Correspondingly, the interface testing device provided in this disclosure embodiment can generally be located in server 105. The interface testing method provided in this disclosure embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105. Correspondingly, the interface testing device provided in this disclosure embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105.

[0024] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0025] Figure 2 This is a schematic flowchart of an interface testing method according to an embodiment of the present disclosure.

[0026] like Figure 2As shown, in this embodiment, the interface testing method 200 is used to test interfaces. The number of interfaces to be tested is at least one. This interface testing method can test a single interface or test multiple interfaces. The interface testing method 200 may include operations S210 to S240.

[0027] In operation S210, in response to receiving a test instruction, at least one target test case is determined for the interface to be tested based on the test instruction.

[0028] For example, an object can configure required target information by inputting, selecting, clicking, dragging, etc., on the front-end page. The object can be a user, and the target information may include configuration information and / or test case identifiers. After completing the configuration, the object can also click the confirm or save button on the front-end page. This operation can trigger a test instruction, which includes the target information configured by the object on the front-end page. Next, the electronic device receives the test instruction and determines the target test cases based on the target information in the test instruction.

[0029] For example, the number of test commands can be at least one. For instance, multiple users may perform actions on the front-end page, and the front-end page can trigger multiple test commands based on these actions.

[0030] For example, test instructions can include configuration information, which can be used to determine target test cases. As another example, test instructions can include test case identifiers, allowing the retrieved test cases corresponding to those identifiers to be identified as target test cases.

[0031] For single-interface testing, one test case can be used. For multi-interface testing, at least two test cases must be used, and each interface must have at least one test case.

[0032] In operation S220, test tasks are determined based on at least one target test case.

[0033] A test task can be a task that calls a target test case to perform interface testing. For single-interface testing, a test task can be determined based on a single test case corresponding to that single interface. For multi-interface testing, a test task can be determined based on multiple test cases corresponding to multiple scenarios for multiple interfaces.

[0034] When operating S230, based on the local remaining resource information and the required resource information for executing the test task, it is determined whether the test task meets the remote processing conditions.

[0035] For example, local remaining resource information may include the amount of local remaining resources, such as remaining computing resources and storage resources. Computing resources may include CPU, and storage resources may include memory. Local remaining resources may also include the percentage of remaining resources, such as CPU utilization and memory utilization. Local remaining resources may also include the remaining amount in the local task queue. For example, if the local task queue has a length of 100 and there are currently 90 tasks in the queue, then the remaining amount is 10 tasks.

[0036] For example, the resource requirements of a test task can include the amount of resources needed to process the test task.

[0037] For example, the resource requirements of a test task can include the estimated duration needed to process the test task. For scheduled tasks, the average duration used to execute the same test task previously can be used as the estimated duration. For test tasks that have not been executed before, the average duration required to execute the task over a past period can be used as the estimated duration. Furthermore, a correspondence between estimated durations and resource requirements can be pre-established, and resource requirements can then be calculated based on this correspondence.

[0038] For example, the required resource quantity could be the number of test tasks.

[0039] For example, if multiple test tasks need to be processed, the test tasks can be sorted based on at least one of the following factors: creation time, name, resource requirements, estimated duration, etc. The resource requirements of a test task can include its execution order among multiple test tasks; for example, the test task might be the 10th task that needs to be processed locally.

[0040] For example, a remote processing condition could be determining whether the difference between the local remaining resources represented by the local remaining resource information and the demand resources represented by the demand resource information is less than or equal to a resource threshold. If so, the test task is determined to meet the remote processing condition. Otherwise, the test task is determined not to meet the remote processing condition.

[0041] When operating S240, if it is determined that the test task meets the remote processing conditions, the remote resource is invoked to process the test task in order to obtain test information for the interface to be tested.

[0042] For example, when calling remote resources to process test tasks, you can call remote resources to process all test tasks, or you can call remote resources to process a portion of multiple test tasks.

[0043] According to the technical solution provided in the embodiments of this disclosure, since remote resources can be invoked to process test tasks, the problem of test tasks being backlogged and unable to be processed due to insufficient local remaining resources can be avoided, thereby improving test efficiency.

[0044] In some embodiments, if it is determined that the conditions for remote invocation are not met, the test task can be processed locally. For example, local resources can be used to invoke the JMeter test engine to execute test cases for a single interface or multiple interfaces.

[0045] The following describes the implementation methods for determining at least one target test case based on the information in the test instructions.

[0046] In one example, a test instruction is used to test a single interface. The test instruction may include configuration information for that single interface, such as global variables, signature information, parameter extraction expressions, and assertion information. The parameter extraction expression represents the expression used to extract the target parameter from the interface output information. For example, if the target parameter is a status code, the extraction expression could be "$.code". The assertion information can include logical judgments that result in true or false statements. Assertions are used to determine whether the actual result of the interface output matches the expected result. For example, if the expected result of the target parameter is "200", after extracting the target parameter "code" using the extraction expression, it is determined whether the target parameter "code" matches the expected result "200" to verify whether the interface is correct.

[0047] For single-interface testing scenarios, after receiving a test instruction, test cases can be generated based on the configuration information. For example, test case templates can be pre-configured and stored. Upon receiving a test instruction, the configuration information can be retrieved from the instruction, and then assembled with the test case template to obtain the test cases. Next, the obtained test cases can be added to at least one target test case.

[0048] In another example, test instructions can be used to test multi-interface scenarios. These instructions may include at least one configuration piece of information for at least one interface, and / or at least one test case identifier for at least one interface. For multi-interface testing scenarios, target test cases can be determined based on the configuration information and / or test case identifiers contained in the test instructions.

[0049] For example, a multi-interface test requires testing interfaces A, B, and C. The user can configure configuration information 'a' for interface A, configuration information 'b' for interface B, and an identifier 'c' for a specific test case of interface C on the front-end page. Next, a test case TC_A for interface A can be generated based on configuration information 'a', and a test case TC_B for interface B can be generated based on configuration information 'b'. The method for generating test cases based on configuration information is described above and will not be repeated here. Furthermore, the test case TC_C corresponding to identifier 'c' can be retrieved from the test case library based on the test case identifier and the mapping information representing the relationship between test cases and test case identifiers. Then, test cases TC_A, TC_B, and TC_C can be defined as a set of test cases for multi-interface testing, corresponding to a test scenario. By referencing existing test cases through test case identifiers, users do not need to configure test cases themselves, thus improving operational efficiency.

[0050] According to another embodiment of this disclosure, during single-interface testing and multi-interface testing, users can configure the required configuration information on the front-end page. The electronic device can then generate test cases based on the configuration information in the test instructions. Furthermore, after new test cases are generated during single-interface and multi-interface testing, they can be added to the test case library, thereby updating the library. This embodiment allows for the storage of new test cases. Therefore, when users perform other tests and need to use previously configured test cases, they can directly reference the previously configured test cases using the test case identifier, eliminating the need to repeatedly configure the same test cases, thus improving testing efficiency.

[0051] Next, we will explain in detail how to determine whether a test task meets the conditions for remote processing, using the following examples.

[0052] In one example, the resources represented by the local remaining resource information may include the amount of local remaining resources, such as computing resource reserves or memory reserves. The required resources represented by the demand resource information may include the amount of resources required to execute the test task. Accordingly, the operation of determining whether the remote processing condition is met may include: determining whether a first remote processing condition is met based on the amount of local remaining resources, the amount of demand resources, and a threshold.

[0053] For example, for scheduled tasks, the average amount of resources used to execute the test task previously can be used as the required resource amount. For test tasks that have not been executed before, the average amount of resources required to execute other tasks over a past period can be used as the required resource amount for that test task.

[0054] For example, the first remote processing condition could be that the difference between the local remaining resources and the required resources is less than or equal to a resource threshold. Alternatively, the sum of the local remaining resources and the required resources could be used as the first data, and the first remote processing condition could also be that the ratio between the first data and the total local resources is greater than or equal to a ratio threshold.

[0055] This example calculates the first data using the local remaining resources and the required resources, and determines whether the first data meets the threshold, thus accurately determining whether the test task meets the remote processing conditions.

[0056] In another example, the resources represented by the local remaining resource information may include the local CPU utilization, and the required resources represented by the demand resource information may include the total number of test tasks. Accordingly, the operation of determining whether the remote processing condition is met may include: determining the maximum number of executions based on the local CPU utilization and the target length of the local task queue, and then determining whether the total number of test tasks is greater than the maximum number of executions. If so, the test tasks are determined to meet the second remote processing condition; otherwise, the second remote processing condition is determined not to be met.

[0057] For example, the target length of the local task queue represents the maximum number of tasks in the local task queue. For example, the target length of the local task queue can be a predetermined value, such as a target length of 100.

[0058] For example, the target length of the local task queue can be determined based on the predetermined waiting time, the task processing time, and the number of local threads. For instance, the predetermined waiting time could represent the maximum acceptable waiting time for the user, and this value could be pre-configured. The task processing time could represent the average time required to execute a task over a past period. For example, the ratio of the predetermined waiting time to the task processing time could be used as a second metric, and the difference between this second metric and the number of local threads could be used as the target length of the local task queue.

[0059] This embodiment dynamically determines the target length of the local task queue based on the predetermined waiting time, task processing time, and the number of local threads. Compared to a scheme that uses a predetermined target length, this approach dynamically adjusts the target length of the local task queue as the task processing time or predetermined waiting time changes. This avoids test tasks piling up locally due to an excessively long predetermined value, and also avoids local resources being idle due to an excessively short predetermined value. Thus, it improves testing efficiency while ensuring efficient use of local resources.

[0060] The target length of the local task queue has been explained above. Next, we will explain the scheme for determining the maximum number of executions based on the target length of the local task queue.

[0061] For example, the ratio of 1 to CPU utilization can be used as the third data. Another example is calculating the ratio of I / O time to CPU time and adding 1 to that ratio as the third data. Yet another example is using the number of threads in the local thread pool as the third data. Then, the sum of these third data and the target length of the local task queue is used to determine the maximum number of executions.

[0062] For example, there may be multiple unprocessed test tasks. These tasks can be handled using a local thread pool, where threads in the pool are processing test tasks in a "processing" state. Alternatively, a local task queue can be set up, where test tasks are queued. After a thread in the thread pool finishes processing a test task in the "processing" state, it will process the test tasks in the local task queue, at which point the test task's state changes from "queued" to "processing".

[0063] This embodiment determines the maximum number of tasks to be executed based on utilization and the target length of the local task queue. Then, it determines whether the remote processing conditions are met based on the relationship between the total number of test tasks and the maximum number of tasks to be executed. Therefore, multiple test tasks can be reasonably allocated to remote processing, thereby ensuring testing efficiency.

[0064] The following example illustrates the process of calling remote resources to process a portion of multiple test tasks.

[0065] For example, based on local remaining resource information and required resource information, multiple test tasks can be split into a first task set and a second task set. Then, the first task set can be executed using the remaining local resources to obtain the first test information corresponding to it. For the second task set, which cannot be handled by local resources, remote resources can be invoked to execute it and obtain the second test information corresponding to it.

[0066] For example, when splitting multiple test tasks, the resource requirements of the first task set can be close to but not exceed the local remaining resources, and the difference between the local remaining resources and the resource requirements of the first task set can be less than a threshold. Then, the other tasks in the multiple test tasks, excluding the first task set, are assigned to the second task set.

[0067] For example, the task set can be divided using the maximum number of test tasks. The test tasks with the maximum number of tasks can be assigned to the first task set, and the remaining test tasks can be assigned to the second task set.

[0068] For example, if there are 200 unprocessed test tasks, the local thread count can be 10, indicating that 10 test tasks are in the processing state. The target length of the local task queue is 100, meaning that 100 test tasks are allowed to queue. In this embodiment, the maximum number of executions can be 110, meaning 110 test tasks can be processed locally, for example, processing test tasks with an execution order of 110 or earlier. Remote resources can be invoked to process 90 test tasks, for example, processing test tasks with an execution order after 110. In other embodiments, remote resources can also be used to process the 200 test tasks.

[0069] Figure 3 This is a schematic diagram of a single-interface testing method according to an embodiment of the present disclosure.

[0070] The following combination Figure 3 Taking single-interface testing as an example, this paper explains the working principle of single-interface testing methods.

[0071] For example, a user can configure the front-end page 305. Configuration information 301 can include global variables, signature information, parameter extraction expressions, assertion information, etc. Based on this configuration information 301, a single test case 302 can be generated. After obtaining the test case 302, a test task 303 can be determined and executed to obtain test information 304. For example, the JMeter test engine can be invoked locally or remotely to execute the test case 302 for a single interface, and then the JMeter test engine's test information 304 can be obtained. The test information 304 can include execution logs and execution results, and then the test information 304 is pushed to the front-end page 305 via SSE (Server Send Event).

[0072] Figure 4 This is a schematic diagram of a multi-interface testing method according to an embodiment of the present disclosure.

[0073] The following combination Figure 4 Taking multi-interface testing as an example, this paper explains the working principle of multi-interface testing methods.

[0074] For example, users can configure settings on front-end page 410. Configuration information 401 can include global variables, signature information, extraction expressions for parameters, assertion information, etc. Test case identifiers 402 can also be configured on front-end page 410. Timing information can also be configured on front-end page 410 to execute scheduled tasks 404.

[0075] Next, based on configuration information 401 and test case identifier 402, multiple test cases can be generated. These multiple test cases can be associated with the same scenario 403, and can be orchestrated to obtain scenario 403 as needed. The orchestration can include the dependencies between various interfaces; based on these dependencies, the return value of the previous interface will serve as the input of the next interface.

[0076] Next, thread pool 405 can be enabled to determine whether a test task meets the remote processing conditions based on local remaining resource information and the resource requirements of the test task to be processed. It's understandable that after scenario 403 is created, if the test task for scenario 403 does not need to be run, then no resources need to be called.

[0077] If the conditions for remote processing are not met, test tasks can be executed locally. For example, you can start the JMeter engine using local resources, execute test tasks using the JMeter engine, and thus obtain test information 408.

[0078] If the remote processing conditions are met, the Node resource pool 406 can be invoked to calculate the number of containers 407 (Docker) to be launched based on the number of scenarios 403 to be created. Containers 407 can then be used to launch the JMeter test engine to execute scenarios 403. For example, containers 407 can be created according to a predetermined amount of resources, i.e., based on a predetermined number of CPU cores and memory.

[0079] During the creation of container 407, the number of scheduled tasks 404 is known, so the required number of containers 407 can be determined based on the number of tasks. For example, if a user has configured 100 scheduled tasks 404, these test tasks can be split and multiple containers 407 can be created at once to process these scheduled test tasks at the specified time. Furthermore, for cases where users temporarily add test tasks, since the number of tasks cannot be predicted at this time, the number of containers 407 can be continuously increased based on the newly added test tasks until the remote resources are less than or equal to a threshold. When the remote resources are less than or equal to the threshold, the frontend test commands can be rejected, and the user can be informed that resources are insufficient and the user needs to wait.

[0080] Understandably, one container 407 can handle multiple test tasks, and the number of containers 407 needs to be determined based on the number of test tasks. For example, each container 407 can handle an additional 10 test tasks. If there are 3 test tasks requiring remote resource processing, only one container 407 needs to be started. If there are 30 test tasks requiring remote resource processing, 3 containers 407 need to be started.

[0081] After receiving test information 408, test information 408 can be output to message queue 409, which can be Kafka. Then, message queue 409 pushes test information 408 to the front-end page 410 via SSE (Server Send Event).

[0082] According to another embodiment of this disclosure, test information can be obtained by executing test tasks. For example, executing a local task can obtain test information for the interface corresponding to the local task, and executing a remote task can obtain test information for the interface corresponding to the remote task. After obtaining the test information, it can be output and then displayed on a front-end page so that the user is aware of the test information. The test information may include execution logs and test results. The execution logs can record relevant information such as user identifier, execution time, task duration, and whether any exceptions occurred during execution. It should be noted that the system can record the execution logs of test tasks for multiple users, and when displaying them, test information related to that user can be shown to the target user.

[0083] In one example, users can perform actions on the front-end page, such as clicking an output button to generate output instructions. Alternatively, output instructions can be automatically generated upon test completion. Output instructions can include query conditions, which may include at least one of a user identifier and time information. Based on the user identifier in the output instruction, target test information for a specific user can be determined from multiple test information sources. For example, when multiple users perform interface testing, the execution log records relevant information for multiple tests, and target test information corresponding to the user identifier can be filtered from the execution log. Similarly, test information for test tasks executed within a specific time period can be filtered from the execution log based on time information.

[0084] In another example, test instructions correspond to test time information. For instance, a test task is created based on a certain test instruction, and the execution time of this test task is the first time period. Therefore, the test instruction corresponds to the first time period. Target test information generated within the first time period can be filtered from the execution log.

[0085] After obtaining the target test information, the target test information can be output to the front-end page, thereby displaying the target test information to the target user through the front-end page.

[0086] This embodiment can filter out target test information for the target user from a large amount of execution logs based on user identification and time information. This allows the target user to know the relevant information of their own interface test, but not the relevant information of other users' interface tests. This reduces the amount of information displayed to the target user and avoids disclosing test-related information to other users.

[0087] Figure 5 This is a schematic structural block diagram of an interface testing apparatus according to embodiments of the present disclosure; and

[0088] like Figure 5 As shown, the interface testing device 500 may include a first determining module 510, a second determining module 520, a third determining module 530, and a calling module 540.

[0089] The first determining module 510 is used to determine at least one target test case for the interface to be tested in response to receiving a test instruction.

[0090] The second determination module 520 is used to determine the test task based on at least one target test case.

[0091] The third determining module 530 is used to determine whether the test task meets the remote processing conditions based on the local remaining resource information and the required resource information for executing the test task.

[0092] The calling module 540 is used to call remote resources to process the test task when it is determined that the test task meets the remote processing conditions, so as to obtain test information for the interface to be tested.

[0093] According to another embodiment of this disclosure, the number of test tasks is multiple, the local remaining resource information includes the local CPU utilization, and the resource demand information includes the total number of test tasks; the third determining module includes: a first determining submodule and a second determining submodule. The first determining submodule is used to determine the maximum number of executions based on the local CPU utilization and the target length of the local task queue; the second determining submodule is used to determine that the test tasks meet the remote processing conditions in response to detecting that the total number of tasks is greater than the maximum number of executions.

[0094] According to another embodiment of this disclosure, the third determining module further includes: a third determining submodule, used to determine the target length of the local task queue based on a predetermined waiting time, a task processing time, and the number of local threads.

[0095] According to another embodiment of this disclosure, the local remaining resource information includes the local remaining resource quantity, and the required resource information includes the estimated resource quantity required to execute the test task; the third determining module includes: a fourth determining submodule, used to determine that the test task meets the remote processing conditions in response to detecting that the difference between the local remaining resource quantity and the estimated resource quantity is less than or equal to a resource quantity threshold.

[0096] According to another embodiment of this disclosure, the number of test tasks is multiple; the invocation module includes a splitting submodule, an execution submodule, and an invocation submodule. The splitting submodule is used to split the multiple test tasks into a first task set and a second task set based on local remaining resource information and required resource information; the execution submodule is used to execute the first task set using local remaining resources to obtain first test information corresponding to the first task set; the invocation submodule is used to invoke remote resources to execute the second task set to obtain second test information corresponding to the second task set.

[0097] According to another embodiment of this disclosure, determining at least one target test case based on information in a test instruction includes at least one of the following: in response to detecting that a test instruction includes configuration information, generating a test case based on the configuration information and adding the generated test case to at least one target test case; and in response to detecting that a test instruction includes a test case identifier, searching for a test case corresponding to the test case identifier from a test case library based on the test case identifier and adding the searched test case to at least one target test case.

[0098] According to another embodiment of this disclosure, the apparatus further includes an adding module, configured to add the generated test cases to a test case library after the test cases are generated.

[0099] According to another embodiment of this disclosure, the configuration information includes at least one of the following: global variables, signature information, extraction expressions for parameters, and assertion information.

[0100] According to another embodiment of this disclosure, the apparatus further includes a filtering module and an output module. The filtering module, after obtaining test information, responds to receiving an output instruction by filtering target test information for a target object from multiple test information sources based on at least one of an object identifier and test time information in the output instruction; the output module is used to output the target test information.

[0101] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0102] In the technical solution disclosed herein, the user's authorization or consent is obtained before acquiring or collecting the user's personal information.

[0103] According to embodiments of this disclosure, this disclosure also provides an electronic device, including at least one processor; and a memory communicatively connected to the at least one processor; the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described interface testing method.

[0104] According to embodiments of this disclosure, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the above-described interface testing method.

[0105] According to embodiments of this disclosure, this disclosure also provides a computer program product, including a computer program that implements the above-described interface testing method when executed by a processor.

[0106] Figure 6 This is a structural block diagram of an electronic device used to implement the interface testing method of embodiments of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0107] like Figure 6 As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded from storage unit 608 into random access memory (RAM) 603. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0108] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0109] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as interface testing methods. For example, in some embodiments, the interface testing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by computing unit 601, one or more steps of the interface testing method described above may be performed. Alternatively, in other embodiments, computing unit 601 may be configured to perform interface testing methods by any other suitable means (e.g., by means of firmware).

[0110] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0111] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0112] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0113] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0114] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0115] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0116] It should be understood that the various processes shown above can be used, with steps rearranged, added, or deleted. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure is achieved, and this is not limited herein. The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. An interface testing method, comprising: in response to receiving a test instruction, determining at least one target test case for a to-be-tested interface according to the test instruction; determining a plurality of test tasks according to the at least one target test case; determining whether the test tasks meet a remote processing condition according to local residual resource information and required resource information required for executing the test tasks, the local residual resource information comprising local central processor utilization, and the required resource information comprising a total number of tasks of the test tasks; and in a case where it is determined that the test tasks meet the remote processing condition, invoking a remote resource to process the test tasks to obtain test information for the to-be-tested interface; wherein the determining whether the test tasks meet the remote processing condition according to the local residual resource information and the required resource information required for executing the test tasks comprises: determining a maximum execution number according to the local central processor utilization and a target length of a local task queue, and determining that the test tasks meet the remote processing condition in response to detecting that the total number of tasks is greater than the maximum execution number, the target length of the local task queue being determined according to a predetermined waiting time length, a task processing time length and a number of threads locally, the target length of the local task queue representing a maximum number of tasks in the local task queue, the predetermined waiting time length representing a maximum waiting time length acceptable by a user, and the task processing time length representing an average time length for executing historical tasks. the local residual resource information comprises a local residual resource amount, and the required resource information comprises an estimated resource amount required for executing the test tasks; 2. The method of claim 1, wherein, the determining whether the test tasks meet the remote processing condition according to the local residual resource information and the required resource information required for executing the test tasks comprises: determining that the test tasks meet the remote processing condition in response to detecting that a difference between the local residual resource amount and the estimated resource amount is less than or equal to a resource amount threshold. the invoking the remote resource to process the test tasks comprises:

3. The method of any one of claims 1-2, wherein, splitting the plurality of test tasks into a first task set and a second task set according to the local residual resource information and the required resource information; executing the first task set using local residual resources to obtain first test information corresponding to the first task set; and invoking the remote resource to execute the second task set to obtain second test information corresponding to the second task set. the determining at least one target test case for a to-be-tested interface according to the test instruction comprises at least one of:

4. The method of any one of claims 1 to 2, wherein, in response to detecting that the test instruction comprises configuration information, generating a test case according to the configuration information, and adding the generated test case to the at least one target test case; and in response to detecting that the test instruction comprises a test case identifier, searching for a test case corresponding to the test case identifier from a case library according to the test case identifier, and adding the searched test case to the at least one target test case. ​ ​ 5. The method of claim 4, wherein, The configuration information comprises at least one of the following: a global variable, signature information, an extraction expression for a parameter, and assertion information.

6. The method of claim 1, further comprising: after obtaining the test information, in response to receiving an output instruction, filtering target test information for a target object from the plurality of test information according to at least one of object identification and test time information in the output instruction; and outputting the target test information.

7. An interface testing apparatus, comprising: a first determining module configured to, in response to receiving a test instruction, determine at least one target test case for a to-be-tested interface according to the test instruction; a second determining module configured to determine a plurality of test tasks according to the at least one target test case; a third determining module configured to determine whether the test tasks satisfy a remote processing condition according to local residual resource information and demand resource information required for executing the test tasks, the local residual resource information comprising a local central processing unit utilization rate, and the demand resource information comprising a total number of tasks of the test tasks; and an invoking module configured to, in a case where it is determined that the test tasks satisfy the remote processing condition, invoke a remote resource to process the test tasks to obtain test information for the to-be-tested interface. The third determining module comprises: a first determining submodule configured to determine a maximum execution number according to the local central processing unit utilization rate and a target length of a local task queue; and a second determining submodule configured to, in response to detecting that the total number of tasks is greater than the maximum execution number, determine that the test tasks satisfy the remote processing condition. The target length of the local task queue is determined according to a predetermined waiting time length, a task processing time length, and a number of threads locally, the target length of the local task queue representing a maximum number of tasks in a local task queue, the predetermined waiting time length representing a maximum waiting time length acceptable by a user, and the task processing time length representing an average time length for executing historical tasks. The local residual resource information comprises a local residual resource amount, and the demand resource information comprises an estimated resource amount required for executing the test tasks. The third determining module comprises:

8. The apparatus of claim 7, wherein, a fourth determining submodule configured to, in response to detecting that a difference between the local residual resource amount and the estimated resource amount is less than or equal to a resource amount threshold, determine that the test tasks satisfy the remote processing condition. The invoking module comprises: a splitting submodule configured to split the plurality of test tasks into a first task set and a second task set according to the local residual resource information and the demand resource information; 9. The apparatus of any of claims 7-8, wherein, an executing submodule configured to execute the first task set using local residual resources to obtain first test information corresponding to the first task set; and an invoking submodule configured to invoke the remote resource to execute the second task set to obtain second test information corresponding to the second task set. The determining the at least one target test case according to information in the test instruction comprises at least one of the following: ​ 10. The apparatus of any of claims 7-8, wherein, ​ In response to detecting that the test instruction comprises configuration information, generating a test case according to the configuration information, and adding the generated test case to the at least one target test case; and In response to detecting that the test instruction comprises a test case identifier, searching for a test case corresponding to the test case identifier from a case library according to the test case identifier, and adding the searched test case to the at least one target test case.

11. The apparatus of claim 10, wherein, The configuration information comprises at least one of the following: a global variable, signature information, an extraction expression for a parameter, and assertion information.

12. The apparatus of claim 7, further comprising: After obtaining the test information, The screening module is configured to, in response to receiving an output instruction, screen target test information for a target object from a plurality of test information according to at least one of an object identifier and test time information in the output instruction; and The output module is configured to output the target test information.

13. An electronic device, comprising: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 6.

14. A non-transitory computer readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to perform the method of any one of claims 1 to 6.

15. A computer program product comprising a computer program which, when executed by a processor, implements the method of any one of claims 1 to 6.

Images