Test case processing method, electronic device, and program product

Abstract

The present disclosure provides a test case processing method, an electronic device and a program product. The method of the present disclosure comprises: in response to a request for exporting at least part of test cases in a first requirement use case, creating a module use case decoupled from the first requirement use case; storing the module use case in a module use case library; in response to an import request for importing test cases into a second requirement use case, finding a target module use case from the module use case library; importing the test case content in the target module use case into the second requirement use case, and establishing an association relationship between the second requirement use case and the target module use case.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to test case processing methods, electronic devices, and program products. Background Technology

[0002] In software testing, test cases are core assets for ensuring the quality of business requirement delivery. Testers typically write a set of test cases for each business requirement based on requirements documents and technical solutions, and organize and manage the test cases by requirements.

[0003] In existing test case management methods, testers often create test cases directly around a specific business requirement, forming a strong dependency between the test cases and the requirement. When facing complex business scenarios with continuous iteration and parallel delivery of multiple requirements, this single-requirement-centric management approach is prone to various problems. For example, testers create test cases independently for each business requirement, and the design perspective of the test cases is only based on the current requirement, making it difficult to assess the impact of changes on the entire business chain from a global business perspective, which can easily lead to insufficient test coverage of related functional modules. Furthermore, there are also problems such as difficulty in updating and reusing test cases. Therefore, a solution that can achieve efficient test case management is needed. Summary of the Invention

[0004] This disclosure provides test case processing methods, electronic devices, and program products.

[0005] According to a first aspect of this disclosure, a test case processing method is provided. The method includes: in response to a request to export at least a portion of test cases from a first requirement test case, creating module test cases decoupled from the first requirement test case; storing the module test cases in a module test case library; in response to an import request to import test cases into a second requirement test case, retrieving a target module test case from the module test case library; importing the test case content from the target module test case into the second requirement test case, and establishing an association between the second requirement test case and the target module test case.

[0006] According to the aforementioned disclosure, by decoupling some test cases from requirement test cases and exporting them as independent module test cases, which are then centrally stored in a module test case library, other requirements can be retrieved and reused. During import, the association between requirements and module test cases is established, improving the utilization rate of test cases. By creating module test case entities that are decoupled from individual requirements and can be stored and managed independently, high-quality test assets originally scattered across various temporary requirement test cases are exported as common knowledge units in the module test case library. Furthermore, module test cases represent complete and stable business function test sets. Reusing and combining module test cases to generate new requirement test cases helps testers build better and more comprehensive test cases more quickly.

[0007] In at least one embodiment of this disclosure, after importing the test case content from the target module test case into the second requirement test case, the method further includes: in response to a modification request for the test case content from the target module test case imported into the second requirement test case, determining and saving the modified test case content; creating the modified test case content as a requirement-related version, and assigning a requirement-related version identifier.

[0008] In at least one embodiment of this disclosure, in response to a request to export at least a portion of the test cases in a first requirement use case, creating a module use case decoupled from the first requirement use case includes: obtaining a request to export at least a portion of the test cases in the first requirement use case; determining a target node corresponding to the node identifier and at least a portion of the target test case content contained in the target node based on at least one node identifier contained in the export request; and creating the target test case content as a module use case based on the business direction specified in the export request.

[0009] In at least one embodiment of this disclosure, storing module test cases in a module test case library includes: determining whether the module test case library contains a baseline version with the same test case content as the module test cases; if not, storing the module test cases as a baseline version in the module test case library, and assigning a module identifier and a baseline version identifier to the module test cases.

[0010] In at least one embodiment of this disclosure, after the modified test case content is created as a requirement-related version, the process includes: obtaining the module identifier, base version identifier, and requirement-related version identifier of the target module test case; writing the module identifier, base version identifier, and requirement-related version identifier into the intro node of the second requirement test case to establish the association between the requirement-related version and the base version of the target module test case; and establishing the association between the requirement-related version and the second requirement test case.

[0011] In at least one embodiment of this disclosure, the method further includes: detecting the business launch requirement corresponding to the second requirement use case; querying the requirement association version that corresponds to the requirement association version identifier from the module use case library according to the requirement association version identifier associated with the second requirement use case; and merging the requirement association version into the base version of the target module use case in the module use case library according to a preset merging rule so as to iteratively update the target module use case.

[0012] In at least one embodiment of this disclosure, according to a preset merging rule, the requirement-related version is merged into the base version of the target module use case in the module use case library to iteratively update the target module use case, including: comparing the requirement-related version with the base version according to the node identifier; if the requirement-related version corresponding to the same node identifier contains use case content not included in the base version, then the use case content is added to the base version; if the requirement-related version corresponding to the same node identifier does not contain use case content included in the base version, then the base version is retained.

[0013] In at least one embodiment of this disclosure, the generation of the first requirement use case includes: obtaining the requirement document and technical solution corresponding to the target business requirement; and generating the first requirement use case based on the requirement document and technical solution.

[0014] According to a second aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, such that the processor performs the method described in the first aspect of any embodiment of this disclosure.

[0015] According to a third aspect of this disclosure, a readable storage medium is provided, wherein executable instructions are stored therein, which, when executed by a processor, are used to implement the method described in the first aspect of any embodiment of this disclosure.

