Test case generation method and device, equipment, medium and program product

Abstract

The invention discloses a test case generation method and device, equipment, a storage medium and a program product, and the method comprises the steps: obtaining one or more test data documents input by a user, and carrying out the text extraction of the one or more test data documents, and obtaining one or more test point documents; performing use case generation on the one or more test point documents based on a first cue word template to obtain an initial test use case; and performing standardized conversion on the initial test case based on a case template to obtain a standard test case.

Description

Technical Field

[0001] This application relates to the fields of cloud storage and software testing technology, and in particular to a test case generation method, apparatus, device, storage medium, and program product. Background Technology

[0002] With the increasing demand for dedicated cloud construction, the need for customization is also growing. However, facing the increasing customization requirements and product version diversity, product testing faces significant challenges, especially the writing, selection, and maintenance of integration test cases. These tasks typically rely on manual operation, which is inefficient and requires highly experienced testers. Current technologies often use test requirements and technical documents as input, generating test cases based on existing test cases or functionalities, generating unit test cases based on code changes, or generating domain-specific test cases based on business documents. These methods generally lack automated generation and execution feedback mechanisms for test case scripts, resulting in insufficient comprehensiveness and effectiveness of the generated test cases. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a test case generation method, apparatus, device, storage medium, and program product.

[0004] The test case generation method provided in this application includes: Obtain one or more test data documents input by the user, and extract text from the one or more test data documents to obtain one or more test point documents; Based on the first prompt word template, test cases are generated from the one or more test point documents to obtain initial test cases; The initial test cases are standardized and transformed based on the test case template to obtain standard test cases.

[0005] The test case generation apparatus provided in this application includes: The acquisition unit is used to acquire one or more test data documents input by the user; The extraction unit is used to extract text from the one or more test data documents to obtain one or more test point documents. The generation unit is used to generate test cases for the one or more test point documents based on the first prompt word template, so as to obtain initial test cases; The conversion unit is used to standardize and convert the initial test cases based on the test case template to obtain standard test cases.

[0006] The processing device provided in this application includes a processor and a memory. The memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute any of the above-described test case generation methods.

[0007] The computer-readable storage medium provided in this application embodiment is used to store a computer program that causes a computer to execute any of the above-described test case generation methods.

[0008] The computer program product provided in this application includes computer program instructions that cause a computer to execute any of the above-described test case generation methods.

[0009] In the technical solution of this application embodiment, one or more test data documents input by the user are obtained, and text extraction is performed on the one or more test data documents to obtain one or more test point documents; test cases are generated from the one or more test point documents based on the first prompt word template to obtain initial test cases; the initial test cases are standardized and transformed based on the test case template to obtain standard test cases. Thus, firstly, multiple test point documents are extracted from multiple test data documents, ensuring comprehensive and targeted test point coverage; secondly, the first prompt word template guides the large model to generate initial test cases corresponding to multiple test point documents, and the initial test cases are standardized using the standardized test case template, achieving consistency and maintainability of test case content, thereby improving the comprehensiveness and effectiveness of test cases. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating the test case generation method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of the automated use case generation device based on cloud storage requirements provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the test case generation module provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the test case automation module provided in an embodiment of this application; Figure 5 This is a flowchart illustrating the test case execution module provided in an embodiment of this application; Figure 6 This is a schematic diagram of the test case generation device provided in the embodiments of this application; Figure 7 This is a schematic diagram of the processing device provided in the embodiments of this application. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0012] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0013] There are currently three main types of cloud storage: object storage, file storage, and block storage. Among them, object storage is a technology that stores and manages data in an unstructured format. It can store any type of data and eliminates the capacity limitations, cost barriers, and other constraints of traditional storage. Object storage is widely used in fields such as cloud computing, big data analytics, the internet, finance, and healthcare.

[0014] With the increasing demand for dedicated cloud construction, the need for customization is also growing. This brings challenges such as product version diversity, configuration variety, and customized functionalities. Currently, test case writing, resource pool acceptance test case retrieval, and resource pool configuration check test cases are mostly done manually by testers. The diverse versions and customized functionalities not only consume a significant amount of time for testers in test case writing, selection, and maintenance, but also require a certain level of technical expertise, necessitating a detailed understanding of the product itself, the project information it's used in, and its application on the live network. Furthermore, in the cloud storage field, there is currently no technical solution for automatically generating integration test cases based on requirements.

[0015] In related technologies, automated use case generation solutions can be mainly divided into the following categories: (1) Based on existing test cases and a small amount of test data (such as new functional points), a larger model is used to train and generate more suitable test cases. This is an optimization and expansion of existing test cases, not an implementation from 0 to 1.

[0016] (2) For unit testing on hardware and software, test cases are automatically generated based on the changed functions.

[0017] (3) Automatic generation of business use cases in fields such as hardware chips, vehicles, autonomous driving, railways, and finance, mainly based on specific business requirement documents and technical documents to generate test cases.

[0018] (4) In electronic system applications, test cases are automatically generated based on requirements documents, and the execution and results are automatically fed back.

[0019] Among them, the above schemes (1) to (3) mainly focus on the automatic generation of test cases, but do not involve the generation of test case automation scripts, automatic execution, and result feedback. Moreover, the application scenarios are mainly unit testing and some business testing in the fields of vehicles, autonomous driving, railways, and finance. They lack the automatic generation, automation, execution, and result feedback of integrated test cases in the storage field. Although the above scheme (4) involves the automatic generation of test cases and the feedback of execution results, it only takes test requirements and technical documents as inputs for test case generation. It does not consider taking the orthogonal correlation between various functions of the product, the interaction correlation between the current network / historical / competitive benchmarking issues and functions, interface documents, and resource pool acceptance configuration documents as inputs for test case generation. Therefore, the generated test cases lack effectiveness and comprehensiveness. At the same time, it lacks the adjustment of the priority of existing test cases by the current network / historical / competitive benchmarking issues, and it also lacks the automatic screening of existing test cases and the addition of new test cases according to different cloud storage business needs.

[0020] Based on this, existing automated use case generation solutions have the following drawbacks: (1) There is a lack of technical solutions for automatically generating test cases based on requirements in the field of cloud storage.

[0021] (2) The input factors for generating test cases are relatively simple. Considering the orthogonal correlation between various functions of the product, the interaction correlation between the current network / historical / competitor benchmarking issues and functions, interface documents, and resource pool acceptance configuration documents as inputs for generating test cases, the generated test cases lack effectiveness and comprehensiveness.

[0022] (3) There is a lack of input of real-time influencing factors such as current network / historical / competitor benchmarking issues to dynamically adjust the priority of existing use cases.

[0023] (4) There is a lack of automatic screening of existing test cases and new test cases to form a complete test case plan based on different cloud storage service requirements.

[0024] (5) There is a lack of automatic use case standardization processing (adding use case tags, distinguishing use case levels and uses) for newly generated use cases, and merging them into the baseline use case library for subsequent unified maintenance.

[0025] To address the aforementioned technical issues, this application proposes a test case generation method. By adding multi-factor input, it not only incorporates test requirements and technical documents as inputs for test case generation, but also adds orthogonal correlations between various product functions, interaction correlations between current / historical / competitive benchmarking issues and functions, interface documents, and resource pool acceptance configuration documents as inputs. Simultaneously, it uses current / historical / competitive benchmarking issues as real-time influencing factors to dynamically adjust the priority of existing test cases. Furthermore, it can automatically filter existing and new test cases based on different cloud storage business needs to form a complete test case plan. This fills the gap in cloud storage technology for automatically generating test cases based on requirements, greatly improving the effectiveness and comprehensiveness of generated test cases. It also allows for convenient and timely adjustment of the test case scope, reducing test leakage rates and solving the problems of single factors and lack of dynamic adjustment mechanisms in related technologies.

[0026] To facilitate understanding of the technical solutions of the embodiments of this application, the technical solutions of this application are described in detail below through specific embodiments. The above-mentioned related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. The embodiments of this application include at least some of the following contents.

[0027] This application provides a test case generation method, which can be generated by... Figure 1 This is a flowchart illustrating the test case generation method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps: Step 101: Obtain one or more test data documents input by the user, and extract text from one or more test data documents to obtain one or more test point documents.

[0028] Here, test data documents refer to the raw input materials used to describe the features of the function under test. Their content covers multiple dimensions, including functional requirements, interface parameters, configuration items, and issue logs. For example, a functional requirements document might describe the newly added S3 object storage interface functionality; an interface document details the request parameters supported by the Simple Storage Service (S3) object storage interface and the interface's behavioral logic; and a historical issue log might record problems caused by S3 object storage interface configuration errors in previous versions and corresponding fixes.

