Method and device for generating test case, computing equipment and program product

Abstract

The embodiment of the invention relates to a method and device for generating a test case, computing equipment and a computer program product. The method comprises the following steps: firstly, acquiring flow data, input data and output data related to an access request of a user, wherein the flow data comprises an interface of a first service pointed by the access request; a dependency condition related to the traffic data is then determined, the dependency condition representing an interface of a second service on which the first service depends. Further, based on the traffic data and the dependency condition, a test case related to the access request is generated.

Description

Technical Field

[0001] Embodiments of the present specification generally relate to the field of software testing, and more particularly to a method, apparatus, computing device, and computer program product for generating test cases. Background Art

[0002] As the entrance to various services, software components can accept various user operations. In the component development process, the stability of software operation is crucial, so the software needs to be tested from multiple aspects. Test cases, as the basis of testing work, are the key link to verify software functions, performance, and security.

[0003] With the development of automated testing technology and artificial intelligence technology, demand analysis and modeling tools and test management tools provide support for the generation of test cases. Based on this, how to achieve intelligent, automated and efficient test case generation, so as to provide more comprehensive and accurate support for software testing, is an important issue in the software development and testing process. Summary of the invention

[0004] The embodiments of this specification provide a method, apparatus, computing device, and computer program product for generating a test case.

[0005] In a first aspect of the present specification, a method for generating a test case is provided. The method includes obtaining traffic data related to an access request of a user, the traffic data including an interface of a first service pointed to by the access request, input data, and output data. The method includes determining a dependency condition related to the traffic data, the dependency condition indicating an interface of a second service on which the first service depends. In addition, the method also includes generating a test case related to the access request based on the traffic data and the dependency condition.

[0006] In a second aspect of the present specification, a device for generating a test case is provided. The device includes a traffic data acquisition module configured to acquire traffic data related to a user's access request, the traffic data including an interface of a first service pointed to by the access request, input data, and output data. The device includes a dependency condition determination module configured to determine a dependency condition related to the traffic data, the dependency condition indicating an interface of a second service on which the first service depends. In addition, the device also includes a test case generation module configured to generate a test case related to the access request based on the traffic data and the dependency condition.

[0007] In a third aspect of the present specification, a computing device is provided. The computing device includes a processor. The computing device also includes a memory coupled to the processor, the memory having instructions stored therein, and when the instructions are executed by the processor, the computing device executes the method according to the first aspect of the present specification.

[0008] In a fourth aspect of the present specification, a computer program product is provided, wherein the computer program product comprises a computer program, and the computer program is executed by a processor to implement the method according to the first aspect of the present specification.

[0009] In a fifth aspect of the present disclosure, a computer storage medium is provided. The computer-readable storage medium stores computer-executable instructions, wherein the computer-executable instructions are executed by a processor to implement the method provided according to the first aspect of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The above and other features, advantages and aspects of the embodiments of the present specification will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, wherein:

[0011] Figure 1 A schematic diagram illustrating an example environment in which some embodiments of the present specification may be implemented;

[0012] Figure 2 A flow chart of a method for generating test cases according to some embodiments of the present specification is shown;

[0013] Figure 3 A flowchart showing a method for determining a dependency condition according to some embodiments of the present specification;

[0014] Figure 4 A flowchart showing a method for generating test cases according to some embodiments of the present specification;

[0015] Figure 5 A flowchart showing a method for generating a second test case according to some embodiments of the present specification; and

[0016] Figure 6 A schematic block diagram of a computing device is shown that illustrates some embodiments of the present description.

[0017] Throughout the drawings, the same or similar reference numbers denote the same or similar elements. DETAILED DESCRIPTION

[0018] The embodiments of the present specification will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present specification are shown in the accompanying drawings, it should be understood that the present specification can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present specification. It should be understood that the drawings and embodiments of the present specification are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0019] It should be noted that the data involved in this specification, as well as the acquisition or use of the data, are all based on the requirements of the relevant laws, regulations and relevant provisions. Before using the technical solutions in the embodiments of this specification, the user should be informed of the type, scope of use, usage scenarios, etc. of the user information involved in a reasonable manner in accordance with the requirements of the above laws, regulations and relevant provisions, and the user's explicit authorization should be obtained. In addition, the above-mentioned process of informing the user and obtaining the user's authorization is only illustrative and does not constitute a limitation on the implementation method of this specification. Other methods that meet the relevant laws and regulations may also be applied to the implementation scheme of this specification.

