Test priority determination method and device, equipment and storage medium

Abstract

The invention relates to the technical field of test and artificial intelligence, and discloses a test priority determination method and device, equipment and a storage medium, and the method comprises the steps: carrying out the function module classification of version iteration associated data, the version iteration associated data comprises a new demand for application iteration, or comprises the new demand and an unclassified defect of an application; obtaining module statistical data of a function module of the application, wherein the module statistical data comprises a new demand number; and obtaining the test priority of the function module according to the module statistical data. According to the method, the function modules are matched for the new requirements and the defects, the test priority is dynamically optimized according to the new requirements and the defect distribution, the high-value function modules and the test cases can be centrally verified in the shortest time under the condition of urgent time, the integrated test efficiency and quality are improved, and the test level is guaranteed.

Description

Technical Field

[0001] The present application relates to the field of testing and artificial intelligence technology, and in particular to a method, apparatus, device and storage medium for determining test priority. Background Art

[0002] With the rapid iteration and agile release of software development models, enterprises' test case management platforms often accumulate tens of thousands of test cases. These test cases cover a wide range of business scenarios, interaction logic, and boundary conditions for different functional modules within apps or large-scale software systems. Application updates often introduce several new requirements, which intersect with existing functional modules. Combined with historical defects and potential risks, integration testing becomes extremely complex.

[0003] Integration Testing is the last step before version release, and it is necessary to verify the overall functionality of the APP or application software within a very short time window.

[0004] Existing technical solutions lack classification accuracy in complex multimodal scenarios and are inadequate for critical decision-making situations like integration testing. Traditional empirical decision-making and manual classification perform poorly in this critical scenario. Manually analyzing a large number of new requirements and defect descriptions and mentally matching them to corresponding modules and test cases consumes considerable time. Static prioritization strategies cannot dynamically adjust based on requirement criticality and defect distribution, resulting in valuable testing resources often being used to test low-value use cases while truly critical, high-risk modules are not promptly verified. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device, equipment and storage medium for determining test priority, aiming to solve the technical problem in the existing technology that test priority cannot be accurately determined.

[0006] A first aspect of the present application provides a method for determining a test priority, the method comprising:

[0007] Classifying the version iteration-related data into functional modules, wherein the version iteration-related data includes new requirements for application iteration, or the version iteration-related data includes new requirements for application iteration and unclassified defects of the application;

[0008] Obtain module statistics of the functional modules of the application, wherein the module statistics include the number of new requirements;

[0009] Get the test priority of functional modules based on module statistics.

[0010] The present application also provides a device for determining a test priority, the device for determining a test priority comprising:

[0011] a classification module, configured to classify the version iteration associated data into functional modules, wherein the version iteration associated data includes new requirements for application iteration, or the version iteration associated data includes new requirements for application iteration and unclassified defects of the application;

[0012] A statistical data acquisition module is used to obtain module statistical data of the functional modules of the application, wherein the module statistical data includes the number of new requirements;

[0013] The priority acquisition module is used to obtain the test priority of the functional module based on the module statistical data.

[0014] A third aspect of the present application provides a computer device comprising: a memory and at least one processor, wherein instructions are stored in the memory; and the at least one processor calls the instructions in the memory so that the computer device executes the above-mentioned method for determining test priority.

[0015] A fourth aspect of the present application provides a computer-readable storage medium, in which instructions are stored. When the computer-readable storage medium is run on a computer, the computer executes the above-mentioned method for determining test priority.

[0016] This application proposes matching functional modules for new requirements and defects, and dynamically optimizes test priorities based on new requirements and defect distribution. When time is tight, high-value functional modules and test cases can be centrally verified in the shortest time possible, thereby improving the efficiency and quality of integrated testing and ensuring the testing level. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flowchart of a first embodiment of a method for determining test priority in an embodiment of the present application;

[0018] Figure 2 This is a functional module diagram of an embodiment of a device for determining a test priority in an embodiment of the present application;

[0019] Figure 3 This is a schematic diagram of an embodiment of a computer device in an embodiment of the present application. DETAILED DESCRIPTION

[0020] The terms "first," "second," "third," "fourth," and the like (if any) in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" or "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] With the rapid iteration and agile release of modern software development models, enterprises' test case management platforms often accumulate tens of thousands of test cases. These test cases cover a wide range of business scenarios, interaction logic, and boundary conditions for different functional modules within apps or large-scale software systems. During version updates (for example, from v1.0 to v1.1 of a mobile app), several (e.g., two) new requirements are typically released. These new features intertwine with existing functional modules, and combined with historical defects and potential risks, integration testing becomes extremely complex.

[0022] Integration Testing is the last step before version release, and it is necessary to verify the overall functionality of the app within a very short time window (such as 1 day).

[0023] In the past, after iterating an application based on new requirements, functional modules were often manually categorized and tested before release. This presented the following issues:

[0024] Manual experience-driven method: Testers try to locate use cases related to a certain requirement or defect among tens of thousands of use cases based on their own experience and historical memory, which leads to inaccurate positioning and matching.

[0025] In addition, traditional solutions often adopt a static priority strategy. The test priority is often set at the beginning of the project and remains unchanged. It is unable to quickly respond to changes in the criticality of new requirements and sudden changes in defect distribution, resulting in the integration test link being unable to quickly focus on high-risk areas.

[0026] In summary, existing technical solutions lack classification accuracy in complex multimodal scenarios, provide limited support for urgent decision-making situations like integration testing, and fail to leverage large models and chain-based thinking to improve intelligent decision-making. Traditional empirical decision-making and manual classification perform poorly in this critical scenario. Manually analyzing a large number of new requirements and defect descriptions and mentally matching them to corresponding modules and test cases consumes considerable time. Static prioritization strategies cannot dynamically adjust based on requirement criticality and defect distribution, resulting in valuable testing resources often being used to test low-value use cases while truly critical, high-risk modules are not promptly verified.

[0027] Based on this, the present application provides a solution for determining test priority.

[0028] refer to Figure 1 , this application provides a method for determining test priority, the method for determining test priority including:

[0029] S100: Classifying version iteration associated data into functional modules, wherein the version iteration associated data includes new requirements for application iteration, or the version iteration associated data includes new requirements for application iteration and unclassified defects of the application.

[0030] Specifically, when it is necessary to iterate the version of application software or application program, developers will generate new requirements and improve the functions of the application software according to the new requirements.

[0031] In addition, for applications, testers can test the applications through divergent testing or exploratory testing to discover new defects in the applications.

[0032] New requirements, new defects, and historical unclassified defects are all version iteration-related data.