[0029] In this embodiment, one or more test data documents in formats such as PDF, Word, and Excel, input by the user, can be obtained. Natural language processing techniques are used to clean, segment, and normalize these test data documents, followed by structured text extraction to obtain a test point document for each test data document. Each test point document contains several test points, and each test point corresponds to a potential test case direction. For example, extracting the function point of user-created storage space (Bucket) from the functional requirements document can generate a preliminary test point: verifying whether the user can successfully create a Bucket.

[0030] Among them, one or more test data documents include configuration item documents, functional requirement documents, design documents, interface documents, functional orthogonal matrix documents, complaint issue documents, historical issue documents, and competitor issue documents; one or more test point documents include configuration test point documents, basic test point documents, principle test point documents, interface test point documents, feature cross test point documents, complaint cross test point documents, historical issue test point documents, and competitor cross test point documents.

[0031] In some embodiments, text extraction is performed on one or more test data documents to obtain one or more test point documents, including at least one of the following: Extract the configuration check item descriptions from the configuration item document to obtain the configuration test point document; Extract descriptions of new functional requirements from the functional requirements document to obtain the basic test point document; Extract the functional requirements principle description from the design document to obtain the principle test point document; Extract the functional requirements of the interfaces and the descriptions of the interface parameters from the interface documentation to obtain the interface test point documentation; Extract the cross-description of functional characteristics from the functional orthogonal matrix document to obtain the characteristic cross-test point document; Based on the functional requirements document and the third prompt word template, the complaint issue document is used to extract the interactive descriptions of complaint issues with new and existing functions, resulting in a complaint cross-test point document. Based on the functional requirements document and the fourth prompt word template, the historical problem document is extracted to describe the interaction between historical problems, new functions, and existing functions, thus obtaining the historical problem test point document. Based on the functional requirements document, the functional differences between the competitor's issue document and the competitor's cross-test point document are extracted.

[0032] Specifically, a configuration item document is a document that describes the various configurable parameters in the system and their settings. It typically includes information such as the configuration item name, configuration item type, default value, and value range. Configuration item documents ensure that testing covers the functional performance under different configurations, helping to improve the comprehensiveness and relevance of test cases.

[0033] The configuration test point document is a collection of test points formed by extracting configuration check item descriptions from the configuration item document. The test points in the configuration test point document mainly focus on the system's behavior under different configurations, such as whether a specific configuration is supported, whether the expected operation is triggered after a configuration change, etc., and can be used to verify the system's stability and compatibility under various configuration combinations.

[0034] For example, the configuration check item: the object storage service must enable Secure Sockets Layer (SSL) encrypted transmission can be translated into a test point: verify whether the object storage service forces the use of the SSL protocol for data transmission when it starts up.

[0035] A functional requirements document (FQV) describes the functional characteristics that a system needs to implement, including functional descriptions, input / output conditions, and boundary conditions. By extracting key functional points from the FQV and generating corresponding test points, it is possible to ensure that new functions are fully validated during the testing phase.

[0036] The basic test point document is a collection of test points extracted from the functional requirements document, summarizing the descriptions of newly added functional requirements. The test points in the basic test point document primarily focus on the basic operational flow and expected results of the new function, such as whether the new function can start normally, whether it can perform basic operations, and whether it can handle typical inputs. The basic test point document forms the basis for test case generation, ensuring that all core functionalities are covered.

[0037] For example, if the functional requirements document describes a signature verification mechanism that supports the S3 API interface, the basic test point document may include test points such as verifying that the S3 API request returns a 403 Forbidden when no signature is provided, and verifying that the signature algorithm supports the Secure Hash Algorithm (SHA).

[0038] Design documents describe the system's internal structure, module division, interface definitions, and other related details. By analyzing design documents, the underlying logic of the functions can be identified, and principle-based test points can be generated based on these principles. This ensures that tests not only cover functional performance but also verify the correctness of the system's underlying logic.

[0039] A principle-based test point document is a collection of test points formed based on the functional requirements principles extracted from the design document. The test points in this document primarily focus on the system's internal operating mechanisms, such as whether algorithms execute correctly, whether state transitions meet expectations, and whether exception handling is appropriate. This helps verify the correctness of the system's deeper logic and improves the depth of testing.

[0040] For example, if the design document describes that the metadata of the object storage system is managed using a B+ tree structure, the principle test point document may include test points to verify whether the metadata insertion operation triggers a split when the B+ tree is full, and test points to verify whether the deletion operation can correctly merge nodes.

[0041] Interface documentation describes the interfaces provided by a system and how they are invoked, including interface paths, request parameters, and response formats. Parsing the interface documentation allows for the generation of interface test cases, ensuring the stability and compatibility of the system during actual interactions.

[0042] An interface test point document is a collection of test points extracted from the interface documentation, summarizing the supported interfaces and their parameter descriptions. The test points in the interface test point document primarily focus on the usability, compatibility, and error handling of the interfaces. For example, it checks whether the interface can be called normally, whether it returns the expected response, and whether it can handle abnormal requests. This helps verify whether the system's interaction with other systems meets expectations.

[0043] For example, if the API documentation defines a GET / objects API to list a list of objects, the API test case documentation may include the following: verifying that the GET / objects API returns all objects when no parameters are provided, verifying that the GET / objects API only returns objects that match the prefix when a prefix parameter is specified, etc.

[0044] A functional orthogonal matrix (FOM) document is a document used to describe the cross-influence relationships between functions, and is often used in multi-factor combination testing scenarios. By using a FOM document, strong correlations between functions can be identified, thereby generating cross-feature test points and improving test case coverage.

[0045] The feature cross-test point document is a set of test points formed by the cross-description of functional features extracted from the functional orthogonal matrix document. The test points in the feature cross-test point document mainly focus on the behavior when multiple functions are enabled at the same time, such as whether there are conflicts or unexpected results. It helps to identify potential combination problems and improve the coverage of test cases.

[0046] For example, if the orthogonal matrix documentation indicates that the newly added multi-tenant isolation feature will affect the access control policy of the object storage service, the feature cross-test point documentation may include test points such as verifying whether users within the same tenant cannot access objects of other tenants after the multi-tenant isolation feature is enabled, and verifying whether the original access control policy is restored after the multi-tenant isolation feature is disabled.

[0047] Complaint and issue documents record user feedback issues, including the problem description, reproduction path, and scope of impact. By analyzing complaint and issue documents, frequently occurring issues can be extracted, and cross-test points can be generated to prioritize the verification of functional areas prone to problems.

[0048] The complaint cross-test point document is a collection of test points formed by the interaction between complaint issues extracted from the complaint issue document and new and existing features. The test points in the complaint cross-test point document mainly focus on areas with frequent user feedback in the past, such as whether the same problem exists, whether it has been fixed, and whether there are still residual effects. It can be used to prioritize the verification of high-risk areas and enhance the targeting of the testing work.

[0049] For example, if the complaint document mentions that some requests fail when uploading large files using the S3 API, testers can generate test points based on the description of segmented uploads in the functional requirements document to verify whether the S3 API segmented upload function returns the corresponding error code when the size of a single segment exceeds the maximum limit.

[0050] Historical issue documents record problems discovered and fixed during testing in previous versions, including root causes, fixes, and scope of impact. By analyzing these documents, previously occurring issues can be extracted, generating historical issue test cases to prevent similar problems from recurring in subsequent versions.

[0051] The Historical Issues Testpoint Document is a collection of testpoints extracted from the Historical Issues Document and described in conjunction with new and existing features. The testpoints in the Historical Issues Testpoint Document primarily focus on whether previously encountered problems will recur and whether there are improvement measures in place for these problems. This helps prevent past issues from recurring in subsequent versions and improves the continuity of testing activities.

[0052] For example, if the issue document records that in the previous version, some objects did not take effect when configuring the caching strategy, test points can be generated by combining the new feature descriptions regarding the caching strategy in the functional requirements document to verify whether the relevant objects can refresh the cache according to the specified strategy after the caching strategy is configured.

[0053] Competitive issue documentation compares the current product with competitors' products, highlighting differences and issues such as missing features, performance deficiencies, and poor user experience. Analyzing this documentation allows for the extraction of problems from competitors, the generation of cross-testing points, and the optimization of the product's quality and competitiveness.

[0054] The competitive cross-test point document is a set of test points extracted from the functional differences described in the competitive product issue documents. The test points in the competitive cross-test point document primarily focus on whether unresolved issues in the competitor's product also exist in this system. It is used to assess whether the same defects or performance bottlenecks exist in this system, which helps optimize product design and functional implementation, thereby improving product quality and enhancing its market competitiveness.

