Test requirement analysis method, device and storage medium

Abstract

This application discloses a test requirements analysis method, device, and storage medium. Relating to the field of software testing technology, the method includes: extracting features from the business attribute data of the software to be tested to obtain structured knowledge elements; constructing a first database based on these structured knowledge elements; parsing the development code logic of the software to be tested to obtain the dependencies between code entities; constructing a second database based on these dependencies; searching the first and second databases respectively based on the requirements document of the software to be tested to obtain search results; and determining the test priority and test strategy for each functional point in the requirements document based on the search results. This application can improve the comprehensiveness and standardization of test requirements analysis, thereby improving the quality of software testing.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a test requirements analysis method, device and storage medium. Background Technology

[0002] With the rapid development of computer software technology, the iteration speed of various application software, embedded software and business systems continues to accelerate, software functions are becoming increasingly complex and business interaction scenarios are constantly increasing, which puts forward higher requirements for the comprehensiveness, efficiency and accuracy of software testing.

[0003] Currently, common software testing methods involve testers independently interpreting and analyzing software test requirements, then relying on their existing knowledge of similar functional modules and industry experience to manually deduce the actual business scenarios of the software's operation. Finally, they subjectively select the functionalities to be tested based on their personal expertise and project experience, and formulate corresponding test implementation strategies and plans. However, this test requirements analysis method, which relies on the individual abilities and experience of testers, is greatly influenced by human factors, lacks unified standards and constraints, and is prone to omissions in test paths and incomplete test scope. This results in insufficient software test coverage, making it difficult to comprehensively identify software defects, and ultimately making it difficult to guarantee both test quality and test standardization.

[0004] Therefore, how to improve the comprehensiveness and standardization of test requirements analysis in order to improve the quality of software testing is an urgent problem to be solved. Summary of the Invention

[0005] The main purpose of this application is to provide a test requirements analysis method, device and storage medium, which aims to improve the comprehensiveness and standardization of test requirements analysis, so as to improve the quality of software testing.

[0006] To achieve the above objectives, this application provides a test requirements analysis method, which includes: Feature extraction is performed on the business attribute data of the software to be tested to obtain structured knowledge elements, and a first database is constructed based on the structured knowledge elements; The development code logic of the software under test is parsed to obtain the dependency relationships between code entities, and a second database is constructed based on the dependency relationships; Based on the requirements document of the software to be tested, the first database and the second database are searched respectively to obtain the search results; Based on the search results, determine the test priority and test strategy for each functional point in the requirements document.

[0007] In one embodiment, the business attribute data includes business process diagrams, system logic diagrams, business checklists, and historical defect databases. The step of extracting features from the business attribute data of the software to be tested to obtain structured knowledge elements includes: Feature extraction is performed on the business process diagram and the system logic diagram to obtain business rules, normal processes, abnormal processes, and key decision points; Feature extraction is performed on the business checklist to obtain boundary scenarios, error-prone scenarios, and related scenarios; Feature extraction is performed on the historical defect database to obtain defect types, root causes, repair solutions, and lessons learned.

[0008] In one embodiment, the step of retrieving the first database and the second database based on the requirements document of the software under test to obtain the retrieval results includes: Based on the requirements document of the software to be tested, a list of function points is determined, and the first database is searched based on the list of function points to obtain a first search result; Based on the requirements document of the software to be tested, the code modification points associated with the requirements are identified, and the second database is searched based on the code modification points to obtain the second search results; The first search result and the second search result are used as the search results.

[0009] In one embodiment, the first database includes a keyword database and a vector database, and the step of constructing the first database based on the structured knowledge elements includes: A keyword database is constructed based on the aforementioned structured knowledge elements; The structured knowledge elements are vectorized to obtain knowledge vectors, and a vector database is constructed based on the knowledge vectors.

[0010] In one embodiment, the step of retrieving the first database based on the function point list to obtain the first search result includes: For each function in the function point list, construct a search statement based on the function point; Based on the search query, the keyword database and the vector database are searched respectively to obtain keyword results and vector results; The keyword results and the vector results are weighted to obtain the first search result, which includes the affected business process segments, checklist entries and historical defect records.

[0011] In one embodiment, the dependency relationship includes a structured call chain and a database table, and the step of retrieving the second database based on the code modification point to obtain a second retrieval result includes: For each function point in the function point list, determine the target code modification point associated with the function point in the code modification points; Based on the target code modification points, the second database is searched to obtain a second search result, wherein the second search result includes the affected interface call chain and database table association relationship.

[0012] In one embodiment, the step of determining the test priority and test strategy for each functional point in the requirements document based on the search results includes: For each functional point in the requirements document, the impact of business logic is determined based on the first search result of the functional point, and the impact of interface change and database change is determined based on the second search result of the functional point. The priority score of the functional point is obtained by weighted summing of the impact of the business logic, the impact of the interface change, and the impact of the database change; The test priority of each function point is determined according to its priority score. Based on the first search result and the second search result, a test strategy is determined for each of the functional points, wherein the test strategy includes test points, test scenarios, checklist recommended scenarios, and defect recommended scenarios.

[0013] In one embodiment, the method further includes: Based on the test priority and the test strategy, the software to be tested is tested to obtain test results; Based on the test results, the business process diagram is revised in reverse to obtain the revised business process diagram. After the revised business process diagram is verified, the first database is updated based on the revised business process diagram.

[0014] Furthermore, to achieve the above objectives, this application also provides a test requirements analysis apparatus, the test requirements analysis apparatus comprising: The first construction module is used to extract features from the business attribute data of the software to be tested, obtain structured knowledge elements, and construct a first database based on the structured knowledge elements. The second construction module is used to perform syntax parsing on the development code logic of the software to be tested, obtain the dependency relationships between code entities, and construct a second database based on the dependency relationships; The retrieval module is used to search the first database and the second database respectively based on the requirements document of the software to be tested, and obtain the retrieval results; The determination module is used to determine the test priority and test strategy for each functional point in the requirements document based on the search results.

[0015] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the test requirements analysis method as described above.

[0016] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a program implementing the test requirements analysis method is stored, and the program implementing the test requirements analysis method is executed by a processor to implement the steps of the test requirements analysis method as described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the test requirements analysis method described above.