[0020] In the description of the embodiments of this specification, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc. may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0021] As mentioned above, the transaction component undertakes a variety of user operations and is a complex and large set of functions. However, due to the lack of technical personnel who can clearly understand the overall picture of the software components, it is easy to have evaluation omissions when the service division of labor changes, personnel flow, and service complexity changes. The reason is that whether through expert experience or historical documents, there is a lack of ability to describe the full range of services. In the related technology, the recording solution based on traffic acquisition use cases automatically generates test cases by intercepting and recording the request and response data of specific interfaces. The main focus is on the traffic data at the interface level, specifically involving the recording of interface names, input parameters, and output parameters. As a result, certain conditions must be met for the use case to be executed, otherwise an error will be reported, and under different use case execution dependency conditions, the same input may produce different behaviors on the system, causing such use cases to be missed during the recording process.

[0022] To this end, an embodiment of the present specification provides a method for generating a test case. First, traffic data related to a user's access request is obtained, and the traffic data includes an interface, input data, and output data of a first service pointed to by the access request. Then, a dependency condition related to the traffic data is determined, and the dependency condition indicates an interface of a second service on which the first service depends. Further, based on the traffic data and the dependency condition, a test case related to the access request is generated.

[0023] In this way, the dependency conditions of the use case can be automatically obtained based on the use case acquired based on the traffic, avoiding the situation where the use case that must meet certain conditions to be executed will report an error during execution, and the same input will produce different behaviors under different use case execution dependency conditions, thereby avoiding the situation where such use cases are missed during the recording process and cause incomplete use case coverage. Therefore, the present invention supplements the lack of dependency conditions in the traffic collection process in the relevant scheme by collecting dependency condition data, improves the pass rate of use case execution and the service denominator coverage, and provides a real and reliable reference basis for subsequent evaluation, thereby improving the accuracy of the test.

[0024] Figure 1 A schematic diagram of an example environment 100 is shown in which some embodiments of the present specification may be implemented. Figure 1 , the example environment 100 includes a computing device 102, which includes but is not limited to a communication device, a computing chip, a computing system, a single server, a distributed server, or a cloud-based server. The computing device 102 is configured to perform a series of operations to generate test cases based on the user's access request. It is understandable that when a user interacts with a service or application in some way (such as clicking a link, submitting a form, or sending an API request), corresponding traffic data will be generated. The computing device 102 captures these traffic data, which include the service interface pointed to by the access request, the input data provided by the user, and the output data returned by the service.

[0025] In some embodiments, the computing device 102 analyzes the traffic data to determine the dependencies associated with them. These dependencies reveal the details of other services or interfaces that the service depends on when performing its functions or processing traffic data. The identification of such dependencies is crucial to ensuring the integrity and executability of the test cases.

[0026] In some embodiments, based on the captured traffic data and dependency conditions, the computing device 102 further generates test cases related to the access request. These test cases are designed to simulate the user's actual access request and verify whether the behavior of the service under given conditions is as expected. Figure 1Although only a single computing device 102 is shown in the figure, the actual application may involve the collaborative work of multiple computing devices to process a large amount of traffic data and generate corresponding test cases. In addition, the computing device 102 can also interact with various external systems and services to obtain necessary information or perform specific operations.

[0027] In some embodiments, the computing device 102 may include a traffic data acquisition module 104, which is responsible for acquiring traffic data related to the user's access request, and the traffic data includes the interface, input data, and output data of the service pointed to by the access request. These data are the basis for generating test cases. In some embodiments, the computing device 102 may include a dependency determination module 106, which is responsible for determining dependency conditions related to the traffic data. These dependency conditions indicate the interfaces of other services or resources required during the service execution process. By tracking the interface calls during the service execution process, the dependency relationship of the service can be determined.

[0028] In some embodiments, the computing device 102 may include a modeling rule determination module 108. It defines the structure, data format, and verification criteria of the test case. The modeling rules are closely related to the interface functions of the service and define fields related to the service input and output data and dependency conditions. The computing device 102 may include a test case generation module 110. Based on the traffic data and dependency conditions, the test case generation module is responsible for generating test cases related to the access request. These test cases are used to verify the functions and performance of the service.