[0055] For example, if a competitor's issue document indicates that a competitor's object storage does not support the breakpoint resume function for segmented uploads, developers can generate test points based on the description of breakpoint resume in the functional requirements document to verify whether the upload can continue from the point of network interruption after a network interruption occurs during the segmented upload process.

[0056] Step 102: Generate test cases for one or more test point documents based on the first prompt word template to obtain initial test cases.

[0057] Here, the first prompt template is a preset instruction template used to guide the large language model to generate initial test cases in a specific format. For example, the first prompt template includes: "Read the test point document and output a mind map, where the first level is the name of the test function point, the second level is the test case title, the third level is the test case steps, and the fourth level is the expected test result."

[0058] In this embodiment, one or more test point documents and a first prompt word template can be input into a large language model. Guided by the first prompt word template, the large language model generates test cases based on the one or more test point documents and outputs an initial test case. This initial test case includes the test function, test case title, test steps, and expected test results.

[0059] It should be noted that the initial test cases are a collection of test cases that have not undergone standardization. The initial test cases may exist in graphical form (such as XMind) or semi-structured text form. For example, for the test case of a user creating a Bucket, the initial test cases may include the user logging into the console → clicking the 'Create Bucket' button → entering the Bucket name → confirming creation, with the expected result of the Bucket being created successfully.

[0060] In some embodiments, step 102 specifically includes: Step 1021: Perform deduplication on the configuration test point document, basic test point document, principle test point document, interface test point document, feature cross test point document, complaint cross test point document, historical issue test point document, and competitor cross test point document to obtain one or more deduplicated test point documents.

[0061] Step 1022: Merge one or more deduplicated test point documents into a comprehensive test point document.

[0062] Specifically, for configuration test point documents, basic test point documents, principle test point documents, interface test point documents, feature cross-test point documents, complaint cross-test point documents, historical issue test point documents, and competitor cross-test point documents, the duplicate or similar content in these test point documents is first deduplicated to reduce redundant information. Then, these deduplicated test point documents are categorized according to functional categories and merged to obtain a comprehensive test point document, which facilitates the generation and management of subsequent test cases.

[0063] The comprehensive test point document not only contains the specific content of each test point, but is also organized according to dimensions such as functional classification, priority, and correlation to form a structured set of test points.

[0064] Step 1023: Input the comprehensive test point document and the first prompt word template into the large model, so that the large model outputs the specific functional points, test points, test steps, and expected test results corresponding to the comprehensive test point document under the guidance of the first prompt word template.

[0065] Step 1024: Based on the specific functional points, test points, test steps, and expected test results corresponding to the comprehensive test point document, determine the initial test cases.

[0066] Specifically, the large model refers to a large language model based on deep learning, such as the Bidirectional Encoder Representation from Transformers (BERT). By inputting the comprehensive test point document and the first prompt word template into the large model, the model can gradually parse the content of the comprehensive test point document and extract key information. Then, guided by the first prompt word template, it generates specific initial test cases based on the extracted key information, including specific functional points, test points, test steps, and expected test results. The generated initial test cases are then output in a specified file format, such as an XMind mind map or an Excel spreadsheet.

[0067] Step 103: Standardize the initial test cases based on the test case template to obtain standard test cases.

[0068] Here, a test case template is a structured table template used to define standard fields for test cases. The test case template includes test case title, test case type, test case level, test case version, test case steps, expected test case result, whether it is a project customization requirement, whether it is a configuration check, and whether it is a public cloud.

[0069] In this embodiment, the fields in the initial test cases can be parsed first, and then mapped to their corresponding positions in the test case template according to the content of the test case template. This ultimately generates test cases that conform to a unified format, i.e., standard test cases. For example, when handling the test point of user creating a Bucket, the standardized test case generated by the system may include the following fields: test case title: User Creates Bucket; test case level: L1; test case steps: User logs into the console → clicks the 'Create Bucket' button → enters the Bucket name → confirms creation; expected test case result: Bucket creation successful, etc.

[0070] In some embodiments, step 103 specifically includes: Standardize the test case format by including test case title, test case type, test case level, test case steps, expected test case results, whether it is a customized requirement of the project, whether it is a configuration check, and whether it is a public cloud. Based on the standardized test case format, the initial test cases are standardized and transformed to obtain standard test cases.

[0071] The test case title describes the functional point or scenario verified by the standard test case; the test case type distinguishes whether the standard test case belongs to different types such as functional testing, interface testing, and performance testing; the test case level indicates the importance (priority) of the standard test case, for example, L0 is high priority and L3 is low priority; the test case version indicates the product version used by the standard test case; the test case steps describe the steps required to execute the standard test case; the expected result of the test case describes the correct behavior that should occur after the standard test case is executed; the "Is it a project-customized requirement" field indicates whether the standard test case is written for the customized requirements of a specific project; the "Is it a configuration check" field indicates whether the standard test case involves checking resource pool configuration items; and the "Is it a public cloud" field indicates whether the standard test case is suitable for a public cloud environment.

[0072] Specifically, by setting the test case template to include the test case title, test case type, test case level, test case version, test case steps, expected test case results, whether it is a project-specific requirement, whether it is a configuration check, and whether it is a public cloud, and using this as a standardized test case format, the structure and content of test cases can be unified, improving the consistency and readability of test cases. Then, based on the standardized test case format, each field in the initial test case is mapped to the corresponding position in the test case template. For example, the test case title is mapped to the first column in the test case template, the test case steps are mapped to the second column, the expected test case result is mapped to the third column, and so on. Based on the source of the initial test case (such as whether it comes from competitor benchmarking issues), corresponding tags are added, such as whether it is a customized project requirement, whether it is a configuration check, and whether it is a public cloud. Finally, the standardization transformation of the initial test case is completed, resulting in standard test cases.

[0073] In some embodiments, the above method further includes: Step S1: Based on one or more test data documents and second prompt word templates, adjust the test case level of one or more target existing test cases in the baseline test case library to obtain one or more target existing test cases with adjusted test case levels.

[0074] Here, the second prompt word template is an instruction template used to dynamically adjust the test case level. It guides the large language model to extract the frequency of problem occurrence and other influencing factors (such as whether it affects basic business input / output operations and existing functional relationship sets) from the test data document. For example, the second prompt word template includes: "Perform frequency statistics on the functional points and configuration items that have problems, and output the problem frequency results."

[0075] In this embodiment, one or more test data documents and a second prompt word template can be input into a large language model. Guided by the second prompt word template, the large language model extracts from the one or more test data documents the frequency of occurrence of all problematic functional points, whether they affect business operation results, and one or more existing functional relationships. Then, based on the frequency of occurrence of all problematic functional points, whether they affect business operation results, and one or more existing functional relationships, the test case level of one or more target existing test cases in the baseline test case library that are associated with one or more existing functional relationships is adjusted, thereby obtaining one or more target existing test cases after test case level adjustment.

[0076] It should be noted that target existing test cases refer to existing test cases in the baseline test case library. Target existing test cases may cover existing functions or historical issues. By prioritizing target existing test cases based on the second prompt word template, it is possible to ensure that test cases corresponding to high-risk or high-frequency issues receive higher attention during testing, thereby improving test coverage and reducing the risk of missed tests, making the priority of test cases more closely aligned with actual business conditions.

[0077] In some embodiments, step S1 specifically includes: Step S11: Summarize the complaint issue documents, historical issue documents, and competitor issue documents to obtain one or more issue function points.

[0078] Specifically, issues can be summarized from complaint documents, historical issue documents, and competitor issue documents in one or more test data documents to obtain one or more problematic functional points. This process involves identifying specific issues related to product functionality from complaint documents, historical issue documents, and competitor issue documents, and categorizing these specific issues into several problematic functional points, representing existing defects, faults, or areas for improvement, and indicating their interaction with specific functional modules. For example, if a user reports that the object storage service experiences response latency under high concurrency, this issue can be categorized as a problematic functional point related to object storage performance.

[0079] Step S12: Input one or more problem function points and the second prompt word template into the large model, so that the large model outputs the frequency of occurrence of each problem function point, whether it affects the business operation results, and the relationship of one or more existing functions under the guidance of the second prompt word template.

[0080] Specifically, one or more problematic functional points and a second prompt word template can be input into the large model. The large model then performs further analysis on these problematic functional points and, guided by the second prompt word template, generates the frequency of occurrence of each problematic functional point, its impact on business operation results, and one or more existing functional relationships. The frequency of occurrence of a problem indicates how often a problem occurs over a period of time, measuring its prevalence; its impact on business operation results indicates whether a problem has a substantial impact on the input and output operations of basic business processes; and its existing functional relationships represent the functional interaction relationships between a problem and existing use cases in the baseline use case library.