[0018] This application provides a test requirements analysis method. First, the application extracts features from the business attribute data of the software to be tested to obtain structured knowledge elements, and constructs a first database based on these structured knowledge elements. Simultaneously, the application performs syntax parsing on the development code logic of the software to be tested to obtain the dependency relationships between code entities, and constructs a second database based on these dependency relationships. Then, the application searches the first and second databases respectively based on the requirements document of the software to be tested to obtain search results. Finally, the application determines the test priority and test strategy for each functional point in the requirements document based on the search results.

[0019] In summary, this application first extracts features from the business attribute data of the software under test and constructs a first database, transforming raw business knowledge into structured knowledge elements that can be automatically processed by the system, avoiding scenario omissions caused by fragmented information when manually interpreting requirements. Second, it performs syntax parsing on the development code logic and constructs a second database, extracting dependencies between code entities, enabling automatic tracking of technical impacts at the code level, thus compensating for the inability of manual analysis to comprehensively assess the scope of code changes. Based on this, a joint search is performed on the two databases using the requirements document, simultaneously locating the scope of impact from both business knowledge and code dependency dimensions, ensuring that each functional point obtains corresponding business attribute information and code-related information. Finally, the test priority and test strategy for each functional point are automatically determined based on the search results, achieving standardization and automation of test decision-making. Therefore, this application transforms test requirement analysis from subjective judgment relying on personal experience into a systematic process supported by structured data, guided by bidirectional retrieval, and with automated decision output, overcoming the shortcomings of traditional requirement test analysis methods such as missing test paths and incomplete test scope, improving the comprehensiveness, standardization, and automation level of test analysis, and ultimately ensuring the quality and efficiency of software testing. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating the first embodiment of the test requirements analysis method of this application; Figure 2 This is a schematic diagram of the database construction process involved in one embodiment of the test requirements analysis method of this application; Figure 3 This is a schematic diagram of the first retrieval process involved in an embodiment of the test requirements analysis method of this application; Figure 4 This is a schematic diagram of the second retrieval process involved in an embodiment of the test requirements analysis method of this application; Figure 5 This is a schematic diagram of the module structure of the test requirements analysis device in this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the test requirements analysis method in this application embodiment.

[0023] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0024] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] Currently, common software testing methods involve testers independently interpreting and analyzing software test requirements, then relying on their existing knowledge of similar functional modules and industry experience to manually deduce the actual business scenarios of the software's operation. Finally, they subjectively select the functionalities to be tested based on their personal expertise and project experience, and formulate corresponding test implementation strategies and plans. However, this test requirements analysis method, which relies on the individual abilities and experience of testers, is greatly influenced by human factors, lacks unified standards and constraints, and is prone to omissions in test paths and incomplete test scope. This results in insufficient software test coverage, making it difficult to comprehensively identify software defects, and ultimately making it difficult to guarantee both test quality and test standardization.

[0027] Therefore, how to achieve comprehensiveness and standardization in test requirements analysis in order to improve the quality of software testing is an urgent problem to be solved.

[0028] The main solution of this application is as follows: Features are extracted from the business attribute data of the software under test to obtain structured knowledge elements; a first database is constructed based on these structured knowledge elements; the development code logic of the software under test is parsed to obtain the dependencies between code entities; a second database is constructed based on these dependencies; the requirements document of the software under test is used to search the first and second databases respectively to obtain search results; and the test priority and test strategy for each functional point in the requirements document are determined based on the search results.

[0029] This application first extracts features from the business attribute data of the software under test and constructs a first database, transforming raw business knowledge into structured knowledge elements that can be automatically processed by the system, avoiding scenario omissions caused by fragmented information when manually interpreting requirements. Second, it performs syntax parsing on the development code logic and constructs a second database, extracting dependencies between code entities, enabling automatic tracking of technical impacts at the code level, thus compensating for the inability of manual analysis to comprehensively assess the scope of code changes. Based on this, it performs a joint search of the two databases using the requirements document, simultaneously locating the scope of impact from both business knowledge and code dependency dimensions, ensuring that each functional point obtains corresponding business attribute information and code-related information. Finally, it automatically determines the testing priority and testing strategy for each functional point based on the search results, achieving standardization and automation of testing decisions. Therefore, this application, through the above steps, transforms test requirements analysis from subjective judgment relying on personal experience into a systematic process supported by structured data, guided by bidirectional retrieval, and with automated decision output. It overcomes the shortcomings of traditional requirements test analysis methods, such as missing test paths and incomplete test scope, improving the comprehensiveness, standardization, and automation level of test analysis, ultimately ensuring the quality and efficiency of software testing.

[0030] It should be noted that the execution subject of the method in the various embodiments of the test requirements analysis method of this application can be a test requirements analysis system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of realizing the above functions, etc. This embodiment does not specifically limit it in this way. The following uses the test requirements analysis system as the execution subject as an example to describe this embodiment and the following embodiments.

[0031] Based on this, this application proposes a test requirements analysis method according to the first embodiment, please refer to... Figure 1 The test requirements analysis method includes steps S10 to S40: Step S10: Extract features from the business attribute data of the software to be tested to obtain structured knowledge elements, and construct a first database based on the structured knowledge elements.

[0032] It should be noted that the software currently undergoing functional testing is referred to as the software under test. Business attribute data refers to relevant information describing the business-level characteristics of the software under test, such as business process descriptions (also known as business process diagrams), system logic descriptions (also known as system logic diagrams), business checklists, historical defect databases, and other unstructured or semi-structured business knowledge materials. Feature extraction refers to using data processing techniques (including but not limited to natural language processing, machine learning models, etc.) to identify and extract representative, computer-understandable, and searchable key information from the aforementioned business attribute data. Structured knowledge elements refer to knowledge units with a unified format, indexable, and searchable after extraction, such as business rules, process nodes, decision conditions, scenario boundaries, defect patterns, etc.

[0033] First, various business attribute data accumulated during the research and development or testing of the software to be tested are acquired. These data are diverse in their original form, inconsistent in format, and uneven in information density. In order for the computer system to automatically use this knowledge to assist in the analysis of test requirements, they need to be standardized. Specifically, through feature extraction technology, core structured knowledge elements are extracted from the original business attribute data, redundancy and noise are eliminated, and knowledge units with unified representation are formed. Subsequently, these structured knowledge elements are stored in a preset database (hereinafter referred to as the first database for distinction) according to a preset data model, thereby constructing a business knowledge base that can be efficiently accessed by subsequent retrieval steps.

