Software development requirement processing method and device, computer device, and storage medium

Abstract

Embodiments of the present application relate to a software development requirement processing method and device, computer equipment and a storage medium. The software development requirement is classified, and a differentiated execution process is selected according to the classification result. Reference materials related to the software development requirement are searched according to the differentiated execution process, and technical documents and test scripts are generated using the reference materials. The test scripts are executed, and log data generated is collected. The log data is diagnosed in combination with the technical documents to generate a diagnosis report. A repair scheme for software code is generated according to the diagnosis report, the repair scheme is code reviewed, and the software code is repaired based on the repair scheme that passes the review. Thus, the abnormal code position and the abnormal reason can be quickly located based on the log data and the technical documents, and the corresponding repair scheme is generated, thereby reducing the manual analysis and manual positioning process, and improving the processing efficiency of unknown fault type software development requirements and the code repair accuracy.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and in particular to a software development requirements processing method, apparatus, computer equipment, and storage medium. Background Technology

[0002] With the continuous expansion of software system scale and the widespread application of microservices and distributed architectures, the number of software development requirements generated during the software development process is growing rapidly, especially the complexity of handling unknown fault-related requirements, which has increased significantly. Developers typically need to combine log data, technical documentation, historical experience, and source code information to analyze, locate, and fix anomalies. The overall process involves multiple development tools and multiple processing steps, making the workflow quite complex.

[0003] In related technologies, the handling of software development requirements involving unknown faults mostly relies on manual log analysis, manual location of abnormal code, and manual writing of repair code. Due to the large volume of log data and the complexity of call chains, developers find it difficult to quickly determine the location and cause of the anomaly. Furthermore, significant differences in experience among developers can easily lead to low efficiency in fault location, inconsistent repair solutions, and repeated analysis of duplicate problems, thus affecting software development efficiency and the accuracy of problem fixing.

[0004] Therefore, how to automate the analysis, anomaly localization, and repair of software development requirements for unknown faults, so as to improve the efficiency of software development requirement processing and the accuracy of code repair, has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of this, in order to solve the above-mentioned technical problems or some of the technical problems, the embodiments of the present invention provide a software development requirements processing method, apparatus, computer equipment and storage medium.

[0006] In a first aspect, embodiments of the present invention provide a software development requirements processing method, comprising: Once the software development requirements are obtained, they are categorized, and a corresponding differentiated execution process is selected based on the categorization results. If the classification result is an unknown fault, reference materials related to the software development requirements are retrieved from a multi-source knowledge base according to the differentiated execution process, and technical documents and test scripts are generated using the reference materials. The test script is executed and the generated log data is collected. The log data is then used to diagnose the problem in conjunction with the technical documentation to generate a diagnostic report. Based on the diagnostic report, a repair plan for the software code corresponding to the software development requirements is generated, and the repair plan is reviewed. If the code review is passed, the software code is repaired based on the approved repair plan.

[0007] In one possible implementation, the method further includes: Extract the problem description information corresponding to the software development requirements, the diagnostic result information corresponding to the diagnostic report, and the code modification information corresponding to the repair plan, and generate corresponding knowledge entries; The knowledge entries are formatted and vectorized to obtain corresponding knowledge vector data. The knowledge entries and knowledge vector data are written into the multi-source knowledge base, and the corresponding vector index of the multi-source knowledge base is updated so that subsequent software development requirements can perform reference retrieval based on the updated multi-source knowledge base.

[0008] In one possible implementation, generating technical documents and test scripts using the reference materials includes: Based on the reference materials and the software code corresponding to the software development requirements, extract the module boundary information, function call chain information and interface definition information corresponding to the software code; Based on the module boundary information, the function call chain information, and the interface definition information, corresponding technical documents are generated. Based on the aforementioned technical document, corresponding test scripts are generated, wherein the test scripts include at least one of the following: interface test scripts, state transition test scripts, and data verification test scripts.

[0009] In one possible implementation, the step of diagnosing the log data in conjunction with the technical documentation to generate a diagnostic report includes: The log data is subjected to anomaly feature extraction, and the extracted anomaly features are matched with a predefined error pattern library to determine the error type corresponding to the anomaly features; Based on the error type and the call chain information and data flow information corresponding to the log data, locate the location of the exception code and the cause of the exception, and generate root cause information; A corresponding diagnostic report is generated based on the root cause information, wherein the diagnostic report includes at least the error type, root cause information, and the scope of the abnormal impact.

[0010] In one possible implementation, the step of generating a remediation plan for the software code corresponding to the software development requirements based on the diagnostic report, and conducting a code review of the remediation plan, includes: Based on the diagnostic report, determine the software code modification area corresponding to the software code; Based on the software context information and code dependency information corresponding to the software code modification area, a corresponding repair solution is generated, wherein the repair solution includes at least one of the following: code modification content and interface call adjustment content; The code review of the repair solution is performed based on preset code review rules to determine the code review result corresponding to the repair solution. The code review rules include at least one of the following: code security rules, code style rules, and interface compatibility rules.

[0011] In one possible implementation, the method further includes: If the classification result is a known fault class, retrieve the historical repair records corresponding to the software development requirements from the multi-source knowledge base, and determine the corresponding target repair strategy based on the historical repair records; The software code is repaired based on the target repair strategy; If the classification result is a new functional class, determine the target functional requirements corresponding to the software development requirements, and generate corresponding functional test cases based on the target functional requirements; Based on the functional test cases, corresponding software functional code is generated, and the software functional code is subjected to functional verification processing.

[0012] In one possible implementation, the method further includes: If the classification result is in the performance optimization category, collect the performance index data corresponding to the software code, and determine the corresponding performance bottleneck location based on the performance index data; generate the corresponding performance optimization plan based on the performance bottleneck location, and optimize the software code based on the performance optimization plan; If the classification result is a refactoring class, the design documents and migration guidelines of the target architecture are retrieved from the multi-source knowledge base to generate a behavior consistency test script; The software code is refactored for security based on the behavior consistency test script, and the refactored software code is reviewed. After the review is passed, it is stored in the project code library. If the classification result is a security vulnerability, the software code is subjected to a security scan to obtain vulnerability detection results; Based on the vulnerability detection results, the corresponding vulnerability type and the scope of vulnerability impact are determined, and a corresponding security remediation plan is generated based on the vulnerability type and the scope of vulnerability impact. The software code is repaired according to the security repair plan.

[0013] Secondly, embodiments of the present invention provide a software development requirements processing apparatus, comprising: The classification module is used to classify the software development requirements when they are obtained, and select the corresponding differentiated execution process based on the classification results. The retrieval module is used to retrieve reference materials related to the software development requirements from a multi-source knowledge base according to a differentiated execution process when the classification result is an unknown fault class, and to generate technical documents and test scripts using the reference materials; The generation module is used to execute the test script and collect the generated log data, and to diagnose the log data in conjunction with the technical documentation in order to generate a diagnostic report; The review module is used to generate a repair plan for the software code corresponding to the software development requirements based on the diagnostic report, and to review the code of the repair plan; The repair module is used to repair the software code based on the repair plan approved in the case that the code review has passed.

[0014] Thirdly, embodiments of the present invention provide a computer device, including: a processor and a memory, wherein the processor is configured to execute a software development requirements processing program stored in the memory to implement the software development requirements processing method described in any one of the first aspects above.

[0015] Fourthly, embodiments of the present invention provide a storage medium storing one or more programs, which can be executed by one or more processors to implement the software development requirements processing method described in any one of the first aspects.

