Use case redundancy detection method, apparatus, device, medium and program product

Abstract

This application provides a method, apparatus, device, medium, and program product for detecting use case redundancy, relating to the field of computer technology, and is used to improve the accuracy of use case redundancy detection. The specific technical solution is as follows: An original set of use cases is obtained, and the use case information of multiple use cases included in the original set is normalized to obtain a normalized set of use cases, which includes the normalized use case information of multiple use cases; based on the normalized set of use cases and the system version information corresponding to each use case, a use case genealogy diagram is established among the multiple use cases, which is used to characterize the relationships between the multiple use cases; based on the normalized set of use cases and the use case genealogy diagram, the redundancy type between each use case and its corresponding candidate use cases is determined, where the candidate use cases corresponding to each use case are: use cases that are redundant with each of the multiple use cases. This application is applied to scenarios involving the detection of use case redundancy.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, medium, and program product for detecting use case redundancy. Background Technology

[0002] In modern software development, agile iteration and continuous delivery have become the industry mainstream, bringing new challenges to the construction and management of test case libraries. As versions evolve, the size of the test case library continues to expand. On the one hand, there are many duplicate or similar test cases across versions; on the other hand, redundancy often arises within the same version due to independent writing by different testers. The existence of redundant test cases not only increases the workload of test execution and maintenance but also easily leads to biases in coverage statistics and a decrease in defect detection efficiency. Therefore, redundancy detection has become a key aspect of test case governance.

[0003] In related technologies, test case redundancy detection mainly relies on manual inspection or simple keyword matching and overall text similarity comparison. This results in low accuracy for test case redundancy detection. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and program product for detecting use case redundancy, which can improve the accuracy of use case redundancy detection.

[0005] In a first aspect, embodiments of this application provide a use case redundancy detection method. The method includes: obtaining an original use case set, and normalizing the use case information of multiple use cases included in the original use case set to obtain a normalized use case set, wherein the normalized use case set includes the normalized use case information of multiple use cases; establishing a use case genealogy diagram among multiple use cases based on the normalized use case set and the system version information corresponding to each use case among the multiple use cases, wherein the use case genealogy diagram is used to characterize the association relationship among multiple use cases; and determining the redundancy type between each use case and the candidate use cases corresponding to each use case based on the normalized use case set and the use case genealogy diagram, wherein the candidate use cases corresponding to each use case are: use cases that are redundant with each use case among the multiple use cases.

[0006] The technical solution provided in this application brings at least the following beneficial effects: First, by standardizing the use case information of the use cases, the standardized use case information is obtained. Then, by constructing a use case genealogy diagram, the version context is introduced, which distinguishes the iterative relationship of the use cases rather than simply judging redundancy. Finally, by combining the standardized use case information and the use case genealogy diagram, the redundancy type between use cases is determined, thereby improving the accuracy of use case redundancy detection.

[0007] One possible implementation involves establishing a use case genealogy diagram among multiple use cases based on a standardized use case set and the system version information corresponding to each use case. This includes: obtaining the first information of each use case from the standardized use case set, and generating a stable identifier for each use case based on the first information; the first information of each use case includes at least one of the following: the use case title in the standardized text corresponding to each use case, the standardized step sequence corresponding to each use case, and the association information of each use case; constructing a version directed graph based on the system version information corresponding to each use case, the version directed graph being used to represent the iterative relationship between the system version information corresponding to each use case; and establishing a use case genealogy diagram based on the version directed graph and the stable identifier of each use case.

[0008] Another possible implementation involves the following: the standardized use case set includes standardized text for each use case and a standardized sequence of steps for each use case. Before determining the redundancy type between each use case and its corresponding candidate use cases based on the standardized use case set and the use case genealogy diagram, the method further includes: parsing the standardized sequence of steps for the first use case to obtain a set of step units for the first use case, wherein the set of step units includes at least one element unit parsed from the standardized sequence of steps for the first use case, and the first use case is any one of multiple use cases; generating a summary feature value for the first use case based on the set of step units for the first use case; and selecting at least one first candidate use case corresponding to the first use case from multiple use cases based on the standardized text and the summary feature value for the first use case.

[0009] Another possible implementation involves determining the redundancy type between each use case and its corresponding candidate use case based on a normalized use case set and a use case genealogy diagram. This includes: calculating a first similarity score based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case, where the first similarity score characterizes the similarity between the first use case and the first candidate use case; and determining the redundancy type between the first use case and the first candidate use case based on the first similarity score, the coverage relationship between the first use case and the first candidate use case, and the genealogical relationship between the first use case and the first candidate use case in the use case genealogy diagram.

[0010] Another possible implementation involves calculating a first similarity score based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case. This includes: calculating at least one similarity component based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case, where each similarity component is used to characterize the similarity between the first use case and the first candidate use case in a similarity dimension; and calculating the first similarity score based on at least one similarity component.

[0011] Another possible implementation is that, after determining the redundancy type between each use case and its corresponding candidate use cases based on the standardized use case set and use case genealogy diagram, the method further includes: generating processing suggestions based on the redundancy type between each use case and its corresponding candidate use cases, and using the processing suggestions to process each use case and its corresponding candidate use cases.

[0012] Secondly, embodiments of this application provide a use case redundancy detection device, including: an acquisition module and a processing module. The acquisition module is used to acquire an original set of use cases and to normalize the use case information of multiple use cases included in the original set of use cases to obtain a normalized set of use cases, which includes the normalized use case information of multiple use cases. The processing module is used to establish a use case genealogy diagram among multiple use cases based on the normalized use case set acquired by the acquisition module and the system version information corresponding to each use case in the multiple use cases. The use case genealogy diagram is used to characterize the association relationship between multiple use cases. Based on the normalized use case set and the use case genealogy diagram acquired by the acquisition module, the processing module determines the redundancy type between each use case and its corresponding candidate use cases. The candidate use cases corresponding to each use case are: use cases that are redundant with each of the multiple use cases.

[0013] One possible implementation involves an acquisition module that further acquires first information for each use case from a set of normalized use cases. A processing module, specifically, generates a stable identifier for each use case based on the first information acquired by the acquisition module. The first information for each use case includes at least one of the following: the use case title in the normalized text corresponding to each use case, the normalized step sequence corresponding to each use case, and the associated information of each use case. Furthermore, based on the system version information corresponding to each use case, a version-directed graph is constructed, which represents the iterative relationship between the system version information corresponding to each use case. Finally, a use case genealogy graph is established based on the version-directed graph and the stable identifier of each use case.

[0014] Another possible implementation involves a normalized use case set comprising normalized text for each use case and a normalized sequence of steps for each use case. The processing module is further configured to, before determining the redundancy type between each use case and its corresponding candidate use cases based on the normalized use case set and the use case genealogy diagram, parse the normalized sequence of steps corresponding to the first use case to obtain a set of step units corresponding to the first use case. This set of step units includes at least one element unit parsed from the normalized sequence of steps corresponding to the first use case. The first use case is any one of multiple use cases. Based on the set of step units corresponding to the first use case, a summary feature value corresponding to the first use case is generated. Finally, based on the normalized text and the summary feature value corresponding to the first use case, at least one first candidate use case corresponding to the first use case is selected from the multiple use cases.

[0015] Another possible implementation involves a processing module that calculates a first similarity score based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case. The first similarity score is used to characterize the similarity between the first use case and the first candidate use case. Based on the first similarity score, the coverage relationship between the first use case and the first candidate use case, and the phylogenetic relationship between the first use case and the first candidate use case in the use case phylogenetic diagram, the redundancy type between the first use case and the first candidate use case is determined.

[0016] Another possible implementation is a processing module, specifically used to calculate at least one similarity component based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case. Each similarity component is used to characterize the similarity between the first use case and the first candidate use case in a similarity dimension; and to calculate a first similarity score based on at least one similarity component.

[0017] Another possible implementation is that the processing module is also used to determine the redundancy type between each use case and its corresponding candidate use cases based on the standardized use case set and use case genealogy diagram, and then generate processing suggestions based on the redundancy type between each use case and its corresponding candidate use cases. The processing suggestions are used to process each use case and its corresponding candidate use cases.

[0018] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory stores a program or instructions executable on the processor, wherein the program or instructions, when executed by the processor, implement the method of the first aspect described above.

[0019] Fourthly, this application provides a readable storage medium on which a program or instructions are stored, which, when executed by a computer, implement the method of the first aspect described above.

[0020] Fifthly, this application provides a computer program product stored in a storage medium, which, when executed by a computer, implements the method described in the first aspect.

[0021] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the method described in the first aspect.

[0022] The beneficial effects of the second to sixth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0023] Figure 1A schematic diagram of the network architecture for an application of a use case redundancy detection method provided in this application embodiment;

[0024] Figure 2 A flowchart illustrating a use case redundancy detection method provided in an embodiment of this application;

[0025] Figure 3 A flowchart illustrating another use case redundancy detection method provided in an embodiment of this application;