[0034] In one feasible implementation, business attribute data includes business process diagrams, system logic diagrams, business checklists, and a historical defect database. During feature extraction, different extraction strategies can be adopted for different types of business attribute data: for flowcharts and logic diagrams, extract business rules, normal process branches, abnormal process branches, and key decision points; for business checklists, extract boundary scenarios, error-prone scenarios, and related scenarios; for the historical defect database, extract defect types, root causes, remediation solutions, and lessons learned. All of the extracted content is treated as structured knowledge elements. When constructing the first database, these structured knowledge elements can be organized and stored according to categories and relationships, and indexes can be created to support keyword and semantic retrieval.

[0035] In another feasible implementation, the first database can be further divided into a keyword database and a vector database: the keyword database is used for exact matching retrieval, and the vector database is used for semantic similarity retrieval. The combination of the two can improve the comprehensiveness and accuracy of the retrieval.

[0036] Step S20: Perform syntax parsing on the development code logic of the software to be tested to obtain the dependency relationships between code entities, and construct a second database based on the dependency relationships.

[0037] It's important to clarify that developing code logic refers to the source code of the software under test and its program structure and execution logic, which can be understood as code engineering. Syntax parsing refers to lexical, syntactic, and semantic analysis of the code, typically using techniques such as Abstract Syntax Trees (ASTs) to convert the code text into a structured representation for programmable analysis. Code entities refer to the basic building blocks of code, such as functions, methods, classes, modules, interfaces, and database access objects. Dependencies refer to the coupling relationships between code entities, such as calls, references, inheritance, and associations; for example, one method calls another method, or a database table is accessed by multiple modules.

[0038] The process involves acquiring all or relevant parts of the development code logic of the software under test; using syntax parsing technology, transforming the source code into an abstract syntax tree or other intermediate representation, identifying various code entities and their call relationships, data access relationships, etc.; then, using these code entities as nodes and their dependencies as edges, constructing a code-level relationship graph; finally, storing this relationship graph in a preset graph database (hereinafter referred to as the second database for distinction), enabling rapid subsequent querying of the scope of upstream and downstream code entities affected by a code modification, thereby providing technical support for test impact analysis. In this embodiment, the specific type of the graph database is not limited; in this embodiment, the second database can be a Neo4j graph database.

[0039] In one feasible implementation, the code project of the software to be tested is parsed using an abstract syntax tree. All source code files are traversed to extract interface definitions and their call chains (i.e., the sequence of downstream interfaces called level by level starting from the entry interface). Simultaneously, the database tables involved in the Data Access Object (DAO) and their relationships (e.g., foreign key joins, union queries, etc.) are extracted. These extraction results are stored as dependencies between code entities in a Neo4j graph database, forming a second database.

[0040] In another feasible implementation, the code change history can be further analyzed to identify frequently changed code modules and their dependency strength. This dynamic information can then be incorporated into the second database to enhance the accuracy of change impact analysis. Once the second database is built, it can support rapid retrieval based on code entity identifiers (such as class names and method names) or code modification points, returning a list of other entities affected by that entity and the impact path.

[0041] Step S30: Based on the requirements document of the software to be tested, search the first database and the second database respectively to obtain the search results.

[0042] It should be noted that the requirements document refers to the product requirements specification describing the changes or new features added to the software under test, and it is usually in the form of natural language text. Retrieval refers to searching for relevant or affected knowledge units and code entities in the first and second databases based on the key information in the requirements document. The retrieval results include business knowledge fragments related to the requirements (such as business processes, check items, and defect examples) obtained from the first database, and code entity dependency information related to the requirements (such as affected interfaces, modules, and database tables) obtained from the second database.

[0043] First, obtain the requirements document for the software to be tested. To utilize information from both the first and second databases to aid test analysis, queries should be initiated on both databases based on the content of the requirements document. For the first database, the search aims to identify structured knowledge elements related to the business functions described in the requirements, such as process rules for similar business scenarios, historical checklists, and past defect records. For the second database, the search aims to identify the code entities involved in or potentially affected by the requirements and their dependencies. For example, if a functional module is mentioned in the requirements, the corresponding code entry point and upstream / downstream call chain can be queried. The searches on both databases can be performed in parallel or sequentially, ultimately yielding a comprehensive search result integrating business and code dimensions, providing input for subsequent decision-making.

[0044] Step S40: Determine the test priority and test strategy for each functional point in the requirements document based on the search results.

[0045] It should be noted that a functional point refers to a single business function or user scenario identified from the requirements document that can be tested independently. Test priority refers to the order or importance of testing each functional point given limited testing resources. Test strategy refers to the test plan developed for each functional point or the overall testing task, including but not limited to the test points to be covered, test scenarios, recommended checklists, and defect types requiring special attention.

[0046] Based on the search results, a priority score is calculated for each functional point, with higher scores indicating that the functional points need to be tested first. Then, based on the priority scores of each functional point, and combined with the specific business knowledge and code dependency information in the search results, a test strategy is generated for each functional point or the whole system.

[0047] Therefore, this application first extracts features from the business attribute data of the software to be tested and constructs a first database, transforming raw business knowledge into structured knowledge elements that can be automatically processed by the system, avoiding scenario omissions caused by fragmented information when manually understanding requirements. Secondly, it performs syntax parsing on the development code logic and constructs a second database, extracting dependencies between code entities, enabling automatic tracking of technical impacts at the code level, thus compensating for the inability of manual analysis to comprehensively assess the scope of code changes. Based on this, it performs a joint search of the two databases based on the requirements document, simultaneously locating the scope of impact from both the business knowledge and code dependency dimensions, ensuring that each functional point obtains corresponding business attribute information and code-related information. Finally, it automatically determines the testing priority and testing strategy for each functional point based on the search results, achieving standardization and automation of testing decisions. Thus, this application transforms test requirements analysis from subjective judgment relying on personal experience into a systematic process supported by structured data, guided by bidirectional retrieval, and with automated decision output, overcoming the shortcomings of traditional requirements test analysis methods such as missing test paths and incomplete test scope, improving the comprehensiveness, standardization, and automation level of test analysis, and ultimately ensuring the quality and efficiency of software testing.