[0016] According to a fourth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method described in the first aspect of any embodiment of this disclosure. Attached Figure Description

[0017] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0018] Figure 1 This is a flowchart illustrating the test case processing method provided in an embodiment of this disclosure.

[0019] Figure 2 This is a flowchart illustrating the test case modification method provided in an embodiment of this disclosure.

[0020] Figure 3 This is a flowchart illustrating the module use case export method provided in an embodiment of this disclosure.

[0021] Figure 4 This is a flowchart illustrating the module use case storage method provided in an embodiment of this disclosure.

[0022] Figure 5 This is a flowchart illustrating the association creation method provided in the embodiments of this disclosure.

[0023] Figure 6 A flowchart illustrating the module use case iterative update method provided in this embodiment of the disclosure.

[0024] Figure 7 This is a flowchart illustrating an iterative update method as exemplified by an embodiment of the present disclosure.

[0025] Figure 8 A flowchart illustrating the first requirement use case generation method provided in this embodiment of the disclosure.

[0026] Figure 9 This is a schematic block diagram of the structure of a test case processing device according to one embodiment of the present disclosure.

[0027] Figure 10 This is a schematic diagram illustrating the test case processing flow as an example of this disclosure.

[0028] Figure 11 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure. Detailed Implementation

[0029] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0030] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0031] Figure 1 This is a flowchart illustrating the test case processing method provided in an embodiment of this disclosure. Figure 1 The method shown includes steps S101 to S104. This method can be applied to the server side (e.g., local server, cloud server, etc.).

[0032] Specifically, Figure 1 The method shown includes step S101: in response to a request to export at least a portion of the test cases in the first requirement use case, creating a module use case decoupled from the first requirement use case.

[0033] It's important to clarify that the requirement use cases mentioned here refer to a collection of test cases tailored to a specific business requirement. Requirement use cases are typically organized in a tree structure, consisting of multiple nodes, each corresponding to one or more test cases. Requirement use cases are attached to their corresponding business requirements, and their lifecycle is linked to those requirements. For example, all the test cases written for optimizing the user registration function constitute one set of requirement use cases. The "first requirement use case" and "second requirement use case" do not refer to a specific set of requirement use cases, but rather are distinctions made for different stages and roles of requirement use cases to facilitate describing the solution process. The first requirement use case is the source of the export operation, i.e., test cases are exported from this requirement use case to create module use cases; the second requirement use case is the target of the import operation, i.e., existing target module use cases are imported into this requirement use case. The decoupling mentioned here refers to severing the direct binding relationship between the module use case and its source, the first requirement use case, so that the module use case exists as an independent use case, and changes or deletions of the original requirement use case do not affect the validity of the module use case.

[0034] In testing applications, when a specific requirement use case contains test cases with high reusability (such as common processes like login authentication and payment processing), testers can initiate export requests for these test case contents. It's important to note that this test case export is not a simple data copying process, but rather a decoupling process that creates independent module test cases. Specifically, the system extracts at least a portion of the test case content specified in the export request, encapsulates it as an independent module test case, and severs its direct data structure dependency from the primary requirement use case. This transforms test cases from private assets of a single requirement into globally shareable public assets, eliminating the strong dependency of test cases within a specific requirement use case on specific test scenarios or requirement use cases. This allows general-purpose test cases to be stored independently as independent entities for a long period, meeting reuse requirements.

[0035] Step S102: Store the module test cases in the module test case library.

[0036] It should be noted that the module test case library mentioned here refers to a database or storage space used to centrally store and manage test cases for various modules, providing services such as retrieval and version control of module test cases.

[0037] The module use case library serves as a central hub for use case assets, providing unified management of module use cases. For example, relational databases or distributed document databases can be used for structured storage of module use cases, assigning them unique storage indexes for subsequent retrieval. This provides a standardized, centralized storage environment for module use cases, laying the foundation for rapid retrieval and reuse across different requirements.

[0038] Step S103: In response to the import request to import test cases into the second requirement test case, locate the target module test case from the module test case library.

[0039] It should be noted that the target module use case mentioned here refers to the module use case entity that meets the import requirements and is retrieved from the module use case library in the import scenario.

[0040] When new business requirements (i.e., second requirement test cases) need to reuse existing test logic, testers no longer need to write from scratch or manually copy across requirements. Instead, they send an import request to the system. The system parses the search criteria (such as module name, business tags, etc.) carried in the import request and performs a search and match in the module test case library, thereby accurately locating the required target module test case. Utilizing the previously established module test case library makes test case acquisition more accurate and convenient, greatly improving the efficiency and accuracy of test case reuse.

[0041] Step S104: Import the test case content from the target module test case into the second requirement test case, and establish the association between the second requirement test case and the target module test case.

[0042] It should be noted that the relationship mentioned here refers to the mapping and binding relationship between the test case content introduced in the second requirement test case and its source target module test case. This relationship provides the basis for subsequent version tracing, difference comparison and automatic merging.