[0026] Figure 4 A flowchart illustrating another use case redundancy detection method provided in an embodiment of this application;

[0027] Figure 5 A flowchart illustrating another use case redundancy detection method provided in an embodiment of this application;

[0028] Figure 6 A flowchart illustrating another use case redundancy detection method provided in an embodiment of this application;

[0029] Figure 7 A flowchart illustrating another use case redundancy detection method provided in an embodiment of this application;

[0030] Figure 8 A flowchart illustrating a use case redundancy detection method provided in an embodiment of this application;

[0031] Figure 9 This is a schematic diagram of the structure of a use case redundancy detection device provided in an embodiment of this application;

[0032] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0034] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0035] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0036] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0037] The present application provides a method, apparatus, device, medium, and program product for detecting use case redundancy, which can be applied to scenarios involving the detection of use case redundancy.

[0038] In current technologies, agile iteration and continuous delivery have become the industry mainstream in modern software development, bringing new challenges to the construction and management of test case libraries. As versions evolve, the size of test case libraries continues to expand. On the one hand, there are many duplicate or similar test cases across versions; on the other hand, redundancy often arises within the same version due to independent writing by different testers. The existence of redundant test cases not only increases the workload of test execution and maintenance but also easily leads to biases in coverage statistics and a decrease in defect detection efficiency. Therefore, how to efficiently detect and manage redundant test cases is a common pain point and urgent need in the field of test management.

[0039] Existing test management tools, such as TestRail, Tricentis qTest, Xray / Zephyr, and AzureDevOps Test Plans, primarily focus on the organization and structuring of test cases, version reuse, execution tracing, and automated result integration. These tools generally offer "test case cloning, copying, moving, and parameterization" capabilities, aiming to improve the reusability and maintainability of test cases. However, most of them do not truly detect and manage redundant test cases, but rather indirectly reduce duplication through searching, tagging, and naming conventions.

[0040] In recent years, emerging tools have begun to utilize artificial intelligence (AI) technology for redundant use case identification. For example, Testomat.io proposed a method based on an AI model to calculate the similarity between use cases. When the similarity exceeds a set threshold, it alerts the user to potential redundancy and allows for merging or cleanup. This approach is an early exploration in the industry and represents the closest implementation idea to this invention. Furthermore, some platforms (such as the Polarion extension) provide testers with "potentially duplicated" alerts through simple keyword or overall text similarity comparisons. However, these methods are still limited to coarse-grained analysis of use case text or overall descriptions and have not yet formed a systematic and refined redundancy detection and management mechanism.

[0041] The shortcomings of existing technologies are mainly reflected in the following aspects: (1) Weak redundancy detection capability. Most mainstream test management tools lack dedicated redundancy detection functions, do not pay much attention to redundancy issues, rely on manual processing, and are inefficient and costly. (2) Existing redundancy detection methods are crude. Although a few tools use artificial intelligence models to calculate overall similarity, this method usually stays at the surface level of text similarity or overall structure comparison, lacking in-depth analysis of test step granularity, business semantics, and version iteration context, resulting in insufficient accuracy of results. (3) Insufficient practicality. Due to the lack of effective control over false positive and false negative rates, the usability and promotion of such methods in actual projects are limited, and it is often difficult to truly guide testers to carry out refined cleaning and management of redundant test cases. (4) Lack of management closed loop. Most existing solutions stay at the detection level and lack automated cleaning, merging, or optimization strategies combined with test case lifecycle management, which cannot form an effective redundancy governance closed loop.

[0042] To address the aforementioned shortcomings, this application aims to propose a test case redundancy detection method for version iteration scenarios. This method enables automated and refined comparison and analysis of test cases across different versions and within the same version. It considers not only the overall textual content of the test cases but also the test case steps, business logic semantics, coverage objectives, and iteration relationships, significantly improving the accuracy and practicality of detection. Furthermore, by integrating with test case library management functions, this method provides automated merging, marking, archiving, or cleanup solutions upon discovering redundancy, thus constructing a complete closed loop for test case redundancy detection and governance. This approach effectively reduces the redundancy ratio of the test library, decreases maintenance costs, improves test execution efficiency, and ensures that the test case library remains concise and efficient even in frequent iteration environments, ultimately enhancing software quality assurance capabilities.

[0043] To address the aforementioned technical issues, embodiments of this application provide a method, apparatus, device, medium, and program product for detecting use case redundancy. First, the use case information is standardized to obtain standardized use case information. Then, a version context is introduced by constructing a use case genealogy diagram, distinguishing the iterative relationships of use cases rather than simply determining redundancy. Finally, the standardized use case information and the use case genealogy diagram are combined to determine the redundancy type between use cases, thereby improving the accuracy of use case redundancy detection.

[0044] The following description, in conjunction with the accompanying drawings, details the use case redundancy detection method, apparatus, device, medium, and program product provided in the embodiments of this application.

[0045] Figure 1 This illustration shows the network architecture of a use case redundancy detection method provided in an embodiment of this application. For example... Figure 1 As shown, the network architecture includes a use case redundancy detection device 101 and a terminal device 102. The use case redundancy detection device 101 and the terminal device 102 are interconnected.

[0046] In some embodiments, the use case redundancy detection device 101 may be a server, a computer, or a processor or processing unit within a server or computer. The server may be a single server or a server cluster consisting of multiple servers. It should be noted that the embodiments of this application do not limit the specific device form of the use case redundancy detection device 101. Figure 1 The example shown is a single server using the use case redundancy detection device 101.

[0047] In some embodiments, the terminal device may be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc., and the embodiments of this application do not specifically limit it. Figure 1 The example shown is a mobile phone, with terminal device 102 as an example.

[0048] In some embodiments, the use case redundancy detection device 101 can obtain the original use case set from the terminal device 102 and perform normalization processing on the use case information of multiple use cases included in the original use case set to obtain a normalized use case set.

[0049] It should be noted that the network architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As network architectures evolve, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0050] See Figure 2 This is a flowchart illustrating a use case redundancy detection method provided in an embodiment of this application. Figure 2 As shown, the use case redundancy detection method provided in this application embodiment can be implemented by the above-mentioned use case redundancy detection device, specifically including the following steps 201 to 203.

[0051] Step 201: The use case redundancy detection device obtains the original use case set and performs normalization processing on the use case information of multiple use cases included in the original use case set to obtain a normalized use case set.

[0052] In some embodiments, the above-mentioned normalized use case set includes normalized use case information for multiple use cases.

[0053] In some embodiments, the use case redundancy detection device can perform data collection to obtain the original set of use cases mentioned above.

[0054] In some embodiments, the test case redundancy detection device can collect test case information of multiple test cases from the test case library through an application programming interface (API) or an export interface to obtain the original test case set mentioned above.

[0055] In some embodiments, a use case, also known as a test case, is a description of the specific steps, input data, and expected results for verifying a software system or functional module. It is the basic unit of software testing. It is used to confirm whether the system behavior meets the design requirements.

[0056] In some embodiments, the use case information for each use case may include at least one of the following fields: use case text, step sequence, assertion, parameters, association information, and execution statistics.

[0057] For example, the use case text may include at least one of the following: use case title and use case description.

[0058] For example, the above sequence of steps can be understood as the actions, inputs, and expectations included in each step of a use case.

[0059] For example, the above assertion may include at least one of the following: user interface (UI), database, logs, status codes, etc.

[0060] For example, the above parameters may include at least one of the following: input data and configuration items.

[0061] For example, the aforementioned associated information may include at least one of the following: requirement identity document (ID), module / page, version information (e.g., version number), etc.

[0062] For example, the above execution statistics may include at least one of the following: most recent execution time, pass rate, failure type distribution, etc.

[0063] In some embodiments, the above-mentioned normalization process may include at least one of the following: text unification, stop word filtering and synonym merging, UI dynamic identifier unification, dynamic field templated formatting, highly discrete field masking, and step structure normalization. The specific details can be determined according to actual usage requirements, and this application embodiment does not limit this.

[0064] In some embodiments, the above text uniformity is used to eliminate misjudgments caused by differences in handwriting and to ensure accurate matching of text content.

[0065] In some embodiments, the above text unification may include at least one of the following: unified encoding, unified capitalization, unified punctuation, and unified whitespace.

[0066] For example, the above-mentioned encoding unification can be to convert all text (such as Chinese characters and special symbols) into a unified encoding format, such as UTF-8;

[0067] The above case unification can be used to convert all text to all uppercase, all lowercase, or first letter capitalized, for example, unifying "login", "Login", and "LOGIN" into "LOGIN".

[0068] The above punctuation standardization can be achieved by replacing the Chinese full-width punctuation mark “,” with the English half-width punctuation mark “,”, or by uniformly processing redundant punctuation marks.

[0069] The above-mentioned whitespace unification can be used to trim, normalize, or delete redundant whitespace characters (spaces, tabs, newlines), such as merging multiple consecutive spaces into one.

