Test case determination method and device, medium and equipment

Abstract

The invention discloses a test case determination method and device, a medium and equipment, and relates to the technical field of tests.The method comprises the steps that in response to a test case generation instruction for a target background service, a target case metadata set corresponding to the target background service in a case metadata set is obtained; the use case metadata set comprises a plurality of use case metadata sets corresponding to the plurality of background services, and the plurality of use case metadata sets define calling parameters of the plurality of background services in a unified preset data format; the plurality of use case metadata sets are obtained by analyzing log information corresponding to each background service in a plurality of subscribed background services; and determining a target test case set corresponding to the target background service according to the test case generation instruction and the target case metadata set. According to the method and the device, the corresponding target test case set can be automatically determined for the target background service, and the test cases corresponding to multiple background services of different program languages can be managed.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to a method, apparatus, medium, and equipment for determining a test case. Background Art

[0002] In order to improve the accuracy of background services, testing of background services is essential. Developing an automated test case generation method based on IDL (Interface Definition Language) for each background service separately consumes a lot of time and cannot provide automated addition and update of test cases for background services that are not defined by IDL. This also increases the difficulty and cost of maintenance and management. In the prior art, there is an urgent need for a solution that can provide unified automatic test case management for multiple background services without being restricted by the programming language of the background service. Summary of the Invention

[0003] In order to achieve automatic management of test cases corresponding to different background services, this application provides a method, device, medium and equipment for determining test cases. The technical solution is as follows:

[0004] In a first aspect, the present application provides a method for determining a test case, the method comprising:

[0005] In response to a test case generation instruction for a target background service, a target use case metadata group corresponding to the target background service in a use case metadata set is obtained; the use case metadata set includes a plurality of use case metadata groups corresponding one-to-one to a plurality of background services, the target background service is any one of the plurality of background services, the programming languages ​​of the plurality of background services are not completely the same, the plurality of use case metadata groups are used to define call parameters of the plurality of background services in a unified preset data format; the plurality of use case metadata groups are obtained by parsing log information corresponding to each of the plurality of subscribed background services, the log information being used to indicate call information recorded by the corresponding background service during a historical call process;

[0006] A target test case set corresponding to the target background service is determined according to the test case generation instruction and the target test case metadata group.

[0007] Optionally, the method further includes:

[0008] Subscribe to the log information corresponding to each of the multiple backend services;

[0009] Determining a log parsing grammar that matches the log information corresponding to each background service according to the log format of the log information corresponding to each background service;

[0010] The log information corresponding to each background service is parsed according to the matched log parsing grammar to obtain a use case metadata group corresponding to each background service.

[0011] Optionally, the log parsing grammar is a first parsing grammar for a key-value pair format, and the log information corresponding to each background service is parsed and processed according to the matched log parsing grammar to obtain a use case metadata group corresponding to each background service, including:

[0012] When the log format of the log information is the key-value pair format, based on the first parsing grammar, a first use case metadata group is extracted from the log information, and the first use case metadata group includes at least one first parameter field and at least one group of first parameter attribute data, and the at least one first parameter field corresponds one-to-one to the at least one group of first parameter attribute data.

[0013] Optionally, the log parsing grammar is a second parsing grammar for a delimiter format, and the log information corresponding to each background service is parsed and processed according to the matched log parsing grammar to obtain a use case metadata group corresponding to each background service, including:

[0014] When the log format of the log information is the delimiter format, dividing the log information according to the delimiters in the log information based on the second parsing grammar to obtain first candidate log data of a key-value pair structure;

[0015] A second use case metadata group corresponding to the log information is extracted from the first candidate log data, wherein the second use case metadata group includes at least one second parameter field and at least one group of second parameter attribute data, and the at least one second parameter field corresponds one-to-one to the at least one group of second parameter attribute data.

[0016] Optionally, the log parsing grammar includes a first parsing grammar for a key-value pair format and a second parsing grammar for a delimiter format. The log information corresponding to each background service is parsed according to the matched log parsing grammar to obtain a use case metadata group corresponding to each background service, including:

[0017] In a case where the log format of the log information includes the key-value pair format and the separator format, performing nested parsing on the log information based on the first parsing grammar and the second parsing grammar to obtain second candidate log data of a key-value pair structure;

[0018] A third use case metadata group corresponding to the log information is extracted from the second candidate log data, wherein the third use case metadata group includes at least one third parameter field and at least one group of third parameter attribute data, and the at least one third parameter field corresponds one-to-one to the at least one group of third parameter attribute data.

[0019] Optionally, determining a target test case set corresponding to the target background service according to the test case generation instruction and the target test case metadata group includes:

[0020] Determining request address data according to the test case generation instruction, wherein the request address data indicates a use case execution environment;

[0021] Traversing log information corresponding to the target backend service, the log information including request body data of multiple request records;

[0022] Generate a target test case according to the request address data, the currently traversed request body data, and at least one target parameter field and at least one set of target parameter attribute data in the target test case metadata group;

[0023] When the traversal is completed, the target test case set consisting of at least one target test case is obtained.

[0024] Optionally, determining a target test case set corresponding to the target background service according to the test case generation instruction and the target test case metadata group includes:

[0025] Determining request address data according to the test case generation instruction, wherein the request address data indicates a use case execution environment;

[0026] Obtain a set of historical test cases corresponding to the target backend service;

[0027] At least one historical test case in the historical test case set is updated according to the request address data and at least one target parameter field and at least one set of target parameter attribute data in the target use case metadata group to obtain the target test case set.

[0028] Optionally, subscribing to log information corresponding to each of the multiple background services includes:

[0029] Based on the preset reporting mechanism, obtain the log information of the current cycle reported by the log storage server corresponding to each background service;

[0030] Alternatively, based on a preset proxy server, the log information of the current period is pulled from the log storage corresponding to each background service.