[0043] The system extracts all test case content from the baseline version of the target module's test cases and imports this content completely into the import node pre-selected by the quality assurance personnel of the second requirement test cases. Simultaneously, the system writes the module identifier of the target module's test cases into this import node, thus establishing a clear and traceable binding relationship between the node of the second requirement test cases and the target module's test cases in the module test case library. This association ensures that the imported test case content in the second requirement test cases is no longer an isolated copy, but a dynamically linked, readily referenceable test case connected to a public knowledge base. Furthermore, it allows for updates and version synchronization of the module test case content as needed.

[0044] Based on the publicly available solutions described above, by decoupling some test cases from requirement test cases and exporting them as independent module test cases, which are then centrally stored in a module test case library, other requirements can be retrieved and reused. Furthermore, the association between requirements and module test cases is established during import, improving the utilization rate of test cases. By creating module test case entities that are decoupled from individual requirements and can be stored and managed independently, high-quality test assets originally scattered across various temporary requirement test cases are exported as common knowledge units in the module test case library. Moreover, module test cases represent complete and stable business function test sets. Reusing and combining module test cases to generate new requirement test cases helps testers to build better and more comprehensive test cases more quickly.

[0045] In one or more embodiments of this disclosure, such as Figure 2 This is a flowchart illustrating the test case modification method provided in an embodiment of this disclosure. Figure 2 As shown, after importing the test case content from the target module test case into the second requirement test case, the method further includes: Step S201: In response to a modification request for the test case content from the target module test case imported into the second requirement test case, determine and save the modified test case content. Step S202: Create the modified test case content as a requirement-related version and assign a requirement-related version identifier.

[0046] In practical applications, quality assurance personnel use the editing interface of the second requirement test case to add, delete, or modify the test case content referenced under the import node, and then initiate a save command. This save command is a specific form of modification request. After receiving the modification request, the system compares the current test case content under the import node with the original test case content at the time of import to determine which test case content has changed. If the modified test case content has subsequent reuse value (i.e., there is a possibility of subsequent reuse), the save operation is performed, and the modified test case content is persistently stored.

[0047] The requirement-associated version mentioned here refers to a specific content version of the target module's test cases, formed after modification and adaptation during a specific requirement's testing process. This requirement-associated version fully encompasses all test cases introduced by the module's test cases in this requirement, including both the unmodified parts inherited from the original baseline version and the parts added or modified in this requirement. In other words, the requirement-associated version is a complete set of test case content for the target module's test cases in this second requirement. The requirement-associated version identifier is a unique identifier assigned by the system to this newly created requirement-associated version, used to uniquely locate and index this version in the module test case library. By preserving the complete modified form of the module test cases in this requirement, it is solidified into a traceable and manageable independent version entity. This requirement-associated version object is associated with the target module's test cases through its module identifier and belongs to the same target module's test case object in the module test case library. Therefore, multiple versions of the target module's test cases may exist simultaneously in the library, such as the initially exported baseline version and the requirement-associated version generated in this step, forming a clear version evolution tree.

[0048] Based on the publicly available solutions described above, temporary modifications to imported module test cases within a single requirement are transformed into a persistent and traceable requirement-related version within the module test case library. Creating a requirement-related version with an independent identifier, rather than simply overwriting the original node, allows for independent querying, comparison, and merging of the modification, facilitating the accumulation and maintenance of the modified test case content.

[0049] In one or more embodiments of this disclosure, such as Figure 3 This is a flowchart illustrating the module use case export method provided in an embodiment of this disclosure. Figure 3 As shown, in response to a request to export at least a portion of the test cases in the first requirement test case, a module test case decoupled from the first requirement test case is created, including: Step S301: Obtaining a request to export at least a portion of the test cases in the first requirement test case. Step S302: Based on at least one node identifier contained in the export request, determining the target node corresponding to the node identifier and at least a portion of the target test case content contained in the target node. Step S303: Based on the business direction specified in the export request, creating the target test case content as a module test case.

[0050] It should be noted that the node identifier mentioned here refers to the identity information used to uniquely identify a specific logical node (such as a test step node or test scenario node) in the test case tree structure. The target node refers to the logical node corresponding to the aforementioned node identifier that is selected to perform the export operation. The target test case content refers to the substantive test data contained within the target node, including but not limited to test steps, expected results, and preconditions. The business direction refers to the semantic tags used to characterize the business domain or functional category to which the test case belongs, such as payment chain or account system, which are used to classify and delineate module test cases based on business dimensions.

[0051] In practical applications, after the first requirement use case is written and tested, its tree structure is reviewed. Based on the assessment of the cohesion and reusability of the business functions, one or more reusable nodes in the tree structure are selected, and an export command is initiated through the interactive interface, thus obtaining the export request. This export request carries relevant information about the selected object to be exported, including the identifier of the selected node and the specified business direction.

[0052] Furthermore, the system parses one or more node identifiers carried in the export request, performs precise retrieval and positioning within the data structure of the first requirement test case, and identifies the corresponding target node. It then traverses downwards through the child node tree of the target node to obtain all test case content contained under that target node. In an optional approach, filtering conditions, such as test case level or test case tag, can be specified when initiating the export request. The system will then filter the test cases under the target node accordingly, obtaining only the portion that meets the conditions as the target test case content. This fine-grained content determination mechanism based on node identifiers breaks through the limitations of traditional technologies that can only copy entire blocks of data. It can accurately extract the required test logic fragments (i.e., a specific required test case) from a complex test case tree, effectively eliminating redundant context unrelated to reuse.