[0070] In some embodiments, the stop word filtering and synonym merging described above are used to focus on core semantics, uniformly processing words with different expressions but the same meaning, in order to improve the fault tolerance and coverage of matching.

[0071] For example, the above stop word filtering can filter out "stop words" that do not affect the core operation, such as "please", "click", "then", etc.

[0072] For example, the above-mentioned synonym merging can be used to merge different expressions with the same meaning into standard terms, such as merging "login", "login", "sign in" and "login" into the standard term "login".

[0073] In some embodiments, the aforementioned UI dynamic identifiers are uniformly used to strip the dynamic and volatile parts of UI element identifiers (such as ID and XPath) so that they remain comparable in version iterations.

[0074] For example, the aforementioned UI dynamic identifier unification can be used to standardize identifiers that include dynamic parts such as timestamps and serial numbers. For instance, #btn-login-2024 can be unified as #btn-login.

[0075] In some embodiments, the above dynamic field templates are used to replace variable data (such as dates, version numbers) in use case steps or expected results with placeholders, and the use case does not depend on specific data.

[0076] For example: Replace date / version number / timestamp / environment number, etc. with {date} / {version} / {env}.

[0077] In some embodiments, the above-mentioned highly discrete field mask is used to handle random, unique identifiers in the expected results that are unpredictable or do not require exact matching, so as to avoid use case failures due to differences in such fields.

[0078] For example, the highly discrete field mask described above can be a mask that replaces highly discrete numerical values ​​or strings. For instance, it can replace ID / random number / order number with {id} / {rand}.

[0079] In some embodiments, the above-described step structure normalization is used to extract and normalize the operation steps described in natural language into a structured, programmable, and comparable sequence of atomic operations.

[0080] For example, extract "Enter xx, Click xx, Verify xx" into comparable standard sentence structures.

[0081] In some embodiments, the core of the above normalization process can be understood as: removing content that "changes with version but is semantically irrelevant" to avoid similarity being interfered with by noise. This solves the engineering problem of "misjudgment caused by differences in cross-version expression" and establishes a unified corpus for subsequent element extraction, indexing, and comparison.

[0082] In some embodiments, the use case redundancy detection device normalizes the use case information of multiple use cases included in the original use case set to obtain a normalized use case set (NormCases). Compared with the original use case set, each use case in the normalized use case set can have an additional field: normalized text (norm_text) and normalized step sequence (norm_steps).

[0083] Step 202: The use case redundancy detection device establishes a use case genealogy diagram among multiple use cases based on the standardized use case set and the system version information corresponding to each use case in multiple use cases.

[0084] In some embodiments, the above use case genealogy diagram is used to characterize the relationships between multiple use cases.

[0085] In some embodiments, the above system version information may be the system version number corresponding to each use case.

[0086] In some embodiments, combined with Figure 2 ,like Figure 3 As shown, step 202 above can be implemented through steps 202a to 202c.

[0087] Step 202a: The use case redundancy detection device obtains the first information of each use case from the normalized use case set, and generates a stable identifier for each use case based on the first information of each use case.

[0088] In some embodiments, the first information for each use case includes at least one of the following: the use case title in the normalized text corresponding to each use case, the normalized step sequence corresponding to each use case, and the associated information for each use case.

[0089] In some embodiments, the use case redundancy detection device can perform hash processing on the first information of each use case to obtain the hash value of the first information of each use case, and then calculate the stable identifier (stable_id) of each use case based on the hash value.

[0090] In some embodiments, the normalized step sequence corresponding to each use case included in the first information of each use case can specifically be: the set of core steps (denoised key step token) in the normalized step sequence corresponding to each use case.

[0091] In some embodiments, the association information of each use case included in the first information of each use case may specifically be: the requirement ID in the association information of each use case.

[0092] Step 202b: The use case redundancy detection device constructs a version directed graph based on the system version information corresponding to each use case.

[0093] In some implementations, the aforementioned version graph is used to represent the iterative relationships between system version information corresponding to each use case. For example, the iterative relationships between version numbers corresponding to each use case.

[0094] For example, the nodes of the above version directed graph can be versions, and the edges of the version directed graph are used to indicate the iteration / branching relationship (parent→child) between versions.

[0095] Step 202c: The use case redundancy detection device establishes a use case genealogy diagram based on the version directed graph and the stability identifier of each use case.

[0096] In some embodiments, during the process of establishing a case lineage graph based on the version directed graph and the stability identifier of each case, if the stability identifiers of two case are consistent, the two case can be directly determined to be a continuation of the same source, and a continuation relationship is established between the two case.

[0097] If the stability identifiers of two use cases are inconsistent, but the semantic similarity and step overlap of the two use cases exceed a preset threshold, then an evolutionary relationship is established between the two use cases.

[0098] If the stability identifiers of two use cases are inconsistent, and the new use case covers the old use case, and the version information of one use case is the updated version information of the other use case, then a replacement relationship is established between the two use cases.

[0099] In some embodiments, the above use case genealogy diagram can be used to introduce version context constraints during subsequent determinations.

[0100] Step 203: The use case redundancy detection device determines the redundancy type between each use case and its corresponding candidate use cases based on the standardized use case set and use case genealogy diagram.

[0101] In some embodiments, the candidate use cases corresponding to each of the above use cases are: use cases that are redundant with each of the multiple use cases.

[0102] The test case redundancy detection method provided in this application first standardizes the test case information to obtain standardized test case information. Then, it introduces version context by constructing a test case genealogy diagram to distinguish the iteration relationship of test cases rather than simply judging redundancy. Finally, it combines the standardized test case information and the test case genealogy diagram to determine the redundancy type between test cases, thereby improving the accuracy of test case redundancy detection.

[0103] In some embodiments, combined with Figure 2 ,like Figure 4 As shown, prior to step 203 above, the use case redundancy detection method provided in this application embodiment may further include steps 301 to 303.

[0104] Step 301: The use case redundancy detection device parses the normalized step sequence corresponding to the first use case to obtain the set of step units corresponding to the first use case.

[0105] In some embodiments, the first use case described above is any one of a plurality of use cases.

[0106] In some embodiments, the set of step units described above includes at least one element unit parsed from the normalized step sequence corresponding to the first use case.

[0107] Specifically, the use case redundancy detection device can perform element unit parsing on the normalized step sequence corresponding to the first use case to obtain the set of step units (StepUnit) corresponding to the first use case.

[0108] In some embodiments, the use case redundancy detection device can use the method of "Named Entity Recognition (NER) + Dependency Syntax + Rule Template" to parse the normalized step sequence corresponding to the first use case and obtain the set of step units corresponding to the first use case.

[0109] Specifically, the use case redundancy detection device can perform the following steps:

[0110] (1) Identify “operation-object-parameter” through the predicate-object-modifier chain;

[0111] (2) Identify assertion types (UI visible, HyperText Transfer Protocol Status Code (HTTP) status, DB verification, etc.) through the assertion pattern library;

[0112] (3) Generate a normalized token to support subsequent editing of distance / dynamic time warping (DTW) / field alignment.

[0113] In some embodiments, the set of step units corresponding to the first use case may include at least one of the following element units: Action, Target, Assert, Page / Interface, and Context.

[0114] In some embodiments, the use case redundancy detection device can construct a "five-dimensional element vector" of the first use case: action, target, assertion, page / interface, and context.

[0115] For example, the above actions can be: clicking, inputting, querying, submitting, or validating;

[0116] The above targets can be: buttons, fields, interfaces, or tables;

[0117] The above assertions can be: equal to / contains / visible / status code / DB check.

[0118] The above page can be: page name;

[0119] The above interface can be: an interface path;

[0120] The above context can be: before / after / environment.

[0121] For example, the above set of step units can be StepUnit = { action, target, data_params, assert_type, assert_rhs, page, context, token_seq}.

[0122] Step 302: The use case redundancy detection device generates a summary feature value corresponding to the first use case based on the set of step units corresponding to the first use case.

[0123] In some embodiments, the above-mentioned digest feature value may include at least one of the following: set signature (sig_set

[0124] ) and sequence signature (sig_seq).

[0125] For example, the use case redundancy detection device can perform MinHash on the set of step units to obtain the set signature.

[0126] For example, the use case redundancy detection device can perform an ordered distance digest (a computable input of edit distance / DTW) on the set of step units to obtain a sequence signature.

[0127] Step 303: The use case redundancy detection device selects at least one first candidate use case corresponding to the first use case from multiple use cases based on the normalized text corresponding to the first use case and the summary feature value corresponding to the first use case.

[0128] In some embodiments, the use case redundancy detection device may first select Y use cases from multiple use cases according to a first rule, and then select at least one first candidate use case corresponding to the first use case from the Y use cases according to a second rule, based on the normalized text corresponding to the first use case and the summary feature value corresponding to the first use case.

