Test case generation method, system and equipment

Abstract

The invention discloses a test case generation method, system and equipment, and the method comprises the steps: periodically calling a target data interface of an automatic test platform, and obtaining an initial method list of an open service platform; querying a use case tree structure of the automatic test platform, and screening a to-be-tested interface list according to a query result and the initial method list; performing grammar analysis on each to-be-tested method corresponding to the to-be-tested interface list, respectively determining multiple target fields and integrating the target fields into multiple groups of structured method features; calling the large language model to generate at least one group of test case data according to each group of structured method features, and verifying the test case data; and pushing the verified target test case data to the automatic test platform, and creating a corresponding target test case on the automatic test platform. By combining double analysis of a large language model and grammatical analysis, the data required by the test case and the test case are quickly generated, and the quick iteration requirement of the service is effectively met.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of use case generation, and in particular to a test case generation method, system and device. BACKGROUND

[0002] With the deepening of digital transformation, Java language is widely used in enterprise-level development. The Open Service Platform (OSP) service based on Java has become the core of multi-field system architecture due to its high scalability and cross-platform characteristics. As a key means to ensure software quality, automated testing can greatly improve testing efficiency and reduce labor costs, and has become an indispensable part of the OSP service development process.

[0003] Currently, Java OSP service interfaces are numerous, complex in logic, and generic parameters frequently appear. Traditional testing requires manual interface sorting, code analysis, case design, and creation in the testing system, which is tedious, repetitive, and inefficient, and cannot adapt to the rapid iteration requirements of services. SUMMARY

[0004] The present application provides a test case generation method, system and device, which solves the technical problem that traditional testing requires manual interface sorting, code analysis, case design, and creation in the testing system, which is tedious, repetitive, and inefficient, and cannot adapt to the rapid iteration requirements of services.

[0005] The first aspect of the present application provides a test case generation method, comprising:

[0006] Periodically calling a target data interface of an automated testing platform to obtain an initial method list of an open service platform;

[0007] Querying a case tree structure of the automated testing platform, and filtering a to-be-tested interface list according to the query result and the initial method list;

[0008] Performing syntax analysis on each to-be-tested method corresponding to the to-be-tested interface list, respectively determining a plurality of target fields and integrating them into a plurality of groups of structured method features;

[0009] Calling a large language model to respectively generate at least one group of test case data according to each group of structured method features and to verify;

[0010] Pushing the target test case data that passes the verification to the automated testing platform, and creating a corresponding target test case in the automated testing platform.

[0011] Optionally, the step of querying the case tree structure of the automated testing platform and filtering the to-be-tested interface list according to the query result and the initial method list comprises:

[0012] querying a use case tree structure of the automated testing platform to determine a list of tested methods corresponding to the tested use cases;

[0013] selecting a method from the initial method list that is not in the list of tested methods as a to-be-tested method;

[0014] integrating an interface group to which the to-be-tested method belongs to construct a to-be-tested interface list.

[0015] Optionally, the target field includes a parameter type field and a non-parameter type field; the step of performing syntax analysis on each to-be-tested method corresponding to the to-be-tested interface list to determine a plurality of target fields and integrate them into a plurality of groups of structured method features respectively, includes:

[0016] According to each to-be-tested interface in the to-be-tested interface list, the corresponding to-be-tested method is retrieved respectively;

[0017] According to each to-be-tested method, the corresponding project source code is located;

[0018] Traverse the syntax structure of each project source code, build and cache the corresponding abstract syntax tree respectively;

[0019] Call the code parser to parse the abstract syntax tree to determine the tree node corresponding to each to-be-tested method;

[0020] Extract the parameter type field and a plurality of non-parameter type fields from the tree node respectively;

[0021] Recursively analyze the parameter type field to construct a complete parameter field;

[0022] Integrate the complete parameter field and various non-parameter type fields according to a preset data format respectively to generate a plurality of groups of structured method features.

[0023] Optionally, the step of calling the large language model to generate at least one group of test case data according to each group of structured method features and verifying, includes:

[0024] Call the large language model to perform semantic conversion on each group of structured method features to generate a plurality of groups of simplified method features;

[0025] After loading each group of simplified method features into a preset prompt word template, a plurality of structured prompts are generated by rendering;

[0026] Call the large language model to perform code semantic analysis on each structured prompt to generate at least one group of test case data respectively; wherein the test case data includes a test case title, a test case description, and a test case parameter;

[0027] The preset verification model is called to perform structured verification on each group of test case data, and test case data that passes the structured verification is determined as target test case data, and test case data that fails the structured verification is deleted.

[0028] Optionally, the step of pushing the target test case data that passes the verification to the automation test platform includes:

[0029] Detecting, from the automation test platform, whether there is a method directory node corresponding to the target test case data that passes the verification;

[0030] If there is, the target test case data is pushed to the automation test platform in batches and mounted in the method directory node;

[0031] If there is not, a method directory node corresponding to the target test case data is created in the automation test platform, and the target test case data is pushed to the automation test platform in batches and mounted in the method directory node;

[0032] A case creation interface of the automation test platform is called, and a target test case corresponding to the target test case data is created.

[0033] Optionally, the method further includes:

[0034] If the target test case data in any batch fails to be pushed, the target test case data in the batch is pushed to the automation test platform again;

[0035] If any target test case fails to be created or the case creation interface fails to be called, abnormal information at a current time is collected;

[0036] If the abnormal information is network abnormality, the case creation interface is called again according to an exponential backoff retry strategy;