[0033] Based on new requirements, the application will be improved or newly added with functional modules. The defects found are also application defects caused by certain functional modules in the application. Based on this, this embodiment will classify the version iteration associated data into functional modules and determine the target functional module to which the version iteration associated data belongs.

[0034] In addition, the test case library records the mapping relationship between functional modules and test cases. New requirements and defects can also be quickly classified into the existing test case library based on the functional modules to which they belong.

[0035] S200: Obtain module statistics of functional modules of the application, wherein the module statistics include the number of new requirements.

[0036] Specifically, an application is an application program or APP, and the various functions of the application are implemented by functional modules. Generally speaking, the more defects a functional module has or the more new requirements it is associated with, the more likely it is that the functional module needs to be tested first. Based on this, this embodiment obtains module statistics for each functional module, and the module statistics include indexes or factors related to test priority: the number of new requirements associated with the functional module, or the number of new requirements and defects of defects associated with the functional module.

[0037] Defects include new defects and historical defects.

[0038] Module statistics can also include defect severity, module importance, and historical risk records.

[0039] S300: Obtaining the test priority of the functional module according to the module statistical data.

[0040] Specifically, the test priority score of each functional module can be calculated according to the module statistical data, and the test priority can be determined according to the test priority score.

[0041] The module statistical data can also be input into the test priority prediction model to predict the test priority of each functional module.

[0042] In addition, when it is necessary to verify the application or APP within a shorter time window, the functional module to which the version iteration associated data belongs can be directly identified as the priority testing module.

[0043] The test cases corresponding to the functional modules with higher test priorities are executed more preferentially to test the corresponding functional modules.

[0044] For example, the entire APP has 100 functional modules to be tested, but due to time constraints, only the most important functional modules can be selected for testing.

[0045] For example, if the live event room is the main feature of this version and has added several important features, and the karaoke room has recently discovered several serious bugs, and other modules such as the social room and the appearance live room have not undergone major changes in this iteration, the system will rank the live event room first, followed by the karaoke room, and then the appearance live room, the social room, and so on. If testing time is insufficient, at least the first two modules will be fully tested.

[0046] During the integration testing phase before a release, the testing team is often faced with numerous change requests and historical defects, leaving them with very little time to conduct a full verification. Furthermore, the importance or risk of each functional module may have changed during the current iteration.

[0047] If we still follow the fixed priorities set at the beginning of the project, we often cannot focus on the most critical and problematic functional points in time. This embodiment can dynamically adjust the test priority, focus on the most critical and problematic functional modules and give priority to testing.

[0048] This embodiment is a new requirement and defect matching functional module, which dynamically optimizes the test priority according to the new requirement and defect distribution. In a time-sensitive environment, high-value functional modules and test cases can be centrally verified in the shortest time, thereby improving the efficiency and quality of integrated testing and ensuring the test level.

[0049] In one embodiment, after obtaining the test priority of the functional module according to the module statistical data in step S300, the method for determining the test priority further includes:

[0050] Match the target test case set corresponding to the functional module from the test case library;

[0051] Filtering target test cases related to version iteration associated data from the target test case set;

[0052] Based on the test priority of the functional module, determine the test priority of the target test cases of the functional module.

[0053] Specifically, in existing technologies, requirement and defect information is often classified and decided based on manual experience. For example, testers are required to analyze numerous new requirement and defect descriptions, using their own experience and historical memory to attempt to locate test cases related to a particular requirement or defect within tens of thousands of test cases. This approach consumes significant manpower and time, and cannot guarantee the accuracy of test case matching. This demonstrates that traditional empirical decision-making and manual classification are inadequate and perform poorly in critical scenarios and decision-making situations like integration testing.

[0054] After completing module classification of requirements or defects and determining the testing priorities of functional modules, this embodiment can further perform fine-grained test case matching. This involves determining which test cases are most worthy of testing first among the dozens or even hundreds of test cases under certain functional modules. This allows for prioritizing the use of important test cases during time-sensitive integration testing.

[0055] The test case library stores test case sets corresponding to the functional modules, and each test case set includes at least one test case.

[0056] When time is tight, testing an application based on a set of test cases corresponding to all functional modules may take a long time and may result in precious testing resources being used to test low-value use cases, while truly critical, high-risk modules are not verified in a timely manner.

[0057] Based on this, this embodiment can filter out target test cases related to version iteration-related data from the template test case set of the functional module, conduct targeted and accurate testing of the application, and save testing time. Among the functional modules, the test priority of the target test cases of the functional module is the same as the test priority of the functional module.

[0058] In time-sensitive situations such as emergency releases, giving priority to using these target test cases to test the application can not only use valuable testing resources to test high-value use cases, but these target test cases usually involve one or more of the following: new functional modules, improved functional modules, high-risk functional modules corresponding to defects, etc. Therefore, giving priority to using these target test cases to test the application can prioritize testing of key functional modules and timely discover and eliminate application defects.

[0059] This embodiment can quickly associate new requirements and defects with existing test cases, and dynamically optimize the priority of test cases based on the latest requirements and defect distribution, so as to concentrate on verifying high-value modules and use cases in the shortest time, improve the efficiency and quality of integrated testing, and ensure the testing level.

[0060] In modern software projects, the number of test cases often grows from thousands to tens of thousands, covering various functional modules and business scenarios of the product.

[0061] In a specific embodiment, in order to facilitate the management of various functional modules and test cases, before using the test case library, a test case library in the form of a test case directory can also be constructed, wherein the test case directory contains a set of test cases corresponding to each functional module and sub-functional module; the test case directory can be constructed in a "tree-like" form, and managed hierarchically from top to bottom, with the top layer defined as the main functional domain (such as live broadcast room, dating, payment, etc.), and then the modules are further subdivided at the lower layer to form a grouping that conforms to the business logic and test scope.

[0062] The test case library can also include the association or mapping relationship between requirements and functional modules, and the association or mapping relationship between defects and functional modules.

[0063] By building a tree-like test case directory, it is easy to find matching test cases. When new requirements or defects appear, you can quickly lock the functional module to which they belong, and then filter out the target test cases from the use case collection under the functional module.

[0064] The following is an example of the test case directory structure:

[0065] To illustrate how to build a directory structure, let's take an example for an app. Assume the app has two main functional areas: live streaming and social networking. Based on the business scenario, these areas can be further broken down into:

[0066] Live broadcast room:

[0067] Multi-person video live broadcast room: including test cases such as multi-person audio and video connection, screen splitting, and PK functions (such as TC-2101~TC-2200, etc.).