[0053] Furthermore, after determining the content of the target test case, the system does not simply export or copy it as free text, but performs a data reconstruction process. Specifically, the system generates a new data object with a globally unique module identifier, which is the module test case. The system uses the target test case content extracted from the target node as the initial content of this module test case. The user-specified business direction is used as a classification attribute and associated with the module test case for storage, thereby determining the business classification and storage location of the module test case in the module test case library. The creation of the module test case here is actually a decoupling from the first requirement test case: at the storage level, the newly created module test case object is stored in an independent module test case library, and its lifecycle management is no longer affected by the archiving, deletion, or other state changes of the first requirement test case; at the reference relationship level, the system writes the aforementioned module identifier on the original target node of the first requirement test case, thereby converting a container node that originally directly stored the specific test case content into a reference pointer pointing to the module test case in the module test case library, thus completing the reconstruction from a tightly coupled subordinate relationship to a decoupled reference relationship. By introducing business direction as an inherent attribute of module use cases, the newly created module use cases have semantic delimitation of the business dimension, making them categorized and searchable structured use cases in the module use case library.

[0054] Based on the publicly available solutions described above, by parsing the node identifiers in the export request, fine-grained and precise location and extraction of target nodes and target test case content within the first requirement test case are achieved. Simultaneously, by creating module test cases based on specified business directions and combining this with the decoupling and refactoring of the storage and reference layers, the extracted content is endowed with clear business semantic attributes and a lifecycle independent of the original requirement. It is precisely because of the fine-grained extraction based on node identifiers and the semantic creation and decoupling based on business directions that module test cases can accurately extract redundant context and possess categorizable and searchable domain attributes. This solves the technical problems of coarse-grained test case reuse, lack of business semantics in reusable assets, difficulty in managing reusable assets, and inefficient retrieval in existing technologies.

[0055] In one or more embodiments of this disclosure, such as Figure 4 This is a flowchart illustrating the module use case storage method provided in an embodiment of this disclosure. Figure 4 As shown, storing module test cases in the module test case library includes: Step S401: Determine whether the module test case library contains a baseline version with the same test case content as the module test case. Step S402: If not, store the module test case as a baseline version in the module test case library, and assign a module identifier and a baseline version identifier to the module test case.

[0056] It's important to note that the "baseline version" mentioned here refers to the standard module test case version in the module test case library. It represents a validated and currently most stable snapshot of test logic for a specific business direction, serving as the reference for subsequent version comparisons, difference merging, and cross-requirement reuse. The "module identifier" refers to a globally unique identifier assigned to a newly added module test case, used to uniquely identify a module test case entity in the module test case library, representing a specific business test module. The "baseline version identifier" is a unique identifier assigned by the system to this baseline version, used to uniquely identify this baseline version snapshot across multiple versions of the module test case, distinguishing different iteration states of the same module.

[0057] In practical applications, the test case content of the module test cases to be stored is parsed and compared with the content of various baseline versions already existing in the module test case library. The "identical test case content" referred to here means that the two test case contents essentially point to the same test logic for the same business function. The comparison dimensions can include substantive logical data such as test step sequences, operation paths, and expected results.

[0058] In one optional approach, the system can compare test case content by calculating similarity hash values ​​or key feature fingerprints. In another optional approach, the system can assist in judgment by checking whether a module identifier has been written to the source node of the module test case. If a module identifier already exists on that node, it indicates that the test case content corresponding to that node has been previously exported, and a corresponding baseline version already exists in the module test case library. Before accumulating module test cases, it is necessary to confirm whether the business logic already has a standard record. This effectively intercepts redundant data and ensures the uniqueness of standard assets within the module test case library.

[0059] If the judgment result is "yes," meaning the module test case library already contains a baseline version with the same test case content as the current module test case, it indicates that the business logic already has an official standard record. In this case, the system refuses to create a duplicate baseline version to avoid data redundancy. The system can notify quality assurance personnel that the content already exists and guide them to directly import the existing baseline version for reuse. This effectively avoids the problems of module test case library redundancy and version fragmentation caused by quality assurance personnel repeatedly exporting test cases for the same business function from different requirements.

[0060] If the judgment result is "no," meaning the module test case library does not contain a baseline version with the same test case content as the current module test case, it indicates that the business logic has not yet established an official standard in the module test case library. In this case, the system stores the module test case as a baseline version in the module test case library and assigns a module identifier and a baseline version identifier to the module test case. Further, the system can continue to perform the following operations: First, assign a globally unique module identifier to the module test case object. This module identifier will serve as the permanent identity identifier of the module test case in the module test case library, used for subsequent retrieval, referencing, and association. It identifies the globally unique family of the module in the module test case library. Second, assign a baseline version identifier to the initial content stored this time, indicating that this version is the initial baseline version of the module test case. It identifies the version number of the content as the first official snapshot within the family. Third, persistently store the module test case object and its contained test case content, module identifier, baseline version identifier, business direction, and other metadata in the module test case library. For example, a module use case table and a version record table can be created in the database. Content is written to the version record table, and the module identifier and the base version identifier are stored as a composite primary key or index field. This module use case becomes the starting point for the evolution of this business function in the module use case library. All subsequent versions of requirements based on this module use case will be managed around this base version.