[0031] In a second aspect, the present application provides a device for determining a test case, the device comprising:

[0032] an acquisition module configured to, in response to a test case generation instruction for a target background service, acquire a target use case metadata group corresponding to the target background service in a use case metadata set; the use case metadata set includes a plurality of use case metadata groups corresponding one-to-one to a plurality of background services, the target background service being any one of the plurality of background services; the programming languages ​​of the plurality of background services are not identical, the plurality of use case metadata groups being used to define call parameters of the plurality of background services in a unified preset data format; the plurality of use case metadata groups being obtained by parsing log information corresponding to each of the plurality of subscribed background services, the log information being used to indicate call information recorded by the corresponding background service during a historical call process;

[0033] The test case determination module is used to determine a target test case set corresponding to the target background service according to the test case generation instruction and the target test case metadata group.

[0034] In a third aspect, the present application provides a computer-readable storage medium, which stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by a processor to implement a method for determining a test case as described in the first aspect.

[0035] In a fourth aspect, the present application provides a computer device, comprising a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement a method for determining a test case as described in the first aspect.

[0036] In a fifth aspect, the present application provides a computer program product, which includes computer instructions, and when the computer instructions are executed by a processor, implements a method for determining a test case as described in the first aspect.

[0037] The test case determination method, apparatus, medium, and equipment provided in this application have the following technical effects:

[0038] The solution provided in the present application can respond to a test case generation instruction for a target background service and obtain a target use case metadata group corresponding to the target background service in the use case metadata set; thereby determining a target test case set corresponding to the target background service based on the test case generation instruction and the target use case metadata group, thereby realizing the automatic generation or update management of the target test cases corresponding to the target background service without the need for manual maintenance by personnel.

[0039] In the solution provided in the present application, the use case metadata set includes multiple use case metadata groups corresponding one-to-one to multiple background services. The target background service is any one of the multiple background services. The programming languages ​​of the multiple background services are not exactly the same, but the multiple use case metadata groups can define the calling parameters of the multiple background services in a unified preset data format, so that the management of test cases corresponding to multiple background services of different programming languages ​​can be achieved without being restricted by the programming language of the background service. For example, for newly added background services, there is no need to develop a separate use case management method for the newly added background services. Only the log subscription for the newly added background services needs to be added.

[0040] In the solution provided in the present application, multiple use case metadata groups are obtained by parsing the log information corresponding to each of the multiple subscribed background services. The log information is used to indicate the call information recorded by the corresponding background service during the historical call process, thereby realizing non-invasive acquisition of the call information of the background service call process. The subscription mechanism can be used to update the use case metadata set, and the managed test cases can be automatically updated.

[0041] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become obvious from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions and advantages of the embodiments of the present application or the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0043] Figure 1 This is a schematic diagram of an implementation environment of a method for determining a test case provided in an embodiment of the present application;

[0044] Figure 2 This is a flow chart of a method for determining a test case provided in an embodiment of the present application;

[0045] Figure 3 This is a flow chart of log parsing provided by an embodiment of the present application;

[0046] Figure 4 This is a flow chart of a log reporting process provided by an embodiment of the present application;

[0047] Figure 5 This is a flow chart of log pulling provided by an embodiment of the present application;

[0048] Figure 6 This is a flow chart of automated management of test cases corresponding to multiple backend services provided by an embodiment of the present application;

[0049] Figure 7 is a schematic diagram of a device for determining a test case provided in an embodiment of the present application;

[0050] Figure 8 This is a schematic diagram of the hardware structure of an operating terminal provided in an embodiment of the present application;

[0051] Figure 9 This is a schematic diagram of the hardware structure of a server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0052] The embodiments of the present application provide methods, devices, media and equipment for determining test cases. The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. Examples of the embodiments are shown in the drawings, where the same or similar numbers throughout represent the same or similar elements or elements with the same or similar functions.

[0053] It should be noted that the terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or devices.

[0054] It is understandable that in the specific implementation of this application, when it comes to user request body data and other related data, when the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0055] See also Figure 1 , which is a schematic diagram of an implementation environment of a method for determining a test case provided by an embodiment of the present application, such as Figure 1 As shown, the implementation environment may include at least a client 01 and a server 02 .

[0056] Specifically, the client 01 may include devices such as smartphones, desktop computers, tablet computers, laptops, in-vehicle terminals, digital assistants, smart wearable devices, and voice interaction devices. It may also include software running on the device, such as web pages provided by service providers to users, or applications provided by these service providers to users. Specifically, the client 01 may be used to provide an operation interface for testers, allowing them to trigger test case generation instructions for the target backend service based on the operation interface.

[0057] Specifically, the server 02 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The server 02 may include a network communication unit, a processor, and a memory, etc. The terminal and the server may be directly or indirectly connected via wired or wireless communication, which is not limited in this application. Specifically, the server 02 may be used to respond to a test case generation instruction for a target background service, obtain a target use case metadata group corresponding to the target background service in the use case metadata set; and determine the target test case set corresponding to the target background service based on the test case generation instruction and the target use case metadata group, thereby realizing automatic generation or updating of test cases and improving test efficiency. The server 02 can also obtain a use case metadata set by parsing the log information corresponding to each of the multiple subscribed background services, where the log information is used to indicate the call information recorded by the corresponding background service during the historical call process; the use case metadata set includes multiple use case metadata groups corresponding one by one to the multiple background services, where the target background service is any background service among the multiple background services, the programming languages ​​of the multiple background services are not exactly the same, and the log formats of the log information of each background service are therefore not exactly the same, but the multiple use case metadata groups can define the call parameters of the multiple background services in a unified preset data format, thereby facilitating the management of test cases corresponding to the multiple background services of different programming languages.

[0058] The solution provided in the embodiment of the present application can be deployed in the cloud, which also involves cloud technology, etc.