[0016] The software development requirement processing solution provided in this invention classifies software development requirements upon acquisition and selects a corresponding differentiated execution process based on the classification results. If the classification result is an unknown fault, the solution retrieves relevant reference materials from a multi-source knowledge base according to the differentiated execution process, and generates technical documents and test scripts using these reference materials. The test scripts are executed, and the generated log data is collected. The log data is then used in conjunction with the technical documents to diagnose the log data and generate a diagnostic report. Based on the diagnostic report, a repair plan for the software code corresponding to the software development requirement is generated, and the repair plan undergoes code review. If the code review is passed, the software code is repaired based on the approved repair plan. Therefore, by classifying software development requirements and constructing an automated processing flow for unknown fault requirements—including knowledge retrieval, technical document generation, test execution, log diagnosis, repair plan generation, and code review—it can quickly locate the location and cause of abnormal code based on log data and technical documents, and generate corresponding repair plans. This reduces manual analysis and location processes, improving the processing efficiency and code repair accuracy for unknown fault software development requirements. Attached Figure Description

[0017] Figure 1 A flowchart illustrating a software development requirements processing method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating another software development requirements processing method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a software development requirements processing device provided in an embodiment of the present invention; Figure 4 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a software development requirements processing system provided in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] To facilitate understanding of the embodiments of the present invention, further explanations and descriptions will be provided below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0020] Figure 1 A software development requirements processing method provided in this embodiment of the invention includes: S11. Once the software development requirements are obtained, classify them and select the corresponding differentiated execution process based on the classification results.

[0021] The software development requirement processing method provided in this invention can be applied to scenarios such as software development platforms, intelligent operation and maintenance platforms, continuous integration and continuous deployment platforms (CI / CD platforms), code hosting platforms, and intelligent software engineering systems deployed on computer equipment. It is particularly suitable for handling software development requirements related to unknown faults in microservice architectures, distributed systems, and large-scale software projects. For example, when unknown faults such as interface call anomalies, service response failures, data processing errors, or system crashes occur during the operation of a software system, the corresponding software development requirements can be automatically analyzed, diagnosed, and repaired using the embodiments of this application, thereby improving the efficiency of software problem handling and software development.

[0022] The execution entity in this embodiment can be a computer device, including but not limited to: a server, cloud platform, software development management system, intelligent development platform, or software processing device integrated with an artificial intelligence model. The execution entity may include functional units such as a log analysis module, knowledge retrieval module, test generation module, diagnostic analysis module, and code repair module, used to perform processes such as software development requirement classification, multi-source knowledge base retrieval, technical document generation, test script generation, log diagnosis, repair plan generation, and code review. Furthermore, the execution entity can also communicate with code repositories, log systems, and multi-source knowledge bases to obtain information such as software code, log data, and historical repair records.

[0023] In this embodiment, software development requirements refer to the problems that need to be solved or the functional descriptions that need to be implemented, as proposed by users during the software development process. These include, but are not limited to: abnormal behaviors that occur during system operation (such as functional failures, data errors, service interruptions), new system capabilities that need to be added (such as adding interfaces, developing new pages, and integrating third-party services), performance metrics that need to be improved (such as optimizing response time and reducing resource consumption), code structures that need to be adjusted (such as module splitting and extracting duplicate code), and security vulnerabilities that need to be fixed (such as SQL injection, privilege escalation, and sensitive information leakage). The software development requirements can be represented in the following ways: problem descriptions provided by users, defect reports submitted by testers, functional specifications proposed by product managers, bottleneck analyses in performance test reports, technical debt discovered by code quality scans, and vulnerability alerts in security scan reports.

[0024] After obtaining the software development requirements, the system first analyzes them to extract key feature information. Key feature information refers to keywords or identifiers that reflect the type and characteristics of the software development requirements, including: problem description keywords (e.g., crashes, freezes, errors), abnormal behavior identifiers (e.g., unknown causes, phenomena), descriptions of functional changes (e.g., additions, implementations, development), performance indicator changes (e.g., slow response, high CPU usage), code structure adjustment intentions (e.g., refactoring, structure optimization), and security-related terms (e.g., vulnerabilities, injection, privilege escalation). Based on the extracted key feature information, a decision tree model is used to classify the software development requirements. The decision tree model is a classification algorithm based on a tree structure. It sets judgment nodes layer by layer and traverses downwards along different branches according to the judgment results, finally reaching the leaf node to determine the classification result. The decision tree model makes judgments sequentially according to the preset judgment nodes: First, it judges whether there is abnormal behavior in the system. Abnormal behavior refers to the phenomenon that the software system exhibits that is inconsistent with expectations, such as functional failure, data error, or unexpected interruption. If there is abnormal behavior, it further judges whether the cause of the abnormality is known. Known cause of the abnormality means that the problem has been analyzed and a clear root cause and solution have been recorded. If the cause of the abnormality is known, it is classified as a known bug (known fault); otherwise, it is classified as an unknown bug (unknown fault).

[0025] If no abnormal behavior is found, the next step is to determine whether performance optimization is needed. Performance optimization refers to improvements in metrics such as system response time, throughput, or resource consumption. If performance optimization is needed, it is categorized as a performance optimization. If not, the next step is to determine whether code refactoring is needed. Code refactoring refers to adjusting the code structure to improve readability, maintainability, or scalability without changing the external behavior of the code. If refactoring is needed, it is categorized as a refactoring. If not, the next step is to determine whether there are security risks. Security risks refer to vulnerabilities or weaknesses in the software system that can be maliciously exploited (such as SQL injection, cross-site scripting attacks, or privilege escalation). If security risks exist, they are categorized as security vulnerabilities. If not, they are categorized as new features. Through the layer-by-layer determination of the above decision tree model, software development requirements are classified into one of the following categories: unknown bugs, known bugs, new features, performance optimization, refactoring, or security vulnerabilities.

[0026] Based on the classification results, the system automatically selects the differentiated execution process corresponding to the type of requirement. The differentiated execution process refers to a processing flow designed for different requirement types, with different combinations of steps, different execution orders, and different quality gates: For requirements with unknown bugs, a six-step closed-loop process is used, including RAG retrieval, document generation, test generation, AI diagnosis, code repair, and review submission; for requirements with known bugs, a five-step fast-track process omitting the diagnostic step is used; for new feature requirements, a six-step test-driven development process is used; for performance optimization requirements, a six-step data-driven process is used; for refactoring requirements, a six-step security refactoring process is used; and for security vulnerability requirements, a zero-tolerance six-step process is used. All processes share the same toolbase, but differentiate themselves in the focus and execution order of specific steps to adapt to the processing characteristics of different types of requirements.

[0027] S12. If the classification result is an unknown fault, retrieve relevant reference materials from the multi-source knowledge base according to the differentiated execution process, and use the reference materials to generate technical documents and test scripts.

[0028] In this embodiment, when the classification result is an unknown fault, the system first initiates the RAG knowledge retrieval process. RAG knowledge retrieval refers to retrieval-enhanced generation technology, which combines an external knowledge base with a large language model to achieve context-aware generation capabilities based on retrieval. The system performs semantic understanding of the software development requirements, extracting key entities and intents from the requirement text. Key entities include: the names of the modules involved, interface identifiers, error codes, log keywords, etc. Intents refer to the type of problem the user hopes to solve, such as "locating the cause of the crash" or "analyzing timeout errors." The system uses a dense vector similarity algorithm to quickly recall the extracted semantic features. After encoding the semantic features into vectors, the system performs cosine similarity calculations with the vector representations of pre-stored knowledge entries in the multi-source knowledge base to obtain the top K candidate documents with the highest relevance. The multi-source knowledge base refers to a comprehensive knowledge storage system that integrates internal enterprise technical documents, code comments, JIRA tickets (issue tracking system tickets), mailing lists, cloud service provider knowledge bases, and open-source community resources.