[0068] Live event room: covers test cases such as game list display, guessing, and rankings (such as TC-2001 to TC-2100).

[0069] Beauty Live Room: A live broadcast scene that focuses on beauty filters and special effects.

[0070] Game live broadcast room: It is aimed at gamified interactive sessions, such as viewers playing mini-games with the host.

[0071] Interactive channel: provides universal barrage, gift rewards and other functions that can be reused by multiple live broadcast rooms.

[0072] Friendship:

[0073] Karaoke Room: Focuses on use cases such as karaoke, singing queues, multi-microphone sequence management, and multi-person chorus.

[0074] Radio Hall: A broadcasting scene that tends towards audio interaction.

[0075] Friendship Hall: supports group chat, friend interaction, room management and other functions.

[0076] Team building: Provides use cases related to multiplayer team play or social activities.

[0077] Within these submodules, we further break down test case sets into specific functional areas. For example, a "multi-person live video streaming room" might include multiple use cases involving microphone invitations, real-time video windows, background switching, and audio and video synchronization. Each category would then correspond to dozens of use cases, forming a hierarchical and relatively complete test case library.

[0078] In one embodiment, the functional module classification of the version iteration associated data in step S100 includes:

[0079] Obtain the attached image in the description document of the version iteration associated data;

[0080] Get the accompanying text of the accompanying drawing;

[0081] Constructing a first prompt corresponding to the version iteration associated data according to first designated data, and inputting the first prompt into the large language model, wherein the first designated data includes text associated with the drawing, a set of candidate functional modules, and a first user requirement description;

[0082] A module classification result of the version iteration associated data given by the large language model according to the first prompt is obtained, wherein the module classification result is used to indicate the functional module to which the version iteration associated data belongs.

[0083] Specifically, for each new requirement or defect, there is a corresponding description document, such as a new requirement document or a defect document, which is used to describe the new requirement or defect. The description document may include descriptive text and one or more drawings such as flowcharts, screenshots, or icons.

[0084] The drawings contain some text related to new requirements or defects, and the drawing-related information such as the drawing-related text in the drawings can be extracted through text extraction means.

[0085] The user can input or select first specified data into the computer device. The computer device can construct a first prompt based on the first specified data and input the prompt into the large language model. The large language model can then classify the functional modules to which the version iteration-related data belongs based on the prompt using chain thinking, and obtain a module classification result or a module identification result.

[0086] Prompts are guidance text provided when interacting with artificial intelligence (AI) dialogue systems. Like a magic wand guiding conversations, prompts help users better communicate with AI. By writing clear and specific prompts, users can accurately express their intentions and questions, resulting in more precise responses from the large language model.

[0087] In one example, the prompt includes the merged text, the candidate module list, and the requirement description text (the first user requirement description).

[0088] When the system calls the large language model, it can put the "candidate module list" (such as "multi-person video live broadcast room", "event live broadcast room", "karaoke hall", etc.) together with the merged text into the prompt word, and add the requirement description text to the prompt word. For example, the requirement description text is used to instruct the large language model "Please perform step-by-step reasoning (chain thinking) and finally give the functional module to which the requirement / defect is most likely to belong."

[0089] The merged text may be at least one of the original text in the description document and the text associated with the attached drawings.

[0090] The thinking chain process of the large language model is as follows:

[0091] The large model first extracts keywords internally, such as "chorus," "song request," and "ranking." It then compares the features of the "music room," "radio room," and "multi-person live video streaming room" modules. If the words "music request" and "chorus" appear repeatedly in the text, the model determines that the corresponding new requirement or defect is more likely related to the "music room."

[0092] This process model will output a chain of thought, for example: "Step 1: Discover 'Karaoke', Step 2: Compare the characteristics of 'Multi-person Video Live Room'... Step 3: Conclusion = Karaoke Hall."

[0093] The large language model outputs the result: "This demand / defect is most suitable for the karaoke module under the dating section", and the system then completes the approximate association.

[0094] Large Language Models (LLMs), also known as large language models, are AI models designed to understand and generate human language. Trained on large amounts of text data, LLMs can perform a wide range of tasks, including text summarization, translation, and sentiment analysis. LLMs are characterized by their massive size and billions of parameters, which help them learn complex patterns in language data.

[0095] Chain-of-Thought (CoT): A prompt engineering method that requires large models to demonstrate a step-by-step reasoning process before answering, making decisions more explainable, auditable, and reducing errors.

[0096] Example description:

[0097] Requirements example:

[0098] The document states, "I want to add a live PK function to the karaoke room. The attached screenshot shows a 'Start PK button.'" There's no "Module" field. The OCR, flowchart, and description all indicate it's related to karaoke or chorus. After analysis, the large model outputs the "Most Matching Karaoke Room," which the system categorizes as a "Friendship / Karaoke Room" functional module.

[0099] Defect examples:

[0100] The document states: "In a multi-person video livestream, after clicking 'Connect with Viewers,' the other party accepts, but the screen displays distorted images." There's no "Related Use Case" field. The screenshot OCR reads: "Connecting..." The large model, based on the keywords "multi-person video" and "connecting viewers," identifies this issue as belonging to the "Livestream / Multi-person Video Livestream" category.

[0101] Furthermore, to support "approximate association paths," few-shot data can be collected, including requirements descriptions and defect descriptions of previously successfully identified functional modules, along with their correct classification results. These examples can be included in prompts when invoking the large model, improving the accuracy of model reasoning.

[0102] Existing technologies use simple text methods such as keyword matching. This solution attempts to roughly determine associations by calculating similarities between requirements, defects, and use case texts using basic NLP techniques such as word segmentation, N-Gram, and the Jaccard coefficient. However, this approach is incapable of handling multimodal information (such as UI elements in screenshots or logical paths in flowcharts), fails to truly understand the semantic meaning of requirements, and results in limited classification accuracy.

[0103] In existing practices, there is a lack of application of big models and chain thinking. Large language models (LLMs) and multimodal processing technologies are not used to deeply understand requirements and defect descriptions to achieve more accurate module classification and use case matching. There are also no cases of introducing big model reasoning and chain thinking step-by-step thinking in integration test priority decisions.

[0104] This embodiment introduces a multimodal large model, thought chain prompts and dynamic priority optimization strategy to achieve significant improvements to existing solutions.

[0105] This embodiment utilizes "approximate association paths" to automatically determine the module to which a new requirement or defect is most likely to belong during module classification analysis, using a multimodal large model and thought chain prompts. This method not only considers simple descriptions but also considers both the original document text and the accompanying text. Combining multimodal information allows for accurate classification of the functional module to which the new requirement or defect belongs. Furthermore, this embodiment incorporates large language model reasoning and step-by-step thought chain thinking to deeply understand requirement and defect descriptions, enabling more precise module classification and use case matching, and improving intelligent decision-making.