[0059] Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide or local area network (WAN) to enable data computing, storage, processing, and sharing. It can also be understood as a general term for network, information technology, integration, management platform, and application technologies used in the cloud computing business model. This technology forms a resource pool, enabling flexible and convenient on-demand use. Backend services for technical network systems, such as video and image websites, and a growing number of portals, require significant computing and storage resources. With the rapid development and application of the internet, every item will likely have its own unique identifier and will need to be transmitted to backend systems for logical processing. Data of varying levels will be processed separately. Data from various industries requires robust system support, thus requiring cloud computing as the foundation for cloud computing. Cloud computing is a computing model that distributes computing tasks across a resource pool composed of numerous computers, enabling various application systems to access computing power, storage space, and information services as needed. The network that provides these resources is called the "cloud." To users, resources in the cloud appear infinitely scalable, readily accessible, usable on demand, and scalable at any time, with a pay-per-use policy. As a provider of cloud computing infrastructure, a cloud computing resource pool platform, often referred to as Infrastructure as a Service (IaaS), is established. Various virtual resources are deployed within the resource pool for external clients to choose from. The cloud computing resource pool primarily includes computing devices (which can be virtualized machines, including operating systems), storage devices, and network devices. Specifically, the server 02 and database are located in the cloud. The server 02 can be either a physical machine or a virtualized machine.

[0060] The following describes a method for determining a test case provided by this application. Figure 2 It is a flowchart of a method for determining a test case provided in an embodiment of the present application. The present application provides method operation steps as described in the embodiment or flowchart, but may include more or fewer operation steps based on conventional or non-creative labor. The order of steps listed in the embodiment is only one way of executing the steps among many orders, and does not represent the only order of execution. When the actual system or server product is executed, it can be executed in sequence or in parallel (for example, in a parallel processor or multi-threaded processing environment) according to the method shown in the embodiment or the accompanying drawings. Please refer to Figure 2 A method for determining a test case provided in an embodiment of the present application may include the following steps:

[0061] S210: In response to a test case generation instruction for a target background service, a target use case metadata group corresponding to the target background service in the use case metadata set is obtained, where the target use case metadata group is used to define call parameters of the target background service in a preset data format.

[0062] The embodiment of the present application realizes the automatic management of test cases for multiple background services, wherein the test case is an entity that defines key information such as request parameters and request methods for initiating service calls.

[0063] In an embodiment of the present application, a use case metadata set includes multiple use case metadata groups corresponding one-to-one to multiple background services. The target background service is any background service among the multiple background services, and accordingly, the target use case metadata group is the use case metadata group corresponding to the target background service among the multiple use case metadata groups. A background service is an application type that runs in the background and can provide specific functional services to users locally or through the network. Multiple use case metadata groups are used to define the call parameters of multiple background services and are also key reference data for managing test cases corresponding to multiple background services.

[0064] In an embodiment of the present application, multiple use case metadata groups are obtained by parsing the log information corresponding to each of the multiple subscribed background services, and the log information is used to indicate the call information recorded by the corresponding background service during the historical call process. Since the programming languages ​​of the multiple background services are not exactly the same, and because the logs are managed differently by each background service, such as being managed independently or by a corresponding log management service, the formats or specifications of the log information corresponding to each background service may be different. However, the multiple use case metadata groups provided by the present application can define the call parameters of multiple background services in a unified preset data format, thereby realizing unified management of the call parameters of multiple background services in different programming languages, without being restricted by the technology stack or interface definition language of the background service.

[0065] S220: Determine a target test case set corresponding to the target background service according to the test case generation instruction and the target test case metadata group.

[0066] In a feasible implementation manner, step S220 may be implemented as follows:

[0067] S221: Determine request address data according to the test case generation instruction, where the request address data indicates the use case execution environment.

[0068] The request address data may indicate whether the use case execution environment is a development environment, a test environment, a pre-release environment, or a live network environment.

[0069] S222: Traverse the log information corresponding to the target background service, where the log information includes request body data of multiple request records.

[0070] Generally, log information can be categorized by event, allowing the corresponding request record to be identified. The request body (RequestBody) is used to transmit data sent from the client to the server. It is typically generated dynamically by the client and includes the parameters, content, or data required to pass the call request to the server. The request body typically appears in request methods such as POST and PUT. The request body can contain various types of data, such as form data, JSON data, and files. The specific data type is specified by the Content-Type field in the request header. By iterating through the log information, you can loop back and replay all request events based on the request records in the log information.

[0071] Common request body formats are as follows:

[0072] 1. Form data (application / x-www-form-urlencoded): Encodes request parameters in key-value format for transmission.

[0073] 2.JSON data (application / json): Encodes request parameters in JSON format to transmit structured data.

[0074] 3. File upload (multipart / form-data): used to upload files to the server. The request body contains the binary data of the file.

[0075] S223: Generate a target test case according to the request address data, the currently traversed request body data, and at least one target parameter field and at least one set of target parameter attribute data in the target test case metadata group.

[0076] The process of generating a target test case includes determining the execution environment, constructing the request body, determining the client protocol, generating assertions, etc. The execution environment can be determined based on the request address data.

[0077] When constructing a request body, the data in the constructed request body needs to be encoded according to the data format indicated by a set of target parameter attribute data corresponding to the target parameter field of the request body in the target use case metadata group, so as to meet the conditions of the current call parameters of the target background service.

[0078] Using at least one target parameter field and at least one set of target parameter attribute data corresponding to at least one target parameter field, the client protocol, service address and other data are determined. For example, the category of the client's communication protocol should belong to one or more categories allowed by a set of target parameter attribute data corresponding to the target parameter field of the communication protocol.