[0129] In some embodiments, the first rule described above can be: first, find N use cases from multiple use cases that are in the same module / business domain as the first use case; then, find P use cases from the N use cases that have the same page name / interface domain as the first use case; and then, find Y use cases from the P use cases that have the same requirement tag / requirement group as the first use case. Where N > P > Y, and X is an integer greater than 1.

[0130] In some embodiments, the second rule described above may be: extracting the first keyword from the normalized text corresponding to each of the Y use cases, building an inverted index based on these first keywords, then extracting the second keyword from the normalized text corresponding to the first use case, using the inverted index to quickly find use cases containing the second keyword from the Y use cases, and then scoring them by matching degree and taking out the top M use cases with the highest scores (Top-M, configurable).

[0131] Simultaneously, Locality-Sensitive Hashing (LSH) is performed on the set signatures in the digest feature values ​​corresponding to the Y use cases, and the Y use cases are assigned to different hash sets. Then, LSH is performed on the set signatures in the digest feature values ​​corresponding to the first use case, the first hash set to which the first use case needs to be assigned is calculated, and then S use cases are obtained. These S use cases are all the use cases in the first hash set.

[0132] Simultaneously, a first semantic vector is generated for the normalized text and summary feature values ​​of each of the Y use cases. Then, an Approximate Nearest Neighbor (ANN) index is constructed for the generated Y first semantic vectors. Next, a second semantic vector is generated for the normalized text and summary feature values ​​of the first use case. Then, the top K first semantic vectors (Top-K, K=50~200 configurable) that are most similar to the second semantic vectors are searched in the ANN index to obtain the K use cases corresponding to the K first semantic vectors.

[0133] Finally, M, S, and K use cases are selected as at least one first candidate use case corresponding to the first use case.

[0134] Understandably, LSH can map similar use cases to the same hash set, or "hash bucket," with a high probability.

[0135] In some embodiments, a first semantic vector is generated for the normalized text and summary feature value of each of the Y use cases. Specifically, this can be done by generating a first semantic vector for the normalized text, use case title, and summary feature value of each of the Y use cases.

[0136] In some embodiments, the number of at least one first candidate use case corresponding to the first use case can be controlled within (50~500).

[0137] In some embodiments, the use case redundancy detection device can, according to a second rule, directly filter out at least one first candidate use case corresponding to the first use case from multiple use cases based on the normalized text corresponding to the first use case and the summary feature value corresponding to the first use case. It should be noted that the detailed steps for filtering out at least one first candidate use case corresponding to the first use case from multiple use cases according to the second rule and the summary feature value corresponding to the first use case can be found in the above embodiments, specifically the description of filtering out at least one first candidate use case corresponding to the first use case from Y use cases according to the second rule and the summary feature value corresponding to the first use case; these details will not be repeated here.

[0138] In some embodiments, combined with Figure 4 ,like Figure 5 As shown, step 203 above can be implemented through steps 203a and 203b.

[0139] Step 203a: The use case redundancy detection device calculates the similarity score between the first use case and the first candidate use case based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case.

[0140] In some embodiments, combined with Figure 5 ,like Figure 6 As shown, step 203a can be implemented in the following steps 401 and 402.

[0141] Step 401: The use case redundancy detection device calculates at least one similarity component based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case.

[0142] In some embodiments, each similarity component is used to characterize the similarity between the first use case and the first candidate use case in a similarity dimension.

[0143] It is understandable that after the use case redundancy detection device obtains at least one candidate use case corresponding to the first use case, it can calculate at least one similarity component for each first candidate use case.

[0144] In some embodiments, the above similarity dimensions may include at least one of the following: semantic similarity, structural sequence similarity, step set similarity, field alignment similarity, and coverage relation.

[0145] In some embodiments, the normalized use case information of the first use case includes a normalized step sequence corresponding to the first use case and normalized text corresponding to the first use case. The normalized text corresponding to the first use case includes a use case title. The use case redundancy detection device can parse the normalized step sequence corresponding to the first use case to obtain a set of step units corresponding to the first use case. Then, based on the set of step units corresponding to the first use case, it generates a summary feature value corresponding to the first use case, thereby obtaining the core text information of the first use case. The same applies to the first candidate use case, which will not be elaborated here. The use case redundancy detection device can calculate the similarity component between the first use case and the first candidate use case under semantic similarity based on the core text information of the first use case and the core text information of the first candidate use case, that is, obtain the semantic similarity (s_sem) between the first use case and the first candidate use case.

[0146] For example, the core text information mentioned above may include: use case title, normalized text, and summary feature value, namely (title + norm_text + step summary).

[0147] In some embodiments, the normalized use case information of the first use case includes the normalized step sequence corresponding to the first use case, and the same applies to the first candidate use case. The use case redundancy detection device can calculate the sequence distance (such as edit distance or dynamic time warping (DTW) distance) between the normalized step sequence of the first use case and the normalized step sequence of the first candidate use case, and then normalize the sequence distance to obtain the normalized sequence distance. Based on the normalized sequence distance, the similarity component of the first use case and the first candidate use case under structural sequence similarity is obtained, that is, the structural sequence similarity (s_seq) between the first use case and the first candidate use case is obtained.

[0148] For example, the use case redundancy detection device calculates the similarity component between the first use case and the first candidate use case in the structural sequence similarity dimension using the following formula: Formula 1 is as follows:

[0149] s_seq = 1 - dist_norm formula 1

[0150] Where s_seq represents the similarity component between the first use case and the first candidate use case in the structural sequence similarity dimension, and dist_norm represents the normalized sequence distance.

[0151] In some embodiments, the normalized use case information of the first use case includes a normalized step sequence corresponding to the first use case. The use case redundancy detection device can parse the normalized step sequence corresponding to the first use case to obtain the set of step units corresponding to the first use case. The same applies to the first candidate use case, which will not be elaborated here. The use case redundancy detection device can calculate the Jaccard similarity coefficient between the set of step units corresponding to the first use case and the set of step units corresponding to the first candidate use case to obtain the similarity component of the first use case and the first candidate use case under the step set similarity, that is, to obtain the step set similarity (s_set) between the first use case and the first candidate use case. It can be represented as: Jaccard(token_set_i, token_set_j).

[0152] In some embodiments, the normalized use case information of the first use case includes various structured fields of the first use case, such as: action, page, assertion, data, expected result, etc. The same applies to the first candidate use case, and will not be elaborated further here. The use case redundancy detection device can compare each structured field of the first use case and each structured field of the first candidate use case item by item, assigning a score to each item based on the degree of matching (e.g., complete match, partial match, no match), and then weighted summing of the scores to obtain the similarity component between the first use case and the first candidate use case under field alignment similarity, i.e., obtaining the field alignment similarity (s_field) between the first use case and the first candidate use case.

[0153] In some embodiments, the normalized use case information of the first use case includes a normalized step sequence corresponding to the first use case. The use case redundancy detection device can parse the normalized step sequence corresponding to the first use case to obtain a set of step units corresponding to the first use case. The same applies to the first candidate use case, which will not be elaborated here. Based on the set of step units corresponding to the first use case and the set of step units corresponding to the first candidate use case, the use case redundancy detection device can calculate the similarity component between the first use case and the first candidate use case under the coverage relation degree, that is, obtain the coverage relation degree (s_cover) between the first use case and the first candidate use case.

[0154] For example, the use case redundancy detection device can calculate the similarity component between the first use case and the first candidate use case in the coverage relation dimension using Formula 2, as follows:

[0155] s_cover =|S∩T| / min(|S|, |T|) (Formula 2)

[0156] Where s_cover represents the similarity component between the first use case and the first candidate use case in the coverage relationship dimension, S represents the set of step units corresponding to the first use case, and T represents the set of step units corresponding to the first candidate use case.

[0157] In some embodiments, the use case redundancy detection device may retain at least one similarity component as explanatory evidence to avoid a "black box".

[0158] Step 402: The use case redundancy detection device calculates the first similarity score based on at least one similarity component.

[0159] In some embodiments, the first similarity score is used to characterize the similarity between the first use case and the first candidate use case.

[0160] In some embodiments, the use case redundancy detection device may perform weighted fusion on at least one similarity component to obtain a weighted fused value, and then use the weighted fused value as a first similarity score.

[0161] In some embodiments, the use case redundancy detection device can perform weighted fusion on at least one similarity component to obtain a weighted fusion value, and then calculate a first similarity score based on the weighted fusion value and the phylogenetic relationship between the first use case and the first candidate use case in the use case phylogenetic diagram.

[0162] For example, when the first candidate use case is the direct predecessor of the first use case, the use case redundancy detection device can add the weighted fused value to a preset value to calculate the first similarity score.

[0163] In some embodiments, when the first candidate use case and the first use case are too far apart across modules or versions, the use case redundancy detection device can subtract the weighted fused value from a preset value to calculate the first similarity score.