[0048] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, the business attribute data includes a business process diagram, a system logic diagram, a business checklist, and a historical defect database. Step S10 may include: Step S101: Extract features from the business process diagram and the system logic diagram to obtain business rules, normal processes, abnormal processes, and key decision points; Step S102: Extract features from the business checklist to obtain boundary scenarios, error-prone scenarios, and related scenarios; Step S103: Extract features from the historical defect database to obtain defect types, root causes, repair solutions, and lessons learned.

[0049] It's important to note that a business process diagram is a graphical or structured representation of a business operation process, typically including elements such as the sequence of activities, branches, and decision nodes. A system logic diagram, on the other hand, is a logical model describing the interaction relationships between system modules, data flow, or state transitions. A business checklist is a pre-listed list of test items or quality assurance points that need to be verified. A historical defect database is a database that records software defects and related information discovered in past testing or production environments. Business rules refer to the logical constraints or judgment conditions that must be followed in a business process; a normal process refers to the path when the business executes smoothly as expected; an abnormal process refers to the path when the business executes under error or boundary conditions; a critical decision point refers to a node in the process where different branches need to be selected based on conditions. Boundary scenarios refer to test situations where the input or state is at a critical value; error-prone scenarios refer to complex situations that are easily overlooked by testers or have historically been prone to errors; related scenarios refer to other business scenarios that interact with, depend on, or have similar logic to the current functional point. Defect type refers to the classification of the essential nature of a defect (such as logical errors, performance problems, security vulnerabilities, etc.); defect root cause refers to the fundamental reason that causes the defect to occur (such as algorithm design errors, missing boundary judgments, etc.); remediation plan refers to the code or configuration changes implemented to resolve the defect; reference value refers to the generalizable testing experience or preventive measures summarized from the defect.

[0050] In this embodiment, to extract structured knowledge elements directly usable for subsequent retrieval and decision-making from diverse business attribute data, targeted feature extraction strategies are required for different types of business attribute data. Specifically, for chart-based data describing processes and logic (business process diagrams, system logic diagrams), the focus is on extracting the dynamic behavioral features contained within, including constraints of business rules, normal and abnormal execution paths, and key branch points in the process. These elements reflect the operational trajectory of the business under different conditions. For checklists in itemized form, the focus is on the test coverage points, extracting error-prone boundary situations, complex scenarios easily overlooked in historical experience, and related scenarios that interact with other functions. For defect databases recording a large number of historical defects, the ontological characteristics and problem-solving experience of defects are summarized, including the defect type, root cause, specific repair methods, and the warning significance of the defect for other similar functions. Through the above differentiated extraction, the original business attribute data is transformed into structured knowledge elements with unified representation, providing standardized input for the subsequent construction of the first database.

[0051] In this embodiment, the first database includes a keyword database and a vector database, and step S10 may further include: Step S104: Construct a keyword database based on the structured knowledge elements; Step S105: The structured knowledge elements are vectorized to obtain knowledge vectors, and a vector database is constructed based on the knowledge vectors.

[0052] It's important to clarify that a keyword database refers to a retrieval engine centered around keywords (or inverted indexes). It segments and indexes text fields within structured knowledge elements, supporting retrieval methods based on precise string matching or keyword matching. A vector database, on the other hand, is a retrieval engine based on vector embedding. It converts unstructured or semi-structured knowledge elements into numerical vectors in a high-dimensional space, enabling approximate nearest neighbor retrieval based on semantic similarity. Vectorization refers to the process of mapping textual knowledge elements into fixed-length numerical vectors using pre-trained or fine-tuned semantic models (such as language models or text embedding models). The knowledge vector is the output of vectorization, representing the coordinate position of the original knowledge element in the semantic space.

[0053] First, based on the existing structured knowledge elements, a keyword database is constructed. This database performs word segmentation, removes stop words, and builds an inverted index on the text content of all knowledge elements. This allows users to quickly locate knowledge element entries containing specific keywords or phrases. The advantage of the keyword database lies in its precise and controllable search results, making it particularly suitable for finding known terms or identifiers.

[0054] Secondly, the same batch of structured knowledge elements are vectorized, transforming each knowledge element into a high-dimensional semantic vector. A vector database is then constructed based on these vectors. The vector database supports using vectors as query conditions, calculating the cosine or Euclidean distance between the query vector and vectors in the database to return the most semantically similar knowledge elements. The advantage of the vector database lies in its ability to understand synonyms, implicit semantics in context, and fuzzy expressions, compensating for the limitations of keyword retrieval in semantic generalization. By simultaneously constructing a keyword database and a vector database, the first database possesses two complementary retrieval capabilities, providing a flexible and comprehensive query interface for subsequent retrieval steps.

[0055] Thus, this embodiment of the application specifically constructs the first database as a keyword database and a vector database, and establishes keyword indexes based on structured knowledge elements and vector indexes through vectorization processing, respectively, enabling subsequent requirement retrieval to possess both precise matching and semantic understanding capabilities. The keyword database supports rapid and accurate location of known terms and identifiers, ensuring the certainty of search results; the vector database can understand synonyms, contextual implicit semantics, and fuzzy expressions, compensating for the shortcomings of keyword retrieval in semantic generalization. The two retrieval methods complement each other, jointly improving the recall and accuracy of matching requirement functional points with business knowledge, and providing more complete and relevant business knowledge input for subsequent test priority evaluation and test strategy generation.

[0056] In this embodiment, step S20 may include: Step S201: Perform syntax parsing on the development code logic of the software to be tested to obtain the interface call chain and database table, use the interface call chain and the database table as the dependency relationship between code entities, and construct a second database based on the dependency relationship.

[0057] It's important to note that an interface call chain refers to the sequence of paths formed by tracing the downstream interfaces called from one interface (such as an API, function, or method), reflecting the dynamic call relationships between modules. A database table refers to the logical structure for storing data in relational or non-relational databases, including table names, field definitions, primary and foreign key constraints, etc. In code logic, database tables are typically referenced or manipulated by code entities through data access layers (such as DAO or ORM). Interface call chains and database tables together constitute the dependencies between code entities: the former reflects behavioral call coupling, while the latter reflects data storage and access coupling.