[0081] Step S13: Based on one or more existing functional relationships corresponding to each problem function point, filter one or more existing use cases in the baseline use case library to obtain one or more target existing use cases.

[0082] Specifically, existing functional relationships represent the functional interaction relationships between problematic functional points and existing use cases in the baseline use case library. For example, whether a problematic functional point affects the operation of other existing use cases, or whether it has functional dependencies on other existing use cases. By comparing one or more existing functional relationships corresponding to each problematic functional point with one or more existing use cases in the baseline use case library, one or more target existing use cases that are functionally associated with each problematic functional point can be identified.

[0083] Step S14: Based on the frequency of occurrence of each problem function point, whether it affects the business operation results, and the relationship between one or more existing functions, adjust the use case level of one or more target existing use cases to obtain one or more target existing use cases after use case level adjustment.

[0084] In some embodiments, step S13 specifically includes: S131: Based on the frequency of occurrence of each problem function point and whether it affects the business operation results, as well as the original use case level of each target existing use case in one or more target existing use cases, the impact calculation is performed on each target existing use case to obtain the impact factor corresponding to each target existing use case.

[0085] Specifically, after identifying one or more target existing use cases that are functionally associated with each problem function point, the impact of each target existing use case can be quantified by combining the frequency of occurrence of the problem corresponding to each problem function point and whether it affects the business operation results, as well as the original use case level corresponding to one or more target existing use cases, so as to obtain the impact factor corresponding to each target existing use case. This factor is used to measure the importance of each target existing use case in its associated problem environment, and to decide whether the priority (original use case level) of each target existing use case needs to be adjusted accordingly.

[0086] S132: Based on the comparison results of the impact factor and impact threshold corresponding to each target stock use case, the use case level of each target stock use case is adjusted to obtain each target stock use case after the use case level is adjusted.

[0087] Specifically, for each target existing use case, the impact factor corresponding to that target existing use case can be compared with the impact threshold. If the impact factor corresponding to the target existing use case is greater than the impact threshold, the use case level corresponding to the target existing use case will be adjusted upward. For example, if the original use case level of a target existing use case is L2, but its current impact factor reaches the threshold of L1, the use case level of the target existing use case will be adjusted to L1.

[0088] It should be noted that the test case level adjustment process is dynamic. The test case level of the target existing test cases can be continuously updated based on the real-time input of problem data to ensure that the testing strategy always closely matches the actual needs.

[0089] Step S2: Store the standard test cases and one or more adjusted target stock test cases into the baseline test case library.

[0090] Here, the baseline test case library is a database that centrally manages test cases. It is usually in the form of a relational database or a NoSQL database, and the baseline test case library supports functions such as version control, tag management, and test case query.

[0091] In this embodiment of the application, after obtaining the newly generated standard test cases and one or more target stock test cases after test case level adjustment, the standard test cases can be stored in the baseline test case library, and the one or more target stock test cases after test case level adjustment can be used to update the corresponding original target stock test cases in the baseline test case library, so as to realize the closed-loop management of test cases and facilitate the subsequent calling and maintenance of the test process.

[0092] It should be noted that each test case in the baseline test case library has detailed tag information, including version number, whether it is a customized requirement for the project, test case level, whether it involves configuration checks, and whether it is suitable for public clouds. This tag information can be used for subsequent test case selection and task deployment.

[0093] In some embodiments, the above method further includes: Input the standard test cases and the fifth prompt word template into the large model, so that the large model can output the initial automated test script corresponding to the standard test cases under the guidance of the fifth prompt word template; The initial automated test script is standardized and transformed to obtain a standard automated test script. Store standard automated test scripts in an automated test case library.

[0094] The fifth prompt word template is a predefined instruction template used to guide the large language model in generating automated test scripts based on given test case content. The fifth prompt word template typically includes placeholders for fields such as test case title, test steps, and expected results, and, combined with code generation rules, guides the large language model to output script code that conforms to specific programming standards.

[0095] An automated test case library is a database or version control system-level target structure that centrally manages automated test scripts. It's used for storing, retrieving, updating, and deploying automated test scripts. The library categorizes and organizes automated test scripts according to functional modules, test types, project versions, and other dimensions, facilitating subsequent test scheduling and version control.

[0096] Specifically, the process begins by inputting standard test cases and the fifth prompt word template into a large language model. Guided by the fifth prompt word template, the large language model generates initial automated test scripts based on the structure and content characteristics of the standard test cases. Next, the initial automated test scripts undergo standardization, including adjustments and optimizations according to unified coding styles, naming conventions, function call methods, and logging methods, resulting in standard automated test scripts. These standardized test scripts are then stored in an automated test case library for subsequent scheduling, execution, and maintenance. This storage process typically includes file path construction, script version marking, metadata addition, and dependency checks. For example, when creating a new branch or committing a new entry in a Git repository, script files are categorized by functional modules and tagged with labels such as L0, L1, and configuration checks to facilitate quick location and execution during subsequent test task selection.

[0097] In some embodiments, the above method further includes: Obtain the user's testing requirements, and filter one or more test cases in the baseline test case library based on the testing requirements and the test case tags in each test case to obtain one or more target test cases; Set up automated scheduling tasks and timed tasks, and execute the automated test scripts corresponding to each target test case in one or more target test cases based on the automated scheduling tasks and timed tasks to obtain the test results corresponding to each target test case; The test results for each target test case are summarized to obtain the comprehensive test results, which are then stored in a preset directory.

[0098] Specifically, each test case in the baseline test case library includes a test case tag, and the automated test case library includes the corresponding automated test script for each test case. By obtaining the test requirements input by the user, information such as the test purpose, test scope, and test priority can be determined. Based on this information and the test case tags of each test case in the baseline test case library, all test cases in the baseline test case library are matched and filtered to obtain one or more target test cases that meet the test requirements. Then, the execution order and time of one or more target test cases can be set according to the test requirements (automated scheduling task), and the predetermined time point or periodic rule for the execution of each target test case can be set (timed task). According to the set automated scheduling task and timed task, the automated test script corresponding to each target test case is executed periodically as needed to obtain the test results for each target test case, including pass status, failure status, execution log, error information, etc. Then, the test results corresponding to each target test case are statistically analyzed to form a comprehensive test result, including key indicators such as overall pass rate, failure reason classification, and anomaly trend. The comprehensive test result is stored in a predefined file path (preset directory) for easy subsequent analysis and archiving.

[0099] In some embodiments, one or more test cases in the baseline test case library are filtered based on test requirements and test case tags in each test case to obtain one or more target test cases, including at least one of the following: When the testing requirement is a regular version test, one or more test cases in the baseline test case library are filtered based on version tags to obtain one or more functional test cases for the preset version. Then, one or more test cases for the preset version are filtered based on level tags to obtain one or more functional test cases for the preset version and preset test case level. The one or more functional test cases for the preset version and preset test case level are used as one or more target test cases. When the testing requirement is acceptance testing of a public cloud resource pool, one or more test cases are filtered based on whether it is a public cloud tag and level tag to obtain one or more public cloud function test cases of the preset test case level, and one or more test cases are filtered based on version tag and whether configuration check tag to obtain one or more configuration check test cases of the preset version; and one or more public cloud function test cases of the preset test case level and one or more configuration check test cases of the preset version are used as one or more target test cases. When the testing requirement is acceptance testing of a private cloud resource pool, one or more test cases are filtered based on whether they are public cloud tags, whether they are project-customized requirement tags, and level tags to obtain one or more private cloud functional test cases with preset project requirements and preset test case levels. One or more test cases are also filtered based on version tags and level tags to obtain one or more functional test cases with preset versions and preset test case levels. Finally, one or more test cases are filtered based on version tags and whether they are configuration check tags to obtain one or more configuration check test cases with preset versions. The one or more private cloud functional test cases with preset project requirements and preset test case levels, the one or more functional test cases with preset versions and preset test case levels, and the one or more configuration check test cases with preset versions are used as one or more target test cases.

[0100] The baseline test case library includes test case tags for each test case, such as version tag, level tag, whether it is a project customization requirement tag, whether it is a configuration check tag, and whether it is a public cloud tag.

[0101] Specifically, the test case selection process, for different testing scenarios, includes but is not limited to the following methods: The first method uses version tags, which are metadata information used to identify the product version to which a test case applies. These typically include a specific version number, such as v10.x or v11.0, to distinguish functional differences between versions. Level tags are classification markers used to identify the priority and importance of test cases. Common levels include L0 (core functionality), L1 (important functionality), L2 (minor functionality), and L3 (auxiliary functionality). In a standard version testing scenario, version tags allow for quick location of test cases applicable to the current scenario's version, while level tags allow for quick location of test cases at the required level. This yields one or more functional test cases for the preset version and level. These two sets of results can then be used as the target test cases for the standard version testing scenario.