[0164] In some embodiments, the use case redundancy detection device may employ linear fusion to perform weighted fusion on at least one similarity component to obtain a weighted fused value. The weights can be learned or configured.

[0165] For example, the use case redundancy detection device can calculate the first similarity score using Formula 3, which is shown below:

[0166] S(i,j) = w1*s_sem + w2*s_seq + w3*s_set + w4*s_field + w5*s_cover +r_ver Formula 3

[0167] Where S(i,j) represents the first similarity score, i represents the first use case, j represents the first candidate use case, s_sem represents the similarity component under semantic similarity, s_seq represents the similarity component under structural sequence similarity, s_set represents the similarity component under step set similarity, s_field represents the similarity component under field alignment similarity, s_cover represents the similarity component under coverage relation, w1, w2, w3, w4, and w5 are the corresponding weights, and r_ver represents the preset value.

[0168] Step 203b: The use case redundancy detection device determines the redundancy type between the first use case and the first candidate use case based on the first similarity score, the coverage relationship between the first use case and the first candidate use case, and the genealogical relationship between the first use case and the first candidate use case in the use case genealogy diagram.

[0169] In some embodiments, if the first similarity score is greater than or equal to a first threshold and the summary feature value is greater than or equal to a second threshold, the use case redundancy detection device can determine that the first use case is completely duplicated with the first candidate use case.

[0170] The second threshold is less than the first threshold.

[0171] In some embodiments, if the first similarity score is less than a first threshold and greater than or equal to a third threshold, and the coverage relationship between the first use case and the first candidate use case is greater than or equal to a fourth threshold, the use case redundancy detection device can determine that the first use case and the first candidate use case are approximately duplicated.

[0172] Among them, the third threshold is less than the second threshold, and the fourth threshold is less than the second threshold but greater than the third threshold.

[0173] In some embodiments, if the coverage relationship between the first use case and the first candidate use case is greater than or equal to a first threshold, there is a lineage edge between the first use case and the first candidate use case, and the first candidate use case is the previous lineage of the first use case, and the first candidate use case has not been executed or has a significantly low pass rate within a preset time period, the use case redundancy detection device can determine that the first use case and the first candidate use case are covered / replaced.

[0174] In some embodiments, if the first similarity score is greater than or equal to the fifth threshold and the difference is only located in the data parameters (data_params) or assertion expectations (assert_rhs), the use case redundancy detection device can determine that the first use case and the first candidate use case are parameterizable.

[0175] Among them, the fifth threshold is greater than the third threshold and less than the fourth threshold.

[0176] In some embodiments, if the structured fields between the first use case and the first candidate use case overlap with each other by a value greater than or equal to a sixth threshold and the assertions are complementary, the use case redundancy detection device can determine that the first use case and the first candidate use case can be merged.

[0177] Thus, by first standardizing the use case information of multiple use cases included in the original use case set, a standardized use case set is obtained. Then, by performing step-level structured parsing on the standardized step sequence corresponding to each use case in the standardized use case set, the core operations of the use cases are accurately captured, avoiding the bias of coarse-grained text comparison. Next, the core content is extracted by generating summary feature values ​​for each use case, reducing interference from irrelevant information. Then, by constructing a use case genealogy diagram to introduce version context, the iterative relationship of use cases is distinguished rather than simply judging redundancy. Finally, by combining the standardized use case set and the use case genealogy diagram, the redundancy type between use cases is determined, thereby improving the accuracy of use case redundancy detection.

[0178] In some embodiments, combined with Figure 2 ,like Figure 7 As shown, after step 203 above, the use case redundancy detection method provided in this application embodiment may further include the following step 501.

[0179] Step 501: The use case redundancy detection device generates processing suggestions based on the redundancy type between each use case and its corresponding candidate use cases.

[0180] In some embodiments, the above processing suggestions are used to process each use case and the candidate use cases corresponding to each use case.

[0181] In some embodiments, if the first use case is completely duplicated with the first candidate use case, the use case redundancy detection device may retain the latest version or execute a more stable use case as the representative; the remaining candidates are marked and archived; and a merging suggestion is generated.

[0182] In some embodiments, when the first use case is approximately duplicated with the first candidate use case, the use case redundancy detection device may suggest parameterization or extraction of shared steps; and generate difference patches (difference data / assertions).

[0183] In some embodiments, when there is a case where the first use case is covered / replaced by the first candidate use case, the use case redundancy detection device may mark the first candidate use case as an archiveable candidate.

[0184] In some embodiments, where the first use case and the first candidate use case are parameterizable, the use case redundancy detection device can generate a draft parameter table and a template suggestion.

[0185] In some embodiments, where the first use case and the first candidate use case can be merged, the use case redundancy detection device can generate a merged draft for review.

[0186] In some embodiments, if the first candidate use case has not been executed for a preset time and there is a SUPERSEDED or the first similarity score is greater than or equal to the first threshold, the use case redundancy detection device can mark it as disabled and migrate the historical report to the representative use case.

[0187] In some embodiments, any "automatic action" is not directly written to the database and takes effect, but instead enters the ReviewQueue:

[0188] <pair_id,label,recommended_action,evidence,diff_summary,operator_decision> .

[0189] In some embodiments, to address the problem of handling hundreds or thousands of similar pairs, the pairwise results can be structured into "redundant clusters." First, an undirected weighted graph Gc is constructed: node → test case, edge → if the similarity score S(i,j) ≥ θ_cluster (e.g., 0.7), an edge is connected with a weight of S(i,j). Then, Louvain or ChineseWhispers clustering is applied to Gc to obtain redundant clusters Cluster_k. Next, a representative score is calculated for each test case within the cluster: score = a*freshness + b*stability + c*coverage (freshness: version freshness / last update time, stability: execution pass rate, volatility, coverage: assertion coverage richness, requirement coverage). The test case with the highest score is selected as the representative, and the rest are auxiliary redundant test cases. The system generates a draft merge / parameterized script for the "representative + auxiliary" clusters.

[0190] In some embodiments, the following output can be provided for each pair or cluster that is determined to be redundant:

[0191] (1) Field alignment table: Which steps are the same / different in which fields;

[0192] (2) Similarity components: s_sem / s_seq / s_set / s_field / s_cover / r_ver;

[0193] (3) Covering relationship: subset / superset / complement.

[0194] Then, the large language model is invoked to generate natural language interpretations from the above evidence, but with explicit constraints: the large language model is only used for interpretation generation and does not participate in threshold determination or final labeling, to ensure traceability and stability.

[0195] The reviewer then performs operations on the ReviewQueue such as accepting / rejecting, adjusting thresholds, or setting special cases. After confirmation, the data is written back to the test management platform.

[0196] (1) Update the use case label (redundant type);

[0197] (2) Attach and merge patches / parameterized templates / archived records;

[0198] (3) Create a traceable audit log.

[0199] Final output: Effective governance results and audit logs.

[0200] In some embodiments, when a new or modified use case arrives, a full database recalculation is not performed; instead, an incremental process is executed.

[0201] (1) Perform normalization processing, element unit parsing processing, and summary feature value generation on newly added / modified use cases;

[0202] (2) Update the LSH bucket, inverted index, and ANN vector index;

[0203] (3) Perform similarity score calculation and redundancy type determination only on its nearest neighbor candidate set, and update the local graph structure of the undirected weighted graph as needed;

[0204] (4) Write the new results into the review queue and wait for confirmation.

[0205] The complexity of a single processing operation is controlled to O(logN+K), avoiding O(N²) complexity for the entire database. It also supports asynchronous batch processing and CI / CD hooks: outputting "redundancy warnings and conflict alerts" during the merge request phase.

[0206] This application proposes a method for detecting use case redundancy, such as Figure 8 As shown, the method follows the main chain of "data normalization → structured element extraction → version genealogy modeling → candidate recall → multi-perspective fine ranking → redundant type determination and action suggestion → clustering and representative test case selection → explanation and human-computer collaboration closed loop → incremental update". It outputs redundant tags, merging / archiving suggestions and difference descriptions that can be written back to the test management platform, forming a traceable closed loop.

[0207] The use case redundancy detection method of this application will be described below through specific embodiments.

[0208] The implementation process of the use case redundancy detection method provided in this application includes the following S1 to S9:

[0209] S1. Data Preparation and Standardization

[0210] S1.1 Data Acquisition

[0211] The system collects the following fields from the test case library via API or export interface:

[0212] (1) Use case text: title, description;

[0213] (2) Steps: Step sequence (each step includes action, input, and expectation);

[0214] (3) Assertions: UI / interface / DB / log / status codes, etc.;

[0215] (4) Parameters: Input data, configuration items;

[0216] (5) Related information: Requirement ID, module / page, version number;

[0217] (6) Execution statistics: recent execution time, pass rate, failure type distribution, etc.

[0218] Output: The original set of use cases, Cases.

[0219] S1.2 Language-Aware Normalization (Configurable Rule Set)