[0079] Assertions are a series of rules that are preset based on the execution results of the target test case to determine whether the execution is successful or not. For example, the rules for determining whether the execution is successful or failed can be constructed based on the enumeration values ​​indicated by a set of target parameter attribute data corresponding to the target parameter field of the response code.

[0080] S224: When the traversal is completed, a target test case set consisting of at least one target test case is obtained.

[0081] Furthermore, each time a target test case is generated, the target test case can be automatically executed, and the execution result of the target test case can be obtained as response body information, which facilitates subsequent analysis work.

[0082] In the above embodiment, the request body data in the log information is combined to construct a target test case that can be automatically executed and meets the target background service call parameter conditions, eliminating the cost of manually writing multiple request body data and improving the automation level and efficiency of constructing the target test case.

[0083] In a feasible implementation manner, step S220 may be implemented as follows:

[0084] S225: Generate instructions based on the test case and determine request address data, where the request address data indicates the use case execution environment.

[0085] The request address data may indicate whether the use case execution environment is a development environment, a test environment, a pre-release environment, or a live network environment.

[0086] S226: Obtain a set of historical test cases corresponding to the target background service.

[0087] The historical test case set can be obtained based on the embodiment shown in steps S221-S224.

[0088] S227: Update at least one historical test case in the historical test case set according to the request address data and at least one target parameter field and at least one set of target parameter attribute data in the target test case metadata group to obtain a target test case set.

[0089] Specifically, the historical request address data of each historical test case in the historical test case set can be updated to the request address data determined based on the test case generation instruction, and each historical test case can be updated according to at least one target parameter field in the target case metadata group, including but not limited to the request body data, client protocol, response code enumeration value, etc. of the historical test case, so that the target test case obtained after the update meets the target background service call parameter conditions.

[0090] In the above embodiment, update management of the target use case metadata group can be achieved based on the subscription to log information, so that historical test cases can be updated using at least one target parameter field and at least one set of target parameter attribute data in the target use case metadata group, thereby meeting the parameter requirements of the current call to the target background service and automatically realizing update management of the test cases.

[0091] Please refer to Figure 3 The method for determining a test case provided in an embodiment of the present application may further include the following steps:

[0092] S310: Subscribe to log information corresponding to each of the multiple background services.

[0093] Typically, traffic recording and playback involves the client attaching a recorder probe and automatically registering it with the server to create a recorded traffic flow. This fully records the responses of all external dependencies (such as databases, distributed caches, and external service responses). The platform then distributes traffic playback instructions to the replay server. Its core approach is to directly record real production data, converting it into reusable and executable test traffic for rapid playback in a test environment.

[0094] In the embodiment provided in this application, the call information recorded by each backend service call process, including request information and response information, is obtained by subscribing to log information. Compared with the above-mentioned traffic recording method, this is a non-real-time, asynchronous data acquisition method that does not intrude on the backend service.

[0095] This application provides two subscription methods. The first is based on a preset reporting mechanism to obtain the log information of the current period reported by the log storage server corresponding to each background service; the second is based on a preset proxy server to pull the log information of the current period from the log storage corresponding to each background service.

[0096] Specifically, such as Figure 4As shown, the SDK (Software Development Kit) for log reporting is mainly provided in the form of HTTP (Hypertext Transfer Protocol) interface. The HTTP interface has the advantages of being simple and universal and not restricted by programming languages. Currently popular high-level programming languages ​​all support access to the HTTP protocol. The HTTP interface uses an asynchronous approach internally to shield the caller from the access time cost. The reported log information is the minimum data set that defines the operation of the target background service itself, including but not limited to Figure 4 The service name, service address, service constraints, communication protocol, request body, and protocol header are shown in the . The reported log information is sent to the log parsing module (Log Parse) corresponding to the background service.

[0097] Specifically, such as Figure 5 As shown, proxy servers can be used to pull logs, enabling non-invasive log subscription for backend services. Based on the log management method used by the backend service, such as local machine logs or a third-party log hosting platform, corresponding proxy services are developed. These proxy services mask differences in log management methods, retrieve log information recorded by the backend service, and transparently transmit it to the corresponding log parsing module (Log Parse).

[0098] In the above embodiment, based on the preset reporting mechanism, the log information of the current period reported by the log storage server corresponding to each background service is obtained; or based on the preset proxy server, the log information of the current period is pulled from the log storage corresponding to each background service, which can cover all log collection paths and will not intrude into the background service, thereby ensuring the normal operation of the background service.

[0099] S320: Determine a log parsing grammar that matches the log information corresponding to each background service according to the log format of the log information corresponding to each background service.

[0100] S330: Parse the log information corresponding to each background service according to the matched log parsing syntax to obtain a use case metadata group corresponding to each background service.

[0101] In other words, the embodiments of the present application can standardize log information in different log formats into a use case metadata group with the same data format, enabling unified management of call parameters for multiple backend services in different programming languages. Furthermore, the use case metadata group can define the call parameters for the corresponding backend service, providing a reference for call parameters when generating test cases.

[0102] In a feasible embodiment, the log parsing grammar is a first parsing grammar for a key-value pair format. Specifically, in the case where the log format of the log information is a key-value pair format, such as a JSON (JavaScript Object Notation, JS object notation, a lightweight data exchange format) log, based on the first parsing grammar, a first use case metadata group is extracted from the log information, and the first use case metadata group includes at least one first parameter field and at least one group of first parameter attribute data, and at least one first parameter field corresponds one-to-one to the at least one group of first parameter attribute data. Among them, at least one first parameter field is used to describe one or more parameters involved in the calling process of the corresponding background service, and a group of first parameter attribute data corresponding to the first parameter field is used to indicate the attribute characteristics of the first parameter field in terms of type, necessity, etc. In the embodiment of the present application, the first parsing grammar for a key-value pair format is not limited to the conversion of a JSON string into a JS object or the conversion of a JS object into a JSON string.