[0029] After rapid recall, the system refines the candidate documents using a cross-encoder, simultaneously calculating a refined relevance score for both the input query and the candidate documents. The system employs a hybrid scoring strategy to determine the final ranking, comprehensively considering vector similarity, BM25 keyword matching scores, and a time decay factor, where the time decay factor assigns higher weight to newer documents. The final output is a list of references sorted by relevance, which may include, but is not limited to: problem localization methods, repair records of similar cases, architectural design specifications of relevant modules, and best practice guidelines.

[0030] After completing the RAG knowledge retrieval, technical documents and test scripts are generated using the retrieved references and the corresponding software code for the software development requirements. The software code refers to the source code files of the target system to be analyzed. Regarding the generation of technical documents, the software code is first parsed using static analysis tools, which analyze the code structure without running the code. Through static analysis, module boundary information, function call chain information, and interface definition information are extracted from the software code. Module boundary information identifies the code's organizational structure, function call chain information describes the calling relationships between functions, and interface definition information describes the exposed API specifications. The extracted information is then integrated with the references retrieved from the RAG retrieval to construct a complete knowledge context. This knowledge context includes the static structure of the code, business logic, and relevant historical experience and best practices.

[0031] Based on the knowledge context, the system generates technical documents through a pre-trained large-scale language model. These documents include system architecture descriptions, data model definitions, core process descriptions, interface specification documents, and flowcharts. For test script generation, the system automatically generates test scripts based on the same knowledge context and the generated technical documents. First, code path analysis identifies critical paths, boundary branches, and exception handling points. This analysis combines control flow graphs and data flow graphs to identify all possible execution paths and data dependencies along those paths. Combining the interface specifications in the technical documents, the system generates interface test cases to verify whether the API request and response meet expectations. Combining the state machine definitions in the technical documents, the system generates state transition test cases to verify the correctness of the system's behavior under different states. Combining the data model in the technical documents, the system generates data verification test cases to verify the integrity, consistency, and boundary conditions of the data. The system assembles these test cases into executable test scripts and automatically generates test data files and mock object definitions. The test scripts support multiple testing frameworks. The generated technical documents and test scripts serve as inputs for subsequent processing steps. The technical documents are used to assist in understanding system behavior during the AI ​​log diagnosis process, while the test scripts are executed to reproduce and verify faults.

[0032] In one possible implementation, technical documents and test scripts are generated using reference materials, including: Based on the reference materials and the software code corresponding to the software development requirements, extract the module boundary information, function call chain information, and interface definition information of the software code; based on the module boundary information, function call chain information, and interface definition information, generate the corresponding technical documents; based on the technical documents, generate the corresponding test scripts, wherein the test scripts include at least one of the following: interface test scripts, state transition test scripts, and data verification test scripts.

[0033] In this embodiment, static analysis tools are used to parse the software code and extract module boundary information, function call chain information, and interface definition information. Static analysis tools are tools that analyze code structure without running the code, including but not limited to the `ast` module for Python, the `JavaParser` library for Java, and the `go / ast` package for Go. Module boundary information identifies the code's organizational structure, including the division of packages, classes, modules, or namespaces and their dependencies, obtained by parsing import statements and package declarations in the code. Function call chain information describes the call relationships between functions, including the function entry point, the list of called functions, the call hierarchy, and the call frequency, obtained by constructing an abstract syntax tree and traversing its function call nodes. Interface definition information describes the exposed API specifications, including the interface name, request parameter types, response format, error code definitions, and HTTP methods, obtained by identifying route decorators, Uniform Resource Locator (URL) pattern matching, or interface declaration statements in the code.

[0034] The system integrates extracted module boundary information, function call chain information, and interface definition information with reference materials to generate technical documentation. Integration refers to associating and integrating the structured code information obtained from static analysis with the textual knowledge in the reference materials to form a unified and complete knowledge context. Specifically, the system associates module boundary information with the architecture design documents in the reference materials, supplementing the functional description, responsibility boundaries, and interaction relationships of each module; it associates function call chain information with the process descriptions in the reference materials to generate a complete execution path description of the business logic; and it associates interface definition information with the interface specifications in the reference materials, supplementing the parameter value range, field meaning, and business constraints. Based on the integrated knowledge context, a large-scale language model generates technical documentation conforming to Markdown format. This technical documentation includes, but is not limited to: system architecture description (including module division, module responsibilities, and inter-module relationships), data model definition (including entity definitions, field descriptions, data types, and relationships), core process description (including business process steps, branch conditions, and exception handling), and interface specification documentation (including interface list, request examples, response examples, and error code descriptions). The system also automatically generates visual flowcharts and architecture diagrams based on code control flow diagrams and data flow diagrams, which can be used as supplementary figures in technical documents.

[0035] Based on the generated technical documentation, corresponding test scripts are generated. Test scripts are executable code used to automatically verify the correctness of software functionality. Interface test scripts are generated based on the interface specification document in the technical documentation. Interface test scripts are used to verify whether API request and response conform to the specification, specifically including: constructing request data that conforms to parameter types and constraints, sending HTTP requests to the target interface, capturing response results, verifying whether the response status code meets expectations, verifying the existence and correct type of fields in the response body, and verifying whether error codes are correctly returned under abnormal input. State transition test scripts are generated based on the state machine definition in the technical documentation. The state machine definition describes the set of legal states of the system and the transition conditions and actions between states. State transition test scripts are used to verify whether the system behaves correctly in different states, specifically including: driving the system into a specified initial state, triggering state transition events, verifying whether the system transitions to the expected state, verifying data consistency before and after state transitions, and verifying whether illegal state transitions are correctly rejected. Data verification test scripts are generated based on the data model definition in the technical documentation. The data model defines the entity's field names, field types, value ranges, required attributes, and uniqueness constraints. Data validation test scripts are used to verify the integrity and consistency of the data, specifically including: testing boundary values ​​(such as minimum, maximum, null, and excessively long strings), testing whether valid data input is correctly accepted, testing whether invalid data input is correctly rejected, and testing whether the integrity of references between data (such as foreign key relationships) is maintained. At least one of the above interface test scripts, state transition test scripts, and data validation test scripts is assembled to generate a complete test suite. Simultaneously, test data files and mock object definitions are automatically generated to isolate the unit under test and provide simulated dependency services. The generated test scripts are delivered to the test execution environment for execution. The results are used to verify whether the system behavior meets expectations and to provide log data for subsequent AI log diagnostic steps.

[0036] S13. Execute the test script and collect the generated log data. Combine the log data with technical documentation to diagnose the problem and generate a diagnostic report.

[0037] In this embodiment, a test script is invoked to test and execute the software code corresponding to the software development requirements. The test script simulates interface calls, data processing, and business execution processes during the software system's operation. During the execution of the test script, log data output by the software system is collected in real time. This log data characterizes the status information during the software system's operation and includes at least one of the following: exception logs, interface call logs, service operation logs, and data processing logs.

[0038] The log data is parsed to extract anomaly features, which include at least one of the following: anomaly keywords, anomaly status codes, anomaly stack traces, and anomaly time information. Based on these anomaly features, the corresponding error type is determined. Correlation analysis of the log data, combined with technical documentation, is performed to determine the propagation path of the anomaly request between different modules. Finally, the technical documentation is used to locate the module, code location, and triggering conditions of the anomaly.

[0039] A corresponding diagnostic report is generated based on the error type, the abnormal module, the location of the abnormal code, and the abnormal triggering conditions. The diagnostic report includes at least the error type, the cause of the abnormality, and the scope of the abnormality's impact, which serves as a basis for subsequent software code repair.

[0040] In one possible implementation, log data is diagnosed in conjunction with technical documentation to generate a diagnostic report, including: The system extracts abnormal features from log data and matches these features with a predefined error pattern library to determine the error type corresponding to the abnormal features. Based on the error type and the call chain and data flow information corresponding to the log data, the system locates the abnormal code location and cause of the abnormality and generates root cause information. Based on the root cause information, the system generates a corresponding diagnostic report, which includes at least the error type, root cause information, and the scope of the abnormality's impact.