[0220] Performing uniform normalization on each use case involves removing content that "changes with version but is semantically irrelevant" to avoid noise interfering with similarity. Specifically, this includes:

[0221] (1) Text consistency: encoding, capitalization, punctuation, and whitespace;

[0222] (2) Stop word filtering and synonym merging: such as “login / login / Signin”;

[0223] (3) Unification of UI dynamic identifiers: unify such as #btn-login-2024 into #btn-login;

[0224] (4) Dynamic field templates: Date / Version Number / Timestamp / Environment Number → {date} / {version} / {env};

[0225] (5) Highly discrete field mask: ID / random number / order number, etc. → {id} / {rand};

[0226] (6) Step structure standardization: Extract “Enter xx, click xx, verify xx” into comparable standard sentence structures.

[0227] Output: Normalized test case set NormCases (compared to the original test case set Cases, each test case has the following additional fields: normalized text norm_text and normalized step sequence norm_steps)

[0228] S1 solves the engineering problem of "misjudgment caused by differences in cross-version descriptions" and establishes a unified corpus for subsequent element extraction, indexing and comparison.

[0229] S2, Structured Modeling and Feature Extraction

[0230] S2.1 Construction of Five-Dimensional Feature Vectors

[0231] For each NormCase in the normalized use case set NormCases, construct a "five-dimensional feature vector":

[0232] (1) Action (click, input, query, submit, validate...);

[0233] (2) Target (button, field, interface, table, etc.);

[0234] (3) Assert(equal to / contains / visible / status code / DB checksum…);

[0235] (4) Page / Interface Page (page name, interface path, etc.);

[0236] (5) Context (pre-context / post-context / environment).

[0237] S2.2 Step-level feature unit parsing (with parser implementation)

[0238] The "NER + dependency syntax + rule template" method is used to parse the step text and form a step unit StepUnit: StepUnit={action,target,data_params,assert_type,assert_rhs,page,context,token_seq};

[0239] (1) Identify “operation-object-parameter” through the predicate-object-modifier chain;

[0240] (2) Identify assertion types (UI visible, HTTP status, DB verification, etc.) through the assertion pattern library;

[0241] (3) Generate a standardized token to support subsequent editing of distance / DTW / field alignment.

[0242] S2.3 Sequence Digest Construction (for Recall and Acceleration)

[0243] Generate two types of summaries for each use case:

[0244] (1) Set signature: Perform MinHash → sig_set on the step token set;

[0245] (2) Sequence signature: Perform an ordered distance digest (edit distance / computable input of DTW) on the step token sequence → sig_seq;

[0246] Output: FeatureCase (including step_units, sig_set, sig_seq, etc.)

[0247] S3, Version Genealogy Modeling

[0248] S3.1 version graph construction

[0249] Construct a VersionGraph (directed graph) based on system version information: Node: version; Edge: Iteration / branch relationship (parent→child).

[0250] S3.2 Stable Identifier Generation (for cross-version tracking of the same origin)

[0251] Generate a stable identifier `stable_id` for each use case, calculated from at least the following combination:

[0252] (1) Standardize the title hash;

[0253] (2) Core step set (denoised key step token) hash;

[0254] (3) Associated requirement ID hash.

[0255] S3.3 Rules for Establishing Lineage Boundaries

[0256] Establish a genealogical relationship between use cases in different versions:

[0257] (1) If stable_id is consistent: directly determine it as a continuation of the same source and establish CONTINUE relationship;

[0258] (2) If they are inconsistent but meet the threshold of (semantic similarity + step overlap): establish EVOLVE (evolution) relationship;

[0259] (3) If the new use case covers the old use case and the version is updated: establish a REPLACE relationship.

[0260] Output: CaseLineageGraph, used to introduce version context constraints during subsequent decision-making.

[0261] S4, Candidate Recall

[0262] Candidate recall objective: Reduce the total number of O(N²) comparisons across the entire database to a small candidate set for fine ranking.

[0263] S4.1 multi-level blocking

[0264] The following blocking keys are used sequentially to filter the candidate pool (any hit allows advancement to the next level):

[0265] (1) Same module / same business domain;

[0266] (2) Same page name / same interface domain;

[0267] (3) Same as demand tag / demand group.

[0268] S4.2 Inverted Index Recall

[0269] Build an inverted index for norm_text or key phrases, and retrieve Top-M based on keywords (configurable).

[0270] S4.3LSH bucket recall (collective similarity fallback)

[0271] Perform LSH on sig_set to map similar sets to the same bucket, with each set within the same bucket being a candidate for the others.

[0272] S4.4 ANN Nearest Neighbor Recall (Semantic Vector Recall)

[0273] Generate semantic vectors for the norm_text+title+step summary, and select the Top-K based on ANN (K=50~200 can be configured).

[0274] Output: CandidatePairs (the number of candidate pairs for each case is controlled between 50 and 500).

[0275] S5, Multi-view Similarity Calculation and Fusion Ranking

[0276] For each candidate pair (i,j), calculate the multidimensional similarity components and fuse them into an interpretable total score.

[0277] S5.1 Similarity component definition (normalized to [0,1])

[0278] (1) Semantic similarity s_sem: sentence vector cosine similarity (title + norm_text + step summary);

[0279] (2) Structural sequence similarity s_seq: Calculate edit distance / DTW for norm_steps, s_seq=1-dist_norm;

[0280] (3) Step set similarity s_set: Jaccard(token_set_i, token_set_j);

[0281] (4) Field alignment similarity s_field: weighted summarization of each field such as action / page / assert / data / expected;

[0282] (5) Coverage degree s_cover: |S∩T| / min(|S|,|T|), reflects the inclusion of subsets / supersets;

[0283] (6) Version adjustment r_ver: If j is the direct predecessor of i: add +γ; if the distance across modules / versions is too large: subtract -δ.

[0284] S5.2 Interpretable Fusion Scoring

[0285] Linear fusion is used (weights can be learned or configured):

[0286] S(i,j)=w1*s_sem+w2*s_seq+w3*s_set+w4*s_field+w5*s_cover+r_ver;

[0287] And retain each component as interpretive evidence to avoid "black boxes".

[0288] Output: SimResult for each candidate pair (including components and total score).

[0289] S6. Redundancy type determination and label / action generation

[0290] Generate redundancy types and action suggestions based on S(i,j), s_cover, lineage direction, and execution statistics. To ensure feasibility, this solution provides decision-making logic that can be directly coded.

[0291] S6.1 Decision rules (example thresholds are configurable)

[0292] (1) Exact duplicate EXACT_DUP: S ≥ 0.90 and s_set ≥ 0.85 and s_seq ≥ 0.85. Action: Retain the latest version or execute the more stable one as a representative; archive the remaining marked candidates; generate a merge suggestion.

[0293] (2) Near duplicate NEAR_DUP: 0.65 ≤ S < 0.90 and s_cover ≥ 0.75. Action: Suggest parameterization or extract shared steps; generate a difference patch (difference data / assertion).

[0294] (3) Superseded / SUPERSEDED: There is a lineage edge j → i and s_cover ≥ 0.9 and version(j) < version(i) and j has not been executed in the last 60 days or the pass_rate is significantly low. Action: Mark j as an archivable candidate.

[0295] (4) Parameterizable candidate PARAM_CAND: S ≥ 0.70 and the differences are only in data_params or assert_rhs. Action: Generate a draft parameter table and templating suggestions.

[0296] (5) Mergeable candidate MERGE_CAND: The two use cases cover each other by ≥ 80% but the assertions are complementary. Action: Generate a merge draft for review.

[0297] (6) Deprecatable / DEPRECATE: Not executed in the last three months, and there is a SUPERSEDED or a representative use case with S ≥ 0.9. Action: Mark as deprecated and migrate the historical report attachment to the representative use case.

[0298] S6.2 Review queue mechanism (ensure a closed-loop implementation)

[0299] Any "automatic actions" do not directly take effect in the database but enter the ReviewQueue:

[0300] <pair_id,label,recommended_action,evidence,diff_summary,operator_decision>

[0301] Output: Redundant labels and action suggestions (pending review).

[0302] S7. Clustering and Representative Use Case Selection

[0303] To address the problem of "difficulty in processing hundreds or thousands of similar pairs", the pairwise results are structured into "redundant clusters (cu)".

[0304] S7.1 Similarity Graph Construction

[0305] Construct an undirected weighted graph Gc: Node → test case, edge → if S(i,j)≥θ_cluster (e.g. 0.7), then connect the edge with weight S(i,j).

[0306] S7.2 Community Clustering

[0307] Clustering Gc using Louvain or Chinese Whispers yields redundant clusters Cluster_k.

[0308] S7.3 represents the use case scoring function and selection.

[0309] For each use case within the cluster, calculate a representative score: score = a*freshness + b*stability + c*coverage (freshness: version freshness / last update time, stability: execution pass rate, volatility, coverage: assertion coverage richness, requirement coverage).