[0037] If the abnormal information is business abnormality, the target test case in the current batch is stopped from being created;

[0038] If the abnormal information is system abnormality, the case creation interface is called again after a preset time period, and alarm information is sent to a preset monitoring end.

[0039] Optionally, the method further includes:

[0040] After the test case is pushed to the automation test platform, the test case is marked as a manual execution type, and the case tree structure is updated;

[0041] The step of jumping to the target data interface of the periodic calling automation test platform to obtain the initial method list of the open service platform.

[0042] Optionally, the method further comprises:

[0043] Real-time operation information of each step is collected and loaded into a preset log template to generate a full-process log.

[0044] The second aspect of the application provides a test case generation system, comprising:

[0045] A method list acquisition module is configured to periodically call a target data interface of an automation test platform to obtain an initial method list of an open service platform.

[0046] An interface list screening module is configured to query a case tree structure of the automation test platform and screen a to-be-tested interface list according to a query result and the initial method list.

[0047] A structured method feature generation module is configured to perform syntax analysis on each to-be-tested method corresponding to the to-be-tested interface list, determine a plurality of target fields respectively, and integrate the plurality of target fields into a plurality of groups of structured method features.

[0048] A case data generation module is configured to call a large language model to generate at least one group of test case data according to each group of structured method features and perform verification.

[0049] A case creation module is configured to push target test case data that passes the verification to the automation test platform and create a corresponding target test case in the automation test platform.

[0050] The third aspect of the application provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the computer program is executed by the processor to make the processor execute the steps of the test case generation method according to any one of the first aspect of the application.

[0051] As can be seen from the above technical solutions, the application has the following advantages:

[0052] The application acquires an initial method list of an open service platform by periodically calling a target data interface of an automated test platform, queries a use case tree structure of the automated test platform, filters a to-be-tested interface list according to a query result and the initial method list, performs syntax analysis on each to-be-tested method corresponding to the to-be-tested interface list, respectively determines a plurality of target fields and integrates them into a plurality of groups of structured method features, respectively generates at least one group of test case data according to each group of structured method features by calling a large language model and verifies the test case data, pushes the target test case data that passes the verification to the automated test platform, and creates a corresponding target test case in the automated test platform. Through the dual analysis of the large language model and the syntax analysis, the required data and test cases for test case generation are quickly generated, and the service rapid iteration requirement is effectively adapted. BRIEF DESCRIPTION OF DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0054] Figure 1 A step flow chart of a test case generation method provided for an embodiment of the present application;

[0055] Figure 2 A code schematic diagram of a structured method feature provided for an embodiment of the present application;

[0056] Figure 3 Another code schematic diagram of a structured method feature provided for an embodiment of the present application;

[0057] Figure 4 A structural block diagram of a test case generation system provided for an embodiment of the present application. DETAILED DESCRIPTION

[0058] The embodiments of the present application provide a test case generation method, system and device, which are used to solve the technical problem that the traditional test needs manual interface carding, code analysis, case design and creation in a test system, the process is tedious, repetitive, inefficient, and difficult to adapt to the service rapid iteration requirement.

[0059] In order to make the application purposes, features and advantages of the present application more obvious and easy to understand, the technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the accompanying drawings of the embodiments of the present application. Obviously, the following described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

[0060] Please refer to Figure 1 , Figure 1 A step flow chart of a test case generation method provided by the embodiment of the present application.

[0061] The test case generation method provided by the present application is applied to an automated test platform, and the method comprises the following steps:

[0062] In step 101, a target data interface of the automated test platform is periodically called to obtain an initial method list of an open service platform.

[0063] The automated test platform refers to an ATP system, which is an integrated platform for carrying test case management, test execution, test result statistics and other functions.

[0064] The target data interface refers to a standardized API (Application Programming Interface) provided by the automated test platform for outputting related method data of the open service platform to the outside, supporting data query and acquisition.

[0065] The open service platform refers to an OSP, which is a technical platform for providing various open service methods.

[0066] The initial method list refers to a complete list containing all registered service methods obtained from the open service platform, covering basic identification information such as method name and interface path.

[0067] In the embodiment of the application, by configuring a periodic scheduling mechanism, the calling period is set based on the demand of the service for the real-time of data, the target data interface authorization information of the integrated automated test platform is used, and the authentication token is cached by using the Token caching mechanism to reduce the repeated login overhead. Subsequently, the interface calling request is automatically initiated according to the preset period, the abnormal retry mechanism is realized in the interface calling process to deal with the network fluctuation or platform response delay problem, the data returned by the target data interface is received and parsed after successful calling, all service method information of the open service platform is extracted, the initial method list is formed by integration and stored in the local cache or the specified database, and the data basis is provided for the subsequent screening operation.

[0068] In addition, the calling period of the target data interface can also be adaptively adjusted based on the method update frequency of the open service platform to balance the data real-time and platform resource overhead. Meanwhile, the open service platform native interface and the target data interface of the automated test platform can be called simultaneously, consistency verification is performed on the two groups of data, if there is a difference, an alarm is triggered and the data of the open service platform native interface is used as the reference, and the accuracy of data acquisition is improved. Meanwhile, only the method data newly added or changed in the last period to the current period can be obtained each time the interface is called, rather than full-amount acquisition, and the data transmission amount and storage pressure are reduced.

[0069] Step 102, querying the case tree structure of the automated test platform, and screening the to-be-tested interface list according to the query result and the initial method list;