[0041] In this embodiment, after the test script is executed, the system collects the log data generated during execution. The log data includes at least test logs, application logs, system logs, and distributed tracing data. First, anomaly features are extracted from the log data. Using regular expression matching and keyword recognition, key information characterizing the abnormal state, such as error keywords, error codes, stack traces, and exception type names, is extracted from the log text. The extracted anomaly features are then matched against a predefined error pattern library. This library stores feature signatures for common error types, including feature templates for null pointer exceptions, database connection timeouts, concurrency race conditions, and memory leaks. During matching, an exact match is performed first; if that fails, semantic similarity matching is performed to ultimately determine the error type corresponding to the anomaly features.

[0042] Based on the error type and the corresponding call chain and data flow information from the log data, the location of the exception code and the cause of the exception are determined. The call chain information records the complete flow path of a request in the distributed system, while the data flow information records the trajectory of data flow between components. The scope of investigation is narrowed down based on the error type; the starting node of the exception is located using the call chain information; the propagation path of the exception data is traced using the data flow information; and the specific code location where the exception occurred is determined by combining the filename and line number in the stack trace. A comprehensive analysis of the error type, code context, and input data characteristics is used to infer the root cause of the exception, and the location of the exception code and the cause are compiled into root cause information.

[0043] A diagnostic report is generated based on root cause information. The report includes at least the following: error type, root cause information, and the scope of the anomaly's impact. The scope of impact is determined by assessing the number of affected modules, the range of affected users, the affected business functions, and the degree of data impact. The generated diagnostic report serves as output, driving subsequent code remediation steps. Simultaneously, the root cause information is fed back into a multi-source knowledge base as material for knowledge accumulation.

[0044] S14. Generate a repair plan for the software code corresponding to the software development requirements based on the diagnostic report, and conduct a code review of the repair plan.

[0045] In this embodiment, a repair plan for the software code corresponding to the software development requirements is generated based on the diagnostic report. The diagnostic report characterizes the corresponding anomalies in the software system and their locations. Based on the anomaly type, location, and impact range in the diagnostic report, the software code areas requiring modification are determined, and a corresponding repair plan is generated by combining this with the relevant software code context information. The repair plan characterizes the software code modifications required to address the anomalies.

[0046] After generating the remediation plan, a code review is conducted. Based on preset code review rules, the software code corresponding to the remediation plan is checked to determine whether there are any logical errors, abnormal interface calls, or non-compliance with code style requirements, and corresponding code review results are generated.

[0047] If the code review is passed, the software code is modified based on the approved fixes to complete the software code fixes corresponding to the software development requirements.

[0048] In one possible implementation, a remediation plan for the software code corresponding to the software development requirements is generated based on the diagnostic report, and the remediation plan undergoes code review, including: Based on the diagnostic report, identify the software code modification areas corresponding to the software code; based on the software context information and code dependency information corresponding to the software code modification areas, generate corresponding repair solutions, wherein the repair solutions include at least one of the following: code modification content and interface call adjustment content; conduct code review on the repair solutions based on preset code review rules to determine the code review results corresponding to the repair solutions, wherein the code review rules include at least one of the following: code security rules, code style rules, and interface compatibility rules.

[0049] In this embodiment, the software code modification area is determined based on the diagnostic report. The software code modification area refers to the range of code that needs to be modified, including the specific source file path, start line number, and end line number. By parsing the stack and call chain information in the diagnostic report, the original code location where the exception occurred is located. Then, static code analysis is used to identify the upstream and downstream code blocks related to that location, including the functions that call that location and the functions called by that location. This code range is then defined as the software code modification area.

[0050] Based on the software context information and code dependency information corresponding to the modified software code area, a corresponding repair plan is generated. Software context information refers to the code environment surrounding the modified software code area, including the input parameters and return value definitions of the function containing the area, the member variable definitions of the class containing the area, the adjacent code logic before and after the area, and the reference relationships of the area within the entire file. Code dependency information refers to the information of external components that the modified software code area depends on, including called third-party library functions, imported local module interfaces, accessed database table structures, and called remote service interfaces. The anomaly causes from the diagnostic report, the specific content of the modified software code area, the software context information, and the code dependency information are all input into the code repair model. The code repair model is built based on a large language model, capable of understanding code semantics and generating repair code that conforms to the project's coding standards. A corresponding repair strategy is generated based on the type of anomaly cause. For example, for null pointer exceptions, a null check is added before accessing the object or ensuring that the object is correctly initialized; for database connection timeouts, the connection pool configuration is adjusted or a retry mechanism is added; for interface call failures, fallback processing or timeout control is added.

[0051] Based on the repair strategy, a corresponding repair plan is generated. The repair plan includes at least one of the following: code modifications or API call adjustments. Code modifications refer to specific changes made to the source code in the modified area of ​​the software code, including adding or deleting lines of code, or comparing the changes before and after. API call adjustments refer to adjustments made to the calling method of remote or local APIs, including modifying API request parameters, adjusting the API call order, adding API call retry logic, or changing the call target.

[0052] The code review of the remediation plan is conducted based on preset code review rules to determine the corresponding code review results. Code review rules refer to a set of rules used to automatically evaluate the quality of the remediation plan, including at least one of the following: code security rules, code style rules, and interface compatibility rules. Code security rules are used to detect whether the remediation plan introduces new security vulnerabilities, including detecting the presence of SQL injection risks (e.g., failure to use parameterized queries), cross-site scripting attack risks (e.g., failure to filter user input), and sensitive information leakage risks (e.g., hardcoding passwords or keys in the code). Code style rules are used to check whether the code style of the remediation plan conforms to project conventions, including naming conventions (e.g., using camelCase for variable names), formatting conventions (e.g., using spaces instead of tabs for indentation), commenting conventions (e.g., adding comments to critical logic), and code structure conventions (e.g., function length does not exceed a preset threshold). Interface compatibility rules are used to detect whether the remediation plan affects the compatibility of existing interfaces, including detecting whether the interface return value format has changed (e.g., fields have been deleted or their types modified), whether the interface request parameters have changed (e.g., required fields have been removed or new required fields have been added), whether the interface error code definition has changed, and whether the interface's behavioral semantics have undergone unexpected changes. The above review rules are applied to each code modification and API call adjustment in the remediation plan. For each rule, the system determines whether it meets the requirements. If it does, it is marked as passed; otherwise, it is marked as a violation, and the reason for the violation is recorded. The system summarizes all review results and generates a structured code review result, which includes the review pass status (fully passed, partially passed, or failed), a list of violations (each item includes the rule name, violation description, violation location, and suggested modification), and a review score.

[0053] If the review result is all or part of the review (and the remaining violations are non-blocking issues), the remediation plan is determined to be a valid remediation plan; if the review result is not approved, the list of violations is fed back to the code remediation model, triggering the regeneration or correction of the remediation plan until the review is approved or the preset retry limit is reached.

[0054] S15. If the code review is passed, fix the software code based on the approved fix plan.

[0055] In this embodiment, after the code review is passed, the approved remediation plan is obtained. Based on the code modification content in the remediation plan, the source files that need to be modified are located, and code change operations are performed on the modified areas of the software code, including adding, deleting, or modifying code lines. For remediation involving multiple files, the modification order is determined according to the dependencies to ensure the integrity of the modification process. At the same time, based on the interface call adjustment content in the remediation plan, the parameters of the corresponding interface call points are modified, the call order is adjusted, or retry logic is added.