[0103] For example, when the log information is in JSON format, that is, in key-value pair format, the key-value pair data in the log information can be directly extracted, where the key name in the key-value pair data is the first parameter field, and the key value is the first parameter attribute data corresponding to the first parameter field.

[0104] In one feasible embodiment, the log parsing grammar is a second parsing grammar for a delimiter format. Specifically, when the log format of the log information is a delimiter format, based on the second parsing grammar, the log information is divided according to the delimiters in the log information to obtain first candidate log data in a key-value pair structure; and a second use case metadata group corresponding to the log information is extracted from the first candidate log data, the second use case metadata group including at least one second parameter field and at least one set of second parameter attribute data, and the at least one second parameter field corresponds one-to-one to the at least one set of second parameter attribute data.

[0105] For example, for a log format like "a=1&b=2&c=3" or "a=1|b=2|c=3," the & and | symbols can be used to separate the key-value pairs a=1, b=2, and c=3, respectively, and the second use case metadata group can be extracted from the key-value pairs. It should be noted that "a=1&b=2&c=3" or "a=1|b=2|c=3" here are only illustrative of the log format; a, b, and c do not have actual parameter field meanings.

[0106] In one feasible embodiment, the log parsing grammar includes a first parsing grammar for a key-value pair format and a second parsing grammar for a delimiter format. Specifically, when the log format of the log information includes a key-value pair format and a delimiter format, the log information is nested and parsed based on the first parsing grammar and the second parsing grammar to obtain second candidate log data of a key-value pair structure; a third use case metadata group corresponding to the log information is extracted from the second candidate log data, the third use case metadata group including at least one third parameter field and at least one set of third parameter attribute data, and the at least one third parameter field corresponds one-to-one to the at least one set of third parameter attribute data.

[0107] For example, for log information similar to case 1, the nested parsing process of the log information is: first parse the entire log log according to the JSON format, then parse the value of the b field in the log according to the & separator, and parse the value of the c field in the log according to the | separator.

[0108]

[0109]

[0110] For example, for log information similar to case 2, the nested parsing process for the log information is as follows: first, parse the entire log according to the & separator. For the b field, its value is parsed according to the JSON string.

[0111] case2:

[0112] log=a=1&b={"b1":"1","b2":"b2"}&c=2

[0113] It should be noted that case 1 and case 2 are two relatively simple examples of log information formats that require nested parsing. In actual applications, the number of times the first parsing syntax and the second parsing syntax are used in nested parsing is not limited and depends on the log information.

[0114] Table 1 shows several parameter fields and parameter attribute data for each parameter field in terms of type, constraint value, description, etc. The data structure of the parameter fields and parameter attribute data in the use case metadata group can be a form structure, a key-value pair structure, an array structure, etc., which is not limited in this application comparison.

[0115] Table 1 Parameter fields in the use case metadata group and parameter attribute data corresponding to the parameter fields

[0116]

[0117]

[0118] In the above embodiment, a universal parsing syntax is provided for JSON parsing and delimiter parsing. When a single universal parsing syntax cannot be used to parse the log information corresponding to a background service, a parsing strategy can be customized based on the log information itself, thereby enabling nested parsing of the log information of the background service, achieving standardization of log information in different formats, and achieving unified management of call parameters corresponding to multiple background services in different programming languages, facilitating the addition or update of call parameters and facilitating the expansion of background services.

[0119] In a specific embodiment, Figure 6 As shown, the automated management of test cases corresponding to multiple background services implemented in this application includes the following steps:

[0120] Maintenance and management of multiple backend services: Multiple backend services are backend services that need to manage test cases. They are not limited by technology stack or programming language. Any backend service can be the object of maintenance in this application.

[0121] Log subscription: Subscribe to the log information recorded by the backend service itself. There are two ways to complete the subscription. The first is to have the backend service server actively report the log information. The second is to use a proxy server to pull the backend service log information from the backend service server.

[0122] Log parsing: The log formats and adopted specifications of the log information corresponding to the backend services are different. Through the log parsing link, the log information with different formats can be standardized into a unified data format.

[0123] Management of use case metadata collection: The use case metadata collection includes multiple use case metadata groups, all of which are internally defined data formats, which define the call parameters of the corresponding background service, that is, indicate the request parameters required for the test case corresponding to the background service to run.

[0124] Use case management: Through the use case metadata group corresponding to each backend service, the test case set corresponding to each backend service can be automatically generated or updated.

[0125] It can be seen from the above embodiments that the technical solution provided by the embodiments of the present application can respond to the test case generation instruction for the target background service and obtain the target use case metadata group corresponding to the target background service in the use case metadata set; thereby, according to the test case generation instruction and the target use case metadata group, the target test case set corresponding to the target background service is determined, and the automatic generation or update management of the target test cases corresponding to the target background service is realized without the need for manual maintenance by personnel.

[0126] In the technical solution provided in the present application, the use case metadata set includes multiple use case metadata groups corresponding one-to-one to multiple background services. The target background service is any one of the multiple background services. The programming languages ​​of the multiple background services are not exactly the same, but the multiple use case metadata groups can define the calling parameters of the multiple background services in a unified preset data format, so that it is not restricted by the programming language of the background service, and unified management of test cases corresponding to multiple background services of different programming languages ​​can be achieved. For example, for newly added background services, there is no need to develop a separate use case management method for the newly added background services. It is only necessary to add a log subscription for the newly added background services.

[0127] In the technical solution provided in the present application, multiple use case metadata groups are obtained by parsing the log information corresponding to each of the multiple subscribed background services. The log information is used to indicate the call information recorded by the corresponding background service during the historical call process, thereby realizing non-invasive acquisition of the call information of the background service call process, and the subscription mechanism can be used to update the use case metadata set, thereby automatically updating the managed test cases.