[0070] The case tree structure refers to a hierarchical data structure for organizing and managing test cases in the automated test platform, which presents the method directory, the association relationship between the created test cases and the corresponding methods in a tree form.

[0071] In the embodiment, the complete case tree structure data of the automated test platform is queried by calling the query interface of the automated test platform, the structure is parsed to extract the list of tested methods corresponding to all created test cases, the list is compared with the initial method list, the difference set calculation is performed to screen out the methods not covered by the created test cases, and then the to-be-tested interface list associated with the methods is generated.

[0072] Among them, the generation of the above-mentioned to-be-tested interface list can also support manual interactive confirmation operation, allowing the staff to supplement the screening result or eliminate invalid interfaces, finally determining the formal to-be-tested interface list and recording the related screening log.

[0073] In addition, a multi-level screening mechanism can also be referred to, after the difference set screening, in combination with the historical test defect data, the methods with high defect rates or prone to problems are preferentially included in the to-be-tested list, and the interfaces marked as not needing to be tested such as internal debugging interfaces are proposed, so as to realize the optimization of the screening result.

[0074] In one example of the present application, step 102 can include the following sub-steps:

[0075] Query the use case tree structure of the automated test platform to determine the list of tested methods corresponding to the tested use cases;

[0076] Select a method from the initial method list that is not in the tested method list as a method to be tested;

[0077] Integrate the interface groups to which the method to be tested belongs to construct a list of interfaces to be tested.

[0078] A tested use case refers to a use case instance that has been created and can perform test operations in the automated test platform, and has a unique mapping relationship with a specific method of an OSP service.

[0079] A tested method list refers to a set of OSP service methods that have been associated with corresponding tested use cases, extracted from the ATP use case tree structure, and includes core association information such as method identification and name.

[0080] A method to be tested refers to an OSP service method in the initial method list that is not covered by the tested method list and for which a corresponding test case has not been created.

[0081] An interface group refers to a classification and division of OSP service methods according to a predetermined rule (such as a business module, a function type, etc.), and interfaces within the same group have similar business attributes or functional characteristics.

[0082] In this embodiment, a use case tree structure query request is initiated by calling a query interface of the ATP system, authentication tokens are reused to reduce login overhead using a Token caching mechanism, the returned complete use case tree structure data is parsed, all created test use case nodes are traversed, corresponding service method identification and name information is extracted, and after removing duplicate data, a tested method list is formed. Then, the tested method list and the initial OSP service method list obtained earlier are compared in both directions to calculate the difference set, automatically identify service methods that do not appear in the tested method list as methods to be tested, and mark the associated information of each method to be tested such as the business module and the function type. Finally, according to the predetermined configurable interface grouping rule, the methods to be tested with the same grouping attribute are classified into one category, a reasonable grouping structure is constructed, the grouping rationality is automatically verified during the process to avoid the same method being repeatedly classified, and finally a structured interface list to be tested is formed, which includes grouping information and complete information of the methods to be tested, to support manual interactive confirmation and optimization.

[0083] Step 103, perform syntax analysis on each method to be tested corresponding to the list of interfaces to be tested, determine multiple target fields respectively, and integrate them into multiple groups of structured method features;

[0084] The to-be-tested method refers to a method code corresponding to each to-be-tested interface in the to-be-tested interface list.

[0085] The target field refers to a core information field related to test case generation in the to-be-tested method, including a method signature, a parameter structure, a return type, generic information, a parameter class field structure and the like.

[0086] The structured method feature refers to structured data formed by integrating the extracted multiple target fields according to a preset standardized format, which can comprehensively and clearly describe the technical features of the to-be-tested method.

[0087] In the embodiment, by loading the Java project source code corresponding to the to-be-tested interface list, an abstract syntax tree cache is established to improve the parsing efficiency, a depth syntax analysis is performed on each to-be-tested method by using the javalang library, the method signature, the parameter structure, the return type, the generic information and the like target fields are sequentially extracted, the recursive analysis mode is used for the parameter class, the internal field structure and the field type information thereof are disassembled, all the extracted target fields are integrated according to the preset structured format, the redundant information is removed and the field association description is supplemented, and finally multiple groups of structured method features corresponding to the to-be-tested methods are formed, so that each group of features can fully reflect the core technical properties of the corresponding method.

[0088] In addition, a syntax analysis library such as the ast library of Python can be added to perform syntax analysis on multiple mainstream server languages, so as to realize the structured feature extraction of the method of the multi-language open service platform. In addition, a dynamic field supplement mechanism is introduced to supplement the fields such as the parameter description and the business scenario description which are not extracted in the syntax analysis process in combination with the interface document of the open service platform, so as to enrich the integrity of the structured method feature.

[0089] In an example of the present application, the target field includes a parameter class field and a non-parameter class field; and step 103 can include the following sub-steps:

[0090] According to each to-be-tested interface in the to-be-tested interface list, the corresponding to-be-tested method is retrieved;

[0091] According to each to-be-tested method, the corresponding project source code is located;

[0092] The syntax structure of each project source code is traversed, and the corresponding abstract syntax tree is constructed and cached;

[0093] The abstract syntax tree is parsed by calling the code parser to determine the tree node corresponding to each to-be-tested method;

[0094] The parameter class field and multiple non-parameter class fields are extracted from the tree node;

[0095] Recursive analysis is performed on the parameter type field to construct a complete parameter field;