[0102] For example, in version v10.x, the system first filters out all test cases tagged with v10.x, then extracts L0 and L1 level test cases from all test cases tagged with v10.x, and forms the final target test case set.

[0103] The second approach uses two binary tags: "Public Cloud" and "Configuration Check". The "Public Cloud" tag is a binary label used to identify whether a test case is suitable for a public cloud environment. The "Configuration Check" tag is also a binary label used to identify whether a test case belongs to the configuration check category. In a public cloud resource pool acceptance test scenario, using the "Public Cloud" and "Configuration Check" tags allows for quick location of test cases at the required test case level for the public cloud scenario, resulting in one or more public cloud functional test cases at the preset test case level. Similarly, using the "Version" and "Configuration Check" tags allows for quick location of configuration check test cases for the required version in the current scenario, resulting in one or more configuration check test cases for the preset version. These two results can then be used as the target test cases for the public cloud resource pool acceptance test scenario.

[0104] The third approach uses a binary tag to identify whether a test case is designed specifically for the customized needs of a particular project. In a private cloud resource pool acceptance test scenario, by using the "Public Cloud" tag, the "Project Customization Requirement" tag, and the level tag, the required test case level and test cases with specific requirements for the private cloud scenario can be quickly located, resulting in one or more private cloud functional test cases with preset project requirements and preset test case levels. Furthermore, by using the version tag and level tag, the required version and test case level for the current scenario can be quickly located, resulting in one or more functional test cases with preset versions and preset test case levels. Finally, by using the version tag and the "Configuration Check" tag, the required version of configuration check test cases for the current scenario can be quickly located, resulting in one or more configuration check test cases for preset versions. Therefore, the results from these three parts can be used as the target test cases for the private cloud resource pool acceptance test scenario.

[0105] By using multiple tag combinations to filter test cases under different testing requirements, we can more flexibly adapt to diverse testing scenarios and accurately match the relationship between test cases and testing requirements. This can improve testing efficiency and coverage, and further achieve the goals of reducing test miss rates and improving test quality.

[0106] In the technical solution of this application embodiment, one or more test data documents input by the user are obtained, and text extraction is performed on the one or more test data documents to obtain one or more test point documents; test cases are generated from the one or more test point documents based on the first prompt word template to obtain initial test cases; the initial test cases are standardized and transformed based on the test case template to obtain standard test cases. Thus, firstly, multiple test point documents are extracted from multiple test data documents, ensuring comprehensive and targeted test point coverage; secondly, the first prompt word template guides the large model to generate initial test cases corresponding to multiple test point documents, and the initial test cases are standardized using the standardized test case template, achieving consistency and maintainability of test case content, thereby improving the comprehensiveness and effectiveness of test cases.

[0107] This application also proposes an automated test case generation device based on cloud storage requirements. This device automatically generates corresponding test cases based on functional requirements, a functional orthogonal matrix, problem-functional orthogonality, configuration check documents, problem frequency, and existing functional test case relationships. It also automatically and dynamically adjusts the priority of existing test cases, automatically filters test cases, automatically schedules test case execution, automatically provides test case results, and automatically merges the generated test cases and priority-adjusted test cases into a baseline test case library. This not only saves manpower and time but also greatly improves testing efficiency and enhances the effectiveness and comprehensiveness of generated test cases, ensuring test quality while improving testing efficiency. For example, Figure 2 The diagram shown is a structural schematic of an automated use case generation device based on cloud storage requirements provided in an embodiment of this application. The device mainly consists of four modules: (1) Test case generation module, which is used to convert the obtained dedicated cloud business requirements, configuration requirements and change requirements into test cases.

[0108] (2) Test case automation module, which uses a large language model to convert the test cases generated in the test case generation module into automated test scripts.

[0109] (3) Test case execution module, which is used to filter test cases output by test case generation module based on different cloud storage business requirements, business scenarios and test case tags, and automatically schedule and execute the filtered test cases to output test results.

[0110] (4) Test result analysis module, which is used to analyze and output the test results output by the test case execution module, and provide testers with result reference.

[0111] The following section provides a detailed introduction to the specific implementation details of each module.

[0112] (1) Test case generation module New test cases are generated from the current product's baseline test case library. This library contains baseline test cases for the current storage product, covering all functionalities of the existing product. Each test case has five tags: version number, whether it's a project customization requirement, test case level, whether it's a configuration check, and whether it's a public cloud application. Newly generated test cases will also be tagged with these five tags to facilitate automatic test case selection later.

[0113] The test case generation module mainly uses a large language model to automatically generate corresponding test cases based on functional requirements documents, configuration check item documents, interface documents, design documents, functional orthogonal matrices, complaint form documents, historical issue form documents, and competitor benchmarking issue forms. It also adjusts the priority of existing test cases, thereby reducing the manual input when writing test cases and improving the efficiency, coverage, and effectiveness of test case writing.

[0114] Figure 3 This is a flowchart illustrating the test case generation module provided in an embodiment of this application, as shown below. Figure 3 As shown, the process includes the following steps: Step 301: Input multiple test data documents into the text preprocessor. The word segmentation tool in the text preprocessor performs text cleaning, word segmentation, stemming, and text normalization summary extraction on the multiple input test data documents. It also optimizes the extracted text based on prompt word engineering technology and outputs a test point document.

[0115] The test point document includes the function name and the tasks to be performed for that function, stored item by item for easy input into the test case generator to generate test cases. The test data documents input into the text processor include: functional requirements document, configuration checklist document, interface document, design document, functional orthogonal matrix, complaint form document, historical issue form document, and competitor benchmarking issue form document. a) Preprocess the functional requirements document to remove useless symbols and redundant words, extract the description of new functional requirements, and output the basic test points of the functional requirements.

[0116] b) Preprocess the design document, extract the deep logical principle description of the functional requirement based on the design document, and output the principle test points of the functional requirement based on the principle description.

[0117] c) Preprocess the interface document, extract the interfaces and interface parameter descriptions supported by the functional requirement from the interface document, and output the interface test points of the functional requirement based on the interface and interface parameter descriptions.

[0118] d) Perform text preprocessing on the functional orthogonal matrix document, which includes the relationship between new functions and existing functions, i.e., whether the new function overlaps with existing functions and whether there will be any impact. Extract the functional characteristic cross description and output the characteristic cross test points of the function based on the functional characteristic cross description.

[0119] e) Retrieve the latest live complaint tickets in real time, analyze the causes of problems and the impact on business IO, and generate a complaint ticket document. Perform text preprocessing on this document. The text preprocessor, in conjunction with the functional requirements document and prompts, segments, extracts, and removes useless words from the document. It then extracts descriptions of the complaint issues and the interactions between new and existing functions, and outputs cross-test points based on these descriptions.

[0120] f) For issues discovered during earlier version testing or resource pool acceptance testing, root cause analysis and impact assessment are performed, followed by classification and labeling to create a historical issue document. This historical issue document undergoes text preprocessing. The text preprocessor, in conjunction with the functional requirements document and prompts, performs word segmentation and text integration on the historical issue document, extracting descriptions related to new and existing functions, and outputting historical issue test points based on these descriptions.

[0121] g) The configuration check item document mainly consists of standardized configuration check item descriptions, including check item descriptions, check steps, and expectations. The text preprocessor mainly removes useless descriptions from the configuration check item document, extracts the configuration check item descriptions, and outputs configuration item test points based on the descriptions.

[0122] h) The competitor benchmarking issue document mainly consists of competitor benchmarking test issues. This document has been categorized and labeled. The text preprocessor, in conjunction with the functional requirements document, extracts the differences between this document and the current function, and outputs the competitor cross-test points based on the description.

[0123] The multiple test points extracted from a) to h) above are deduplicated, and then the multiple deduplicated test points are merged into a single test point document and input into the test case generator.

[0124] Step 302: Input the test point document and prompt words into the test case generator based on the large model. The test case generator generates the initial test cases corresponding to the test point document according to the prompt words.

[0125] The test case generator was previously pre-trained on the existing functional sample dataset using a Transformer-based BERT model, and the trained model was fine-tuned using prompt word engineering and task-specific data-based fine-tuning techniques. The test point documents, processed by the text preprocessor, and the prompt words are input into the large-model-based test case generator. Based on the input prompt words (e.g., "Read test point document, output mind map," where "the first level of the mind map is the test function name, the second level is the test case title, the third level is the test case steps, and the fourth level is the test expectation"), the generator ultimately generates an XMind format mind map, which is the initial test case. This mind map includes specific functional points, test points, test steps, and expected test results.