[0061] Based on the publicly available solutions described above, standardized management of module test cases is achieved by introducing an existence check for the baseline version during the database entry process. It is precisely because of this technical feature—first checking if a baseline version with the same content already exists, and only creating a new baseline version and assigning a module identifier and baseline version identifier if it doesn't already exist—that the module test case library avoids meaningless duplication and ensures that the same business logic has one and only one authoritative baseline version for reference. This achieves streamlined management of test cases.

[0062] In one or more embodiments of this disclosure, such as Figure 5 This is a flowchart illustrating the association creation method provided in the embodiments of this disclosure. Figure 5 As shown, after creating the modified test case content as a requirement-related version, the process includes: Step S501: Obtaining the module identifier, base version identifier, and requirement-related version identifier of the target module test case. Step S502: Writing the module identifier, base version identifier, and requirement-related version identifier into the introductory node of the second requirement test case to establish the association between the requirement-related version and the base version of the target module test case. And, Step S503: Establishing the association between the requirement-related version and the second requirement test case.

[0063] It should be noted that the "introduction node" mentioned here refers to a specific node in the test case tree structure of the second requirement test case, used to carry the test case content imported from the module test case library.

[0064] In practical applications, when establishing relationships, the system needs to collect key identity information required to construct a complete relationship chain. Specifically, the module identifier identifies the original module use case to which the customized version belongs; the base version identifier identifies the original standard version that the customized version depends on when it is derived; and the requirement-related version identifier identifies the currently generated customized version itself. The system obtains these three identifiers from the module use case library and the current operation context, preparing the data foundation for establishing multi-dimensional index relationships at the introductory nodes.

[0065] Furthermore, at the smallest granularity of the data structure, namely the introductory node, three key pieces of information are simultaneously recorded: "which module identifier does it belong to", "which base version it is derived from (base version identifier)" and "which customized version it is currently (requirement-related version identifier)".

[0066] By writing the base version identifier and the requirement-related version identifier side-by-side into the same import node, cross-version association between the updated version and the base version is achieved. In other words, even if the node content undergoes deep customization modifications, the import node still retains the identifier information pointing to its original base version. This design allows the subsequent system to accurately determine the comparison benchmark during automatic merging, calculating the differences between the modified content pointed to by the requirement-related version identifier and the original content pointed to by the base version identifier. This solves the problem in existing technologies where modifications result in a loss of connectivity and the inability to perform accurate difference comparisons.

[0067] Furthermore, in addition to establishing source attribution relationships between versions at the node level, the system also establishes attribution relationships between customized versions and business requirements at the macro level. In specific implementation, the system maps and binds the requirement identifier of the second requirement test case to the requirement's associated version identifier, recording which specific requirement generated the associated version. This allows for the construction of an efficient search channel for customized versions by reverse lookup from requirements. In complex collaborative testing scenarios, a requirement often customizes multiple module test cases, generating multiple requirement-related versions. When this requirement goes live, the system needs to find all related versions to be merged with a single click for automatic merging. By establishing a clear mapping relationship between requirement identifiers and requirement-related version identifiers, the system can use the requirement identifier as an index to directly query all requirement-related versions associated with the requirement from the module test case library, solving the problem of inefficient retrieval and batch processing caused by the lack of business attribution for customized versions in existing technologies.

[0068] Based on the publicly available solutions described above, by simultaneously writing module identifiers, baseline version identifiers, and requirement-related version identifiers into the introduced nodes, and establishing a macroscopic association between requirement-related versions and second requirement use cases, a three-dimensional association network is constructed from nodes to versions and from versions to requirements. It is precisely because of this dual-version association mechanism—which retains both the baseline version identifier and the requirement-related version identifier in parallel at the nodes—and the establishment of a mapping relationship between requirement identifiers and requirement-related version identifiers, that customized use cases retain a complete traceability baseline and possess a clear business affiliation. This solves the problems in existing technologies where modified use cases become data silos, the source baseline cannot be traced, and the version to be merged cannot be efficiently retrieved according to the requirement dimension.

[0069] In one or more embodiments of this disclosure, such as Figure 6 This is a flowchart illustrating the module use case iterative update method provided in an embodiment of this disclosure. Figure 6 As shown, it also includes: Step S601: Detecting the business deployment requirement corresponding to the second requirement use case. Step S602: Based on the requirement association version identifier associated with the second requirement use case, querying the requirement association version that corresponds to the requirement association version identifier from the module use case library. Step S603: According to the preset merging rules, merging the requirement association version into the base version of the target module use case in the module use case library for iterative updates of the target module use case.

[0070] The preset merging rules mentioned here refer to the logical strategies pre-configured by the system to determine how to integrate the customized content in the requirement-related version with the baseline version in the module use case library. The purpose is to ensure that the baseline version does not lose its original general logic while absorbing the customized logic.