[0056] After code modifications are completed, regression test cases related to this fix are automatically executed, including previously generated test scripts for reproducing the fault and existing unit tests related to the modified code area. If all test cases pass, the system confirms a successful fix, marks the fixed code as pending submission, and generates a code change summary containing a list of modified files and change descriptions. The code change summary is linked with the diagnostic report, fix plan, and test execution results to form a complete fix record, which will be submitted to the version control system and simultaneously fed back into the multi-source knowledge base as material for knowledge preservation. If any test cases fail, the system analyzes the reasons for the failure, rolls back the code changes, and re-triggers the fix plan generation process.

[0057] In one possible implementation, after fixing the software code based on the reviewed fix, the method further includes: Extract problem description information corresponding to software development requirements, diagnostic result information corresponding to diagnostic reports, and code modification information corresponding to repair solutions to generate corresponding knowledge entries; perform formatting and vectorization encoding on the knowledge entries to obtain corresponding knowledge vector data; write the knowledge entries and knowledge vector data into a multi-source knowledge base and update the corresponding vector index of the multi-source knowledge base so that subsequent software development requirements can perform reference retrieval based on the updated multi-source knowledge base.

[0058] In this embodiment, after the software code repair is completed, the problem description information corresponding to the software development requirements, the diagnostic result information corresponding to the diagnostic report, and the code modification information corresponding to the repair plan are extracted, and corresponding knowledge entries are generated based on the extracted information. Specifically, the problem description information characterizes the description of the abnormal problem corresponding to the software development requirements, the diagnostic result information characterizes the diagnostic result corresponding to the abnormal problem, and the code modification information characterizes the software code modifications made to address the abnormal problem. The problem description information, diagnostic result information, and code modification information are then correlated and integrated to generate structured knowledge entries corresponding to the abnormal problem.

[0059] The knowledge entries undergo formatting and vectorization encoding. Formatting is used to standardize the field content, data structure, and content format of the knowledge entries to obtain standardized knowledge data. Vectorization encoding is used to extract semantic features from the knowledge entries based on a semantic encoding model to generate corresponding knowledge vector data, which represents the semantic feature information of the knowledge entries.

[0060] After obtaining the knowledge vector data, the knowledge entries and knowledge vector data are written into a multi-source knowledge base. This multi-source knowledge base stores historical problem information, diagnostic results, and code repair information corresponding to different software development requirements. Subsequently, the vector index of the multi-source knowledge base is updated to establish an index relationship between the knowledge vector data and the corresponding knowledge entries, enabling subsequent software development requirements to retrieve reference materials for similar problems based on the updated multi-source knowledge base.

[0061] In one possible implementation, if the classification result is a known fault class, historical repair records corresponding to the software development requirements are retrieved from a multi-source knowledge base, and a corresponding target repair strategy is determined based on the historical repair records; the software code is then repaired based on the target repair strategy.

[0062] If the classification result is a new functional class, determine the target functional requirements corresponding to the software development requirements, and generate corresponding functional test cases based on the target functional requirements; generate corresponding software functional code based on the functional test cases, and perform functional verification processing on the software functional code.

[0063] If the classification result is "performance optimization", collect the performance index data corresponding to the software code, and determine the corresponding performance bottleneck location based on the performance index data; generate the corresponding performance optimization plan based on the performance bottleneck location, and optimize the software code based on the performance optimization plan.

[0064] If the classification result is "refactoring," the design documents and migration guidelines of the target architecture are retrieved from a multi-source knowledge base to generate behavioral consistency test scripts. The software code is then safely refactored based on these test scripts, and the refactored code undergoes a code review. Once the review is passed, the code is stored in the project code repository.

[0065] If the classification result is a security vulnerability, a security scan is performed on the software code to obtain vulnerability detection results. Based on the vulnerability detection results, the corresponding vulnerability type and scope of impact are determined, and a corresponding security remediation plan is generated based on the vulnerability type and scope of impact. The software code is then remediated according to the security remediation plan.

[0066] In this embodiment, when the classification result is a known fault class, historical repair records corresponding to the software development requirement are retrieved from a multi-source knowledge base. A known fault class refers to a requirement type where the cause of the anomaly has been located and only a repair operation is required. Historical repair records are complete records of similar problems previously handled, including problem descriptions, root cause analyses, repair solution code, and verification results. The system uses a combination of vector retrieval and keyword matching to calculate the similarity between keywords of the current software development requirement (such as error type, class name, and method name in the exception stack trace) and the problem descriptions and root cause analyses in the historical repair records, recalling the historical records with the highest similarity. Repair solution code is extracted from the recalled records and used as the target repair strategy. The target repair strategy is a code modification scheme that can be directly applied or requires only minor adjustments. The code modifications in the target repair strategy are applied to the corresponding locations in the software code, and regression testing is performed after the repair is completed to verify the repair effect.

[0067] If the classification result is a new functional category, the target functional requirements corresponding to the software development needs are determined. A new functional category refers to a requirement type that needs to add new capabilities to the system. Target functional requirements refer to the functional specifications that users expect to achieve, including input parameters, output format, business logic rules, and boundary conditions. Based on test-driven development principles, the system generates corresponding functional test cases according to the target functional requirements. These test cases cover normal scenarios, boundary scenarios, and abnormal scenarios. The system uses these functional test cases as acceptance criteria, generating software functional code that meets the test cases. The generation of software functional code adopts an iterative approach: first, a code framework is generated; then, test cases are run to verify whether they pass; if they fail, the code is adjusted based on the failure information until all test cases pass. The passed software functional code undergoes functional verification processing, which includes executing all functional test cases, confirming that the output meets expectations, and checking whether the code coverage reaches a preset threshold.

[0068] When the classification result is "performance optimization," performance metric data corresponding to the software code is collected. Performance optimization refers to needs where the system runs slowly or consumes a lot of resources, requiring performance improvement. Performance metric data includes response time (e.g., average interface latency and P99 latency), throughput (e.g., requests processed per second), CPU utilization, memory usage, and I / O latency. The software code is sampled and analyzed using performance profiling tools to generate performance flame graphs or call trees, identifying the most resource-intensive hotspot functions and the most frequently executed code paths. Based on this analysis, performance bottlenecks are determined. Performance optimization plans are automatically generated based on the bottleneck locations. These plans include, but are not limited to: caching strategies (e.g., adding local or distributed caching), asynchronous processing (e.g., changing synchronous calls to message queues), batch operations (e.g., merging multiple queries into one), and algorithm optimization (e.g., replacing O(n²) algorithms with O(n log n) algorithms). The code modifications from the optimization plans are applied to the software code, and performance benchmark tests are triggered to verify the optimization effects.

[0069] If the classification result is "refactoring," the system retrieves design documents and migration guidelines for the target architecture from a multi-source knowledge base. Refactoring refers to requirements where code is difficult to maintain or the architecture is chaotic, necessitating adjustments to the internal structure while maintaining external behavior. Based on the retrieved design documents and migration guidelines, a behavior consistency test script is generated to verify that the external behavior of the system before and after refactoring is identical. The system performs a safe refactoring of the software code based on the behavior consistency test script. Safe refactoring refers to adjusting the code structure to improve readability, maintainability, or scalability without changing the external behavior of the code, including but not limited to: extracting common methods, renaming variables, splitting large classes, and converting conditional logic to polymorphism. After refactoring, the system executes the behavior consistency test script again and compares the execution results with the baseline before refactoring. If they are completely consistent, the refactoring is considered successful. The refactored software code undergoes a code review, which includes checking code style consistency, the rationality of new abstractions, and whether potential performance issues have been introduced. After passing the review, the refactored code is stored in the project code repository.