[0106] In one embodiment, obtaining the accompanying text of the accompanying drawings includes:

[0107] If the attached image contains a screenshot, identifying the text information in the screenshot;

[0108] If the attached image contains an icon, identifying the icon and obtaining an icon description of the icon;

[0109] If the attached figure includes a flow chart, the node information (node ​​key points and flow direction or flow arrow) of each flow node in the flow chart is extracted.

[0110] Specifically, obtain the first attached figure in the requirement document (description document) of the new requirement;

[0111] Get the first figure's associated text:

[0112] If the first attached figure includes a screenshot, identifying text information in the screenshot;

[0113] If the first attached image includes an icon, identifying the icon and obtaining an icon description of the icon;

[0114] If the first figure includes a flowchart, node information of each flow node in the flowchart is extracted, wherein the node information includes, for example, the key points of the node, the flow direction corresponding to the flow arrow, and the like.

[0115] The text information in the above screenshots, the icon descriptions of the icons, and the node information in the flowchart are all text or information associated with the drawings.

[0116] Constructing a first prompt corresponding to the new requirement based on first specified data, and inputting the first prompt into the large language model, wherein the first specified data includes original text in the requirement document of the new requirement, at least one of the text associated with the first figure, and a first set of candidate functional modules;

[0117] A first module identification result of the new requirement given by the large language model according to the first prompt is obtained, wherein the first module identification result is used to indicate the functional module to which the new requirement belongs.

[0118] Obtaining a second drawing in a defect document (description document) of an unclassified defect;

[0119] Get the second figure's associated text:

[0120] If the second attached image includes a screenshot, identifying text information in the screenshot;

[0121] If the second attached image includes an icon, identifying the icon and obtaining an icon description of the icon;

[0122] If the second figure includes a flow chart, node information of each flow node in the flow chart is extracted, wherein the node information includes, for example, key points of the node, flow directions corresponding to flow arrows, etc.;

[0123] The text information in the above screenshots, the icon descriptions of the icons, and the node information in the flowchart are all text associated with the attached drawings.

[0124] constructing a first prompt corresponding to the defect based on first designated data, and inputting the first prompt into the large language model, wherein the first designated data includes at least one of original text in the defect document that is not classified as a defect, text associated with the second drawing, and a second set of candidate functional modules;

[0125] A second belonging module identification result of the unclassified defect given by the large language model according to the first prompt is obtained, wherein the second belonging module identification result is used to indicate the functional module to which the unclassified defect belongs.

[0126] More specifically, if a screenshot is included in the requirement document or defect document, the system can call the OCR (optical character recognition) module to extract text information in the screenshot, such as "initiate a chorus", "multi-person live broadcast", "PK challenge", etc.

[0127] For icons, text identifiers within them can be identified. Furthermore, during the UI design phase, a mapping table between icons and icon descriptions can be stored. From this mapping table, the corresponding icon description for any icon can be matched, enabling the purpose of identifying icons and converting them into readable text. For example, the description for a gift icon might be "Gift Reward Entrance."

[0128] For flowcharts, if a flowchart is included in the requirement document or defect document, for example, one or more of a UML sequence diagram, an activity diagram, or a simple block diagram, the system can transcribe the key points of each node in the flowchart into sentences, thereby realizing the transcription of the flowchart and obtaining a flowchart transcribed text.

[0129] Flowchart example: "Enter the karaoke room → Select a song → Start a chorus → Update the queue after the chorus ends."

[0130] In addition, the original text and the text associated with the attached drawings in the requirement document or defect document can be merged to obtain the merged text. For example:

[0131] Combine the original text of the requirement / defect, the OCR recognition results corresponding to the screenshot, the icon description, and the flowchart transcription text into a context, for example:

[0132] Requirement description (original text): Enable multi-person chorus function in the karaoke room

[0133] OCR recognition result: The "Start Chorus" button is recognized from the screenshot

[0134] Flowchart transcription text: Enter the karaoke room -> Start a chorus -> UI shows that multiple people are singing together

[0135] In subsequent analysis, the large model of this embodiment can simultaneously consider text, screenshot information, icon descriptions, and process diagrams, rather than just a simple description. Combining multimodal information can accurately classify the functional modules to which new requirements or defects belong.

[0136] In one embodiment, before obtaining the drawings in the description document of the version iteration associated data, the version iteration associated data is classified into functional modules, further comprising:

[0137] If the target clue of the function module is found from the target field of the associated data record table, the function module to which the version iteration associated data belongs is determined according to the target clue of the function module;

[0138] If no target clue of the function module is found in the target field of the associated data record table, the attached figure and subsequent steps in the description document of obtaining the version iteration associated data are executed.

[0139] or,

[0140] In one embodiment, the version iteration associated data is classified into functional modules, including:

[0141] Find the functional module clues of the version iteration related data from the target field of the related data record table;

[0142] If the target clue of the function module is found from the target field of the associated data record table, the function module to which the version iteration associated data belongs is determined according to the target clue of the function module.

[0143] Specifically, in daily development and testing, various records are accumulated through the requirements management system, defect management system, and test case management platform:

[0144] Requirement ID: such as REQ-1001, REQ-1002, used to identify a new functional requirement.

[0145] Defect ID: such as BUG-101, BUG-202, used to track the problem and the repair process.

[0146] Use case ID: such as TC-3001, TC-3002, corresponding to an item in the test case set.

[0147] Many projects include fields such as "Module," "Related Use Cases," and "Affected Scope" in requirements or defect tickets. This can be considered structured information and is crucial for subsequent automated classification. In this embodiment, these fields are exported from the management system and maintained in a data table in the background, forming a mapping.

[0148] For example, this data table is a related data record table that records the related data corresponding to each requirement and defect. For example:

[0149] The following data is recorded in the associated data record table:

[0150] Requirement "REQ-500" record: Module = Event Live Broadcast Room

[0151] Defect "BUG-25" record: Related use case ID = TC-2030

[0152] By promptly completing these fields each time a new requirement is raised or a new defect is discovered, you can use the "precise association path" later to achieve direct mapping.

[0153] In this embodiment, before determining the functional module to which the version iteration associated data belongs through the attached drawing information, the target functional module to which the version iteration associated data belongs may be determined through field matching.

[0154] Search the target field in the associated data record table for the functional module associated with the version iteration. For example, for a requirement, the functional module associated with the requirement is the value of the "Associated Module" field; for a defect, the functional module associated with the defect is the value of the "Associated Use Case" field.