[0071] In practical applications, the system monitors requirement status change events in the R&D process in real time. For example, the test case management platform interfaces with the requirement management or continuous integration system. The system can subscribe to requirement deployment topic messages in a message queue (such as Kafka) or poll the status interface of the requirement management system. When a signal indicating that the business requirement corresponding to the second requirement test case has been released and deployed is received, the system confirms that the business requirement corresponding to the second requirement test case has been officially deployed, thus triggering the subsequent merging process. If the deployment requirement is not detected, it indicates that the customized logic of the requirement has not yet undergone complete business verification, and the system does not trigger the merging operation to avoid unverified logic polluting the baseline version of the module test case library. This solution uses the objective and irreversible business event of requirement deployment as the sole triggering condition, ensuring that only customized logic that has undergone actual business verification will enter the merging process, fundamentally solving the problem of delayed test case library updates caused by forgetting.

[0072] Furthermore, once the merge process is triggered, the system extracts the requirement-related version identifier associated with the requirement based on the established relationship between the requirement-related version and the second requirement use case. Then, using this requirement-related version identifier as an index, a query operation is performed in the module use case library to accurately locate and extract the complete data of the requirement-related versions stored in the library that have a mapping relationship with this identifier. When the second requirement use case modifies multiple target module use cases during testing, multiple requirement-related versions will exist in the system, each associated with the second requirement use case through its requirement-related version identifier. The system can query all requirement-related versions corresponding to the requirement at once, forming a set of versions to be merged. Utilizing the structured association data link built in the preceding steps, accurate and batch retrieval of customized versions is achieved. Direct location via identifier and batch querying using the requirement-related version identifier as an index effectively solves the problems of difficult, inefficient, and easily overlooked data collection for merging.

[0073] Furthermore, after retrieving the set of related versions of the requirements to be merged, the system performs a merge operation on each related version of the requirements and its corresponding base version of the target module use cases. The merging process is not a simple overall overwrite; instead, it identifies the added, changed, or deleted nodes in the related versions of the requirements relative to the base version based on preset merging rules, and securely integrates the business-verified customized logic into the base version. After the merge is complete, the base version evolves, generating a new base version and replacing the old one, achieving iterative updates to the target module use cases. Through automated integration performed using preset merging rules, the module use case library can automatically iterate and evolve with each business requirement deployment.

[0074] Based on the publicly available solutions described above, the merging process is triggered by monitoring business launch requirement events. Versions to be merged are accurately recalled based on requirement-related version identifiers, and then merged with the baseline version according to preset merging rules to achieve iterative updates. It is precisely this automatic merging mechanism, combining event-driven and relational queries, that enables customized test case logic validated by business operations to automatically, accurately, and securely flow back to the module test case library. This effectively solves the problems of test case library updates heavily relying on manual operation, prone to omissions and errors, and severely delayed updates.

[0075] In one or more embodiments of this disclosure, such as Figure 7 This is a flowchart illustrating an iterative update method as exemplified by an embodiment of this disclosure. Figure 7As shown, according to preset merging rules, the requirement-related versions are merged into the base version of the target module's use cases in the module use case library for iterative updates of the target module's use cases. This includes: Step S701: Comparing the requirement-related versions with the base version based on node identifiers. Step S702: If the requirement-related version corresponding to the same node identifier contains use case content not included in the base version, then the use case content is added to the base version. Step S703: If the requirement-related version corresponding to the same node identifier does not contain use case content included in the base version, then the base version is retained.

[0076] When merging versions, the system does not treat the two versions as unstructured, flat text. Instead, it uses node identifiers as the basis for structured alignment. The system iterates through the node identifiers in the relevant requirement version and the base version, establishes mapping relationships between logical nodes with the same node identifier, and compares the differences in use case content under the same node identifier. The node identifiers remain stable throughout the version evolution of the module's use cases. This provides a reliable anchor point for the system to automatically and accurately locate differences, solving the problem of logical confusion caused by unstructured comparison in existing technologies.

[0077] When the comparison results show test case content that exists in the related version of the requirement but not in the base version under the same node identifier, it indicates that this content may be customized logic added by the user based on business verification. For example, in the base version of the "Mobile Number Verification" module test case, there is only one node, "Domestic Mobile Number Format Verification"; however, in this requirement, due to business expansion to support international users, the quality assurance personnel added two test nodes: "International Area Code Verification" and "Hong Kong, Macao and Taiwan Number Verification". When the system finds that the node identifiers of these two newly added nodes do not exist in the base version, it appends these two newly added nodes and all their contained test case content to the test case tree structure of the base version. If the related version of the requirement corresponding to the same node identifier does not contain test case content not included in the base version, i.e., there is no new content, the system does not need to perform an addition operation and maintains the existing state of the base version under that node. This achieves secure changes to incremental content.

[0078] When the comparison results show that under the same node identifier, there are use cases present in the baseline version but missing in the related requirement version, it indicates that the user may have deleted certain common steps due to specific business constraints during the customization process of this requirement. For example, in a specific requirement, due to temporary simplification of the business scenario, the quality assurance personnel deleted the "Graphic Verification Code Verification" node from the "Mobile Number Verification" module use case, keeping only the "SMS Verification Code Verification" node. During the comparison, the system found that the "Graphic Verification Code Verification" node present in the baseline version does not exist in the related requirement version. In this case, the system adopts a conservative strategy: retaining the node and its contained use case content in the baseline version, without performing a deletion operation. If the related requirement version corresponding to the same node identifier contains use case content contained in the baseline version, it means that both share this part of the logic, and the system can maintain the existing content of the baseline version.