[0070] If the classification result is a security vulnerability, a security scan is performed on the software code to obtain vulnerability detection results. A security vulnerability refers to a requirement type in the system that poses a security risk that can be maliciously exploited. The security scan uses static application security testing tools to perform rule matching and taint analysis on the source code to detect security vulnerabilities, including but not limited to: SQL injection, cross-site scripting (XSS), path traversal, sensitive information leakage, privilege escalation, and insecure deserialization. The vulnerability detection results are analyzed to determine the vulnerability type (e.g., SQL injection) and the scope of impact (e.g., affected API endpoints, database tables, user roles). Based on the vulnerability type and scope of impact, corresponding remediation guidelines are retrieved from the security knowledge base to generate a security remediation plan. The security remediation plan includes specific code modification suggestions, such as: for SQL injection, changing string concatenation to parameterized queries; for XSS, adding output encoding; for sensitive information leakage, removing password fields from logs. The software code is then remediated according to the security remediation plan. After the remediation is completed, a security scan is performed again to verify that the vulnerability has been eliminated and no new security issues have been introduced.

[0071] In one possible implementation, after the code is fixed and regression testing passes, the system triggers a knowledge flywheel accumulation step. The knowledge flywheel refers to a self-reinforcing loop mechanism of knowledge retrieval, execution flow, experience accumulation, and backflow into the database. Key information is extracted from this process, including: the original description of the software development requirements (e.g., occasional payment timeout errors when submitting an order), root cause information from the diagnostic report (e.g., database connection not being released in time in line 47 of the payment log service file), and code modifications in the remediation plan (e.g., changing manual connection release to automatic management). This key information is formatted into structured knowledge entries, each containing the problem type (e.g., database connection pool exhaustion), problem description (e.g., payment timeout in high-concurrency scenarios), root cause analysis (e.g., transaction not properly closing connections), solution (e.g., using automatic management to release connections), associated code location (e.g., lines 45-55 of the payment log service file), and applicable scenario tags (e.g., payment timeout, connection pool, high concurrency). Knowledge entries are vector-encoded to generate corresponding knowledge vector data. These knowledge entries and their vector data are then written into a multi-source knowledge base, and the corresponding vector indexes in the knowledge base are updated. After this process, the number of knowledge entries related to database connection pools in the multi-source knowledge base increased from 3 to 4. When developers encounter similar connection timeout issues later, they can directly retrieve the solutions accumulated in this process through vector retrieval, eliminating the need for re-analysis. As the number of processing iterations increases, the knowledge base continues to expand, the relevance of retrieval and retrieval gradually improves, and the accuracy of AI-generated diagnostic and repair solutions also increases, forming a self-reinforcing positive cycle that becomes more accurate with use—the knowledge flywheel effect.

[0072] This application categorizes software development requirements and, for requirements with unknown faults, constructs an automated processing flow encompassing reference retrieval, technical document generation, test script execution, log diagnosis, repair plan generation, code review, and knowledge base updates. Based on log data and technical documents, it can quickly locate the location and cause of anomalies and automatically generate corresponding software code repair plans. This reduces manual analysis, manual location, and repetitive repair processes, improving the efficiency of processing software development requirements with unknown faults and the accuracy of software code repair. Furthermore, by writing diagnostic results and code repair information into a multi-source knowledge base and updating the vector index, it also enables the continuous accumulation of historical problems and repair experience, improving the retrieval efficiency and automated processing capabilities for subsequent similar software development requirements.

[0073] As an example Figure 2 A flowchart illustrating another software development requirements processing method provided in an embodiment of the present invention is shown below. Figure 2 As shown, the method specifically includes: After obtaining the software development requirements, they are categorized into "Unknown Faults": User feedback indicates that "an occasional payment timeout error occurs when submitting an order, but not every time." The system uses an intelligent classifier to categorize this as an "Unknown Fault," triggering a six-step closed-loop process: The system retrieves connection pool configurations and similar historical records from the knowledge base, generates technical documents and test scripts, executes the test scripts to reproduce the problem (5 out of 50 tests resulted in timeouts), uses log diagnostics to locate the database connection failure in line 47 of the payment log service file, generates a repair plan (changing manual release to automatic management), reviews and approves the code, modifies it, and after the repair, all regression tests pass. Finally, the problem description, root cause analysis, and repair plan are fed back into the knowledge base.

[0074] Known Fault Category: User feedback: "Login interface returns 500 error". The system categorized this as a known fault using an intelligent classifier. A search of the knowledge base revealed a similar issue handled three months prior, the root cause being the lack of null value validation for the username parameter. The system directly reused the previous fix, adding a null value check to the login interface entry point. After review and approval, the fix was completed, taking 5 minutes.

[0075] New Feature Category: The product manager proposed "adding a user points system, where users earn 10 points for each completed order." The system uses an intelligent classifier to categorize this as a new feature category. First, it generates functional test cases (scenarios such as earning points for normal orders, deducting points for returns, and not awarding points for repeated orders). Then, based on the test cases, it generates functional code (points record table, points addition interface, points deduction interface). Finally, it performs functional verification, and delivers the code only after all test cases pass.

[0076] Performance Optimization Category: The test report indicated that "the order query interface response time exceeded 3 seconds." The system used an intelligent classifier to categorize it as a performance optimization category. Performance metrics data revealed that slow queries accounted for 80% of the time, pinpointing that the order query statement was not using an index. An optimization plan was generated (creating an index on the order time field and changing pagination queries to cursor mode). After optimization, the interface response time decreased from 3 seconds to 200 milliseconds.

[0077] Refactoring Category: The code scan report indicated that "the order processing module contains duplicate code, with the same price calculation logic in all three methods." The system categorized this as a refactoring category using an intelligent classifier, retrieved refactoring guidelines from the knowledge base, generated behavioral consistency test scripts (covering all price calculation scenarios), extracted the duplicate logic into common methods while keeping the calculation results unchanged, executed the consistency test scripts for verification, and then reviewed and stored in the code repository.

[0078] Security Vulnerability Category: The security scan report found an "SQL injection vulnerability in the user query interface." The system categorized it as a security vulnerability using an intelligent classifier, analyzed and confirmed the vulnerability code, retrieved remediation guidelines from the security knowledge base, generated a security remediation plan (changing string concatenation to parameterized queries), and performed a security scan again after the fix to confirm that the vulnerability had been eliminated.

[0079] Figure 5 This is a schematic diagram of the structure of a software development requirements processing system provided in an embodiment of the present invention, such as... Figure 5 As shown, the system specifically includes: This application system adopts a four-layer architecture design, with each layer collaborating through standardized interfaces and an event-driven mechanism to achieve overall functionality. The following combines... Figure 5 The four-layer architecture is explained in detail.

[0080] Core Engine Layer: Located at the bottom of the architecture, the core engine layer is the system's foundational capability layer, providing core AI-related algorithms and model capabilities. This layer comprises four main engines: the RAG knowledge retrieval engine, responsible for vector encoding, similarity calculation, hybrid sorting, and result fusion, using a vector database for storage and supporting millisecond-level retrieval of hundreds of millions of documents; the code understanding engine, built on static analysis tools, providing code parsing, abstract syntax tree traversal, dependency analysis, and call chain tracing capabilities, supporting multiple programming languages; the test generation engine, based on code path analysis, identifying critical paths and boundary conditions, automatically generating high-coverage test cases, supporting unit testing, integration testing, contract testing, and performance testing; and the AI ​​diagnostic engine, based on a large language model and rule engine, performing log analysis, error pattern matching, root cause localization, and remediation suggestion generation, supporting the fusion analysis of multimodal data such as logs, metrics, and traces. The core engine layer provides capability call interfaces to upper layers.