[0096] The complete parameter field and various non-parameter type fields are integrated according to a preset data format to generate multiple sets of structured method features.

[0097] The interface to be tested refers to an OSP service interface that has been screened and determined and for which a corresponding test case has not yet been created. The method to be tested refers to a specific service implementation method belonging to the interface to be tested and is the direct target of test case generation, containing complete code logic and data interaction rules. The project source code refers to the engineering source code file corresponding to the Java OSP service, containing complete implementation code, class definition, and dependency reference of the method to be tested, and other core information. The abstract syntax tree (AST) is a hierarchical tree data structure formed by parsing the Java source code according to the syntax rules, which can clearly present the syntax composition and logical association of the code. The code parser refers to a tool or library with Java syntax parsing capability (such as the javalang library mentioned in the document), which can traverse and analyze the AST and extract the target syntax node information.

[0098] In this embodiment, the corresponding test case has not yet been created. The method to be tested refers to a specific service implementation method belonging to the interface to be tested and is the direct target of test case generation, containing complete code logic and data interaction rules. The project source code refers to the engineering source code file corresponding to the Java OSP service, containing complete implementation code, class definition, and dependency reference of the method to be tested, and other core information. The abstract syntax tree (AST) is a hierarchical tree data structure formed by parsing the Java source code according to the syntax rules, which can clearly present the syntax composition and logical association of the code. The code parser refers to a tool or library with Java syntax parsing capability (such as the javalang library mentioned in the document), which can traverse and analyze the AST and extract the target syntax node information.

[0099] The javalang library and other code parsers are called to perform deep traversal on the cached abstract syntax tree, accurately match and determine the target tree node corresponding to each method to be tested, and extract the parameter type field and method signature, return type, generic information, and other non-parameter type fields from the tree node. Recursive analysis is performed on the parameter type field to construct a complete parameter field, and the complete parameter field and various non-parameter type fields are integrated according to a preset standardized data format to generate multiple sets of structured method features corresponding to each method to be tested, ensuring that the feature information fully reflects the syntax and logical properties of the method to be tested.

[0100] Among them, the structured method features generated according to the project source code can be as shown in Figure 2 and Figure 3 As shown in Figure 2As shown, the getQaChildListById method of the AcsServiceimpl class parsing process is: first, extract the core identification from the Java code, determine the target class (aim_class) as AcsServiceimpl, and the target method name (aim_method) as getQaChildListById; then integrate the access modifier, return type, method name, parameter list and method body placeholder of the method to generate the method_def field, the content is public List <record>getQaChildListById(List <long>idList){ / / Method implementation...}; Finally, parse the parameter list (param_list) for the unique parameter idList, and specify its parameter name (name) as idList, parameter type (type) as List, and generic type (generic_type) as Long. Since this parameter is a basic generic collection type, there is no custom DTO or struct field, so the struct is empty.

[0101] As shown in Figure 3 , the queryUser method of the UserService class parses the process as follows: First, extract the core identifier from the Java code to determine the target class (aim_class) as UserService and the target method name (aim_method) as queryUser. Then, integrate the method signature and method body placeholder to generate the method_def field. Taking the actual method signature as an example, the content is:

[0102] publicUserVOqueryUser(QueryRequestqueryRequest){ / / Method implementation...}

[0103] Finally, parse the parameter list (param_list) for the parameter queryRequest (DTO class type), and specify its parameter name (name) as queryRequest, parameter type (type) as QueryRequest. Since this parameter is a custom DTO class rather than a generic collection, the generic type (generic_type) is empty. At the same time, enumerate all fields and types of the DTO class, and fill in the struct (struct) as StringuserId, StringuserName, Integerage, Listtags.

[0104] Step 104, call the large language model to generate at least one set of test case data according to the characteristics of each group of structured methods and verify;

[0105] Large language model refers to an artificial intelligence model with strong natural language processing and logical reasoning capabilities, such as OpenAI-compatible large language models, which can generate text content that meets requirements based on input structured information.

[0106] Test case data refers to relevant data used to test open service platform methods, including test case title, test description, test parameters, expected results, and other core content.

[0107] In this embodiment, the large language model is called to generate a corresponding prompt word based on each set of structured method features, and the content of the prompt word template corresponding to the test case is rendered to generate a corresponding prompt word. The dynamically rendered prompt word is input to the large language model to generate at least one set of test case data including a test case title, a description, test parameters, and expected results. At the same time, the Pydantic model is called to structure and verify the generated test case data, check whether the format is compliant, whether the parameters match the method features, and whether the logic is self-consistent, and filter out the test case data that passes the verification as the target test case data.

[0108] It should be noted that multiple large language models of different types such as logic models and scene models can be called to generate test case data, and multiple sets of test case data can be fused and optimized to improve the scene adaptability of the test case. In addition, the business attributes in the structured method features can be combined to associate with general test scenes such as abnormal input scenes, boundary value scenes, or high-concurrency scenes in corresponding industries, so as to guide the large language model to generate targeted scene-based test cases and cover more potential test points.

[0109] In one example of the present application, step 104 can include the following sub-steps:

[0110] The large language model is called to perform semantic conversion on each set of structured method features to generate multiple sets of simplified method features.

[0111] After loading each set of simplified method features into the preset prompt word template, multiple structured prompt words are rendered and generated.

[0112] The large language model is called to perform code semantic analysis on each structured prompt word to generate at least one set of test case data, wherein the test case data includes a test case title, a test case description, and test case parameters.