[0058] In this embodiment, to construct a second database that reflects the technical impact at the code level, a deep syntactic analysis of the development code logic of the software under test is required. Through analysis, two core types of technical dependency information are identified from the source code: one is the call chain between interfaces, i.e., which interfaces call which other interfaces, and the order and hierarchy of these calls; the other is the association between code entities and database tables, i.e., which code modules (e.g., data access functions, entity classes) operate on which database tables, and the relationships between tables (e.g., foreign key dependencies, join queries). Extracting and recording these two types of information as dependencies between code entities comprehensively depicts the call path and data flow path during software runtime. Subsequently, a second database is constructed based on these dependencies, enabling rapid querying of affected upstream and downstream interfaces and associated database tables based on code modification points, thereby achieving automated analysis of the scope of impact of code changes.

[0059] For example, such as Figure 2 The diagram illustrates the database construction process. First, various business attribute data of the software under test are acquired, including: business process diagrams and system logic diagrams described in Mermaid or JSON format, business checklists, and a historical defect database. Additionally, the development code project (i.e., the development code logic) of the software under test is acquired. Then, through AI reading comprehension (i.e., feature extraction using a large model), the above business attribute data is structured: business rules, normal and abnormal processes, and key decision points are extracted from the business process diagrams and system logic diagrams; boundary scenarios, related scenarios, and error-prone scenarios are extracted from the business checklists; and defect types, repair solutions, and lessons learned are extracted from the historical defect database. These extraction results collectively constitute structured knowledge elements. Simultaneously, AST syntax parsing is performed on the development code logic to extract interface call chains and database tables. Subsequently, a first database is constructed based on the structured knowledge elements: on the one hand, the structured knowledge elements are stored in a search engine (e.g., Elasticsearch, corresponding to a keyword database); on the other hand, they are vectorized and stored in a vector database. The interface call chains and database tables are used to construct a second database, specifically a Neo4j graph database.

[0060] Thus, this embodiment of the application achieves dual automation of business knowledge extraction and code technology tracing by extracting information from business process diagrams, checklists, and historical defect databases into structured knowledge elements, and simultaneously performing syntax parsing on the development code logic to obtain interface call chains and database tables as dependencies. Specifically, the structured processing at the business level avoids scenario omissions and experience gaps during manual deduction, while the dependency parsing at the code level compensates for the difficulty of manually assessing the impact of interface changes and databases. The synergy of these two approaches ensures that test requirements analysis possesses both the completeness of business coverage and the accuracy of technical impact, effectively improving the comprehensiveness and reliability of test analysis.

[0061] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the first and second embodiments described above can be referred to the above description and will not be repeated hereafter. Based on this, step S30 may include: Step S301: Determine a list of function points based on the requirements document of the software to be tested, and search the first database based on the list of function points to obtain a first search result.

[0062] It should be noted that the feature point list is a collection of individual business functions or user scenarios identified from the requirements document that can be tested independently, such as user login, data export, and permission configuration. The first search result refers to the business knowledge fragments related to the feature point list obtained from the first database, which may include descriptions of affected business processes, checklist items, and historical defect records.

[0063] First, the requirements document is parsed to extract a list of functional points. This parsing process typically utilizes large modeling or natural language processing techniques to break down the natural language descriptions in the requirements document into structured functional point items. After obtaining the functional point list, corresponding search queries are generated for each functional point or the entire list. Then, these queries are used as input to initiate a search in a first database, yielding the first search results.

[0064] In this embodiment, step S301 may include: Step S3011: For each function point in the function point list, construct a search statement based on the function point; Step S3012: Based on the search statement, search the keyword database and the vector database respectively to obtain keyword results and vector results; Step S3013: The keyword results and the vector results are weighted to obtain the first search result, wherein the first search result includes the affected business process segments, checklist entries and historical defect records.

[0065] It should be noted that the search query is a string or vector expression generated based on the name, description, or related attributes of a function point to query the database. Keyword results refer to relevant business knowledge entries retrieved from the keyword database through keyword matching; vector results refer to relevant business knowledge entries retrieved from the vector database through semantic similarity calculation. Weighted processing combines the two types of search results according to a certain weighting coefficient or fusion algorithm to integrate the advantages of both. The first search result is the final set of business knowledge retrieval obtained after weighted processing, specifically including affected business process segments, checklist entries, and historical defect records.

[0066] In this embodiment, to comprehensively and accurately acquire business knowledge related to each functional point from the first database, the system adopts a dual-path retrieval and fusion strategy. First, for each functional point in the functional point list, the system generates one or more retrieval queries (i.e., retrieval statements) based on the text description of that functional point. Then, these retrieval statements are used to search the two sub-databases in the first database: the keyword database is precisely matched using BM25 (keyword matching scoring algorithm) to obtain keyword results; the vector database is semantically similar to obtain vector results. It is understood that keyword retrieval ensures that known terms and identifiers are accurately matched, while vector retrieval discovers knowledge items that are semantically similar to the functional point but use different terminology; the two complement each other. Finally, the keyword results and vector results are merged according to a preset weight or fusion algorithm, and the most relevant items are selected as the first retrieval result for that functional point. This first retrieval result includes business process fragments related to the functional point (reflecting the business execution path), checklist items (reflecting the test points that need to be verified), and historical defect records (reflecting similar problems that have occurred in the past), providing a data foundation for subsequent evaluation of the impact on business logic. The fusion algorithm used for weighted calculation can be the RRF (Reciprocal Rank Fusion) algorithm.

[0067] For example, such as Figure 3The diagram illustrates the first retrieval process. After inputting the requirements document, the system first uses a large model for AI extraction and standardization to obtain a list of functional points. For each functional point, a retrieval query is generated, and vector retrieval and BM25 keyword retrieval are performed on the business knowledge base (i.e., the first database). The two retrieval results are then weighted and fused using the RRF (Reverse Ranking Fusion) algorithm, outputting the affected business process diagram, recommended functional checklists (i.e., checklist items), and recommended typical functional defects (i.e., historical defect records). Finally, AI analysis and summarization are used to form a business-dimensional analysis result. It should be understood that the first retrieval result not only outputs the affected business process diagram but also simultaneously outputs business process segments directly related to the current retrieval query.

[0068] Step S302: Based on the requirements document of the software to be tested, determine the code modification points associated with the requirements, and search the second database based on the code modification points to obtain the second search results.