[0128] The embodiment of the present application also provides a test case determination device 700, such as Figure 7 As shown, the device may include:

[0129] An acquisition module 710 is configured to, in response to a test case generation instruction for a target background service, acquire a target use case metadata group corresponding to the target background service in a use case metadata set; the use case metadata set includes multiple use case metadata groups corresponding one-to-one to multiple background services, wherein the target background service is any background service among the multiple background services; the programming languages ​​of the multiple background services are different, and the multiple use case metadata groups are used to define call parameters of the multiple background services in a unified preset data format; the multiple use case metadata groups are obtained by parsing log information corresponding to each of the multiple subscribed background services, wherein the log information is used to indicate call information recorded by the corresponding background service during historical calls;

[0130] The test case determination module 720 is configured to determine a target test case set corresponding to the target background service according to the test case generation instruction and the target test case metadata group.

[0131] In one embodiment of the present application, the apparatus 700 may further include:

[0132] A log subscription unit, configured to subscribe to log information corresponding to each of the plurality of background services;

[0133] A parsing grammar determining unit, configured to determine a log parsing grammar matching the log information corresponding to each background service according to a log format of the log information corresponding to each background service;

[0134] The log parsing unit is used to parse the log information corresponding to each background service according to the matched log parsing grammar to obtain the use case metadata group corresponding to each background service.

[0135] In one embodiment of the present application, the log parsing unit may include:

[0136] The first extraction sub-unit is used to extract a first use case metadata group from the log information based on the first parsing grammar when the log format of the log information is the key-value pair format, wherein the first use case metadata group includes at least one first parameter field and at least one group of first parameter attribute data, and the at least one first parameter field corresponds one-to-one to the at least one group of first parameter attribute data.

[0137] In one embodiment of the present application, the log parsing unit may include:

[0138] a log partitioning subunit, configured to, when the log format of the log information is the delimiter format, partition the log information according to the delimiter in the log information based on the second parsing grammar to obtain first candidate log data of a key-value pair structure;

[0139] The second extraction sub-unit is used to extract a second use case metadata group corresponding to the log information from the first candidate log data, wherein the second use case metadata group includes at least one second parameter field and at least one group of second parameter attribute data, and the at least one second parameter field corresponds one-to-one to the at least one group of second parameter attribute data.

[0140] In one embodiment of the present application, the log parsing unit may include:

[0141] a nested parsing subunit, configured to, when the log format of the log information includes the key-value pair format and the separator format, perform nested parsing on the log information based on the first parsing grammar and the second parsing grammar to obtain second candidate log data of a key-value pair structure;

[0142] A third extraction sub-unit is used to extract a third use case metadata group corresponding to the log information from the second candidate log data, wherein the third use case metadata group includes at least one third parameter field and at least one group of third parameter attribute data, and the at least one third parameter field corresponds one-to-one to the at least one group of third parameter attribute data.

[0143] In one embodiment of the present application, the test case determination module 720 may include:

[0144] a first request address data determining unit, configured to determine request address data according to the test case generation instruction, wherein the request address data indicates a use case execution environment;

[0145] A traversal unit, configured to traverse log information corresponding to the target background service, wherein the log information includes request body data of multiple request records;

[0146] a generating unit, configured to generate a target test case according to the request address data, the currently traversed request body data, and at least one target parameter field and at least one set of target parameter attribute data in the target test case metadata group;

[0147] The target test case set determining unit is configured to obtain the target test case set consisting of at least one target test case when the traversal is completed.

[0148] In one embodiment of the present application, the test case determination module 720 may include:

[0149] a second request address data determining unit, configured to determine request address data according to the test case generation instruction, wherein the request address data indicates a use case execution environment;

[0150] A historical test case set acquisition unit, configured to acquire a historical test case set corresponding to the target backend service;

[0151] An updating unit is used to update at least one historical test case in the historical test case set according to the request address data and at least one target parameter field and at least one set of target parameter attribute data in the target use case metadata group to obtain the target test case set.

[0152] In one embodiment of the present application, the log subscription unit may include:

[0153] An active reporting unit, configured to obtain the log information of the current period reported by the log storage server corresponding to each background service based on a preset reporting mechanism;

[0154] The proxy pulling unit is used to pull the log information of the current period from the log storage corresponding to each background service based on a preset proxy server.

[0155] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0156] It should be noted that the apparatus provided in the above embodiments, when implementing its functions, is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0157] An embodiment of the present application provides a computer device, which includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement a method for determining a test case as provided in the above method embodiment.

[0158] See also Figure 8 , which shows a hardware structure diagram of an operating terminal provided in an embodiment of the present application, and the operating terminal is used to implement the method for determining the test case provided in the above embodiment.

[0159] The operating terminal 1600 may include an RF (Radio Frequency) circuit 1610, a memory 1620 including one or more computer-readable storage media, an input unit 1630, a display unit 1640, a video sensor 1650, an audio circuit 1660, a WiFi (wireless fidelity) module 1670, a processor 1680 including one or more processing cores, and a power supply 160. It will be understood by those skilled in the art that Figure 8 The operating end structure shown in the figure does not constitute a limitation on the operating end, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0160] RF circuitry 1610 can be used to receive and transmit signals during information transmission or calls. Specifically, it receives downlink information from the base station and forwards it to one or more processors 1680 for processing. It also transmits uplink data to the base station. Typically, RF circuitry 1610 includes, but is not limited to, an antenna, at least one amplifier, a tuner, one or more oscillators, a subscriber identity module (SIM) card, a transceiver, a coupler, an LNA (Low Noise Amplifier), a duplexer, and the like. Furthermore, RF circuitry 1610 can communicate with the network and other devices via wireless communication. This wireless communication can utilize any communication standard or protocol, including but not limited to GSM (Global System of Mobile Communication), GPRS (General Packet Radio Service), CDMA (Code Division Multiple Access), WCDMA (Wideband Code Division Multiple Access), LTE (Long Term Evolution), email, and SMS (Short Messaging Service).

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