[0155] In addition, the "Module" and "Related Use Case" fields can be directly entered into the requirements document for the corresponding requirement and the defect document for the corresponding defect. The associated data record table is equivalent to the requirements document or defect document. By scanning the requirements document and the corresponding defect document, you can also determine whether the requirements document contains the "Module" field and whether the defect document contains the "Related Use Case" field.

[0156] In addition, if the coverage of the associated data record table is limited, these target fields are not filled in, or the values ​​of the target fields are filled in incorrectly, the precise association path cannot be called, and the only option is to call the "approximate association path".

[0157] The logic of "approximate association path" is as follows:

[0158] If, for a certain requirement, the requirement document or the associated data record table does not contain the "Belonging Module" field, or the value of the "Belonging Module" field is empty, or the value of the "Belonging Module" field is incorrect, then the attached figure in the description document of obtaining the version iteration associated data and subsequent steps are executed to call the approximate association path for module matching.

[0159] If, for a defect, the defect document or associated data record table does not contain the "Associated Use Case" field, or the value of the "Associated Use Case" field is empty, or the value of the "Associated Use Case" field is incorrect, the attached figure in the description document for obtaining the version iteration associated data and subsequent steps are executed to call the approximate association path for module matching.

[0160] In this embodiment, when a target field is missing or contains an incorrect value in a requirement or defect document, the "approximate association path" can be invoked to automatically determine the module to which the new requirement or defect is most likely to belong, using a multimodal large model and thought chain prompts. This function is crucial. In many practical scenarios, people writing requirement / defect descriptions inevitably omit labels such as "belonging module" and "associated use case." In such cases, by using the approximate association path to obtain text information from screenshots, flowcharts, and icons, a precise match of functional modules can be achieved.

[0161] This embodiment preferentially uses field matching to obtain clues about the functional modules to which new requirements or defects belong, which can quickly and accurately achieve module classification matching.

[0162] In one embodiment, if a target clue of a function module is found from the target field of the associated data record table, determining the function module to which the version iteration associated data belongs according to the target clue of the function module includes:

[0163] If the version iteration-related data is a new requirement, the function module to which the new requirement belongs is searched from the module field in the requirement record table;

[0164] If the version iteration associated data is an unclassified defect, the associated use case of the unclassified defect is searched from the associated use case field of the defect record table. Based on the association relationship between the functional modules and test cases in the test case library, the functional module associated with the associated use case is determined to be the functional module to which the unclassified defect belongs.

[0165] Specifically, the target clue of the function module is the value of the function module field or the associated use case field; the associated data record table is the requirement record table or the defect record table.

[0166] If the version iteration associated data is a new requirement, the module field of the new requirement is matched and searched in the requirement record table. The functional module to which the new requirement belongs can be determined based on the field value of the module.

[0167] If the version iteration associated data is an unclassified defect, the associated use case of the unclassified defect is searched from the associated use case field of the defect record table. Based on the association relationship between the functional modules and test cases in the test case library, the functional module associated with the associated use case is determined to be the functional module to which the unclassified defect belongs.

[0168] The requirement record table may be a requirement document, and the defect record table may be a defect document.

[0169] In addition, after determining the functional module to which the new requirement or defect belongs, the new requirement or defect can be mapped to the corresponding node of the test case library to associate the new requirement and defect with the functional module to facilitate the use of these associations in subsequent steps.

[0170] More specifically, during scanning and parsing, the system automatically scans the requirement record or defect record for fields such as "Module" and "Related Use Case" when creating or updating a requirement or defect. If these fields are not empty, the system then proceeds to the precise association logic or precise association path.

[0171] Complete classification: For example, if a requirement "REQ-500" records "Belongs to module = event live broadcast room", it will directly fall into the "live broadcast room / event live broadcast room" functional module level; if "Belongs to module = karaoke hall", it will directly fall into the "karaoke hall" level; if the defect "BUG-50" is marked with "Associated use case ID = TC-1052", then according to the functional module corresponding to the associated use case, it can be quickly determined that the defect belongs to the "dating / karaoke hall" functional module.

[0172] Compare test case catalog: The system queries the internally maintained index table, for example: test case TC-2050 → "Event Live Broadcast Room" module, test case TC-1050 → "Karaoke Hall" module, and then directly associates requirements / defects with use cases or functional modules in the test case catalog.

[0173] This embodiment can complete module classification matching through existing structured fields, with simple operation, high efficiency and low error rate.

[0174] In one embodiment, the module statistics also include the number of defects. Step S300 of obtaining the test priority of the functional module based on the module statistics includes:

[0175] Input the module statistics of each functional module into the large language model, use the large language model to sort the priority of each functional module, and obtain the test priority of the functional module;

[0176] or,

[0177] The key indicators that affect the module test priority are calculated based on the module statistical data, where the module statistical data also includes the module importance and historical risk records. The key indicators include requirement importance, defect quantity increment, module importance and historical risk coefficient. The key indicators are substituted into the module test priority score calculation formula to obtain the test priority score of the functional module. The module test priority score calculation formula is the weighted sum of the key indicators.

[0178] Specifically, after completing the module classification of requirements or defects, you can further dynamically adjust the testing priority of functional modules in the integration test, that is, in the time-sensitive integration test, determine which functional modules to test first and which functional modules are most worthy of priority testing.

[0179] The module statistics of the functional modules can be input into the large language model, and the large language model is used to sort the priorities of the functional modules to obtain the test priority of the functional modules. The test priority of the functional modules includes the test priority sorting of each functional module.

[0180] In addition, you can instruct the large language model to output a "test priority sorting description" to help users understand the logic and rationality of the large language model test priority sorting.

[0181] Key indicators that affect module testing priorities can also be calculated based on module statistics, where module statistics include the number of new requirements, the number of defects, module importance, and historical risk records.

[0182] The importance of the functional module's requirements can be determined based on the number of new requirements. Generally, the higher the number of new requirements, the higher the importance of the requirements.

[0183] For the same functional module, the change in the number of defects before and after the revision can be counted to obtain the incremental number of defects.

[0184] In addition, the severity of defects in the functional modules can also be calculated based on the severity of the defects. The more defects a functional module contains and the higher the severity of the defects, the higher the severity of the defects in the functional module.

[0185] The historical risk coefficient of a functional module can be calculated based on the historical risk records corresponding to the functional module. The more historical risk records a functional module has, the greater the historical risk coefficient.

[0186] Key indicators include requirement importance, defect quantity increment, module importance and historical risk factor, and may also include defect severity.