[0029] In some embodiments, the computing device 102 may include a deduplication module 112. The deduplication module is responsible for removing duplicate test cases and performing deduplication processing on the generated test cases according to the modeling rules to generate a traffic denominator. The computing device 102 may include a label determination module 114, which is responsible for generating labels for the test cases and further processing the test cases according to the inspection fields input by the user. By labeling the test cases, the test cases can be more conveniently classified, retrieved and managed.

[0030] In some embodiments, the computing device 102 may include a use case denominator generation module 116, which generates a test case with a label based on the traffic denominator and the use case label. The module can also generate an automated use case based on the use case denominator, and automatically execute the test case to verify the service function. When the service is changed, the affected label is evaluated according to the content affected by the service change, and the use case range affected by the change is quickly retrieved through the label in the full denominator use case.

[0031] In this way, the computing device 102 can automatically obtain the use case dependency conditions based on the traffic acquisition use case, which supplements the lack of dependency conditions in the traditional traffic collection process and avoids the problems of use case execution failure and incomplete use case coverage. It improves the pass rate of use case execution and the coverage rate of service denominators, providing a real and reliable reference for subsequent change evaluation.

[0032] It should be understood that the architecture and functions in the example environment 100 are described for exemplary purposes only and do not imply any limitation on the scope of the present description. The embodiments of the present description may also be applied to other environments with different structures and / or functions.

[0033] Figure 2 FIG. 2 shows a flow chart of generating a test case 200 of the present specification. In some embodiments, Figure 1 In the example environment 100 shown in , the method 200 can be performed by the computing device 102. It should be understood that although the following content is described with the computing device 102 as the execution subject, the method 200 can also be performed by other devices. The method 200 can also include additional actions not shown and / or can omit the actions shown, and the scope of the present disclosure is not limited in this respect.

[0034] At step 202, traffic data related to the user's access request is obtained, and the traffic data includes the interface, input data, and output data of the first service pointed to by the access request. It is understandable that the user's access request usually occurs when the user interacts with a service or application, and the interaction may include the user clicking a link, submitting a form, and sending an API request. In some embodiments, traffic collection for online services is commonly performed in the form of traffic recording clients, logs, and other technical solutions.

[0035] In some embodiments, when a user initiates an access request, the request is usually sent to an interface of a specific service or application. The interface defines the format and content of the request and how the service should respond. It is understood that the "first service interface" refers to the interface of the service or application that the user request first reaches.

[0036] In some embodiments, input data is information sent by a user to a service interface through an access request, which may include form data filled in by the user, query parameters, request header information, etc. Input data is critical to understanding the user's intentions and needs. By analyzing the input data, you can understand what operation the user is trying to perform and what information they provide to support this operation.

[0037] In some embodiments, the output data is the response returned by the service interface to the user after receiving the user's access request. It may include query results, status information, error messages, etc. The output data can generally reflect the content and results of the service's response to the user's request. By analyzing the output data, the performance and accuracy of the service can be evaluated, as well as whether the user has obtained the results they expect.

[0038] At step 204, a dependency condition related to the traffic data is determined, the dependency condition indicating the interface of the second service on which the first service depends. In some embodiments, the dependency condition related to the traffic data generally refers to the fact that in a service architecture, service A (first service) needs to rely on the interface or data provided by service B (second service) when performing its functions or processing traffic data. This dependency relationship ensures that data can flow correctly between services and supports service A (first service) to achieve its designed functions.

[0039] At step 206, based on the traffic data and the dependency conditions, a test case related to the access request is generated. It is understandable that by analyzing the traffic data, the user's access behavior and the system's response mode can be understood. By analyzing the dependency conditions, the boundaries and scope of the test case and the external environment that needs to be simulated or configured can be determined. In some embodiments, various possible combinations of input conditions and dependency conditions can be considered to ensure the coverage and effectiveness of the test case.

[0040] In the embodiments of the present disclosure, the use case dependency conditions can be automatically obtained based on the traffic acquisition use case, which supplements the lack of dependency conditions in the traditional traffic collection process and avoids the problems of use case failure and incomplete use case coverage. The pass rate of use case execution and service denominator coverage are improved, providing a real and reliable reference for subsequent change evaluation.