[0310] The highest-scoring test case is selected as the representative, and the rest are auxiliary redundant test cases. The system generates a draft merge / parameterized script for the "representative + auxiliary" test cases.

[0311] Output: Redundant clusters and representative use cases, cluster-level governance recommendations.

[0312] S8. Explanation Generation and Human-Machine Collaboration Closed Loop

[0313] S8.1 Difference Description Generation

[0314] For each pair or cluster that is deemed redundant, the output is:

[0315] (1) Field alignment table: Which steps are the same / different in which fields;

[0316] (2) Similarity components: s_sem / s_seq / s_set / s_field / s_cover / r_ver;

[0317] (3) Covering relationship: subset / superset / complement.

[0318] S8.2 Natural Language Interpretation

[0319] The large language model is invoked to generate natural language interpretations of the above evidence, but with explicit constraints: the large language model is only used for interpretation generation and does not participate in threshold determination or final labeling, to ensure traceability and stability.

[0320] S8.3 Write-back Closed Loop

[0321] The reviewer performs operations on the ReviewQueue such as accepting / rejecting, adjusting thresholds, and setting special cases. After confirmation, a response is written back to the test management platform.

[0322] (1) Update the use case label (redundant type);

[0323] (2) Attach and merge patches / parameterized templates / archived records;

[0324] (3) Create a traceable audit log.

[0325] Output: Effective governance results and audit logs.

[0326] S9, Incremental Updates and Online Performance

[0327] When a new or modified test case arrives, a full database recalculation is not performed; instead, an incremental process is executed.

[0328] (1) Execute S1 and S2 to generate normalization and features for newly added / modified use cases;

[0329] (2) Update the LSH bucket, inverted index, and ANN vector index;

[0330] (3) Perform S5 and S6 only on its nearest neighbor candidate set, and update the local graph structure of S7 as needed;

[0331] (4) Write the new results into the review queue and wait for confirmation.

[0332] The complexity of a single processing operation is controlled to O(logN+K), avoiding O(N²) complexity for the entire database. It also supports asynchronous batch processing and CI / CD hooks: outputting "redundancy warnings and conflict alerts" during the merge request phase.

[0333] It should be noted that the descriptions of each step S1 to S9 in this embodiment can be found in the descriptions in the above embodiments, and will not be repeated here.

[0334] Core Data Objects

[0335] -Use case object Case: case_id, version_id, module_id, title, steps[], asserts[], params, req_ids[], exec_stats

[0336] - Normalized object NormCase: case_id, norm_text, norm_steps[], tokens[], masked_map

[0337] - Structured FeatureCase objects: case_id, action_set, target_set, assert_set, page_set, context_set, step_units[]

[0338] - Lineage object: Nodes are case_id, edges are EVOLVE / REPLACE, and associated with version_graph

[0339] - CandidatePair: (case_i, case_j, coarse_keys, recall_reason)

[0340] - Similarity results SimResult: s_sem, s_seq, s_set, s_field, s_cover, r_ver, S_total

[0341] - Decision result: label, recommended_action, confidence, evidence

[0342] - Redundant Cluster: cluster_id, members[], representative_case_id

[0343] (2) Pseudocode for key decision

[0344] ```

[0345] Input: Cases, VersionGraph

[0346] Output: Labels, Actions, Clusters, ReviewQueue

[0347] For case in Cases:

[0348] norm = normalize(case) # S1

[0349] feat = extract_features(norm) # S2

[0350] stable_id = build_stable_id(feat) # S3

[0351] update_indexes(norm, feat) # S4 / S9

[0352] for case in Cases:

[0353] candidates = recall_candidates(case) # S4

[0354] for c in candidates:

[0355] sim = calc_similarity(case, c) # S5

[0356] decision = classify(sim, lineage, exec_stats) # S6

[0357] if decision.trigger:

[0358] push_to_review_queue(decision)

[0359] Gc = build_similarity_graph(sim_results, theta=0.7) # S7

[0360] clusters = community_detection(Gc)

[0361] representatives = pick_representatives(clusters)

[0362] generate_explanations(review_queue, clusters) # S8

[0363] ```

[0364] In some embodiments, the key points of this application can be summarized as follows: 1. Redundancy detection strategy oriented towards version iteration: Introducing a version-first comparison mechanism, using the latest version as a benchmark, tracking the evolution and replacement relationships of historical version use cases. This approach differs from traditional single similarity judgment and is closer to the real needs in an iterative environment. 2. Multi-perspective similarity calculation integrating semantics and structure: Not only is the semantic similarity of use case text calculated using semantic vector models (such as BERT), but it also combines structured features such as step sequence similarity, page / assertion / input data, etc. A comprehensive similarity is obtained through weighted fusion, thereby accurately identifying redundant use cases that are semantically similar but have different expressions. 3. Use case similarity graph and clustered redundancy management: Constructing a "use case similarity graph Gc", and automatically dividing redundant clusters using graph community discovery algorithms. In each redundant cluster, based on version freshness, execution stability, and assertion coverage, a "representative use case" is automatically selected, and merging / parameterization suggestions are generated. This mechanism avoids the problem of scattered results and difficulty in manual processing caused by relying solely on pairwise similarity. 4. Explanation Generation and Human-Machine Collaboration Closed Loop: The system automatically outputs a difference alignment table, similarity components, and machine-readable comparison descriptions; the large language model is used only for natural language interpretation. The review interface supports "one-click acceptance / rejection / threshold adjustment / blacklisting of special cases" and writes the results back to the test case library, forming a traceable closed loop. 5. Incremental Updates and Online Performance Optimization: When adding / modifying test cases, only the affected shards are partially updated, avoiding full recalculation. Complexity is controlled at O(logN+K), and redundancy risk warnings are provided in the CI / CD process, achieving scalability under real-time, continuous iteration.

[0365] In some embodiments, the feasibility of implementing the proposed solution can be summarized in the following five points: 1. Data-level feasibility: The required basic data (test case text, version number, execution record, requirement association) can be directly exported from existing test management platforms (such as TestRail, qTest, AzureDevOps) or obtained through APIs. Data cleaning and template processing can be achieved through common regular expressions, rule bases, and text preprocessing techniques. 2. Algorithm-level feasibility: Semantic vector representation can reuse existing open-source NLP models (BERT, RoBERTa, ERNIE, etc.). Sequence alignment and set similarity calculation are mature algorithms (edit distance, DTW, MinHash+LSH). Graph clustering algorithms (Louvain, ChineseWhispers) have mature implementations and can be directly applied to the constructed test case similarity graph. 3. System architecture feasibility: A microservice architecture can be adopted (data acquisition module + feature extraction and similarity calculation service + graph analysis and clustering service + result interpretation and human-computer interaction interface). Incremental updates are implemented by maintaining vector indexes (ANNs, such as Faiss and Milvus) and hash buckets (LSH), which is a common industry practice. 4. Feasibility of Application Scenarios: In large internet companies, banking and financial software, and government and enterprise IT projects, the scale of test cases typically reaches tens of thousands or even hundreds of thousands. The efficiency and automation capabilities of this method can significantly reduce manual costs. In a CI / CD environment, the method can be embedded in the PullRequest / MergeRequest stage to automatically highlight potential redundancy and avoid unnecessary expansion. 5. Verifiability of Technical Effects: Compared with traditional methods based on text retrieval or manual comparison, this invention can significantly improve the recall and accuracy of redundancy detection. Clustering and representative selection mechanisms can directly reduce execution redundancy and improve testing efficiency. The incremental update mechanism ensures that the system can still run in real time under large-scale and high-frequency iterations, possessing engineering implementation value.

[0366] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there is no conflict, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0367] It should be noted that for a detailed explanation of the steps performed by each module and their beneficial effects, please refer to the description in the above embodiments, which will not be repeated here.

[0368] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware 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.

[0369] This application embodiment can divide the use case redundancy detection device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0370] In some embodiments, this application also provides a use case redundancy detection device. This use case redundancy detection device may include one or more functional modules for implementing the use case redundancy detection method of the above method embodiments.

[0371] For example, Figure 9 This is a schematic diagram of a use case redundancy detection device provided in an embodiment of this application. Figure 9 As shown, the use case redundancy detection device 900 includes: an acquisition module 902 and a processing module 903.

[0372] The aforementioned acquisition module 902 is used to acquire the original test case set and to perform normalization processing on the test case information of multiple test cases included in the original test case set to obtain a normalized test case set, which includes the normalized test case information of multiple test cases.

[0373] The processing module 903 is used to establish a test case genealogy diagram among multiple test cases based on the standardized test case set obtained by the acquisition module 902 and the system version information corresponding to each test case in the multiple test cases. The test case genealogy diagram is used to represent the relationship between multiple test cases. Based on the standardized test case set and test case genealogy diagram obtained by the acquisition module, the redundancy type between each test case and the candidate test cases corresponding to each test case is determined. The candidate test cases corresponding to each test case are: test cases that are redundant with each test case among the multiple test cases.