[0187] Substitute the key indicators into the module test priority score calculation formula to obtain the test priority score of the functional module. The higher the test priority score, the more priority it needs to be tested. The module test priority score calculation formula reflects the multi-factor scoring rule.

[0188] In one embodiment, the module test priority score calculation formula is shown in the following formula 1:

[0189] Module test priority score = (requirement importance × α) + (defect number increment × β) + (module importance × γ) + (historical risk coefficient × δ) Formula 1.

[0190] For example, the system will eventually give a module priority list, such as: "Event live broadcast room (highest) > Karaoke room (high) > Game live broadcast room (medium) > Appearance live broadcast room (medium) > Dating room (low)".

[0191] Based on this, the testing team decided to execute the relevant test cases for the event live broadcast room and the karaoke room first, and put the less important modules at the end to ensure that the core functions were verified first.

[0192] During the integration testing phase before a release, the testing team is often faced with numerous change requests and historical defects, leaving them with very little time to conduct full verification. Furthermore, the importance or risk of each module can change during the current iteration.

[0193] If we still follow the unchanging priorities set at the beginning of the project, we often cannot focus on the most critical and problematic functional points in a timely manner.

[0194] This embodiment can accurately obtain the test priority of the functional module based on the module statistical data, and dynamically adjust the priority of the functional module to optimize the order of functional module verification during the integration test process. It can prioritize the verification of important and critical functional modules in a shorter time, focus on the most critical and most likely problematic functional points, correct application defects in time before release, and ensure the normal operation of various functions after the application is released.

[0195] In one embodiment, filtering out target test cases related to version iteration associated data from a target test case set includes:

[0196] Calculate the similarity between the description text of the version iteration associated data and the description text of the test cases in the target test case set;

[0197] According to the obtained similarity, at least one target test case having a similarity greater than a similarity threshold is selected from the target test case set.

[0198] Specifically, the version iteration-related data is new requirements or unclassified defects.

[0199] After completing the module classification of requirements or defects, you can further perform fine matching of test cases to determine which test cases are most worth testing first among the dozens or even hundreds of test cases under the functional modules.

[0200] Each functional module may have multiple sub-functional modules, and each sub-functional module often has many use cases. Just knowing that the requirement / defect belongs to a certain module is not enough to directly "select the use case".

[0201] This embodiment selects several test cases that are most consistent with the target requirements / defects from the test case set under the functional module based on similarity.

[0202] More specifically, the description text of the requirements or defects, the title of each test case, the operation steps and other texts are vectorized (Embedding), the similarity score is calculated, and the first few use cases with similarity greater than the similarity threshold are selected.

[0203] Embedding, vectorization, Embedding is a method of using a numerical vector to "represent" an object (Object).

[0204] Given two texts A and B, text similarity refers to the degree of semantic similarity between the two texts.

[0205] The at least one target test case with the highest similarity includes a preset number of test cases with the highest similarity, or includes the top m percent of test cases with the highest similarity.

[0206] This allows the testing team to execute these highly relevant use cases first to verify new functions or defects as early as possible.

[0207] In one embodiment, filtering out target test cases related to version iteration associated data from a target test case set includes:

[0208] Constructing a second prompt according to second specified data, and inputting the second prompt into the large language model, wherein the second specified data includes a target test case set, a description text of the version iteration associated data, and a second user requirement description;

[0209] Obtain a prioritized test case matching list output by the large language model, wherein the test case matching list includes target test cases related to the version iteration associated data matched from the target test case set.

[0210] Specifically, the second user requirement description is used to instruct the large language model to match target test cases related to the version iteration associated data from the target test case set; the target test case set includes description texts of the test cases.

[0211] The description text of the version iteration associated data is used to describe new requirements or defects.

[0212] The large model then compares the results again: The second prompt is fed into the large language model, which then reads the test cases for the functional module one by one. Using a chain of thought, it lists the test cases that mention core actions or keywords and align with the current requirement or defect. Finally, it returns a prioritized list of target test cases related to the requirement or defect.

[0213] Example:

[0214] Suppose the "Karaoke Hall" functional module has 50 test cases. A new requirement associated with this module includes the requirement "shared lyrics and subtitles for multi-person chorus singing." Using a large model or similarity algorithm, we can find five test cases (TC-1053, TC-1057, TC-1060, etc.) that contain "multi-person chorus singing" and "subtitle synchronization" from the 50 test cases. This prioritizes these test cases for execution by the test team.

[0215] In addition, intersection test cases can be screened out from the two sets of target test case sets obtained by the similarity method and the large model semantic analysis method. The intersection test cases are included in both sets of target test case sets, further ensuring the accuracy of the final target test cases screened out.

[0216] This example uses text comparison or large-scale semantic analysis at the use case level to select several test cases from the functional modules that best align with the target requirements / defects. This allows the team to execute these highly relevant use cases first to verify new features or defects as early as possible.

[0217] Each module often contains numerous test cases. Simply knowing the functional module to which a requirement or defect belongs isn't enough to directly "select" a test case. This application uses text comparison or large-scale semantic analysis at the use case level to select a number of target test cases from the functional module that best align with the target requirement or defect. This allows the team to execute these highly relevant test cases first, verifying new features or defects as early as possible.

[0218] The following describes the entire process from requirement description to test completion:

[0219] This article uses a more complete scenario to demonstrate how to address requirements and defects in a version integration test by relying on the "precise association" and "approximate association" paths of this application, as well as subsequent use case screening and priority adjustment.

[0220] Scenario description:

[0221] During a certain version iteration, the following requirements and defects emerged:

[0222] Request: Add a "multi-person live broadcast" feature to a multi-person live broadcast room, allowing the host and multiple viewers to appear simultaneously on the video screen. The attached screenshots (OCR can identify "initiate multi-person live broadcast") and a simple flowchart ("enter multi-person live broadcast room -> host clicks connect -> multiple viewers join -> split-screen display") are provided, but the document does not specify the module to which this function belongs.

[0223] Defect: There is a historical defect, BUG-50, which states, "If two users simultaneously request a duet in a karaoke room, queue management may fail." The bug tracking system lacks an "associated use case" field and does not specify which module it belongs to. Only a screenshot (OCR extraction shows "Karaoke request failed") and steps are provided.

[0224] The following is a demonstration of the process:

[0225] 1. Directory Check and Accurate Association

[0226] The system first scans the requirements and defects to see if there are any fields for "belonging module" or "associated use case". The results show that:

[0227] There is no such information for new requirements;

[0228] BUG-50 also has no clear key information.