[0041] Figure 3 A flowchart of a method 300 for determining dependency conditions of the present specification is shown. In some embodiments, service B may include direct services and indirect services that service A depends on. When the interface of service A is called, service A is executed. When service A is executed, the computing device 102 may use logging and monitoring tools to track the interface calls during the execution of service A. When interface B1 is detected to be called, it can be determined that service B1 is a direct service of service A. In some embodiments, the computing device 102 obtains interface B1. Further, the computing device 102 uses a monitoring tool to track the interface calls during the execution of service B1. When interface B2 is detected to be called, it can be determined that service B2 is an indirect service of service A. In some embodiments, the computing device 102 obtains interface B2. It can be understood that there can be one or more direct services and indirect services.

[0042] In some embodiments, the scenario may be that a user purchases a product. When the user places an order, the "user order service" (service A) is called. When the "user order service" is executed, the "inventory check service" (service B1) is called to confirm whether there is sufficient inventory of the product. If the "inventory check service" finds that the inventory is insufficient, the "inventory check service" will further call the "purchase service" (service B2) to request replenishment. Therefore, even if the "purchase service" is not directly called by the "user order service", it is indirectly triggered by the "inventory check service" during the execution of the "user order service". Therefore, the "inventory check service" is a direct service of the "user order service", and the "purchase service" is an indirect service of the "user order service".

[0043] In some embodiments, service B (second service) that service A (first service) depends on will change after service A is executed. In some embodiments, when the interface of service A is called to execute service A, the computing device 102 tracks that interface B is called during the execution of service A, and after service A is executed, the state, data, or behavior of service B has changed. During the tracking process, the computing device 102 can determine the time before service B changes, the time when the change occurs, and the time after the change, and these times can determine the dependency relationship. For example, a dependency condition may be that service B must complete the change before service A starts executing, and a dependency condition may be that service A needs to complete execution within a specific time period after service B changes.

[0044] In some embodiments, the scenario may be a user purchasing a product. To purchase a certain product, the user first adds 5 products to the shopping cart, and then submits an order to purchase the 5 products in the shopping cart. When the user submits the order, the computing device 102 calls the "order processing service" (service A) to process the order. During the execution of the "order processing service", the "inventory management service" (service B) will be relied on to check the inventory of the selected product. Before the user submits the order, the inventory of the product is sufficient, but when the user submits the order or earlier, other users also purchase the product, resulting in a change in the inventory quantity. In this case, when the "order processing service" calls the "inventory management service", the computing device 102 will find that the inventory has changed. At this time, the "order processing service" needs to determine two dependent conditions based on this change: whether the inventory quantity before the change meets the user's order, and whether the inventory quantity after the change is still sufficient.

[0045] In some embodiments, the computing device 102 obtains data of the second service according to the dependency condition, and generates a complete test case based on the obtained data of the second service, traffic data (actual request data generated by the user) and the dependency condition. In the generated test case, the part related to the dependency condition will be automatically filled with the data obtained from the second service, and this data is filled in according to a predefined format.

[0046] In some embodiments, when a user searches for a product, the "search product service" relies on the "product information service" to obtain detailed information about the product, such as price, material, etc. When the computing device 102 obtains a piece of traffic data that the user searches for the product "wool", the computing device 102 queries the product information of "wool" from the "product information service", including price, brand, etc.