[0081] Infrastructure Layer: The infrastructure layer provides basic resources such as computing, storage, and networking support for the core engine layer. Heterogeneous computing resource scheduling supports hybrid scheduling of graphics processing units (GPUs), tensor processors (TCPUs), and central processing units (CPUs), using a container orchestration system to achieve automatic scaling and dynamically adjusting resources based on load. The data lake and feature platform store raw log data, indicator data, and tracking data, using a data lake table format to manage data versions and supporting time-travel queries. The vector database cluster deploys a distributed vector database, supporting high-concurrency vector retrieval and employing a sharding strategy for horizontal scaling. Object storage is used to store documents, code, and model files, supporting version control and lifecycle management. The core engine layer uses infrastructure layer resources through capability calls and persists processing results to the infrastructure layer through data storage.

[0082] Platform Service Layer: Built on top of the infrastructure layer, the platform service layer provides the platform capabilities required for development, deployment, and operation. The MLOps toolchain (Machine Learning Operations Toolchain) provides model training pipelines, model version management, A / B testing, and model monitoring. The agent orchestration framework builds agent workflows based on an agent orchestration library, supporting multi-agent collaboration, tool calls, memory management, and human-machine collaboration. Experiment tracking and model management record hyperparameters, metrics, and outputs for each experiment, supporting experiment comparison and reproduction, managing model versions, and supporting rollback and canary releases. The API gateway serves as a unified entry point, providing authentication, rate limiting, circuit breaking, and monitoring capabilities, supporting both RESTful and gRPC communication protocols. The core engine layer is invoked by the platform service layer through service calls, and the platform service layer utilizes the computing and storage resources of the infrastructure layer through resource scheduling.

[0083] Application Service Layer: Located at the top layer of the architecture, the application service layer provides users with specific application scenarios and functions. Domain-Specific AI Capabilities: Customized AI capabilities are provided for different domains (such as cloud computing, finance, and e-commerce), including cloud platform fault diagnosis, financial compliance checks, and e-commerce recommendation optimization. API Economy and Ecosystem Integration: Standardized API interfaces are provided to support third-party system integration, and a plugin marketplace is built to support community contributions of skills and tools. Intelligent Operation and Maintenance Q&A: An intelligent Q&A system built based on RAG technology supports natural language queries, helping users quickly obtain technical documents, best practices, and fault handling guides. Visual Workbench: A web interface is provided to display the requirement processing flow, task status, knowledge base retrieval results, and diagnostic reports, supporting human-machine collaboration and allowing human intervention at key decision points. The application service layer calls the platform service layer through the API gateway, triggering the requirement processing workflow.

[0084] The four-layer architecture collaborates through standardized interfaces and an event-driven mechanism. In terms of call relationships, the application service layer calls the platform service layer via APIs, the platform service layer calls the core engine layer via services, and the core engine layer uses infrastructure layer resources via capability calls, forming a top-down call chain. Regarding data flow, the application service layer collects user input and feedback and stores it as knowledge; the core engine layer processes the knowledge and generates vector indexes; the infrastructure layer persistently stores the knowledge; and the platform service layer manages the knowledge update process, forming a complete data loop from data collection to storage and updating. In terms of communication, the layers communicate asynchronously through message queues. For example, code commit events trigger the knowledge update process, and test failure events trigger the diagnostic process, achieving decoupling and efficient collaboration between layers. The event-driven mechanism, combined with standardized API calls and resource scheduling, enables the four-layer architecture to flexibly respond to different types of processing tasks, supporting the efficient operation of the overall solution.

[0085] Figure 3 This is a schematic diagram of the structure of a software development requirements processing device provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the device specifically includes: The classification module 31 is used to classify the software development requirements when they are obtained, and select the corresponding differentiated execution process based on the classification results. The retrieval module 32 is used to retrieve reference materials related to the software development requirements from a multi-source knowledge base according to a differentiated execution process when the classification result is an unknown fault class, and to generate technical documents and test scripts using the reference materials. The generation module 33 is used to execute the test script and collect the generated log data, and to diagnose the log data in conjunction with the technical document to generate a diagnostic report; The review module 34 is used to generate a repair plan for the software code corresponding to the software development requirements based on the diagnostic report, and to review the code of the repair plan. Repair module 35 is used to repair the software code based on the repair plan approved in the case that the code review has passed.

[0086] In one possible implementation, the update module 36 is used to extract the problem description information corresponding to the software development requirements, the diagnostic result information corresponding to the diagnostic report, and the code modification information corresponding to the repair plan, and generate corresponding knowledge entries. The knowledge entries are formatted and vectorized to obtain corresponding knowledge vector data. The knowledge entries and knowledge vector data are written into the multi-source knowledge base, and the corresponding vector index of the multi-source knowledge base is updated so that subsequent software development requirements can perform reference retrieval based on the updated multi-source knowledge base.

[0087] In one possible implementation, the generation module is further configured to extract module boundary information, function call chain information, and interface definition information corresponding to the software code based on the reference materials and the software code corresponding to the software development requirements. Based on the module boundary information, the function call chain information, and the interface definition information, corresponding technical documents are generated. Based on the aforementioned technical document, corresponding test scripts are generated, wherein the test scripts include at least one of the following: interface test scripts, state transition test scripts, and data verification test scripts.

[0088] In one possible implementation, the generation module is specifically used to extract abnormal features from the log data and match the extracted abnormal features with a predefined error pattern library to determine the error type corresponding to the abnormal features; Based on the error type and the call chain information and data flow information corresponding to the log data, locate the location of the exception code and the cause of the exception, and generate root cause information; A corresponding diagnostic report is generated based on the root cause information, wherein the diagnostic report includes at least the error type, root cause information, and the scope of the abnormal impact.

[0089] In one possible implementation, the review module is specifically used to determine the software code modification area corresponding to the software code based on the diagnostic report; Based on the software context information and code dependency information corresponding to the software code modification area, a corresponding repair solution is generated, wherein the repair solution includes at least one of the following: code modification content and interface call adjustment content; The code review of the repair solution is performed based on preset code review rules to determine the code review result corresponding to the repair solution. The code review rules include at least one of the following: code security rules, code style rules, and interface compatibility rules.

[0090] In one possible implementation, the repair module is further configured to, when the classification result is a known fault class, retrieve historical repair records corresponding to the software development requirements from the multi-source knowledge base, and determine the corresponding target repair strategy based on the historical repair records; The software code is repaired based on the target repair strategy; The generation module is further configured to, when the classification result is a new functional class, determine the target functional requirements corresponding to the software development requirements, and generate corresponding functional test cases based on the target functional requirements. Based on the functional test cases, corresponding software functional code is generated, and the software functional code is subjected to functional verification processing.

[0091] In one possible implementation, the generation module is further configured to, when the classification result is a performance optimization class, collect performance index data corresponding to the software code, and determine the corresponding performance bottleneck location based on the performance index data. Based on the location of the performance bottleneck, a corresponding performance optimization plan is generated, and the software code is optimized based on the performance optimization plan. If the classification result is a refactoring class, the design documents and migration guidelines of the target architecture are retrieved from the multi-source knowledge base to generate a behavior consistency test script; The software code is refactored for security based on the behavior consistency test script, and the refactored software code is reviewed. After the review is passed, it is stored in the project code library. If the classification result is a security vulnerability, the software code is subjected to a security scan to obtain vulnerability detection results; Based on the vulnerability detection results, the corresponding vulnerability type and the scope of vulnerability impact are determined, and a corresponding security remediation plan is generated based on the vulnerability type and the scope of vulnerability impact. The software code is repaired according to the security repair plan.

[0092] The device provided in this embodiment may be as follows: Figure 3 The apparatus shown can perform, as Figure 1 All steps of the method, thus achieving Figure 1 For details on the technical effects of the method shown, please refer to [link / reference]. Figure 1 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0093] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Figure 4 The computer device 400 shown includes at least one processor 401, a memory 402, at least one network interface 404, and other user interfaces 403. The various components in the computer device 400 are coupled together via a bus system 405. It is understood that the bus system 405 is used to implement communication between these components. In addition to a data bus, the bus system 405 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 4The general designated all buses as Bus System 405.