[0229] Therefore, it is impossible to complete the precise association directly, and it is necessary to switch to the "approximate association path".

[0230] 2. Approximate association path

[0231] 2.1 Requirements for multiple people to connect to the microphone

[0232] Preprocessing

[0233] OCR recognizes the words "Initiate multi-person call" button from the screenshot.

[0234] The flow chart is transcribed as "entering the multi-person video live broadcast room->the anchor clicks to connect to the microphone->multiple viewers connect->split-screen display".

[0235] Big Model + Chain Thinking

[0236] The system integrates the list of optional modules (multi-person video live broadcast room, event live broadcast room, karaoke room, etc.) with the above text into prompts and provides them to the big model, requiring a step-by-step analysis of the requirement text and screenshots / flowcharts.

[0237] The large model outputs: "Based on keywords such as multi-person video, anchor connection, and split screen, this demand should be classified as 'live broadcast room / multi-person video live broadcast room'."

[0238] Classification

[0239] System record: This requirement falls on the "live broadcast room / multi-person video live broadcast room".

[0240] 2.2 Bug BUG-50

[0241] Preprocessing

[0242] The document only states "Chorus request caused queue exception", and the screenshot OCR shows "Order failed".

[0243] Big Model + Chain Thinking

[0244] The prompt lists options such as "event live broadcast room, appearance live broadcast room, karaoke room, and multi-person video live broadcast room".

[0245] After the large model analysis, it was determined that "chorus and karaoke in this description are keywords unique to karaoke halls" and should be classified into "social / karaoke halls".

[0246] Classification

[0247] System record: BUG-50 belongs to the "Friendship / Karaoke Room".

[0248] 3. Fine Matching of Use Cases

[0249] 3.1 Requirements for multi-person live broadcast

[0250] The requirements have been categorized into "Live Broadcast Room / Multi-person Video Live Broadcast Room," and there may be hundreds of use cases under this module (TC-2101 to TC-2200).

[0251] Through similarity or large-scale model comparison, we screen out use cases that are most similar to "multi-person connection", "split-screen live broadcast", and "anchor and audience interaction", such as TC-2150, TC-2152, TC-2155, etc.

[0252] The system recommends that these use cases be tested first to cover the core processes of new requirements.

[0253] 3.2 Bug BUG-50

[0254] The defect lies in the "Dating / Karaoke Hall" module, which may have 60 use cases.

[0255] After scanning keywords such as "chorus", "song request", and "queue management", find the corresponding 3 to 5 most relevant use cases (such as TC-1052, TC-1054, and TC-1057).

[0256] This allows the tester to immediately regress and verify the core scenarios related to the defect.

[0257] 4. Dynamic adjustment of priority

[0258] When the team is preparing to conduct integration testing for this version, it must also consider other requirements and defect distribution to determine the order of the entire testing schedule. The system automatically calculates the results:

[0259] The new multi-person live video streaming feature in this round is a major highlight of the version.

[0260] The "Karaoke Hall" has had many bugs recently, and BUG-50 has not been completely resolved;

[0261] The live broadcast room of the event only underwent minor repairs this time;

[0262] There are no obvious changes to the appearance live broadcast room and other modules.

[0263] The system or built-in policy engine gives the priority ranking thus:

[0264] Live broadcast room / multi-person video live broadcast room (highest), because of the importance of new functions;

[0265] Friendship / Karaoke Hall (high), due to frequent defects;

[0266] Live broadcast room / event live broadcast room (middle), little change;

[0267] Other modules (medium or low).

[0268] Based on this, the testing team first arranged core manpower to test the key use cases of the "Multi-person Video Live Room", then dealt with the defect-related use cases of the "Karaoke Room", and finally covered the event live room and other modules.

[0269] This application dynamically increases the priority of high-risk and high-criticality modules, allowing the testing team to focus on verifying areas that may cause major problems, discover and resolve defects in advance, and reduce the risk of going online.

[0270] refer to Figure 2 The present application also provides a device for determining a test priority, characterized in that the device for determining a test priority includes:

[0271] A classification module 100 is configured to classify version iteration-related data into functional modules, wherein the version iteration-related data includes new requirements for application iterations, or the version iteration-related data includes new requirements for application iterations and unclassified defects of the application;

[0272] The statistical data acquisition module 200 is used to obtain module statistical data of the functional modules of the application, wherein the module statistical data includes the number of new requirements;

[0273] The priority acquisition module 300 is used to acquire the test priority of the functional module according to the module statistical data.

[0274] In one embodiment, the test priority determination device further includes:

[0275] The test case matching module is used to match the target test case set corresponding to the functional module from the test case library;

[0276] A test case screening module is used to screen out target test cases related to version iteration associated data from a target test case set;

[0277] The use case test priority determination module is used to determine the test priority of the target test cases of the functional modules based on the test priority of the functional modules.

[0278] In one embodiment, the classification module 100 includes:

[0279] An illustration acquisition module is used to acquire illustrations from a description document of version iteration associated data;

[0280] A text extraction module, used to obtain the accompanying text of the accompanying drawings;

[0281] A first prompt constructing module is configured to construct a first prompt corresponding to the version iteration-related data based on first specified data, and input the first prompt into the large language model, wherein the first specified data includes text associated with the version diagram, a set of candidate functional modules, and a first user requirement description;

[0282] The classification result acquisition module is used to obtain the module classification result of the version iteration associated data given by the large language model according to the first prompt, wherein the module classification result is used to indicate the functional module to which the version iteration associated data belongs.

[0283] In one embodiment, the text extraction module includes:

[0284] A screenshot recognition module, configured to recognize text information in a screenshot if the attached image contains a screenshot;

[0285] An icon recognition module, configured to recognize an icon if one is included in the attached drawing and obtain an icon description of the icon;

[0286] The flowchart recognition module is used to extract the node information of each flow node in the flowchart if the attached figure contains a flowchart.

[0287] In one embodiment, the classification module 100 further includes:

[0288] A clue search and classification module is used to determine the function module to which the version iteration associated data belongs according to the function module target clue if a target clue of the function module to which the associated data belongs is found from the target field of the associated data record table;

[0289] The jump module is used to execute the attached figure and subsequent steps in the description document of obtaining version iteration related data if the target clue of the functional module is not found from the target field of the related data record table.

[0290] In one embodiment, the clue search and classification module includes:

[0291] The first field searches for the classification module, and is used to search the function module to which the new requirement belongs from the module field of the requirement record table if the version iteration associated data is a new requirement;