[0047] In some embodiments, the computing device 102 generates a complete test case using the acquired traffic data (user's request to search for "wool" products), dependency conditions ("search product service" depends on "product information service"), and data acquired from "product information service". In the generated test case, data related to product information is automatically filled with data acquired from "product information service", and these data are filled in according to a predefined format (such as JSON, XML, etc.).

[0048] Figure 4 A flowchart of a method for generating a test case in the present specification is shown. In some embodiments, the interface of service A (first service) defines the functions and parameters of the service. According to the interface, the computing device 102 can obtain predefined modeling rules related to the test case, and the modeling rules may include the structure, data format, and verification criteria of the test case. The computing device 102 generates multiple test cases based on the captured traffic data and dependency conditions. It can be understood that these test cases cover different parameters and different combinations of dependency conditions.

[0049] In some embodiments, after generating multiple test cases, it is necessary to remove duplicates therein to generate test cases related to the access request. Duplicate test cases waste test resources and also affect the accuracy of the test results. The computing device 102 can deduplicate the generated test cases according to predefined modeling rules, and the deduplicated test cases can be called traffic denominators. It is understandable that the computing device 102 can adopt different modeling rules according to different interfaces, and when defining the modeling rules, they can be defined by summarizing expert experience and combing service rules.

[0050] In some embodiments, the scenario may be a user searching for a product. The "Product Search Service" is responsible for executing the user's request. The "Product Search Service" has a corresponding interface that defines the search keywords entered by the user, the screening conditions (brand, price), and the type and format of the results returned by the service. In order to ensure the stability and accuracy of the "Product Search Service", its functions are tested.

[0051] According to the corresponding interface of "Product Search Service", the computing device 102 formulates a set of modeling rules, which include the structure of the test case (such as request parameters, expected response format), data format (such as keyword length, quota range format) and verification standards (such as response time, accuracy of returned results). When formulating the modeling rules, the computing device 102 summarizes which parameter combinations are common and which parameter combinations will cause anomalies based on expert experience. The computing device 102 can also sort out service rules, such as search keyword length, quota range format requirements, etc. The computing device 102 integrates these experiences and rules to formulate modeling rules to guide the generation and deduplication of test cases.

[0052] The computing device 102 generates multiple test cases based on the captured traffic data table (such as the keywords and filter conditions actually searched by the user) and dependent conditions (such as system status and network status). These test cases cover different parameter combinations and dependent conditions. In order to avoid wasting test resources and affecting the accuracy of test results, the computing device 102 deduplicates these test cases according to predefined modeling rules. The deduplicated test cases can be called "traffic denominators", which represent all unique test scenarios.

[0053] In some embodiments, the modeling rules are closely related to the functions of the service interface. The modeling rules define fields related to at least one of the name, description, and acquisition path of the service input data, fields related to at least one of the name, description, and acquisition path of the service output data, and fields related to at least one of the name, description, and acquisition path of the service dependency. In some embodiments, the modeling fields can be "service type", "describe specific service information", "request.bizType", "payment method", "payment method for this order", "response.payChannel", "user risk test", "user risk test specific type", "userRiskFacade.response.riskLevel".

[0054] In some embodiments, the computing device 102 generates test cases according to predefined modeling rules. Each test case contains a series of fields that describe the specific content of the test case, such as the purpose of the test, the value of the input data, and the expected results. By comparing the fields of these test cases, the computing device 102 can identify which test cases are repeated, and repetition means that two or more test cases have the same values ​​in key fields (such as input data, expected output, etc.), thereby covering the same test scenario.

[0055] In some embodiments, in order to optimize the test process and reduce unnecessary testing work, it is necessary to remove duplicate test cases. Existing solutions generate a large number of duplicate test cases, which puts tremendous pressure on the execution of test cases and failure analysis. For a large amount of traffic, all executions result in the consumption of a large amount of hardware resources by automated execution, and at the same time, system jitter will cause a large number of test cases to fail, which will put tremendous pressure on subsequent failure analysis. Removing duplicate test cases may involve a variety of strategies. The computing device 102 can choose to retain a representative test case, or merge multiple similar test cases to create a more comprehensive test case. By removing duplicate test cases, a more streamlined and efficient set of test cases is obtained. This set of test case sets is related to specific access requests, can accurately reflect the behavior of the service under different conditions, and provides a solid foundation for subsequent testing and analysis work.

[0056] In some embodiments, it is necessary to transform the input data, output data, or dependency conditions of the service according to the service requirements using the transformation logic in the modeling rules to meet specific service processing requirements. The computing device 102 obtains the transformation logic of the field in the modeling rules, and the field is related to at least one of the input data, output data, and dependency conditions of the executed service. The computing device 102 obtains the fields of one or more of the input data, output data, and dependency conditions of the service, and transforms the fields based on the obtained transformation logic.

[0057] In some embodiments, the scenario may be that the user uses a red envelope when paying. The service requirement of this scenario may be to determine whether the user used a red envelope when paying, without paying attention to the specific red envelope coupon template. Therefore, the field conversion logic obtained by the computing device 102 is that no matter which red envelope coupon template the user uses to send the red envelope, it is uniformly converted into the field of "whether to use red envelope". The computing device 102 also needs to obtain fields related to the use of red envelopes. This field may appear in the input data of the service, such as the user's payment information, or it may appear in dependent conditions, such as a certain payment rule.

[0058] Therefore, the computing device 102 converts the red envelopes of different coupon templates into whether to use the red envelopes according to the previously determined conversion logic, and converts the field representing the specific coupon template (first field) into a field representing whether to use the red envelope (second field). This process may involve operations such as data filtering, mapping, or aggregation, and the final result is a more concise data representation that better meets service requirements.

[0059] Figure 5 A flow chart of the method for generating a second test case in the present specification is shown. In some embodiments, the computing device 102 labels the test cases generated based on traffic and dependency conditions. The computing device 102 applies predefined labeling rules to generate labels for the test cases. The predefined labeling rules may be based on specific attributes of the test cases, such as test objectives, test scope, test environment, etc., or may be based on specific data in the test cases, such as the value of the interface field, user operation type, etc. By labeling the test cases, it is easier to classify, retrieve and manage the test cases. When performing service change analysis retrieval, it helps to improve the change analysis capabilities and avoid omissions in change assessments.

[0060] In some embodiments, the computing device 102 combines the test case with the corresponding label to generate a labeled test case (second test case). The labeled test case (second test case) not only contains all the information of the test case, but also adds the label generated by the label rule to establish an association relationship between the label and the test case.

[0061] In some embodiments, when a service changes (such as a new function is launched, an old function is modified or deleted, etc.), the computing device 102 will immediately detect the change. Further, the computing device 102 will analyze the specific content of the service change and determine which tags are associated with these changes. Tags can represent specific functional modules, service processes, user roles, or any other identifiers that help classify and organize test cases.

[0062] In some embodiments, after determining the tag associated with the service change, the computing device 102 will retrieve the test case with the tag from the full set of test cases (second test cases). The purpose is to quickly locate the range of test cases that may be affected by the service change. According to the specific content of the service change, the computing device 102 adjusts the retrieved test case. Specifically, it may include updating the description, steps, expected results, etc. of the test case to ensure that the actual situation after the service change can be accurately reflected.

[0063] In some embodiments, the computing device 102 receives additional information from the user, which may be inspection content related to the initially created test case (first test case). The inspection content may include specific functional points that the user wants to verify, expected test results, test environment requirements, or any other information that helps ensure the accuracy and completeness of the test case. In this case, the computing device 102 generates a new test case (second test case) based on the initially created test case, the tags related to the test case, and the inspection content entered by the user.

[0064] It is understandable that, based on the traffic denominator, the use case label and the inspection field, the computing device 102 generates a use case denominator containing the result inspection content after marking. The computing device 102 can automatically generate specific test cases based on the use case denominator based on the automation tool and framework. The generated automated use case can include execution conditions, input parameters, interface names, output parameters, and inspection results. This information together constitutes a complete description of the test case, so that the test case can be automatically executed and the results can be verified. Due to intelligent analysis and screening, redundant and unnecessary test scenarios are removed, and the number of automated use cases generated will be reduced by several orders of magnitude compared to the original traffic data. The execution and error analysis efficiency of automated use cases is significantly improved. Since the test cases are automatically generated and the execution process is also automated, it can greatly save manpower and time. At the same time, the automation tool can also provide detailed error reports and statistical analysis to help developers locate and solve problems faster.

[0065] Figure 6 The block diagram of a computing device 600 suitable for implementing an embodiment of the present invention is schematically shown. The computing device 600 can be used to implement the computing device 102. The computing device 600 can be used to implement the execution Figure 2 The method 200 is shown in the apparatus. Figure 6 As shown, the computing device 600 includes a processing unit (CPU) 601, which can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 602 or computer program instructions loaded from a storage unit 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the computing device 600 can also be stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0066] Multiple components in the computing device 600 are connected to the I / O interface 605, including: an input unit 606, an output unit 607, and a storage unit 608. The processing unit 601 performs the various methods and processes described above, such as executing the method 200. For example, in some embodiments, the various processes or operations described above can be implemented as a computer software program, which is stored in a machine-readable medium, such as the storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the computing device 600 via the ROM 602 and / or the communication unit 609. When the computer program is loaded into the RAM 603 and executed by the CPU 601, the various methods and processes described above can be executed, such as executing one or more operations of the method 200. Alternatively, in other embodiments, the CPU 601 can be configured to execute the various methods and processes described above, such as executing one or more actions of the method 200, by any other appropriate means (for example, by means of firmware).