[0079] The baseline version is a general testing standard applicable to all business scenarios, representing the most complete set of test logic for that business function. The requirement-related version, on the other hand, is a customized version based on a specific business requirement. Its deletion might simply be because the business scope of that specific requirement is narrow and doesn't currently need to cover that test scenario, not because the test logic itself is flawed or outdated. By setting up an "append-only, delete-not-overwrite" anti-accidental deletion logic, the pollution of global public assets by local customization operations is prevented, ensuring the baseline version's original general integrity is absolutely guaranteed when absorbing business increments.

[0080] It should be noted that for changes of the modification type, that is, when the same node identifier exists in both the requirement-related version and the base version but the use case content is different, the system will update the modified use case content in the requirement-related version to the corresponding node in the base version, thereby synchronizing the optimized logic that has been verified by the business to the public knowledge base.

[0081] Based on the publicly available solutions described above, the system performs a structured alignment and comparison between the requirement-related versions and the baseline version based on node identifiers. Addition operations are performed for newly added content, while the baseline version is retained for missing content. It is precisely this asymmetric merging rule, which combines incremental absorption with prevention of accidental deletion, that allows the system to accurately capture newly added logic generated by business verification during the automated merging process, while absolutely avoiding the loss of common logic in the baseline version due to the deletion of a single requirement. This effectively solves the problems of overall coverage merging easily damaging the integrity of common use cases, and the low efficiency and error-prone nature of manual comparison merging.

[0082] In one or more embodiments of this disclosure, such as Figure 8 This is a flowchart illustrating the first requirement use case generation method provided in an embodiment of this disclosure. Figure 8As shown, the generation method of the first requirement use case includes: Step S801: Obtain the requirement document and technical solution corresponding to the target business requirement. Step S802: Generate the first requirement use case based on the requirement document and technical solution.

[0083] In practical applications, testers participate in requirements review meetings and technical solution review meetings, obtaining requirement documents and technical solutions related to the target business requirements from the requirements management platform or project management system. The system can provide document upload or online association functions. Testers upload or associate the aforementioned requirement documents and technical solutions to the system, which then obtains this document data. If both the requirement documents and technical solutions are successfully obtained, the subsequent generation process begins; if the acquisition fails, for example, due to a missing technical solution, the system can output a prompt message reminding testers to supplement the technical solution before writing test cases, ensuring that the generated first requirement test case has sufficient dual-source information support.

[0084] Furthermore, based on the business functionalities, user scenarios, and acceptance criteria defined in the requirements document, and combined with the code change points, system impact scope, interface design, and exception handling mechanisms clearly stated in the technical solution, test cases are written in the system's test case editing interface, constructing a tree structure for the first requirement test cases. Because quality assurance personnel refer to both the requirements document and the technical solution when writing test cases, they can comprehensively cover the test scenarios from both business functionality and technical implementation dimensions: covering both the verification logic of the forward business process and the exception branch scenarios involved in the technical solution, such as interface timeouts, data anomalies, and low-level exception scenarios like concurrency conflicts. The system receives input from the quality assurance personnel and generates structured first requirement test case data.

[0085] Based on the publicly available solutions described above, the system utilizes both requirements documents and technical solutions as parallel dual-source inputs, guiding quality assurance personnel to write and generate the first requirement use cases. This dual-source driven generation mechanism ensures that the initially generated first requirement use cases possess high coverage and a standardized structure from the outset. It covers both the forward flow of business functions and abnormal scenarios in technical implementation, effectively resolving the problems of incomplete use case coverage, non-standardized structure, and uncontrollable quality caused by relying solely on requirements documents.

[0086] Based on any of the above embodiments, this disclosure also provides a test case processing apparatus. Figure 9 This is a schematic block diagram of a test case processing apparatus according to one embodiment of this disclosure. Figure 9As shown, the test case processing apparatus includes: a creation module 901, used to create module test cases decoupled from the first requirement test cases in response to a request to export at least a portion of the test cases in the first requirement test cases; a storage module 902, used to store the module test cases in a module test case library; a search module 903, used to search for the target module test cases in the module test case library in response to an import request to import test cases into the second requirement test cases; and a relationship establishment module 904, used to import the test case content from the target module test cases into the second requirement test cases and establish an association relationship between the second requirement test cases and the target module test cases.

[0087] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0088] To facilitate understanding, the implementation process of this application will be described below through specific embodiments. Figure 10 This is a schematic diagram illustrating the test case processing flow as an example of this disclosure.

[0089] Before exporting, there is a target node in the first requirement test case, which directly stores the contents of three specific test cases: Test Case 1, Test Case 2, and Test Case 3. This is the original state, and the test case contents are completely dependent on the first requirement test case.