[0292] The second field searches for the classification module. If the version iteration associated data is an unclassified defect, the associated use case of the unclassified defect is searched from the associated use case field of the defect record table. Based on the association relationship between the functional modules and the test cases in the test case library, it is determined that the functional module associated with the associated use case is the functional module to which the unclassified defect belongs.

[0293] In one embodiment, the module statistics also include the number of defects. The priority acquisition module 300 includes:

[0294] The model prediction module is used to input the module statistical data of each functional module into the large language model, use the large language model to sort the priority of each functional module, and obtain the test priority of the functional module;

[0295] or,

[0296] The priority acquisition module 300 includes:

[0297] The indicator calculation module is used to calculate the key indicators that affect the module test priority based on the module statistical data. The module statistical data also includes the module importance and historical risk records. The key indicators include the importance of requirements, the increase in the number of defects, the module importance and the historical risk coefficient.

[0298] The score calculation module is used to substitute key indicators into the module test priority score calculation formula to obtain the test priority score of the functional module.

[0299] The module test priority score calculation formula is the weighted sum of key indicators.

[0300] In one embodiment, the test case screening module includes:

[0301] A similarity calculation module, used to calculate the similarity between the description text of the version iteration associated data and the description text of the test case in the target test case set;

[0302] The target case screening module is used to select at least one target test case with a similarity greater than a similarity threshold from the target test case set according to the obtained similarity.

[0303] In one embodiment, the test case screening module includes:

[0304] a second prompt constructing module, configured to construct a second prompt according to second specified data, and input the second prompt into the large language model, wherein the second specified data includes a target test case set, a description text of the version iteration associated data, and a second user requirement description;

[0305] The use case screening result acquisition module is used to obtain the test case matching list output by the large language model, wherein the test case matching list includes the target test cases related to the version iteration associated data matched from the target test case set.

[0306] Figure 37 is a structural diagram of a computer device provided in an embodiment of the present application. The computer device 700 may have relatively large differences due to different configurations or performances, and may include one or more processors (central processing units, CPU) 710 (for example, one or more processors) and a memory 720, and one or more storage media 730 (for example, one or more massive storage devices) for storing application programs 733 or data 732. Among them, the memory 720 and the storage medium 730 can be temporary storage or persistent storage. The program stored in the storage medium 730 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the computer device 700. Furthermore, the processor 710 can be configured to communicate with the storage medium 730 to execute a series of instruction operations in the storage medium 730 on the computer device 700.

[0307] The computer device 700 may further include one or more power supplies 740, one or more wired or wireless network interfaces 750, one or more input and output interfaces 760, and / or one or more operating systems 731. It will be appreciated by those skilled in the art that Figure 3 The illustrated computer device structure does not limit the computer device and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0308] The present application also provides a computer device, which includes a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor executes the steps of the test priority determination method in the above-mentioned embodiments.

[0309] The present application also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. The computer-readable storage medium stores instructions, which, when executed on a computer, cause the computer to execute the steps of the test priority determination method.

[0310] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0311] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0312] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for determining test priority, characterized in that: The method for determining the test priority includes: Classifying the version iteration associated data into functional modules, wherein the version iteration associated data includes new requirements for application iteration, or the version iteration associated data includes new requirements for application iteration and unclassified defects of the application; Obtaining module statistics of the functional modules of the application, wherein the module statistics include the number of new requirements; The test priority of the functional module is obtained according to the module statistical data.

2. The method for determining test priority according to claim 1, wherein: After obtaining the test priority of the functional module according to the module statistical data, the test priority determination method further includes: Match the target test case set corresponding to the functional module from the test case library; Filtering target test cases related to the version iteration associated data from the target test case set; Based on the test priority of the functional module, the test priority of the target test case of the functional module is determined.

3. The method for determining test priority according to claim 1 or 2, wherein: The functional module classification of version iteration related data includes: Obtaining the attached drawings in the description document of the version iteration associated data; Obtaining the accompanying text of the drawing; Constructing a first prompt corresponding to the version iteration-related data according to first designated data, and inputting the first prompt into a large language model, wherein the first designated data includes the text associated with the drawing, the set of candidate functional modules, and the first user requirement description; Obtain a module classification result of the version iteration associated data given by the large language model according to the first prompt.

4. The method for determining test priority according to claim 3, wherein: The obtaining of the accompanying drawing text includes: If the drawing includes a screenshot, identifying text information in the screenshot; If the drawing includes an icon, identifying the icon and obtaining an icon description of the icon; If the drawing includes a flowchart, node information of each flow node in the flowchart is extracted.

5. The method for determining test priority according to claim 3, wherein: Before obtaining the drawings in the description document of the version iteration associated data, the functional module classification of the version iteration associated data further includes: If a target clue of the function module is found from the target field of the associated data record table, the function module to which the version iteration associated data belongs is determined according to the target clue of the function module; If no target clue of the function module is found in the target field of the associated data record table, the accompanying drawings and subsequent steps in the description document of obtaining the version iteration associated data are executed.

6. The method for determining test priority according to claim 1 or 2, characterized in that: The module statistics also include the number of defects, The obtaining the test priority of the functional module according to the module statistical data includes: Calculate key indicators that affect module testing priority based on the module statistical data, wherein the module statistical data also includes module importance and historical risk records, and the key indicators include requirement importance, defect quantity increment, module importance and historical risk coefficient, Substitute the key indicators into the module test priority score calculation formula to obtain the test priority score of the functional module, wherein the module test priority score calculation formula is the weighted sum of the key indicators.

7. The method for determining test priority according to claim 2, wherein: The step of screening out target test cases related to the version iteration associated data from the target test case set includes: Calculating the similarity between the description text of the version iteration associated data and the description text of the test cases in the target test case set; According to the obtained similarity, at least one target test case having a similarity greater than a similarity threshold is selected from the target test case set.

8. A device for determining test priority, characterized in that: The test priority determination device includes: a classification module, configured to classify the version iteration associated data into functional modules, wherein the version iteration associated data includes new requirements for application iteration, or the version iteration associated data includes new requirements for application iteration and unclassified defects of the application; A statistical data acquisition module, configured to acquire module statistical data of the functional modules of the application, wherein the module statistical data includes the number of new requirements; The priority acquisition module is used to obtain the test priority of the functional module according to the module statistical data.

9. A computer device, characterized in that: The computer device includes: a memory and at least one processor, wherein instructions are stored in the memory; The at least one processor calls the instructions in the memory to enable the computer device to execute the method for determining the test priority according to any one of claims 1 to 7.

10. A computer-readable storage medium having instructions stored thereon, characterized in that: When the instructions are executed by a processor, the method for determining the test priority according to any one of claims 1 to 7 is implemented.

Images