[0162] The input unit 1630 can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control. Specifically, the input unit 1630 may include an image input device 1631 and other input devices 1632. The image input device 1631 can be a camera or a photoelectric scanning device. In addition to the image input device 1631, the input unit 1630 can also include other input devices 1632. Specifically, the other input devices 1632 can include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, power keys, etc.), a trackball, a mouse, a joystick, etc.

[0163] Display unit 1640 can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of operation terminal 1600. These graphical user interfaces can be composed of graphics, text, icons, videos, or any combination thereof. Display unit 1640 may include a display panel 1641. Optionally, display panel 1641 can be configured in the form of an LCD (Liquid Crystal Display), an OLED (Organic Light-Emitting Diode), or the like.

[0164] The operating terminal 1600 may include at least one video sensor 1650, which is used to obtain video information of the user. The operating terminal 1600 may also include other sensors (not shown), such as light sensors, motion sensors, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor can adjust the brightness of the display panel 1641 according to the brightness of the ambient light, and the proximity sensor can turn off the display panel 1641 and / or the backlight when the operating terminal 1600 is moved to the ear. As a type of motion sensor, the gravity acceleration sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that recognize the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc. As for other sensors that can be configured on the operating terminal 1600, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they are not described here.

[0165] Video circuit 1660, speaker 1661, and microphone 1662 provide a video interface between the user and console 1600. Audio circuit 1660 converts received audio data into electrical signals and transmits them to speaker 1661, which then converts them into sound signals for output. Microphone 1662, on the other hand, converts collected sound signals into electrical signals, which are then received by audio circuit 1660 and converted into audio data. The audio data is then processed by processor 1680 and transmitted via RF circuit 1610 to, for example, another console, or to memory 1620 for further processing. Audio circuit 1660 may also include an earphone jack to allow communication between external headphones and console 1600.

[0166] WiFi is a short-range wireless transmission technology. The operating terminal 1600 can help users send and receive emails, browse web pages, and access streaming media through the WiFi module 1670. It provides users with wireless broadband Internet access. Figure 8 A WiFi module 1670 is shown, but it is understandable that it is not an essential component of the operating terminal 1600 and can be omitted as needed without changing the essence of the invention.

[0167] Processor 1680 is the control center of operating terminal 1600, connecting all components of the phone using various interfaces and circuits. By running or executing software programs and / or modules stored in memory 1620 and accessing data stored in memory 1620, it executes various functions of operating terminal 1600 and processes data, thereby providing overall control of the phone. Optionally, processor 1680 may include one or more processing cores; preferably, processor 1680 may integrate an application processor and a modem processor, with the application processor primarily handling the operating system, user interface, and application programs, while the modem processor primarily handles wireless communications. It is understood that the modem processor may not be integrated into processor 1680.

[0168] The operating terminal 1600 also includes a power supply 160 (e.g., a battery) for powering each component. Preferably, the power supply can be logically connected to the processor 1680 via a power management system, thereby enabling management of charging, discharging, and power consumption management functions through the power management system. The power supply 160 can also include any components such as one or more DC or AC power supplies, a recharging system, a power failure detection circuit, a power converter or inverter, and a power status indicator. Although not shown, the operating terminal 1600 can also include a Bluetooth module, etc., which will not be described in detail herein.

[0169] Specifically, in this embodiment, the operating terminal 1600 further includes a memory and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by one or more processors. The one or more programs include instructions for executing the test case determination method provided in the above method embodiment.

[0170] An embodiment of the present application also provides a server, which includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to implement the test case determination method provided in the above method embodiment.

[0171] The memory can be used to store software programs and modules. The processor executes the software programs and modules stored in the memory to perform various functional applications and detect abnormal behavior. The memory may mainly include a program storage area and a data storage area. The program storage area can store the operating system, application programs required for functions, etc.; the data storage area can store data created based on the use of the device. In addition, the memory may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.

[0172] Figure 9 This is a hardware structure diagram of a server provided in an embodiment of the present application. Figure 9As shown, the server 1700 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 1710 (the processor 1710 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 1730 for storing data, and one or more storage media 1720 (such as one or more mass storage devices) for storing application programs 1723 or data 1722. Among them, the memory 1730 and the storage medium 1720 can be temporary storage or permanent storage. The program stored in the storage medium 1720 may include one or more modules, each module may include a series of instruction operations on the server. Furthermore, the central processing unit 1710 can be configured to communicate with the storage medium 1720 to execute a series of instruction operations in the storage medium 1720 on the server 1700. The server 1700 may also include one or more power supplies 1760, one or more wired or wireless network interfaces 1750, one or more input and output interfaces 1740, and / or one or more operating systems 1721, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0173] The input / output interface 1740 can be used to receive or send data via a network. Specific examples of the aforementioned network may include a wireless network provided by the communication provider of the server 1700. In one embodiment, the input / output interface 1740 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In another embodiment, the input / output interface 1740 can be a radio frequency (RF) module for wirelessly communicating with the Internet.

[0174] It can be understood by those skilled in the art that Figure 9 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 9 More or fewer components than shown, or with Figure 9 Different configurations shown.

[0175] The present application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor on an operating terminal reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the operating terminal to perform the test case determination method in the above-mentioned method embodiment; or a processor on a server terminal reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the server terminal to perform the test case determination method on the server side in the above-mentioned method embodiment.

[0176] The embodiments of the present application further provide a non-transitory computer-readable storage medium including instructions, such as a memory including instructions, wherein the instructions can be executed by a processor of an operation terminal to complete the various steps of the operation terminal side in the above method embodiment, or the instructions can be executed by a processor of a service terminal to complete the various steps of the service terminal side in the above method embodiment. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0177] It should be noted that the order of the embodiments of the present application described above is for descriptive purposes only and does not represent the superiority or inferiority of the embodiments. The above description is of specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described 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 accompanying 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.