[0126] Step 303: Input the initial test cases into the test case template processor. The test case template processor generates standardized test cases from the initial test cases according to the test case template.

[0127] Input the initial test cases into the test case template processor. The test case template processor is mainly implemented in Python. It is used to generate standardized test cases from the mind map-style initial test cases according to the test case template (test case title, test case type, test case level, test case version, test case steps, test case expectations, whether it is a project customization requirement, test case level, whether it is a configuration check, whether it is a public cloud), and output an Excel format test case file.

[0128] Step 304: Compile the complaint form document, historical issue document document, and competitor benchmarking issue document document into a problem set. Input the problem set and prompt words into the text preprocessor. The text processor outputs the frequency of occurrence of each problem function point, whether it affects basic business input and output operations, and the set of existing function relationships based on the prompt words.

[0129] Step 305: Input the frequency of occurrence of the problem, whether it affects basic business input and output operations, and the set of existing functional relationships for each problem function point into the existing use case level classifier. The existing use case level classifier determines the specific existing functional use cases in the baseline use case library that have the same functional relationship as the problem function point based on the set of existing functional relationships. Based on the original use case level of the specific existing functional use cases and the frequency of occurrence of the problem and whether it affects basic business input and output operations for each problem function point, the impact value of the specific existing functional use cases is calculated.

[0130] Step 306: The existing use case level classifier compares the impact value of a specific existing functional use case with different use case level thresholds, and determines the new use case level of the specific existing functional use case based on the comparison results.

[0131] Step 307: Compare the new use case level of a specific existing functional use case with the original use case level. If they are different, modify the original use case level of the specific existing functional use case to the corresponding new use case level using the existing use case level modifier.

[0132] Compile complaint forms, historical issue forms, and competitor benchmarking issue forms into a single issue set and input it into a text preprocessor. Simultaneously, input a prompt ("Statistically count the frequency of issues with the functional points and configuration items, and output the frequency results"). Guided by the prompt, the text preprocessor will output the frequency of each issue for each functional point and configuration item in the issue set, whether it affects basic business I / O, and the set of existing functional relationships.

[0133] For existing functional use cases in the baseline use case library that are related to the above-mentioned existing functional relationship set, based on their original use case level, whether they affect basic business IO, and the frequency of problems, the corresponding impact value P is calculated according to the following formula (1) with a certain weight coefficient. When the value of P is greater than or equal to 1, the use case level is adjusted to L0; when the value of P is less than 1 but greater than or equal to 0.9, the use case level is adjusted to L1; when the value is less than 0.9 but greater than or equal to 0.8, the use case level is adjusted to L2; when the value is less than 0.8 but greater than or equal to 0.7, the use case level is adjusted to L2. This optimizes the test scope of the resource pool in subsequent versions, expands the test case scope, and reduces the test leakage rate. The formula for calculating the impact value P is as follows: (1) in, The original level of the existing functional use cases is represented by the following values: L0=1, L1=0.9, L2=0.8, L3=0.7, with a weight coefficient of 1 to ensure that the use case level will only be adjusted upwards and not downwards; IO indicates whether it affects basic business IO, with 1 if it does and 0 otherwise, with a weight coefficient of 1; PF indicates the frequency of the problem, with a weight coefficient of 0.1.

[0134] Step 308: Input the newly generated standard test cases into the baseline test case library, and update the existing functional test cases with adjusted test case levels into the baseline test case library.

[0135] (2) Test Case Automation Module The test case automation module mainly involves writing automated scripts for the test cases generated in the test case generation module to automate the test case process. Figure 4 This is a flowchart illustrating the test case automation module provided in an embodiment of this application, as shown below. Figure 4 As shown, the process includes the following steps: Step 401: Input the test cases and prompts generated in the test case generation module into the test case automation processor. The test case automation processor generates the initial automated test script corresponding to the test cases under the guidance of the prompts.

[0136] The test cases generated in the test case generation module are input into the test case automation processor for automated test case implementation. The test case automation processor is mainly implemented using the Python language. It generates the initial automated test script corresponding to the test case by calling the large language model and using the input prompt words.

[0137] The test case title, test case steps, and expected test case results in the test case document are used as prompt word templates and input into the test case automation processor for the generation of the initial automated test script.

[0138] Step 402: Determine whether the test cases generated in the test case generation module are functional test cases or configuration test cases. If they are functional test cases, proceed to step 403; if they are configuration test cases, proceed to step 404.

[0139] Step 403: Input the initial automated test script corresponding to the functional test case into the functional script standardization processor. The functional script standardization processor will then template the initial automated test script corresponding to the functional test case to generate a standard automated test script.

[0140] Step 404: Input the initial automated test script corresponding to the configuration test case into the configuration script standardization processor. The configuration script standardization processor will then template the initial automated test script corresponding to the configuration test case to generate a standard automated test script.

[0141] After the initial script is automatically generated, the corresponding script standardization processor is used to template the initial automated script for functional test cases and configuration test cases. The script standardization processor is implemented in Python. It mainly modifies the test case titles in the initial automated script for functional test cases and configuration test cases, removes useless, redundant and duplicate scripts, and finally generates standard automated test cases.

[0142] Step 405: Combine the standard automated test scripts corresponding to the functional test cases and the standard automated test scripts corresponding to the configuration test cases into the automated test case library for subsequent automated execution scheduling of test cases.

[0143] (3) Test case execution module The test case execution module includes three steps: test case selection, test case scheduling, and test case execution task assignment. Figure 5 This is a flowchart illustrating the test case execution module provided in an embodiment of this application, as shown below. Figure 5As shown, the process includes the following steps: Step 501: Obtain the user's testing requirements.

[0144] Step 502: Based on the user's testing requirements, use the test case filter to filter the test cases in the baseline test case library according to the test case tags to obtain the target test cases to be executed.

[0145] a) For regular version testing: First, filter the baseline test case library based on version tags to select all levels (L0, L1, L2, L3) of new feature requirements in the preset version (e.g., v10.x). Then, filter the higher-level L0 and L1 functional test cases based on test case level tags. The functional test cases consist of two parts: all levels (L0, L1, L2, L3) of new feature requirements in the preset version, and L0 and L1 functional test cases.

[0146] b) For public cloud resource pool acceptance testing: L0 public cloud function test cases are selected based on the public cloud tag and test case level tag. Then, configuration check item test cases for the preset version are selected based on the version tag and whether configuration checks are performed. The public cloud resource pool acceptance function test cases consist of two parts: L0 public cloud function test cases and configuration check item test cases for the preset version.

[0147] c) For acceptance testing of the dedicated cloud resource pool: L0 private cloud functional test cases for dedicated requirements are selected based on the application project of the dedicated cloud (whether it is tagged as a public cloud), whether it is tagged as a customized project requirement, and the test case level tag. L0 functional test cases for basic functions are selected based on version tags and test case level tags. Configuration check test cases for a preset version are selected based on version tags and whether a configuration check tag is used. The dedicated cloud resource pool acceptance functional test cases consist of three parts: L0 private cloud functional test cases for dedicated requirements, L0 functional test cases for basic functions, and configuration check test cases for a preset version.

[0148] Step 503: Input the target test case into the test case execution scheduler. The test case execution scheduler will schedule the corresponding standard automated test script based on the target test case.

[0149] Step 504: After scheduling the standard automated test script corresponding to the target test case, issue the test case execution task to execute the standard automated test script corresponding to the target test case.

[0150] For the selected test cases, automated scheduling tasks are set up, and scheduled tasks are constructed to automatically execute the test cases at regular intervals and output the test results. This part is mainly implemented by setting up scheduled tasks using cron jobs. The automated scripts are stored in S3 objects, and the nose-htmloutput plugin is used. After the scripts run automatically, they output HTML format test reports. After execution, all test results are automatically summarized and stored in a specified directory. The automated scripts are checked against the configuration items, and scheduled cron job tasks are set up. Specific tasks are batch-distributed using Ansible to run the scripts and output the results to a specified directory for subsequent test result analysis.

[0151] The automated test case generation device based on cloud storage requirements proposed in this application addresses this gap by incorporating multiple input factors. These factors include not only test requirements and technical documents, but also orthogonal correlations between product functions, interaction correlations between current / historical / competitive benchmarking issues and functions, interface documentation, and resource pool acceptance configuration documents. Furthermore, the device uses current / historical / competitive benchmarking issues as real-time influencing factors to dynamically adjust the priority of existing test cases. It can automatically filter existing and new test cases to form a complete test case plan based on different cloud storage business requirements. This fills the gap in cloud storage technology for automatically generating test cases based on requirements, significantly improving the effectiveness and comprehensiveness of test case generation. It also allows for convenient and timely adjustments to the test case scope, reducing the test miss rate.