[0113] A preset verification model is called to perform structured verification on each set of test case data, and test case data that passes the structured verification is determined as target test case data, and test case data that fails the structured verification is deleted.

[0114] Simplified method features refer to core attributes of the method to be tested, such as key parameters, functional purposes, and return logic.

[0115] Prompt word template refers to a template file with a preset input format and instruction logic built based on the LangChain framework.

[0116] In this embodiment, a large language model compatible with OpenAI is called to input each group of structured method features into the model for semantic conversion, extract core semantics and remove redundant technical descriptions, and generate multiple groups of lightweight simplified method features. Then each group of simplified method features is loaded into a preset prompt template based on the LangChain framework, the simplified method features are dynamically filled by the Jinja2 template engine, and multiple structured prompts containing clear generation instructions and core input information are rendered. The above-mentioned large language model is called again to perform code semantic analysis on each structured prompt, and at least one group of test case data containing test case title, test case description and test case parameters is generated based on the functional logic and parameter constraints of the method to be tested.

[0117] Finally, a preset Pydantic validation model is called to perform structured validation on each group of test case data according to standardized rules, check field integrity, format compliance and logical consistency, determine the data that passes the validation as target test case data, automatically delete the test case data that fails the validation, and record the validation result log.

[0118] It should be noted that the prompt template can include a system prompt part and a user prompt part. The system prompt part positions the role of the large language model as a test engineer, whose goal is to design test cases for the executed interface function to cover the main link, while giving key information such as method name, complete method definition, parameter rules, etc. of the test object, as well as the number of test cases generated. The user prompt part limits the return result to be a JSON object, and the root node of the JSON object includes a specific array, and each test case object in the specific array fixedly contains three fields such as test case title, test case description and test case parameter.

[0119] Step 105, push the target test case data that passes the validation to the automated test platform, and create the corresponding target test case in the automated test platform.

[0120] The target test case data refers to the test case data that passes the validation. The target test case refers to the test case instance automatically generated by the automated test platform according to the platform's case management rules after receiving the target test case data. It can be managed in the case tree structure.

[0121] In the embodiment, first, the target test case data is batched, the data format is formatted according to the interface requirements of the automation test platform, then an HTTP API call (addCaseByAtp) is initiated, the target test case data after the arrangement is pushed to the automation test platform in batches, the idempotent directory creation mechanism is realized in the pushing process, it is intelligently detected whether the method directory node corresponding to the test case to be created exists, if it exists, it is directly reused, if it does not exist, it is automatically created, at the same time, the problems such as concurrent creation conflict, network exception caused pushing failure and the like are handled, the data pushing success rate is ensured through the failure retry mechanism, the pushing progress and the creation result are fed back in real time, after the target test case is successfully created in the automation test platform, the local log record creation details are updated.

[0122] It should be noted that the batch interval set by the batch pushing of the target test case data can be divided according to the number of target test case data and the interface bearing capacity of the automation test platform, so as to avoid interface congestion or timeout caused by too large data volume of single data pushing, thereby improving the pushing efficiency.

[0123] In addition, the target test case can also be assigned a priority (such as high, medium and low) based on the business importance weight in the structured method feature and the historical test data, and the priority information is carried synchronously when pushed to the platform, the platform manages the test cases according to the priority, and the test personnel can execute the high-priority cases preferentially.

[0124] In an example of the present application, step 105 can include the following sub-steps:

[0125] Detecting whether the method directory node corresponding to the target test case data passing the verification exists from the automation test platform;

[0126] If it exists, the target test case data is pushed to the automation test platform in batches and mounted in the method directory node;

[0127] If it does not exist, the method directory node corresponding to the target test case data is created in the automation test platform, the target test case data is pushed to the automation test platform in batches and mounted in the method directory node;

[0128] The case creation interface of the automation test platform is called, and the corresponding target test case is created according to the target test case data.

[0129] The method directory node refers to the node element in the case tree structure of the automation test platform for hierarchical classification management of test cases, which corresponds to the business module and function classification of the method of the OSP service.

[0130] The use case creation interface refers to a standardized HTTP API (such as the addCaseByAtp interface) provided by the ATP system, which supports receiving compliant test case data and completing the automated creation of test cases.

[0131] In the embodiment, the directory node query interface of the ATP system is called, and the information such as the business module and the function classification to which the to-be-tested method corresponding to the target test case data belongs is combined to detect whether a matching method directory node exists in the ATP case tree structure. In the detection process, the token caching mechanism is used to reuse the authentication token to reduce the login overhead. If it is detected that the method directory node already exists, the target test case data is split according to a preset batch based on the node identifier, a data push request is initiated to the ATP system in batches, and each batch of test case data is accurately mounted to the existing directory node. If the corresponding method directory node is not detected, an idempotent creation operation is performed to generate a hierarchical method directory node matched with the to-be-tested method in the ATP case tree structure, to avoid repeated creation, and then the target test case data is pushed to the ATP system in batches and mounted to the newly created directory node. After the pushing is completed, the use case creation interface (addCaseByAtp) of the ATP system is automatically called, the mounted target test case data is input, and abnormal situations such as creation conflict and network fluctuation are handled. The failure retry mechanism is used to ensure the success rate of case creation, and the creation progress is fed back in real time and the whole operation log is recorded.