[0069] It's important to note that the code modification points associated with a requirement refer to the code entities (such as files, classes, methods, functions, etc.) involved in the code change records corresponding to the current requirement document. Code modification points typically originate from commit records in version control systems (such as Git), and these records are associated with specific requirements through requirement IDs, branch names, or commit comments. The second search result refers to code dependency information associated with the code modification points, retrieved from a second database. Specifically, this may include affected interface call chains and database table relationships, as well as affected functional modules or regression test scopes.

[0070] First, retrieve the code commit records associated with the current requirements document. These commit records are typically linked to the requirements through association mechanisms in the development process (such as attaching a requirement ID with the commit). Then, analyze the commit records using a large model or code analysis tools to identify specific code changes, such as which files, functions, or classes were modified, added, deleted, or updated. Next, use these code changes as search criteria to query a second database and obtain the second set of search results.

[0071] Understandably, the second database stores the dependencies between code entities (such as API call chains and database table relationships). Graph queries can identify upstream and downstream code entities affected by these modifications. For example, if a low-level utility function is modified, all upper-level interfaces that call that function can be retrieved; if a data access object is modified, other tables with foreign key relationships to that database table and the code modules that operate on those tables can be retrieved. Finally, these affected technical modules and dependency paths are aggregated to form the second search results.

[0072] In this embodiment, the dependency relationship includes a structure call chain and a database table. Step S302 may include: Step S3021: For each function point in the function point list, determine the target code modification point associated with the function point in the code modification points; Step S3022: Based on the target code modification point, the second database is searched to obtain a second search result, wherein the second search result includes the affected interface call chain and database table association relationship.

[0073] It should be noted that the modification points selected from all code modification points that have a mapping relationship with the currently processed functional point are called target code modification points. The affected interface call chain refers to the sequence of upstream and downstream called interfaces obtained through dependency queries based on the code entities involved in the target code modification point. The affected database table relationships refer to the connection relationships (such as foreign key constraints and join dependencies) between data tables associated with the target code modification point, as well as the operation relationships between these tables by the code entities.

[0074] In this embodiment, to obtain technical impact information related to each functional point at the code level, the system first needs to map code modification points to functional points, identifying the target code modification point corresponding to each functional point. This is because a requirements document may contain multiple functional points, and the modified code entities in the code commit record may serve some of these functional points. Only by establishing the correspondence between functional points and code modification points can the impact of interface changes and database changes be independently evaluated for each functional point.

[0075] Specifically, for each feature in the feature list, the system analyzes all code modification points and, based on preset association rules (such as feature identifiers in code commit comments, semantic similarity between code entity names and feature name names, and reverse call chain tracing), filters out target code modification points directly related to that feature. Then, starting from these target code modification points, a second database is queried, and graph traversal is used to obtain the interface call chains and database table relationships affected by these modification points. For example, if the target code modification point is a data access method, the search results may include the sequence of business interfaces calling that method (upstream impact), and the relationships between the data table operated by that method and other tables (data impact). The final second search results provide a quantitative basis from a technical perspective for subsequent evaluation of the impact of interface changes and database changes on each feature.

[0076] Step S303: Use the first search result and the second search result as the search result.

[0077] The search results refer to the information obtained from searching the first and second databases separately, combined or merged, and used as input for subsequent steps (determining test priorities and test strategies). The first search result focuses on business-level knowledge, such as affected business processes, checklists, and historical defects; the second search result focuses on technical-level information, such as affected API call chains, database table relationships, and functional modules. Together, they constitute a complete view of the impact of requirements from both business and technical perspectives.

[0078] For example, such as Figure 4 The diagram shows the second retrieval process. Based on the code submission records associated with the requirements, code modification points are obtained through large-scale model analysis. Using the code modification points as query conditions, a relationship retrieval is performed on the code knowledge base (i.e., the second database). By querying the interface call chain and database table relationships between code entities, the affected code functional modules and their scope of impact are determined, and regression test recommendations are then output.

[0079] Thus, this application embodiment not only ensures the comprehensiveness and accuracy of business knowledge matching through dual-modal retrieval and weighted fusion, but also accurately locks the scope of technical impact through the association mapping between functional points and code modification points and graph database relationship retrieval. This enables test requirement analysis to simultaneously obtain complete business scenario coverage and accurate technical change tracking, effectively improving the recall and relevance of search results, and laying a solid data foundation for the subsequent multi-dimensional impact assessment of each functional point.

[0080] In this embodiment, step S40 may include: Step S401: For each functional point in the requirements document, determine the business logic impact based on the first search result of the functional point, and determine the interface change impact and database change impact based on the second search result of the functional point. Step S402: The impact of the business logic, the impact of the interface change, and the impact of the database change are weighted and summed to obtain the priority score of the function point; Step S403: Determine the test priority of each function point according to its priority score.

[0081] It should be noted that the business logic impact refers to the assessment of the importance, complexity, or risk level of a specific function at the business level, based on business process fragments, checklist items, and historical defect records in the first search result. The interface change impact refers to the assessment of the scope or coupling strength of code interface changes to the modules involved in the function, based on interface call chain information in the second search result. The database change impact refers to the assessment of the impact of changes to the data table structure or operations on the function, based on database table relationships in the second search result. Weighted summation involves linearly combining the above three impacts according to preset weighting coefficients to obtain a comprehensive numerical value. The priority score is the numerical value obtained after weighted summation, used to quantify the degree to which each function should be tested first.

[0082] For each feature in the requirements document, the impact is calculated from both business and technical dimensions. First, based on the first search result (including related business processes, checklists, and historical defects), the business logic impact is determined. For example, the more complex the process, the more checklists, and the more severe the historical defects, the higher the business logic impact. Second, based on the second search result (including the corresponding API call chain and database table relationships), the API change impact and database change impact are determined. For example, the longer the call chain and the more APIs affected, the higher the API change impact; the more complex the table relationships or the greater the table structure changes, the higher the database change impact. After obtaining these three impact values, the system performs a weighted sum according to preset weights (e.g., business logic impact weight 0.4, API change impact weight 0.3, database change impact weight 0.3) to calculate the priority score for each feature. Finally, all feature values ​​are sorted from highest to lowest priority score; a higher score indicates a higher testing priority and requires priority testing. This process transforms subjective test prioritization into objective quantitative calculation, ensuring the rationality of test resource allocation.