[0374] The test case redundancy detection device provided in this application first standardizes the test case information to obtain standardized test case information. Then, it introduces version context by constructing a test case genealogy diagram to distinguish the iteration relationship of test cases rather than simply judging redundancy. Finally, it combines the standardized test case information and the test case genealogy diagram to determine the redundancy type between test cases, thereby improving the accuracy of test case redundancy detection.

[0375] In some embodiments, the acquisition module 902 is further configured to acquire first information of each use case from the normalized use case set; the processing module 903 is specifically configured to generate a stable identifier for each use case based on the first information of each use case acquired by the acquisition module 902; the first information of each use case includes at least one of the following: the use case title in the normalized text corresponding to each use case, the normalized step sequence corresponding to each use case, and the association information of each use case; and construct a version directed graph based on the system version information corresponding to each use case, the version directed graph being used to characterize the iterative relationship between the system version information corresponding to each use case; and establish a use case genealogy graph based on the version directed graph and the stable identifier of each use case.

[0376] Another possible implementation involves a standardized use case set comprising standardized text for each use case and a standardized sequence of steps for each use case. The processing module 902 is further configured to, before determining the redundancy type between each use case and its corresponding candidate use cases based on the standardized use case set and the use case genealogy diagram, parse the standardized sequence of steps corresponding to the first use case to obtain a set of step units corresponding to the first use case. This set of step units includes at least one element unit parsed from the standardized sequence of steps corresponding to the first use case. The first use case is any one of multiple use cases. Based on the set of step units corresponding to the first use case, a summary feature value corresponding to the first use case is generated. Finally, based on the standardized text and summary feature value corresponding to the first use case, at least one first candidate use case corresponding to the first use case is selected from the multiple use cases.

[0377] Another possible implementation is that the processing module 902 is specifically used to calculate a first similarity score based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case. The first similarity score is used to characterize the similarity between the first use case and the first candidate use case. Based on the first similarity score, the coverage relationship between the first use case and the first candidate use case, and the phylogenetic relationship between the first use case and the first candidate use case in the use case phylogenetic diagram, the redundancy type between the first use case and the first candidate use case is determined.

[0378] Another possible implementation is that the processing module 902 is specifically used to calculate at least one similarity component based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case. Each similarity component is used to characterize the similarity between the first use case and the first candidate use case in a similarity dimension. Based on at least one similarity component, a first similarity score is calculated.

[0379] Another possible implementation is that the processing module 902 is also used to generate processing suggestions based on the redundancy type between each use case and its corresponding candidate use cases after determining the redundancy type between each use case and its corresponding candidate use cases based on the normalized use case set and use case genealogy diagram. The processing suggestions are used to process each use case and its corresponding candidate use cases.

[0380] It should be noted that the use case redundancy detection device can implement all the processes implemented in the above method embodiments and achieve the same beneficial effects. To avoid repetition, it will not be described again here.

[0381] In the case where the functions of the integrated modules described above are implemented in hardware, this application provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 10 As shown, the electronic device 90 includes: a processor 92, a communication interface 93, and a bus 94. Optionally, the electronic device 90 may also include a memory 91.

[0382] Processor 92 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0383] Communication interface 93 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0384] The memory 91 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0385] As one possible implementation, the memory 91 can exist independently of the processor 92. The memory 91 can be connected to the processor 92 via a bus 94 and is used to store instructions or program code. When the processor 92 calls and executes the instructions or program code stored in the memory 91, it can implement the use case redundancy detection method provided in the embodiments of this application.

[0386] In another possible implementation, the memory 91 can also be integrated with the processor 92.

[0387] Bus 94 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 94 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 10 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0388] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0389] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0390] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0391] This application also provides a readable storage medium storing a program or instructions that, when executed by a computer, implement the use case redundancy detection method provided in the above embodiments. It is understood that all or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; the readable storage medium can be any of the foregoing embodiments or memory; the readable storage medium can also be an external storage device of the service invocation device, such as a pluggable hard drive, SmartMedia Card (SMC), Secure Digital (SD) card, flash card, etc., equipped on the service invocation device. Further, the readable storage medium can include both internal storage units of the service invocation device and external storage devices. The readable storage medium is used to store the computer program and other programs and data required by the service invocation device. The readable storage medium can also be used to temporarily store data that has been output or will be output.

[0392] This application also provides a computer program product, which is stored in a storage medium and implements the use case redundancy detection method provided in the above embodiments when the computer program product is executed by a computer.

[0393] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0394] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0395] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for detecting use case redundancy, characterized in that, The method includes: Obtain the original set of test cases, and perform normalization processing on the test case information of multiple test cases included in the original set of test cases to obtain a normalized set of test cases, which includes the normalized test case information of the multiple test cases. Based on the standardized set of use cases and the system version information corresponding to each use case in the plurality of use cases, a use case genealogy diagram is established among the plurality of use cases. The use case genealogy diagram is used to characterize the relationship between the plurality of use cases. Based on the standardized use case set and the use case genealogy diagram, the redundancy type between each use case and the candidate use cases corresponding to each use case is determined. The candidate use cases corresponding to each use case are: use cases that are redundant with each use case among the multiple use cases.

2. The method according to claim 1, characterized in that, The step of establishing a use case genealogy diagram among the multiple use cases based on the standardized use case set and the system version information corresponding to each use case in the multiple use cases includes: First information of each use case is obtained from the set of normalized use cases, and a stable identifier for each use case is generated based on the first information of each use case; the first information of each use case includes at least one of the following: the use case title in the normalized text corresponding to each use case, the normalized step sequence corresponding to each use case, and the association information of each use case; Based on the system version information corresponding to each use case, a version directed graph is constructed, which is used to represent the iterative relationship between the system version information corresponding to each use case; Based on the version directed graph and the stable identifier of each use case, the use case genealogy graph is established.

3. The method according to claim 2, characterized in that, The standardized use case set includes the standardized text corresponding to each use case and the standardized step sequence corresponding to each use case; before determining the redundancy type between each use case and the candidate use cases corresponding to each use case based on the standardized use case set and the use case genealogy diagram, the method further includes: The normalized step sequence corresponding to the first use case is parsed to obtain a set of step units corresponding to the first use case. The set of step units includes at least one element unit parsed from the normalized step sequence corresponding to the first use case. The first use case is any one of the plurality of use cases. Based on the set of step units corresponding to the first use case, a summary feature value corresponding to the first use case is generated; Based on the normalized text corresponding to the first use case and the summary feature value corresponding to the first use case, at least one first candidate use case corresponding to the first use case is selected from the plurality of use cases.

4. The method according to claim 3, characterized in that, The step of determining the redundancy type between each use case and its corresponding candidate use cases based on the normalized use case set and the use case genealogy diagram includes: Based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case, a first similarity score is calculated. The first similarity score is used to characterize the similarity between the first use case and the first candidate use case. Based on the first similarity score, the coverage relationship between the first use case and the first candidate use case, and the genealogical relationship between the first use case and the first candidate use case in the use case genealogy diagram, the redundancy type between the first use case and the first candidate use case is determined.

5. The method according to claim 4, characterized in that, The calculation of the first similarity score based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case includes: Based on the normalized use case information of the first use case and the normalized use case information of the first candidate use case, at least one similarity component is calculated. Each similarity component is used to characterize the similarity between the first use case and the first candidate use case in a similarity dimension. The first similarity score is calculated based on the at least one similarity component.

6. The method according to claim 1, characterized in that, After determining the redundancy type between each use case and its corresponding candidate use cases based on the standardized use case set and the use case genealogy diagram, the method further includes: Based on the redundancy type between each use case and the corresponding candidate use cases, processing suggestions are generated, which are used to process each use case and the corresponding candidate use cases.

7. A test case redundancy detection device, characterized in that, The device includes: an acquisition module and a processing module; The acquisition module is used to acquire an original set of test cases and to normalize the test case information of multiple test cases included in the original set of test cases to obtain a normalized set of test cases, wherein the normalized set of test cases includes the normalized test case information of the multiple test cases. The processing module is configured to establish a use case genealogy diagram among the multiple use cases based on the standardized use case set obtained by the acquisition module and the system version information corresponding to each use case in the multiple use cases. The use case genealogy diagram is used to characterize the association relationship among the multiple use cases. Based on the standardized use case set obtained by the acquisition module and the use case genealogy diagram, the processing module is configured to determine the redundancy type between each use case and the candidate use cases corresponding to each use case. The candidate use cases corresponding to each use case are: use cases that are redundant with each use case among the multiple use cases.

8. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the use case redundancy detection method as described in any one of claims 1-6.

9. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a computer, implement the use case redundancy detection method as described in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product is stored in a storage medium, and when the computer program product is executed by a computer, it implements the use case redundancy detection method as described in any one of claims 1-6.

Images