[0132] In addition, the operation permission (such as creation and editing permission) of the current operation account to the target directory node can also be verified before the test case is created or mounted. When there is no permission, an alarm is triggered and permission application is supported, to ensure the security of platform data. At the same time, after each batch of data is pushed and the case is created, the ATP system returns the execution result in real time, and the local system synchronously updates the push state, the creation state and the ATP system case ID of the corresponding test case, to form a data trace link.

[0133] In another example of the present application, step 105 can further include the following sub-steps:

[0134] If the target test case data of any batch fails to be pushed, the target test case data of the batch is pushed to the automated test platform again;

[0135] If any target test case fails to be created, or the use case creation interface fails to be called, the abnormal information at the current time is collected;

[0136] If the abnormal information is a network exception, the use case creation interface is called again according to an exponential backoff retry strategy;

[0137] If the abnormal information is a business exception, the creation of the target test case of the current batch is stopped;

[0138] If the abnormal information is a system exception, the use case creation interface is called again after a preset period of time, and alarm information is sent to a preset monitoring end.

[0139] The exponential backoff retry strategy refers to a strategy in which the retry interval increases exponentially when the interface is retried, i.e., the time interval of each retry is a multiple of the previous time interval, which is used to avoid additional pressure on the system caused by frequent retries and to improve the success rate of retries.

[0140] Abnormal information refers to error-related information generated during the target test case pushing, creating process, or when the use case creation interface is called, including exception type, error code, error description, triggering scenario, etc. Network exceptions include, but are not limited to, environment-related exceptions caused by network link interruption, excessively high network delay, insufficient network bandwidth, etc. Business exceptions include, but are not limited to, operation failures caused by violating business rules or data constraints, such as test case parameters not meeting business specifications, insufficient permissions, etc. System exceptions refer to operation failures caused by system-level problems such as ATP system failures, resource depletion, and interface services not running normally, such as service downtime, database connection failure, etc.

[0141] In this embodiment, during the batch pushing of target test case data, the pushing results of each batch are monitored in real time, and if any batch pushing fails, the retry pushing mechanism of the batch is triggered immediately, and the target test case data of the batch is pushed to the ATP system again.

[0142] When the ATP system use case creation interface (addCaseByAtp) is called to create a target test case, if any target test case creation fails or the interface call fails, the abnormal information (including exception type, error details, operation context, etc.) of the current time is automatically collected; the collected abnormal information is determined by type, if it is determined to be a network exception, the use case creation interface is called multiple times according to the exponential backoff retry strategy until the interface call is successful or the maximum number of retries is reached; if it is determined to be a business exception, the creation operation of the current batch of target test cases is immediately stopped, and the exception details and the list of test cases that are not successfully created are recorded; if it is determined to be a system exception, the use case creation interface is called again after a preset period of time, and alarm information (including exception type, occurrence time, impact scope, etc.) is automatically pushed to a preset monitoring end. The retry process, exception handling results, and alarm information are recorded throughout the process to ensure that the operation is traceable.

[0143] In addition, after collecting business exception information, the ATP system's business rule library can be used to automatically analyze the root cause of the exception and generate targeted correction suggestions (such as parameter adjustment direction, permission application path), which are fed back to relevant personnel, shortening the problem investigation and repair time.

[0144] In another example of the present application, the method can further include the following steps:

[0145] When the test case is pushed to the automated test platform, the test case is marked as a manual execution type, and the case tree structure is updated.

[0146] The jump execution periodically calls the target data interface of the automated test platform to obtain the initial method list of the open service platform.

[0147] The manual execution type refers to the execution mode identifier of the test case, which indicates that the test case needs to be manually triggered by the tester, and is distinguished from the automated execution type, which is suitable for test requirements that require manual judgment results or special scene verification.

[0148] In an embodiment of the present application, when the test case is successfully pushed to the automated test platform and the creation is completed, the case attribute modification interface of the automated test platform is called to uniformly set the execution type field of the batch of test cases as a manual execution type, while carrying associated information such as case ID and marking time; subsequently, the node information of the newly added test case, the execution type identifier, and the association relationship of the directory are synchronized to the ATP case tree through the case tree structure synchronization interface, the real-time update of the case tree structure is completed, and the subsequent query can accurately identify the covered cases; after the update operation is confirmed to be completed, the process automatically jumps to step 101 to wait for the discovery and test case generation process of the uncovered interface in the next period, and the whole process relies on the Token cache mechanism to reduce the login overhead of interface calling.

[0149] In one example of the present application, the method further includes the following steps:

[0150] Real-time collection of operation information of each step and loading to a preset log template to generate a full-process log.

[0151] In the present embodiment, a log collection module can be embedded in each execution step of steps 101-105 described above to capture operation information in the step execution process in real time, including step name, execution start and end time, operation object identifier (such as initial method list ID, interface under test ID, test case ID), interface calling parameter and return result, execution state (success / failure), and exception details (if execution fails). The collected operation information is matched with the fixed fields and variable fields of the preset log template according to the field type, the log content is automatically filled and formatted to ensure the structuring and standardization of the log information; after generating a single-step log, the log data of all steps is integrated according to the process execution order to form a full-process log containing a unique process ID, and the log file supports local storage and ATP system synchronous backup, while recording metadata such as log generation time and log version, which facilitates subsequent retrieval and query according to conditions such as process ID and time range.

[0152] In addition, for log collection, log importance levels such as a debug level, an information level, a warning level, and an error level can be divided, so that a user can configure collection fields of logs at different levels according to requirements, for example, a debug level log retains complete details, and an error level log highlights abnormal information, so as to balance comprehensiveness and lightness of logs.