[0067] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing / processing device.

[0068] The computer program instructions for performing the operation of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. Computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be personalized by utilizing the state information of the computer-readable program instructions, and the electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present invention.

[0069] These computer-readable program instructions can be provided to a processor in a voice interaction device, a general-purpose computer, a special-purpose computer, or a processing unit of other programmable data processing devices, thereby producing a machine, so that when these instructions are executed by the processing unit of a computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other device to work in a specific manner.

[0070] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0071] The embodiments of the present invention have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

[0072] The above are only optional embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for generating a test case, comprising: Acquire traffic data related to an access request of a user, wherein the traffic data includes an interface, input data, and output data of a first service pointed to by the access request; determining a dependency condition associated with the traffic data, the dependency condition indicating an interface of a second service on which the first service depends; as well as Based on the traffic data and the dependency conditions, a test case related to the access request is generated.

2. The method according to claim 1, wherein the second service includes a direct service and an indirect service on which the first service depends, and determining the dependency condition comprises: Calling the interface of the first service to execute the first service; In the process of executing the first service, determining the direct service on which the first service depends, wherein the first service includes an interface related to the direct service; Determine the indirect service on which the direct service depends, wherein the direct service includes an interface related to the indirect service; as well as The interfaces of the direct service and the indirect service are obtained.