[0083] Step S404: Based on the first search result and the second search result, determine the test strategy for each of the functional points, wherein the test strategy includes test points, test scenarios, checklist recommended scenarios, and defect recommended scenarios.

[0084] It should be noted that a testing strategy refers to a specific testing plan developed for each functional point, comprising at least four components: test points, test scenarios, recommended checklist scenarios, and recommended defect scenarios. Test points are specific check items that need to be verified, extracted from the functional point, such as "displaying a friendly message when the old password is incorrect." Test scenarios refer to the specific environment, operating steps, and data conditions for executing the test, such as "the user's account is locked after three consecutive incorrect password entries." Recommended checklist scenarios are verification points applicable to the current functional point, selected from the business checklist items in the first search results. Recommended defect scenarios are specific scenarios where similar problems have occurred, extracted from historical defect records in the first search results, used to remind testers to pay close attention.

[0085] Based on the first search results (business process fragments, checklist items, and historical defect records) and the second search results (interface call chains and database table relationships), a structured test strategy is automatically generated for each functional point. Test points are primarily derived from the breakdown of the functional point itself and extracted from key decision points and boundary conditions in the business process. Test scenarios are derived from normal / abnormal process paths in the business process, abnormal branches in the interface call chain (such as timeouts and error codes), and boundary conditions in database operations. Checklist recommendation scenarios directly reference checklist items with high matching degrees from the first search results. Defect recommendation scenarios are extracted from historical defect records in the first search results, providing reproducibility scenarios and avoidance suggestions. In this way, test strategies no longer rely on testers' ad-hoc ideas but are automatically recommended by the system based on historical knowledge and code structure, improving both efficiency and coverage.

[0086] In this embodiment, the test requirements analysis method of this application further includes: Step A10: Based on the test priority and the test strategy, test the software to be tested and obtain the test results; Step A20: Based on the test results, reverse-correct the business process diagram to obtain a corrected business process diagram. After the corrected business process diagram passes verification, update the first database based on the corrected business process diagram.

[0087] It should be noted that test results refer to the actual output obtained after executing tests according to the above priorities and strategies, including test pass / fail, discovered defects, and related evidence such as logs and screenshots. Reverse engineering refers to using information reflected in the test results (such as discrepancies between the actual execution path and expectations, or the discovery of new business scenario branches) to improve the original business process diagram. The revised business process diagram refers to the new version after adjustments, additions, or deletions. Validation refers to performing consistency checks or manual / automatic verification on the revised business process diagram to ensure it accurately reflects the actual business logic. Updating the primary database refers to replacing the original version with the validated revised business process diagram or storing it incrementally in the primary database to keep the knowledge base up-to-date.

[0088] In this embodiment, the system first utilizes the previously generated test priorities and test strategies to perform actual testing activities on the software under test. Tests can be executed by an automated testing framework or manually by testers according to the strategy, ultimately summarizing the results. The test results include not only conclusions about whether the functionality is correct, but also deviations in business logic discovered during testing, inconsistencies between expected and actual processes, and newly discovered business scenario branches.

[0089] Based on these test results, the system can reverse-engineer existing business process diagrams to identify any missing, incorrect, or outdated elements, and revise them accordingly. This includes adding missing exception branches, adjusting decision node conditions, and supplementing boundary handling paths. After revision, the revised business process diagram needs to be validated to ensure its correctness and completeness. Validation can be conducted through comparison with actual system behavior, expert review, or regression testing based on historical test data. Once the revised business process diagram passes validation, the system updates it to the primary database. This closed-loop mechanism allows the primary database to continuously evolve as testing practices deepen, improving the timeliness and accuracy of the knowledge base. This, in turn, enables subsequent test requirement analysis to be based on more comprehensive business knowledge, forming a positive cycle.

[0090] This application also provides a test requirements analysis device. Please refer to... Figure 5 The test requirement analysis device includes: The first construction module 10 is used to extract features from the business attribute data of the software to be tested, obtain structured knowledge elements, and construct a first database based on the structured knowledge elements. The second construction module 20 is used to perform syntax parsing on the development code logic of the software to be tested, obtain the dependency relationship between code entities, and construct a second database based on the dependency relationship; The retrieval module 30 is used to retrieve the first database and the second database respectively based on the requirements document of the software to be tested, and obtain the retrieval results; The determination module 40 is used to determine the test priority and test strategy for each functional point in the requirements document based on the search results.

[0091] Optionally, the business attribute data includes business process diagrams, system logic diagrams, business checklists, and historical defect databases, and the first construction module 10 is further used for: Feature extraction is performed on the business process diagram and the system logic diagram to obtain business rules, normal processes, abnormal processes, and key decision points; Feature extraction is performed on the business checklist to obtain boundary scenarios, error-prone scenarios, and related scenarios; Feature extraction is performed on the historical defect database to obtain defect types, root causes, repair solutions, and lessons learned.

[0092] Optionally, the retrieval module 30 is further configured to: Based on the requirements document of the software to be tested, a list of function points is determined, and the first database is searched based on the list of function points to obtain a first search result; Based on the requirements document of the software to be tested, the code modification points associated with the requirements are identified, and the second database is searched based on the code modification points to obtain the second search results; The first search result and the second search result are used as the search results.

[0093] Optionally, the first building module 10 is further configured to: A keyword database is constructed based on the aforementioned structured knowledge elements; The structured knowledge elements are vectorized to obtain knowledge vectors, and a vector database is constructed based on the knowledge vectors.

[0094] Optionally, the retrieval module 30 is further configured to: For each function in the function point list, construct a search statement based on the function point; Based on the search query, the keyword database and the vector database are searched respectively to obtain keyword results and vector results; The keyword results and the vector results are weighted to obtain the first search result, which includes the affected business process segments, checklist entries and historical defect records.

[0095] Optionally, the dependency relationship includes a structured call chain and a database table, and the retrieval module 30 is further used for: For each function point in the function point list, determine the target code modification point associated with the function point in the code modification points; Based on the target code modification points, the second database is searched to obtain a second search result, wherein the second search result includes the affected interface call chain and database table association relationship.