[0153] It should be understood that, although each step in the flowchart involved in each of the above embodiments is shown in sequence according to the arrow, the steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified herein, the execution of the steps is not strictly limited in sequence, and the steps can be executed in other orders. Moreover, at least part of the steps in the flowchart involved in each of the above embodiments can include multiple steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence of the steps or stages is not necessarily sequential, but can be alternately executed with at least part of other steps or steps or stages in other steps.

[0154] The test case generation system provided by the embodiments of the present application is described below. The test case generation system described below can be correspondingly referred to the test case generation method described above.

[0155] Referring to Figure 4 The embodiments of the present application provide a test case generation system, comprising:

[0156] The method list acquisition module 401 is configured to periodically call a target data interface of an automated test platform to acquire an initial method list of an open service platform.

[0157] The interface list screening module 402 is configured to query a case tree structure of the automated test platform, and screen a to-be-tested interface list according to the query result and the initial method list.

[0158] The structured method feature generation module 403 is configured to perform syntax analysis on each to-be-tested method corresponding to the to-be-tested interface list, respectively determine a plurality of target fields, and integrate the plurality of target fields into a plurality of groups of structured method features.

[0159] The case data generation module 404 is configured to call a large language model to respectively generate at least one group of test case data according to each group of structured method features and perform verification.

[0160] The case creation module 405 is configured to push the target test case data that passes the verification to the automated test platform, and create a corresponding target test case in the automated test platform.

[0161] Optionally, the interface list screening module 402 is specifically configured to:

[0162] query the use case tree structure of the automated test platform to determine a list of tested methods corresponding to the tested use cases;

[0163] select a method not in the list of tested methods from the initial list of methods as a method to be tested;

[0164] integrate the interface groups to which the method to be tested belongs to construct a list of interfaces to be tested.

[0165] Optionally, the target field includes a parameter type field and a non-parameter type field; the structured method feature generation module 403 is specifically configured to:

[0166] According to each interface to be tested in the list of interfaces to be tested, the corresponding method to be tested is retrieved respectively;

[0167] According to each method to be tested, the corresponding project source code is located;

[0168] Traverse the syntax structure of each project source code, respectively construct the corresponding abstract syntax tree and cache;

[0169] Call the code parser to parse the abstract syntax tree to determine the tree node corresponding to each method to be tested;

[0170] Extract the parameter type field and multiple non-parameter type fields from the tree node respectively;

[0171] Recursively analyze the parameter type field to construct a complete parameter field;

[0172] According to a preset data format, the complete parameter field and various non-parameter type fields are integrated respectively to generate multiple groups of structured method features.

[0173] Optionally, the use case data generation module 404 is specifically configured to:

[0174] Call the large language model to perform semantic conversion on each group of structured method features to generate multiple groups of simplified method features;

[0175] After loading each group of simplified method features into a preset prompt word template, multiple structured prompts are rendered and generated;

[0176] Call the large language model to perform code semantic analysis on each structured prompt to generate at least one group of test case data respectively; wherein the test case data includes a test case title, a test case description and a test case parameter;

[0177] Call the preset verification model to perform structured verification on each group of test case data, determine the test case data that passes the structured verification as target test case data, and delete the test case data that fails the structured verification.

[0178] Optionally, the use case creation module 405 is specifically used for:

[0179] detecting, from the automated test platform, whether there is a method directory node corresponding to the target test case data that passes the verification;

[0180] If there is, the target test case data is pushed to the automated test platform in batches and mounted in the method directory node.

[0181] If there is not, a method directory node corresponding to the target test case data is created on the automated test platform, and the target test case data is pushed to the automated test platform in batches and mounted in the method directory node.

[0182] The use case creation interface of the automated test platform is called, and the corresponding target test case is created according to the target test case data.

[0183] Optionally, the use case creation module 405 is specifically used for:

[0184] If the target test case data of any batch fails to be pushed, the target test case data of the batch is pushed to the automated test platform again.

[0185] If any target test case fails to be created or the use case creation interface fails to be called, abnormal information at the current time is collected.

[0186] If the abnormal information is network abnormality, the use case creation interface is called again according to an exponential backoff retry strategy.

[0187] If the abnormal information is business abnormality, the creation of the target test case of the current batch is stopped.

[0188] If the abnormal information is system abnormality, the use case creation interface is called again after a preset period of time, and an alarm information is sent to a preset monitoring end.

[0189] Optionally, the system further includes a periodic monitoring module, which is used for:

[0190] After the test case is pushed to the automated test platform, the test case is marked as a manual execution type, and a case tree structure is updated.

[0191] The step of jumping to execute a target data interface of the automated test platform to obtain an initial method list of the open service platform.

[0192] Optionally, the system further includes a log collection module, which is used for:

[0193] Operation information of each step is collected in real time and loaded to a preset log template to generate a whole-process log.

[0194] The embodiment of the present application provides an electronic device, comprising a memory and a processor, the memory stores a computer program, and the computer program is executed by the processor to make the processor execute the steps of the test case generation method according to any embodiment of the present application.

[0195] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working process of the above-described system and module can refer to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0196] In several embodiments provided by the present application, it should be understood that the disclosed system and method can be implemented by other manners. For example, the system embodiments described above are only schematic, for example, the division of the modules is only a logical function division, and actual implementation can have another division manner, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed systems or modules can be indirect coupling or communication connection through some interfaces, systems or modules, and can be electrical, mechanical or other forms.