[0152] Figure 6 This is a schematic diagram of the test case generation device provided in the embodiments of this application, as shown below. Figure 6 As shown, the device includes: Acquisition unit 601 is used to acquire one or more test data documents input by the user.

[0153] Extraction unit 602 is used to extract text from one or more test data documents to obtain one or more test point documents.

[0154] The generation unit 603 is used to generate test cases for one or more test point documents based on the first prompt word template, so as to obtain initial test cases.

[0155] The conversion unit 604 is used to standardize and convert the initial test cases based on the test case template to obtain standard test cases.

[0156] In some embodiments, the device further includes: The adjustment unit is used to adjust the test case level of one or more target existing test cases in the baseline test case library based on one or more test data documents and second prompt word templates, so as to obtain one or more target existing test cases with adjusted test case levels.

[0157] The storage unit is used to store standard test cases and one or more target stock test cases adjusted to test case level into the baseline test case library.

[0158] In some embodiments, one or more test data documents include configuration item documents, functional requirement documents, design documents, interface documents, functional orthogonal matrix documents, complaint issue documents, historical issue documents, and competitor issue documents; one or more test point documents include configuration test point documents, basic test point documents, principle test point documents, interface test point documents, feature cross-test point documents, complaint cross-test point documents, historical issue test point documents, and competitor cross-test point documents.

[0159] In some embodiments, the extraction unit 602 is specifically used for at least one of the following: Extract the configuration check item descriptions from the configuration item document to obtain the configuration test point document; Extract descriptions of new functional requirements from the functional requirements document to obtain the basic test point document; Extract the functional requirements principle description from the design document to obtain the principle test point document; Extract the functional requirements of the interfaces and the descriptions of the interface parameters from the interface documentation to obtain the interface test point documentation; Extract the cross-description of functional characteristics from the functional orthogonal matrix document to obtain the characteristic cross-test point document; Based on the functional requirements document and the third prompt word template, the complaint issue document is used to extract the interactive descriptions of complaint issues with new and existing functions, resulting in a complaint cross-test point document. Based on the functional requirements document and the fourth prompt word template, the historical problem document is extracted to describe the interaction between historical problems, new functions, and existing functions, thus obtaining the historical problem test point document. Based on the functional requirements document, the functional differences between the competitor's issue document and the competitor's cross-test point document are extracted.

[0160] In some embodiments, the generating unit 603 is specifically used for: The configuration test point document, basic test point document, principle test point document, interface test point document, feature cross test point document, complaint cross test point document, historical issue test point document, and competitor cross test point document are deduplicated to obtain one or more deduplicated test point documents. Merge one or more deduplicated test point documents into a comprehensive test point document; Input the comprehensive test point document and the first prompt word template into the large model, so that the large model can output the specific functional points, test points, test steps, and expected test results corresponding to the comprehensive test point document under the guidance of the first prompt word template; Based on the specific functional points, test points, test steps, and expected test results corresponding to the comprehensive test point document, the initial test cases are determined.

[0161] In some embodiments, a use case template includes a use case title, use case type, use case level, use case version, use case steps, expected use case result, use case level, whether it is a project customization requirement, whether it is a configuration check, and whether it is a public cloud.

[0162] In some embodiments, the conversion unit 604 is specifically used for: Standardize the test case format by including test case title, test case type, test case level, test case steps, expected test case results, test case level, whether it is a customized requirement of the project, whether it is a configuration check, and whether it is a public cloud. Based on the standardized test case format, the initial test cases are standardized and transformed to obtain standard test cases.

[0163] In some embodiments, the adjustment unit is specifically used for: By summarizing complaint issue documents, historical issue documents, and competitor issue documents, one or more issue function points can be obtained; Input one or more problematic functional points and a second prompt word template into the large model, so that the large model, guided by the second prompt word template, outputs the frequency of occurrence of each problematic functional point, whether it affects the business operation results, and the relationship of one or more existing functions. Based on one or more existing functional relationships corresponding to each problem function point, one or more existing use cases in the baseline use case library are filtered to obtain one or more target existing use cases; Based on the frequency of occurrence of each problem function point, whether it affects the business operation results, and the relationship with one or more existing functions, the use case level of one or more target existing use cases is adjusted to obtain one or more target existing use cases after use case level adjustment.

[0164] In some embodiments, the adjustment unit is further specifically used for: Based on the frequency of occurrence of each problem function point and whether it affects the business operation results, as well as the original use case level of each target existing use case in one or more target existing use cases, the impact calculation is performed on each target existing use case to obtain the impact factor corresponding to each target existing use case. Based on the comparison results of the impact factor and impact threshold corresponding to each target stock use case, the use case level of each target stock use case is adjusted to obtain each target stock use case after use case level adjustment.

[0165] In some embodiments, the device further includes: The prediction unit is used to input standard test cases and the fifth prompt word template into the large model, so that the large model outputs the initial automated test script corresponding to the standard test cases under the guidance of the fifth prompt word template.

[0166] In some embodiments, the conversion unit 604 is further configured to perform a standardization conversion on the initial automated test script to obtain a standard automated test script.

[0167] In some embodiments, the storage unit is also used to store standard automated test scripts to an automated test case library.

[0168] In some embodiments, each test case in the baseline test case library includes a test case tag, and the automated test case library includes an automated test script corresponding to each test case.

[0169] In some embodiments, the acquisition unit 601 is also used to acquire the user's test requirements.

[0170] In some embodiments, the device further includes: The filtering unit is used to filter one or more test cases in the baseline test case library based on test requirements and test case tags in each test case, to obtain one or more target test cases.

[0171] The settings unit is used to configure automated scheduling tasks and timed tasks.

[0172] The execution unit is used to execute the automated test script corresponding to each target test case in one or more target test cases based on automated scheduling tasks and timed tasks, and obtain the test results corresponding to each target test case.

[0173] The summary unit is used to summarize the test results corresponding to each target test case to obtain the comprehensive test results.

[0174] In some embodiments, the storage unit is also used to store the comprehensive test results to a preset directory.

[0175] In some embodiments, use case tags include version tags, grade tags, whether it is a project customization requirement tag, whether it is a configuration check tag, and whether it is a public cloud tag.

[0176] In some embodiments, the filtering unit is specifically used for at least one of the following: When the testing requirement is a regular version test, one or more test cases in the baseline test case library are filtered based on version tags to obtain one or more functional test cases for the preset version. Then, one or more test cases for the preset version are filtered based on level tags to obtain one or more functional test cases for the preset version and preset test case level. The one or more functional test cases for the preset version and preset test case level are used as one or more target test cases. When the testing requirement is acceptance testing of a public cloud resource pool, one or more test cases are filtered based on whether it is a public cloud tag and level tag to obtain one or more public cloud function test cases of the preset test case level, and one or more test cases are filtered based on version tag and whether configuration check tag to obtain one or more configuration check test cases of the preset version; and one or more public cloud function test cases of the preset test case level and one or more configuration check test cases of the preset version are used as one or more target test cases. When the testing requirement is acceptance testing of a private cloud resource pool, one or more test cases are filtered based on whether they are public cloud tags, whether they are project-customized requirement tags, and level tags to obtain one or more private cloud functional test cases with preset project requirements and preset test case levels. One or more test cases are also filtered based on version tags and level tags to obtain one or more functional test cases with preset versions and preset test case levels. Finally, one or more test cases are filtered based on version tags and whether they are configuration check tags to obtain one or more configuration check test cases with preset versions. The one or more private cloud functional test cases with preset project requirements and preset test case levels, the one or more functional test cases with preset versions and preset test case levels, and the one or more configuration check test cases with preset versions are used as one or more target test cases.

[0177] Those skilled in the art should understand that Figure 6 The functions of each unit in the communication device shown can be understood by referring to the relevant description of the aforementioned method. Figure 6 The functions of each unit in the communication device shown can be implemented by a program running on a processor or by specific logic circuits.

[0178] Figure 7 This is a schematic diagram of the processing device provided in an embodiment of this application. The processing device may be a terminal device or a network device. Figure 7 The processing device shown includes a processor 701, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0179] Optionally, such as Figure 7As shown, the processing device may further include a memory 702. The processor 701 can retrieve and run computer programs from the memory 702 to implement the methods described in this embodiment.

[0180] The memory 702 can be a separate device independent of the processor 701, or it can be integrated into the processor 701.

[0181] Optionally, such as Figure 7 As shown, the processing device may also include a transceiver 703, which the processor 701 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0182] The transceiver 703 may include a transmitter and a receiver. The transceiver 703 may further include an antenna, which may be one or more.