[0090] Subsequently, after exporting, quality assurance personnel performed the export operation on the target node. Following export, the system generated an independent module test case in the module test case library, assigned it the module identifier MOD-001, and stored test cases 1, 2, and 3 as the base version V1.0 of this module test case. Simultaneously, the content of the original target node in the first requirement test case was replaced with a pointer to the module test case library, with only the module identifier MOD-001 recorded on the node, establishing a traceability relationship with the target module test case in the module test case library.

[0091] Before modification after importing, quality assurance personnel import the module test cases when writing the second requirement test cases. The system creates an import node in the second requirement test cases, which contains the module identifier MOD-001 and the version identifier V1.0, pointing to the base version V1.0 of the target module test cases in the module test case library. At this time, the test case content under the import node is completely consistent with the base version, including test case 1, test case 2, and test case 3.

[0092] After modification and saving, the quality assurance personnel modified the content of the test cases introduced in the second requirement test cases, modifying the content of test case 2 and adding test case 4. After saving, the system generated a requirement-related version for the target module test case MOD-001 in the module test case library, assigning a version identifier VER-DEMAND-2024. This version includes test case 1, the modified test case 2, test case 3, and the newly added test case 4. Simultaneously, the version identifier on the introduced node in the second requirement test case was updated from V1.0 to VER-DEMAND-2024, pointing to the newly generated requirement-related version, while the base version V1.0 remained unchanged. If a test case in the base version was deleted during this modification, that test case was retained in the base version and not deleted.

[0093] The execution subject of the test case processing method in the specific embodiments of this disclosure can be an electronic device such as a server (including a local server or a cloud computing platform).

[0094] Therefore, based on any of the above embodiments, this disclosure also provides an electronic device that can execute the test case processing method of any of the embodiments described above.

[0095] Figure 11 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure.

[0096] The hardware architecture of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application of the hardware and overall design constraints. Bus 1100 connects various circuits, including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400, such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.

[0097] Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, this diagram uses only one connection line, but this does not imply that there is only one bus or one type of bus.

[0098] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0099] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0100] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0101] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0102] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0103] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0104] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0105] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0106] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0107] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A test case processing method, characterized in that, The method includes: In response to a request to export at least a portion of the test cases in the first requirement test case, a module test case decoupled from the first requirement test case is created; Store the module test cases in the module test case library; In response to the import request to import test cases into the second requirement test case, the target module test case is located in the module test case library; Import the test case content from the target module test case into the second requirement test case, and establish the association between the second requirement test case and the target module test case.

2. The test case processing method according to claim 1, characterized in that, After importing the test case content from the target module test case into the second requirement test case, the process also includes: In response to a request to modify the test case content in the target module test case imported in the second requirement test case, the modified test case content is determined and saved. Create the modified test case content as a requirement-related version and assign a requirement-related version identifier.

3. The test case processing method according to claim 1, characterized in that, The step of creating a module use case decoupled from the first requirement use case in response to a request to export at least a portion of the test cases in the first requirement use case includes: Obtain export requests for at least a portion of the test cases in the first requirement use case; Based on at least one node identifier contained in the export request, determine the target node corresponding to the node identifier and at least a portion of the target test case content contained in the target node; Based on the business direction specified in the export request, the target test case content is created as the module test case.

4. The test case processing method according to claim 1, characterized in that, The step of storing the module use cases into the module use case library includes: Determine whether the module test case library contains a baseline version with the same test case content as the module test case; If not included, the module use case will be stored as a baseline version in the module use case library, and a module identifier and a baseline version identifier will be assigned to the module use case.

5. The test case processing method according to claim 2, characterized in that, After creating the modified test case content as a requirement-related version, the process includes: Obtain the module identifier, base version identifier, and requirement-related version identifier of the target module use case; The module identifier, the base version identifier, and the requirement-related version identifier are written into the intro node of the second requirement use case to establish the association between the requirement-related version and the base version of the target module use case; and, Establish the association between the required version and the second required use case.

6. The test case processing method according to claim 5, characterized in that, Also includes: The business launch requirement corresponding to the second requirement use case was detected; Based on the requirement association version identifier associated with the second requirement use case, retrieve the requirement association version that corresponds to the requirement association version identifier from the module use case library; According to the preset merging rules, the required related versions are merged into the base version of the target module use case in the module use case library so as to iteratively update the target module use case.

7. The test case processing method according to claim 6, characterized in that, The step of merging the requirement-related versions into the baseline version of the target module use case in the module use case library according to preset merging rules for iterative updates of the target module use case includes: Based on the node identifier, the version associated with the requirement is compared with the baseline version; If the requirement associated version corresponding to the same node identifier contains use case content that is not included in the base version, then the use case content is added to the base version. If the requirement-associated version corresponding to the same node identifier does not contain the use case content contained in the baseline version, then the baseline version is retained.

8. The test case processing method according to claim 1, characterized in that, The methods for generating the first requirement use case include: Obtain the requirements documents and technical solutions corresponding to the target business needs; Based on the aforementioned requirements document and technical solution, the first requirement use case is generated.

9. An electronic device, characterized in that, include: The memory stores execution instructions; as well as, A processor that executes execution instructions stored in the memory, causing the processor to perform the method of any one of claims 1 to 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 8.

Images