[0197] The modules described as separate components can or can not be physically separated, and the components displayed as modules can or can not be physical modules, that is, can be located in one place, or can be distributed on a plurality of network modules. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0198] In addition, the functional modules in each embodiment of the present application can be integrated in one processing module, or each module can exist physically, or two or more modules can be integrated in one module. The integrated module can be realized in the form of hardware or in the form of software functional module.

[0199] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the foregoing embodiments of the present application are described in detail, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalent; and these modifications or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.< / long> < / record>

Claims

1. A test case generation method characterized by, include: Periodically call the target data interface of the automated testing platform to obtain the initial method list of the open service platform; Query the test case tree structure of the automated testing platform, and filter the list of interfaces to be tested according to the query results and the initial method list; Syntax parsing is performed on each method to be tested corresponding to the list of interfaces to be tested, and multiple target fields are determined and integrated into multiple sets of structured method features; The large language model is invoked to generate at least one set of test case data according to the structured method features described in each group, and then the data is verified. The target test case data that has passed the verification is pushed to the automated testing platform, where the corresponding target test cases are created.

2. The test case generation method of claim 1, wherein, The steps of querying the test case tree structure of the automated testing platform and filtering the list of interfaces to be tested according to the query results and the initial method list include: Query the test case tree structure of the automated testing platform to determine the list of tested methods corresponding to the tested test cases; Select methods that are not in the tested methods list from the initial method list as methods to be tested; Integrate the interface groups to which the methods under test belong to construct a list of interfaces to be tested.

3. The test case generation method of claim 1, wherein, The target fields include parameter-type fields and non-parameter-type fields; the step of parsing the syntax of each method to be tested corresponding to the list of interfaces to be tested, determining multiple target fields, and integrating them into multiple sets of structured method features includes: For each interface in the list of interfaces to be tested, retrieve the corresponding method to be tested. Locate the corresponding project source code according to each of the methods to be tested; Iterate through the syntax structure of the source code of each project, construct the corresponding abstract syntax tree, and cache it. The code parser is invoked to parse the abstract syntax tree and determine the tree node corresponding to each method under test. Extract parameter-type fields and various non-parameter-type fields from the tree nodes respectively; Recursively analyze the parameter fields to construct complete parameter fields; The complete parameter fields and various non-parameter fields are integrated according to a preset data format to generate multiple sets of structured method features.

4. The test case generation method of claim 1, wherein, The step of calling the large language model to generate at least one set of test case data according to the structured method features of each group and then verifying it includes: The large language model is invoked to perform semantic transformation on the structured method features of each group, generating multiple groups of simplified method features; After loading the simplified method features of each group into the preset prompt word template, multiple structured prompt words are generated by rendering. The large language model is invoked to perform code semantic analysis on each of the structured prompt words, generating at least one set of test case data; wherein the test case data includes test case title, test case description and test case parameters; The preset verification model is invoked to perform structured verification on the test case data of each group. The test case data that passes the structured verification is determined as the target test case data, and the test case data that fails the structured verification is deleted.

5. The test case generation method according to claim 1, characterized in that, The step of pushing the verified target test case data to the automated testing platform and creating corresponding target test cases on the automated testing platform includes: The automated testing platform is used to detect whether there is a method directory node corresponding to the target test case data that has passed the verification. If it exists, the target test case data will be pushed to the automated testing platform in batches and mounted in the method directory node; If it does not exist, a method directory node corresponding to the target test case data is created on the automated testing platform, and the target test case data is pushed to the automated testing platform in batches and mounted on the method directory node. Call the test case creation interface of the automated testing platform to create the corresponding target test cases according to the target test case data.

6. The test case generation method according to claim 5, characterized in that, The method further includes: If the push of target test case data for any batch fails, the target test case data for that batch will be pushed to the automated testing platform again. If any of the target test cases fails to be created, or if the test case creation interface call fails, collect the exception information at the current moment; If the abnormal information is a network abnormality, the use case creation interface will be called again according to the exponential backoff retry strategy; If the above-mentioned abnormal information is a business abnormality, then stop creating the target test cases for the current batch; If the abnormal information is a system abnormality, the test case creation interface will be called again after a preset time period, and an alarm message will be sent to the preset monitoring terminal.

7. The test case generation method according to claim 1 or 5, characterized in that, The method further includes: After the test case is pushed to the automated testing platform, the test case is marked as a manual execution type, and the test case tree structure is updated. The step involves jumping to the target data interface of the automated testing platform, which is called periodically, to obtain the initial method list of the open service platform.

8. The test case generation method according to claim 1, characterized in that, The method further includes: The system collects operation information for each step in real time and loads it into a preset log template to generate a full-process log.

9. A test case generation system, characterized in that, include: The method list retrieval module is used to periodically call the target data interface of the automated testing platform to obtain the initial method list of the open service platform; The interface list filtering module is used to query the test case tree structure of the automated testing platform and filter the list of interfaces to be tested according to the query results and the initial method list. The structured method feature generation module is used to perform syntax parsing on each method to be tested corresponding to the list of interfaces to be tested, determine multiple target fields, and integrate them into multiple sets of structured method features. The test case data generation module is used to call the large language model to generate at least one set of test case data according to the structured method features described in each group and then verify it. The test case creation module is used to push the validated target test case data to the automated testing platform and create the corresponding target test cases on the automated testing platform.

10. An electronic device, characterized in that, The device includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the test case generation method as described in any one of claims 1-8.

Images