[0183] The processing device may specifically be the test case generation device of the embodiments of this application, and the processing device may implement the corresponding processes of the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0184] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0185] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0186] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to the processing device in this application embodiment, and the computer program causes the computer to execute the corresponding processes implemented by the various methods in this application embodiment; for brevity, further details are omitted here.

[0187] This application also provides a computer program product, including computer program instructions. This computer program product can be applied to the processing device in this application embodiment, and the computer program instructions cause the computer to execute the corresponding processes implemented by the various methods in this application embodiment; for brevity, further details are omitted here.

[0188] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0189] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0190] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0191] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0192] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0193] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0194] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A test case generation method, characterized in that, The method includes: Obtain one or more test data documents input by the user, and extract text from the one or more test data documents to obtain one or more test point documents; Based on the first prompt word template, test cases are generated from the one or more test point documents to obtain initial test cases; The initial test cases are standardized and transformed based on the test case template to obtain standard test cases.

2. The method according to claim 1, characterized in that, The method further includes: Based on the one or more test data documents and the second prompt word template, the test case level of one or more target stock test cases in the baseline test case library is adjusted to obtain one or more target stock test cases with adjusted test case levels. Store the standard test cases and one or more target existing test cases after the test case level adjustment to the baseline test case library.

3. The method according to claim 2, characterized in that, The one or more test data documents include configuration item documents, functional requirement documents, design documents, interface documents, functional orthogonal matrix documents, complaint issue documents, historical issue documents, and competitor issue documents; the one or more test point documents include configuration test point documents, basic test point documents, principle test point documents, interface test point documents, feature cross-test point documents, complaint cross-test point documents, historical issue test point documents, and competitor cross-test point documents.

4. The method according to claim 3, characterized in that, The text extraction of one or more test data documents to obtain one or more test point documents includes at least one of the following: The configuration check item descriptions are extracted from the configuration item document to obtain the configuration test point document; The basic test point document is obtained by extracting new functional requirement descriptions from the functional requirement document. The functional requirements principle description is extracted from the design document to obtain the principle test point document; The interface document is used to extract the functional requirements support interfaces and interface parameter descriptions to obtain the interface test point document; The functional characteristic cross-description is extracted from the functional orthogonal matrix document to obtain the characteristic cross-test point document; Based on the functional requirements document and the third prompt word template, the complaint issue document is used to extract the interactive descriptions of complaint issues with new and existing functions to obtain the complaint cross-test point document. Based on the functional requirements document and the fourth prompt word template, the historical problem document is extracted to describe the interaction between historical problems, new functions, and existing functions, so as to obtain the historical problem test point document. Based on the functional requirements document, the functional differences between the competitor's issue document and the competitor's cross-test point document are extracted.

5. The method according to claim 4, characterized in that, The process of generating test cases based on the first prompt word template for the one or more test point documents to obtain initial test cases includes: The configuration test point document, basic test point document, principle test point document, interface test point document, feature cross test point document, complaint cross test point document, historical issue test point document, and competitor cross test point document are deduplicated to obtain one or more deduplicated test point documents. Merge one or more deduplicated test point documents into a comprehensive test point document; The comprehensive test point document and the first prompt word template are input into the large model, so that the large model outputs the specific functional points, test points, test steps, and expected test results corresponding to the comprehensive test point document under the guidance of the first prompt word template. Based on the specific functional points, test points, test steps, and expected test results corresponding to the comprehensive test point document, the initial test cases are determined.

6. The method according to claim 5, characterized in that, The test case template includes the test case title, test case type, test case level, test case version, test case steps, expected test case result, test case level, whether it is a customized requirement for the project, whether it is a configuration check, and whether it is a public cloud. The standardization transformation of the initial test cases based on the test case template to obtain standard test cases includes: The test case title, test case type, test case level, test case steps, expected test case result, test case level, whether it is a project customization requirement, whether it is a configuration check, and whether it is a public cloud are used as standardized test case formats. The initial test cases are then standardized and transformed based on the standardized test case formats to obtain the standard test cases.

7. The method according to claim 3, characterized in that, The step involves adjusting the test case levels of one or more target existing test cases in the baseline test case library based on the one or more test data documents and the second prompt word template, to obtain one or more target existing test cases with adjusted test case levels, including: The complaint issue documents, the historical issue documents, and the competitor issue documents are summarized to obtain one or more issue function points; Input one or more problematic functional points and the second prompt word template into the large model, so that the large model, guided by the second prompt word template, outputs the frequency of occurrence of each problematic functional point, whether it affects the business operation results, and the relationship of one or more existing functions; Based on one or more existing functional relationships corresponding to each problem function point, one or more existing use cases in the baseline use case library are filtered to obtain one or more target existing use cases; Based on the frequency of occurrence of each problem function point, whether it affects the business operation results, and the relationship between one or more existing functions, the use case level of the one or more target existing use cases is adjusted to obtain one or more target existing use cases after the use case level is adjusted.

8. The method according to claim 7, characterized in that, Based on the frequency of occurrence of each problematic function point, whether it affects the business operation result, and one or more existing function relationships, the use case level of the one or more target existing use cases is adjusted to obtain one or more target existing use cases after the use case level adjustment, including: Based on the frequency of occurrence of each problem function point and whether it affects the business operation results, as well as the original use case level of each target existing use case in the one or more target existing use cases, the impact calculation is performed on each target existing use case to obtain the impact factor corresponding to each target existing use case. Based on the comparison results of the impact factor and impact threshold corresponding to each target stock use case, the use case level of each target stock use case is adjusted to obtain each target stock use case after the use case level is adjusted.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: The standard test cases and the fifth prompt word template are input into the large model, so that the large model outputs the initial automated test script corresponding to the standard test cases under the guidance of the fifth prompt word template. The initial automated test script is standardized to obtain a standard automated test script; Store the standard automated test scripts in the automated test case library.

10. The method according to claim 9, characterized in that, Each test case in the baseline test case library includes a test case tag, and the automated test case library includes an automated test script corresponding to each test case; the method further includes: Obtain the user's testing requirements, and filter one or more test cases in the baseline test case library based on the testing requirements and the test case tags in each test case to obtain one or more target test cases; Set up automated scheduling tasks and timed tasks, and execute the automated test scripts corresponding to each target test case in the one or more target test cases based on the automated scheduling tasks and timed tasks to obtain the test results corresponding to each target test case; The test results corresponding to each target test case are summarized to obtain a comprehensive test result, and the comprehensive test result is stored in a preset directory.

11. The method according to claim 10, characterized in that, The use case tags include version tags, level tags, whether it is a project customization requirement tag, whether it is a configuration check tag, and whether it is a public cloud tag; The step involves filtering one or more test cases in the baseline test case library based on the test requirements and the test case tags in each test case to obtain one or more target test cases, including at least one of the following: When the test requirement is a regular version test, one or more test cases in the baseline test case library are filtered based on the version tag to obtain one or more functional test cases of the preset version, and one or more test cases of the preset version are filtered based on the level tag to obtain one or more functional test cases of the preset version and preset test case level. And use one or more functional test cases of the preset version and preset test case level as the one or more target test cases; When the test requirement is a public cloud resource pool acceptance test, the test cases are filtered based on the public cloud label and the level label to obtain one or more public cloud function test cases of the preset test case level, and the test cases are filtered based on the version label and the configuration check label to obtain one or more configuration check test cases of the preset version. And one or more public cloud function test cases of the preset test case level and one or more configuration check test cases of the preset version are used as the one or more target test cases; When the test requirement is a private cloud resource pool acceptance test, the test cases are filtered based on the public cloud tag, the project customization requirement tag, and the level tag to obtain one or more private cloud functional test cases with preset project requirements and preset test case levels. The test cases are also filtered based on the version tag and the level tag to obtain one or more functional test cases with preset versions and preset test case levels. Finally, the test cases are filtered based on the version tag and the configuration check tag to obtain one or more configuration check test cases with preset versions. The preset project requirements and preset use case levels, one or more private cloud functional test cases, the preset version and preset use case levels, and one or more configuration check test cases of the preset version are used as the one or more target test cases.

12. A test case generation device, characterized in that, The device includes: The acquisition unit is used to acquire one or more test data documents input by the user; The extraction unit is used to extract text from the one or more test data documents to obtain one or more test point documents. The generation unit is used to generate test cases for the one or more test point documents based on the first prompt word template, so as to obtain initial test cases; The conversion unit is used to standardize and convert the initial test cases based on the test case template to obtain standard test cases.

13. A processing apparatus, characterized in that, include: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 11.

Images