[0094] The user interface 403 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

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

[0096] In some implementations, memory 402 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 4021 and application program 4022.

[0097] The operating system 4021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 4022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this embodiment can be included in the application program 4022.

[0098] In this embodiment of the invention, by calling the program or instructions stored in the memory 402, specifically the program or instructions stored in the application program 4022, the processor 401 executes the method steps provided in each method embodiment, including, for example: Once the software development requirements are obtained, they are categorized, and a corresponding differentiated execution process is selected based on the categorization results. If the classification result is an unknown fault, reference materials related to the software development requirements are retrieved from a multi-source knowledge base according to the differentiated execution process, and technical documents and test scripts are generated using the reference materials. The test script is executed and the generated log data is collected. The log data is then used to diagnose the problem in conjunction with the technical documentation to generate a diagnostic report. Based on the diagnostic report, a repair plan for the software code corresponding to the software development requirements is generated, and the repair plan is reviewed. If the code review is passed, the software code is repaired based on the approved repair plan.

[0099] The methods disclosed in the above embodiments of the present invention can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 402. Processor 401 reads the information in memory 402 and, in conjunction with its hardware, completes the steps of the above method.

[0100] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0101] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0102] The computer device provided in this embodiment may be as follows: Figure 4 The device shown can perform, for example Figure 1 All steps of the method, thus achieving Figure 1 For details on the technical effects of the method shown, please refer to [link / reference]. Figure 1 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0103] This invention also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; the memory may also include combinations of the above types of memory.

[0104] When one or more programs in the storage medium can be executed by one or more processors to implement the above-described software development requirement processing method executed on the device side.

[0105] The processor is used to execute a software development requirements processing program stored in memory to implement the following steps of a software development requirements processing method executed on the device side: Once the software development requirements are obtained, they are categorized, and a corresponding differentiated execution process is selected based on the categorization results. If the classification result is an unknown fault, reference materials related to the software development requirements are retrieved from a multi-source knowledge base according to the differentiated execution process, and technical documents and test scripts are generated using the reference materials. The test script is executed and the generated log data is collected. The log data is then used to diagnose the problem in conjunction with the technical documentation to generate a diagnostic report. Based on the diagnostic report, a repair plan for the software code corresponding to the software development requirements is generated, and the repair plan is reviewed. If the code review is passed, the software code is repaired based on the approved repair plan.

[0106] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0107] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0108] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for processing software development requirements, characterized in that, include: Once the software development requirements are obtained, they are categorized, and a corresponding differentiated execution process is selected based on the categorization results. If the classification result is an unknown fault, reference materials related to the software development requirements are retrieved from a multi-source knowledge base according to the differentiated execution process, and technical documents and test scripts are generated using the reference materials. The test script is executed and the generated log data is collected. The log data is then used to diagnose the problem in conjunction with the technical documentation to generate a diagnostic report. Based on the diagnostic report, a repair plan for the software code corresponding to the software development requirements is generated, and the repair plan is reviewed. If the code review is passed, the software code is repaired based on the approved repair plan.

2. The method according to claim 1, characterized in that, The method further includes: Extract the problem description information corresponding to the software development requirements, the diagnostic result information corresponding to the diagnostic report, and the code modification information corresponding to the repair plan, and generate corresponding knowledge entries; The knowledge entries are formatted and vectorized to obtain corresponding knowledge vector data. The knowledge entries and knowledge vector data are written into the multi-source knowledge base, and the corresponding vector index of the multi-source knowledge base is updated so that subsequent software development requirements can perform reference retrieval based on the updated multi-source knowledge base.

3. The method according to claim 1, characterized in that, The generation of technical documents and test scripts using the reference materials includes: Based on the reference materials and the software code corresponding to the software development requirements, extract the module boundary information, function call chain information and interface definition information corresponding to the software code; Based on the module boundary information, the function call chain information, and the interface definition information, corresponding technical documents are generated. Based on the aforementioned technical document, corresponding test scripts are generated, wherein the test scripts include at least one of the following: interface test scripts, state transition test scripts, and data verification test scripts.

4. The method according to claim 1, characterized in that, The step of diagnosing the log data in conjunction with the technical documentation to generate a diagnostic report includes: The log data is subjected to anomaly feature extraction, and the extracted anomaly features are matched with a predefined error pattern library to determine the error type corresponding to the anomaly features; Based on the error type and the call chain information and data flow information corresponding to the log data, locate the location of the exception code and the cause of the exception, and generate root cause information; A corresponding diagnostic report is generated based on the root cause information, wherein the diagnostic report includes at least the error type, root cause information, and the scope of the abnormal impact.

5. The method according to claim 1, characterized in that, The step of generating a remediation plan for the software code corresponding to the software development requirements based on the diagnostic report, and conducting a code review of the remediation plan, includes: Based on the diagnostic report, determine the software code modification area corresponding to the software code; Based on the software context information and code dependency information corresponding to the software code modification area, a corresponding repair solution is generated, wherein the repair solution includes at least one of the following: code modification content and interface call adjustment content; The code review of the repair solution is performed based on preset code review rules to determine the code review result corresponding to the repair solution. The code review rules include at least one of the following: code security rules, code style rules, and interface compatibility rules.

6. The method according to claim 1, characterized in that, The method further includes: If the classification result is a known fault class, retrieve the historical repair records corresponding to the software development requirements from the multi-source knowledge base, and determine the corresponding target repair strategy based on the historical repair records; The software code is repaired based on the target repair strategy; If the classification result is a new functional class, determine the target functional requirements corresponding to the software development requirements, and generate corresponding functional test cases based on the target functional requirements; Based on the functional test cases, corresponding software functional code is generated, and the software functional code is subjected to functional verification processing.

7. The method according to claim 1, characterized in that, The method further includes: If the classification result is in the performance optimization category, collect the performance index data corresponding to the software code, and determine the corresponding performance bottleneck location based on the performance index data; generate the corresponding performance optimization plan based on the performance bottleneck location, and optimize the software code based on the performance optimization plan; If the classification result is a refactoring class, the design documents and migration guidelines of the target architecture are retrieved from the multi-source knowledge base to generate a behavior consistency test script; The software code is refactored for security based on the behavior consistency test script, and the refactored software code is reviewed. After the review is passed, it is stored in the project code library. If the classification result is a security vulnerability, the software code is subjected to a security scan to obtain vulnerability detection results; Based on the vulnerability detection results, the corresponding vulnerability type and the scope of vulnerability impact are determined, and a corresponding security remediation plan is generated based on the vulnerability type and the scope of vulnerability impact. The software code is repaired according to the security repair plan.

8. A software development requirements processing device, characterized in that, include: The classification module is used to classify the software development requirements when they are obtained, and select the corresponding differentiated execution process based on the classification results. The retrieval module is used to retrieve reference materials related to the software development requirements from a multi-source knowledge base according to a differentiated execution process when the classification result is an unknown fault class, and to generate technical documents and test scripts using the reference materials; The generation module is used to execute the test script and collect the generated log data, and to diagnose the log data in conjunction with the technical documentation in order to generate a diagnostic report; The review module is used to generate a repair plan for the software code corresponding to the software development requirements based on the diagnostic report, and to review the code of the repair plan; The repair module is used to repair the software code based on the repair plan approved in the case that the code review has passed.

9. A computer device, characterized in that, include: A processor and a memory, the processor being configured to execute a software development requirements processing program stored in the memory to implement the software development requirements processing method according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the software development requirements processing method according to any one of claims 1 to 7.

Images