[0096] Optionally, the determining module 40 is further configured to: For each functional point in the requirements document, the impact of business logic is determined based on the first search result of the functional point, and the impact of interface change and database change is determined based on the second search result of the functional point. The priority score of the functional point is obtained by weighted summing of the impact of the business logic, the impact of the interface change, and the impact of the database change; The test priority of each function point is determined according to its priority score. Based on the first search result and the second search result, a test strategy is determined for each of the functional points, wherein the test strategy includes test points, test scenarios, checklist recommended scenarios, and defect recommended scenarios.

[0097] Optionally, the test requirement analysis device further includes a correction module, which is used for: Based on the test priority and the test strategy, the software to be tested is tested to obtain test results; Based on the test results, the business process diagram is revised in reverse to obtain the revised business process diagram. After the revised business process diagram is verified, the first database is updated based on the revised business process diagram.

[0098] The test requirement analysis apparatus provided in this application, employing the test requirement analysis method described in the above embodiments, can solve the technical problem of how to improve the comprehensiveness and standardization of test requirement analysis to enhance the quality of software testing. Compared with the prior art, the beneficial effects of the test requirement analysis apparatus provided in this application are the same as those of the test requirement analysis method provided in the above embodiments, and other technical features in the test requirement analysis apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0099] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the test requirements analysis method in Embodiment 1 above.

[0100] The following is for reference. Figure 6 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0101] like Figure 6 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0102] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0103] The electronic device provided in this application, employing the test requirements analysis method described in the above embodiments, can solve the technical problem of how to improve the comprehensiveness and standardization of test requirements analysis to enhance the quality of software testing. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the test requirements analysis method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0104] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0106] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the test requirements analysis method in the above embodiments.

[0107] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0108] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0109] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by an electronic device, the electronic device performs the following actions: extracts features from the business attribute data of the software under test to obtain structured knowledge elements, and constructs a first database based on the structured knowledge elements; performs syntax parsing on the development code logic of the software under test to obtain the dependencies between code entities, and constructs a second database based on the dependencies; searches the first database and the second database respectively based on the requirements document of the software under test to obtain search results; and determines the test priority and test strategy for each functional point in the requirements document based on the search results.

[0110] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0111] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0112] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0113] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described test requirements analysis method. This medium can solve the technical problem of how to improve the comprehensiveness and standardization of test requirements analysis to enhance the quality of software testing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the test requirements analysis method provided in the above embodiments, and will not be repeated here.

[0114] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the test requirements analysis method described above.

[0115] The computer program product provided in this application can improve the comprehensiveness and standardization of test requirements analysis, thereby improving the quality of software testing. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the test requirements analysis method provided in the above embodiments, and will not be repeated here.

[0116] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A test requirements analysis method, characterized in that, The test requirements analysis method includes: Feature extraction is performed on the business attribute data of the software to be tested to obtain structured knowledge elements, and a first database is constructed based on the structured knowledge elements; The development code logic of the software under test is parsed to obtain the dependency relationships between code entities, and a second database is constructed based on the dependency relationships; Based on the requirements document of the software to be tested, the first database and the second database are searched respectively to obtain the search results; Based on the search results, determine the test priority and test strategy for each functional point in the requirements document.

2. The test requirements analysis method as described in claim 1, characterized in that, The business attribute data includes business process diagrams, system logic diagrams, business checklists, and historical defect databases. The step of extracting features from the business attribute data of the software to be tested to obtain structured knowledge elements includes: Feature extraction is performed on the business process diagram and the system logic diagram to obtain business rules, normal processes, abnormal processes, and key decision points; Feature extraction is performed on the business checklist to obtain boundary scenarios, error-prone scenarios, and related scenarios; Feature extraction is performed on the historical defect database to obtain defect types, root causes, repair solutions, and lessons learned.

3. The test requirements analysis method as described in claim 1, characterized in that, The step of retrieving the first database and the second database based on the requirements document of the software under test to obtain the retrieval results includes: Based on the requirements document of the software to be tested, a list of function points is determined, and the first database is searched based on the list of function points to obtain a first search result; Based on the requirements document of the software to be tested, the code modification points associated with the requirements are identified, and the second database is searched based on the code modification points to obtain the second search results; The first search result and the second search result are used as the search results.

4. The test requirements analysis method as described in claim 3, characterized in that, The first database includes a keyword database and a vector database. The step of constructing the first database based on the structured knowledge elements includes: A keyword database is constructed based on the aforementioned structured knowledge elements; The structured knowledge elements are vectorized to obtain knowledge vectors, and a vector database is constructed based on the knowledge vectors.

5. The test requirements analysis method as described in claim 4, characterized in that, The step of retrieving the first database based on the function point list to obtain the first search result includes: For each function in the function point list, construct a search statement based on the function point; Based on the search query, the keyword database and the vector database are searched respectively to obtain keyword results and vector results; The keyword results and the vector results are weighted to obtain the first search result, which includes the affected business process segments, checklist entries and historical defect records.

6. The test requirements analysis method as described in claim 3, characterized in that, The dependency relationship includes a structure call chain and a database table. The step of retrieving the second database based on the code modification point to obtain the second retrieval result includes: For each function point in the function point list, determine the target code modification point associated with the function point in the code modification points; Based on the target code modification points, the second database is searched to obtain a second search result, wherein the second search result includes the affected interface call chain and database table association relationship.

7. The test requirements analysis method as described in claim 3, characterized in that, The steps for determining the test priority and test strategy for each functional point in the requirements document based on the search results include: For each functional point in the requirements document, the impact of business logic is determined based on the first search result of the functional point, and the impact of interface change and database change is determined based on the second search result of the functional point. The priority score of the functional point is obtained by weighted summing of the impact of the business logic, the impact of the interface change, and the impact of the database change; The test priority of each function point is determined according to its priority score. Based on the first search result and the second search result, a test strategy is determined for each of the functional points, wherein the test strategy includes test points, test scenarios, checklist recommended scenarios, and defect recommended scenarios.

8. The test requirements analysis method as described in any one of claims 2 to 7, characterized in that, The method further includes: Based on the test priority and the test strategy, the software to be tested is tested to obtain test results; Based on the test results, the business process diagram is revised in reverse to obtain the revised business process diagram. After the revised business process diagram is verified, the first database is updated based on the revised business process diagram.

9. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the test requirements analysis method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the test requirements analysis method as described in any one of claims 1 to 8.

Images