3. The method according to claim 1, wherein the dependency condition comprises a first dependency condition and a second dependency condition, and determining the dependency condition comprises: Calling the interface of the first service to execute the first service, wherein the second service on which the first service depends is changed after the execution is completed; Determine the time associated with the second service before the change and the second service after the change; as well as The first dependency condition and the second dependency condition are determined based on time associated with the second service before the change and the second service after the change.

4. The method according to claim 2 or 3, wherein the dependency condition further includes data of the second service, and generating the test case comprises: Based on the dependency condition, acquiring data of the second service on which the first service depends; as well as Based on the traffic data, the dependency conditions, and the data of the second service, the test case related to the access request is generated so that the data of the second service is filled into the part of the test case related to the dependency conditions according to a predefined format.

5. The method according to claim 1, wherein generating the test case comprises: Based on the interface of the first service, obtaining predefined modeling rules related to the test case; According to the modeling rules, a plurality of test cases are generated based on the traffic data and the dependency conditions; as well as Repetitive test cases among the multiple test cases are removed to generate the test case related to the access request.

6. The method according to claim 5, wherein the modeling rule is related to an interface function of a service in a system, and the modeling rule defines a field related to at least one of a name, a description, and an acquisition path of input data of the service, a field related to at least one of a name, a description, and an acquisition path of output data of the service, and a field related to at least one of a name, a description, and an acquisition path of a dependency condition of the service, and removing duplicate test cases comprises: Determining duplicate test cases based on fields in the plurality of test cases, the fields of the plurality of test cases being generated based on corresponding modeling rules; as well as The determined duplicate test cases in the plurality of test cases are removed to generate the test case related to the access request.

7. The method according to claim 6, further comprising: Based on the service requirements, obtaining conversion logic related to a field of at least one of the input data, output data, and dependency condition of the first service in the modeling rule; Obtaining a first field of at least one of input data, output data, and dependency conditions of the service; as well as Based on the conversion logic, the first field is converted into a second field.

8. The method of claim 1 , wherein the test case comprises a second test case, and generating the second test case comprises: Based on the traffic data and the dependency condition, generate a first test case related to the access request; Based on a predefined labeling rule, generating a label for the first test case; as well as Based on the first test case and the corresponding label, the second test case is generated.

9. The method according to claim 8, further comprising: In response to detecting a service change, determining an associated tag according to content of the service change; Retrieving a corresponding second test case from a plurality of second test cases based on the associated tag; as well as Based on the content of the service change, the second test case corresponding to the associated tag is adjusted.

10. The method according to claim 8, wherein generating the second test case comprises: Obtaining inspection content related to the first test case input by a user; as well as The second test case is generated based on the first test case, the corresponding label, and the inspection content.

11. A device for generating a test case, comprising: A flow data acquisition module, configured to acquire flow data related to an access request of a user, wherein the flow data includes an interface, input data, and output data of a first service pointed to by the access request; a dependency condition determination module, configured to determine a dependency condition related to the traffic data, the dependency condition indicating an interface of a second service on which the first service depends; as well as The test case generation module is configured to generate a test case related to the access request based on the traffic data and the dependency condition.

12. A computing device comprising: processor; as well as A memory coupled to the processor, the memory having instructions stored therein, which, when executed by the processor, cause the computing device to perform the method according to any one of claims 1 to 10.

13. A computer program product comprising a computer program, the computer program being executed by a processor to implement the method according to any one of claims 1 to 10.

Images