[0178] The various embodiments in this application are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences from other embodiments. In particular, the device embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the partial description of the method embodiments.

[0179] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or may be accomplished by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0180] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for determining a test case, characterized in that: The method comprises: In response to a test case generation instruction for a target background service, a target use case metadata group corresponding to the target background service in a use case metadata set is obtained; the use case metadata set includes a plurality of use case metadata groups corresponding one-to-one to a plurality of background services, the target background service is any one of the plurality of background services, the programming languages ​​of the plurality of background services are not completely the same, the plurality of use case metadata groups are used to define call parameters of the plurality of background services in a unified preset data format; the plurality of use case metadata groups are obtained by parsing log information corresponding to each of the plurality of subscribed background services, the log information being used to indicate call information recorded by the corresponding background service during a historical call process; A target test case set corresponding to the target background service is determined according to the test case generation instruction and the target test case metadata group.

2. The method according to claim 1, characterized in that The method further comprises: Subscribe to the log information corresponding to each of the multiple backend services; Determining a log parsing grammar that matches the log information corresponding to each background service according to the log format of the log information corresponding to each background service; The log information corresponding to each background service is parsed according to the matched log parsing grammar to obtain a use case metadata group corresponding to each background service.

3. The method according to claim 2, characterized in that The log parsing grammar is a first parsing grammar for a key-value pair format. The log information corresponding to each backend service is parsed and processed according to the matched log parsing grammar to obtain a use case metadata group corresponding to each backend service, including: When the log format of the log information is the key-value pair format, based on the first parsing grammar, a first use case metadata group is extracted from the log information, and the first use case metadata group includes at least one first parameter field and at least one group of first parameter attribute data, and the at least one first parameter field corresponds one-to-one to the at least one group of first parameter attribute data.

4. The method according to claim 2, characterized in that The log parsing grammar is a second parsing grammar for a delimiter format. The log information corresponding to each background service is parsed and processed according to the matched log parsing grammar to obtain a use case metadata group corresponding to each background service, including: When the log format of the log information is the delimiter format, dividing the log information according to the delimiters in the log information based on the second parsing grammar to obtain first candidate log data of a key-value pair structure; A second use case metadata group corresponding to the log information is extracted from the first candidate log data, wherein the second use case metadata group includes at least one second parameter field and at least one group of second parameter attribute data, and the at least one second parameter field corresponds one-to-one to the at least one group of second parameter attribute data.

5. The method according to claim 2, characterized in that The log parsing grammar includes a first parsing grammar for a key-value pair format and a second parsing grammar for a delimiter format. The log information corresponding to each backend service is parsed according to the matched log parsing grammar to obtain a use case metadata group corresponding to each backend service, including: In a case where the log format of the log information includes the key-value pair format and the separator format, performing nested parsing on the log information based on the first parsing grammar and the second parsing grammar to obtain second candidate log data of a key-value pair structure; A third use case metadata group corresponding to the log information is extracted from the second candidate log data, wherein the third use case metadata group includes at least one third parameter field and at least one group of third parameter attribute data, and the at least one third parameter field corresponds one-to-one to the at least one group of third parameter attribute data.

6. The method according to any one of claims 1 to 5, characterized in that The step of determining a target test case set corresponding to the target background service according to the test case generation instruction and the target test case metadata group includes: Determining request address data according to the test case generation instruction, wherein the request address data indicates a use case execution environment; Traversing log information corresponding to the target backend service, the log information including request body data of multiple request records; Generate a target test case according to the request address data, the currently traversed request body data, and at least one target parameter field and at least one set of target parameter attribute data in the target test case metadata group; When the traversal is completed, the target test case set consisting of at least one target test case is obtained.

7. The method according to any one of claims 1 to 5, characterized in that The step of determining a target test case set corresponding to the target background service according to the test case generation instruction and the target test case metadata group includes: Determining request address data according to the test case generation instruction, wherein the request address data indicates a use case execution environment; Obtain a set of historical test cases corresponding to the target backend service; At least one historical test case in the historical test case set is updated according to the request address data and at least one target parameter field and at least one set of target parameter attribute data in the target use case metadata group to obtain the target test case set.

8. The method according to claim 2, characterized in that The subscribing to log information corresponding to each of the multiple background services includes: Based on the preset reporting mechanism, obtain the log information of the current cycle reported by the log storage server corresponding to each background service; Alternatively, based on a preset proxy server, the log information of the current period is pulled from the log storage corresponding to each background service.

9. A device for determining a test case, characterized in that: The device comprises: an acquisition module configured to, in response to a test case generation instruction for a target background service, acquire a target use case metadata group corresponding to the target background service in a use case metadata set; the use case metadata set includes a plurality of use case metadata groups corresponding one-to-one to a plurality of background services, the target background service being any one of the plurality of background services; the programming languages ​​of the plurality of background services are not identical, the plurality of use case metadata groups being used to define call parameters of the plurality of background services in a unified preset data format; the plurality of use case metadata groups being obtained by parsing log information corresponding to each of the plurality of subscribed background services, the log information being used to indicate call information recorded by the corresponding background service during a historical call process; The test case determination module is used to determine a target test case set corresponding to the target background service according to the test case generation instruction and the target test case metadata group.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by a processor to implement a test case determination method as described in any one of claims 1 to 8.

11. A computer device, characterized in that: The computer device includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement a test case determination method as described in any one of claims 1 to 8.

12. A computer program, comprising computer instructions, wherein the computer instructions are loaded and executed by a processor to implement the test case determination method according to any one of claims 1 to 8.

Images