Software automatic generation methods, apparatus, equipment, storage media and program products

Abstract

This application provides a method, apparatus, device, storage medium, and program product for automatic software generation, relating to the fields of artificial intelligence and fintech. The method includes: obtaining task requirements; splitting and generating sub-tasks based on the task requirements; generating corresponding acceptance test cases for each sub-task; inputting the sub-tasks and acceptance test cases into a code generation agent to generate initial business code; executing the acceptance test cases to verify the initial business code; if verification fails, adjusting the generation strategy of the code generation agent based on the verification failure result to generate adjusted business code, until all acceptance test cases pass verification, obtaining the target business code. This method solves the problem of test and coding separation in existing technologies through a two-level closed-loop mechanism, dynamically optimizing the generation logic, reducing redundant attempts, shortening the iteration cycle, significantly improving the accuracy of code generation, and ensuring code quality through automated closed-loop verification.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and financial technology, and in particular to a software automatic generation method, apparatus, device, storage medium and program product. Background Technology

[0002] In enterprise software development, financial system function iteration, and automated testing, development teams typically need to design and implement systems based on business requirements. Traditional development processes involve manually breaking down requirements into sub-tasks, writing code, and creating acceptance test cases, then manually executing these tests to verify the correctness of the code logic. However, as software system complexity increases, the efficiency of manually breaking down requirements, writing test cases, and debugging code becomes a bottleneck, especially in fields like finance where system stability and security are paramount. Developers often need to repeatedly modify code to meet test case constraints, leading to long development cycles and high costs.

[0003] While existing test-driven development (TDD) methods use test cases to drive code writing, they largely rely on manual operations and lack automated closed-loop processes for test case generation, code optimization, and acceptance testing. This results in a disconnect between the testing and coding processes, making it difficult to form a complete quality assurance chain from requirements to acceptance. Therefore, the lack of an automated code generation mechanism with test cases as constraints leads to low development efficiency and a high risk of errors. Summary of the Invention

[0004] This application provides a method, apparatus, device, storage medium, and product for automatically generating software, in order to solve the technical problem that the lack of an automated code generation mechanism with test cases as constraints in the prior art leads to low development efficiency and easy errors.

[0005] In a first aspect, this application provides a method for automatically generating software, comprising:

[0006] Obtain task requirements, break them down into subtasks based on the requirements, and generate corresponding acceptance test cases for each subtask.

[0007] Input subtasks and acceptance test cases into the code to generate an intelligent agent and generate initial business code;

[0008] Execute acceptance test cases to verify the initial business code. If the verification fails, adjust the generation strategy of the code generation agent based on the verification failure result to generate the adjusted business code. Continue until all acceptance test cases pass the verification to obtain the target business code.

[0009] Secondly, this application provides a software automatic generation apparatus, comprising:

[0010] The module is used to obtain task requirements, split them into subtasks based on the task requirements, and generate corresponding acceptance test cases for each subtask.

[0011] The generation module is used to input subtasks and acceptance test cases into the code to generate an intelligent agent and generate the initial business code.

[0012] The verification module is used to execute acceptance test cases to verify the initial business code. If the verification fails, the generation strategy of the code generation agent is adjusted based on the verification failure result to generate the adjusted business code until all acceptance test cases pass the verification and the target business code is obtained.

[0013] Thirdly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor;

[0014] The memory stores instructions that the computer executes;

[0015] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0016] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method of any one of the first aspects.

[0017] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0018] The software automatic generation method, apparatus, device, storage medium, and program product provided in this application solve the problem of separation between testing and coding in existing technologies through a two-level closed-loop mechanism. During the code generation phase, acceptance test cases serve as mandatory constraints to ensure that the code logic is consistent with test expectations, avoiding the subjectivity and omission risks of manual debugging. If an acceptance test case discovers an error in the account balance calculation logic, it is automatically fed back to the code generation agent, generating corrected code. A strategy adjustment mechanism after verification failure enables the code generation agent to dynamically optimize the generation logic, reducing redundant attempts and shortening the iteration cycle. By deeply binding test cases with code generation, the accuracy of code generation is significantly improved, while automated closed-loop verification ensures code quality, forming a complete quality assurance chain from requirements to functionality. Attached Figure Description

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

[0020] Figure 1This is a schematic diagram of a software development plan;

[0021] Figure 2 A flowchart illustrating an automatic software generation method provided in an embodiment of this application;

[0022] Figure 3 A schematic diagram of a unit test forced optimization loop provided in an embodiment of this application;

[0023] Figure 4 A schematic diagram illustrating a task requirement-level acceptance verification provided in an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of the structure of a software automatic generation device provided in an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0026] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0029] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0030] It should be noted that the software automatic generation method, apparatus, device, storage medium and program product provided in this application can be used in the fields of artificial intelligence and financial technology, as well as in any field other than artificial intelligence and financial technology. The application fields of the software automatic generation method, apparatus, device, storage medium and program product in this application are not limited.

[0031] The specific application scenarios of this application are mainly in the fields of enterprise-level software development, financial system function iteration, and automated testing. In actual software development scenarios, development teams typically need to design and implement systems based on business requirements (such as task requirements or functional requirement documents). In the traditional development process, developers need to manually break down requirements into sub-tasks, then write code and corresponding acceptance test cases, and manually execute tests to verify the correctness of the code logic. However, as the complexity of software systems increases, the efficiency of manually breaking down requirements, writing test cases, and debugging code has gradually become a bottleneck, especially in fields such as finance and healthcare where the requirements for system stability and security are extremely high. Developers need to repeatedly modify code to meet the constraints of test cases, resulting in long development cycles and high costs.

[0032] Figure 1 A schematic diagram of a software development solution, such as... Figure 1 As shown, existing software development technologies primarily rely on the following two approaches: 1. Task-description-based code generation: Developers generate initial code based on requirements documents or task descriptions, using code generation tools. Acceptance test cases are then manually written and executed. If a test fails, the problem is manually analyzed and the code modified, repeating the debugging process until the test passes. 2. Test-driven development: This approach emphasizes acceptance test cases as the driving force, writing test cases before writing code, and verifying the code logic through test results.

[0033] While existing test-driven development (TDD) methodologies emphasize test case-driven code writing, they largely rely on manual operations and lack automated closed-loop processes for test case generation, code optimization, and acceptance testing. This results in a disconnect between the testing and coding processes, making it difficult to form a complete quality assurance chain from requirements to acceptance. Furthermore, the lack of large-scale modeling techniques for automation, coupled with the absence of closed-loop mechanisms for acceptance test case execution and feedback, leads to a separation of testing and coding in the development process, hindering the formation of a complete verification chain from requirements to acceptance.

[0034] Therefore, existing software development methods have the following shortcomings: Acceptance test cases and their writing require significant manual intervention, resulting in low efficiency and a high risk of overlooking key test scenarios; test case generation relies on manual processes. The code generation and testing verification processes lack a closed loop, requiring manual intervention for code optimization after test failures, limiting iteration efficiency and lacking an automated closed loop. Existing solutions do not integrate the automated execution of acceptance test cases with the code optimization process, leading to a disconnect between requirement-level verification and task-level verification, making it difficult to guarantee the integrity of the final functionality; acceptance testing is not effectively integrated.

[0035] The software automatic generation method, apparatus, device, storage medium, and program product provided in this application decompose user requirements into multiple sub-tasks through a requirements decomposition step, and generate corresponding acceptance test cases for each sub-task as constraints for code generation. The code generation agent takes the sub-task description and acceptance test cases as input to generate initial business code. The acceptance test cases are executed to verify the correctness of the code logic: if verification fails, the code generation agent's strategy is dynamically adjusted, the code is regenerated, and this process is repeated until all acceptance test cases pass verification, forming a task-level closed-loop verification. This aims to solve the aforementioned technical problems of existing technologies.

[0036] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0037] Figure 2 This is a flowchart illustrating a software automatic generation method provided in an embodiment of this application, such as... Figure 2 As shown, the method includes:

[0038] S201. Obtain task requirements, break down and generate sub-tasks based on task requirements, and generate corresponding acceptance test cases for each sub-task.

[0039] In one example, the task requirements are obtained, broken down into multiple specific development subtasks, and corresponding acceptance test cases are generated for each subtask. For example, the "user login function" is split into two subtasks: "verify user credentials" and "generate session tokens." The acceptance test cases are technical descriptions of the input conditions and expected output combinations used to verify the logical correctness of the business code, such as "input parameter X, expected output Y."

[0040] S202. Input the sub-tasks and acceptance test cases into the code to generate the intelligent agent and generate the initial business code.

[0041] In one example, the code generation agent is an automated code generation module based on an artificial intelligence model. The input includes subtask descriptions and acceptance test cases, and the output is executable business code.

[0042] S203. Execute acceptance test cases to verify the initial business code. If the verification fails, adjust the generation strategy of the code generation agent based on the verification failure result to generate the adjusted business code until all acceptance test cases pass the verification and the target business code is obtained.

[0043] In one example, if the initial business code output is inconsistent with the expected output after executing acceptance test cases, the initial business code verification is determined to have failed. Based on the verification failure result, the cause of the failure is analyzed (such as logical errors or uncovered boundary conditions), and the failed business code is used as feedback input to the code generation agent. The code generation strategy of the code generation agent is dynamically adjusted (such as modifying the code structure or adding logic), and the adjusted business code is regenerated. This process is repeated until all acceptance test cases pass verification. The final generated target business code satisfies the functional requirements of the subtask and passes the constraints of the acceptance test cases, forming a task-level closed-loop verification.

[0044] In one implementation scenario, a multi-level closed-loop code generation and acceptance method is provided to solve the problem of separation of testing and coding, so as to achieve the following objectives: (1) automatic conversion of requirements → subtasks → acceptance test cases; (2) code iteration optimization driven by acceptance test cases and acceptance test cases as mandatory constraints; (3) completion of dual automated verification at the task level and requirement level. According to the task requirements, complete acceptance test cases are generated. The task requirements (task requirements and acceptance test cases) are broken down into subtasks with smaller granularity, and corresponding acceptance test cases are automatically generated for the subtasks. The descriptions of the acceptance test cases and subtasks are used as prompt words and provided to the code generation agent to generate the initial business code corresponding to the subtasks. The acceptance test cases are executed to verify the correctness of the generated initial business code. When the verification fails, the code generation agent is prompted to optimize the code again according to the acceptance test cases. Through continuous testing verification and code optimization, the target business code that meets all the verifications of the acceptance test cases is finally generated. After the subtasks are coded, the target business code corresponding to each subtask is assembled into the required function. The required function is then accepted by acceptance test cases. If the requirements are not met, iterative optimization is carried out again. The final result is based on the acceptance test cases passing.

[0045] Specifically, a software generation method driven by requirements and their test cases may include: 1. Step 1: Unit test-driven model construction: Based on a knowledge base of the mapping relationship between unit-level acceptance test cases and code, as well as the mapping relationship between subtasks and code, fine-tune the training code generation model so that the code generation model can generate corresponding business code according to unit-level acceptance test cases and subtasks.

[0046] 2. Step Two: Building the Acceptance Script Generation Model: Based on the knowledge base of the mapping relationship between acceptance test cases and acceptance scripts, fine-tune the training script generation model so that the model can generate automated acceptance scripts based on acceptance test cases.

[0047] 3. Step Three: Task Requirements Decomposition: Analyze the action steps of the task requirements, use the large model to decompose the task requirements into multiple specific original steps, and the original steps correspond to the sub-tasks of atomic development. Review, supplement and adjust the sub-tasks to ensure the integrity and executability of the decomposed sub-tasks.

[0048] 4. Step Four: Subtask-level Unit Test Generation: For each atomic subtask, automatically generate unit-level acceptance test cases that cover that subtask. For example, manual review and supplementation may also be included to ensure that the unit-level acceptance test cases guarantee coverage.

[0049] 5. Step Five: Agent-Driven Code Generation: The descriptions of the atomized subtasks and their corresponding acceptance test cases are used as joint input prompts to generate an agent and generate the initial business code.

[0050] 6. Step Six: Force Optimization Loop Closure Through Unit Testing: Figure 3 A diagram illustrating the forced optimization loop for unit tests, as shown below. Figure 3 As shown, acceptance test cases are executed to verify the initial business code. If the test fails, the failed case and its error analysis reason are fed back as a mandatory instruction to the code generation agent, driving it to regenerate the adjusted business code. This process is repeated until all unit-level acceptance test cases pass verification. For example, it is necessary to set the number of loops to reopen a new dialogue to avoid the context becoming too long; and to set the number of loops requiring manual intervention to prevent entering an infinite loop.

[0051] 7. Step Seven: Task Requirement-Level Acceptance Closure: Assemble all subtask code to form complete requirement code, connect the subtask transmission relationships and find the entry point of the automated script; manually adjust the automated acceptance script generated in Step Two based on the entry point, and perform overall verification; if acceptance fails, locate the defects through manual analysis (supplement and modify subtasks / acceptance scripts / code, etc.), and selectively perform iterative optimization of Steps Four to Six based on the modifications. For example, if subtasks are modified, Steps Four to Six need to be executed; if only unit tests are modified, Steps Six to Seven are executed; if only the acceptance script is modified, Step Seven is executed. Figure 4 This application provides a schematic diagram of a task requirement-level acceptance verification method, as shown in the embodiment. Figure 4 As shown, the verification object for task requirement-level acceptance verification includes: the assembled complete requirement code (composed of all task code). Triggering conditions include: automatic triggering after all atomic tasks pass unit test verification. The verification process includes: executing the automated acceptance script generated in step two (automatically generated based on acceptance test cases), and the system checking the acceptance results.

[0052] In another implementation scenario, the automatic software generation method may include: Step 1: Unit Test-Driven Model Construction: Based on the knowledge base of the mapping relationship between acceptance test cases and code, and the knowledge base of the mapping relationship between subtasks and code, a unit test-driven model is constructed. Specifically, this includes: fine-tuning and training the code generation agent based on the above knowledge bases, enabling it to generate corresponding business code according to the acceptance test cases and subtask descriptions. For example, in the development of a financial system, if the subtask description is "verify whether the user's account balance is sufficient", the model needs to generate the corresponding code logic based on the acceptance test case "input balance 1000, request amount 500, expected output balance 500". The fine-tuned code generation agent is generated, capable of generating compliant business code based on the acceptance test cases and subtask descriptions. The acceptance test case is a combination of input conditions and expected outputs used to verify the correctness of the code logic, such as "input parameter X, expected output Y". The subtask is an atomic development task after requirement decomposition, such as "implement user login function". The code generation agent is an automated code generation module based on an artificial intelligence model. By fine-tuning the training, the code generation agent learns the mapping relationship between acceptance test cases and code, thereby automatically satisfying test constraints when generating code and improving the accuracy of code generation.

[0053] Step 2: Acceptance Script Generation Model Construction: Based on a knowledge base mapping acceptance test cases and acceptance scripts, an acceptance script generation model is constructed. Specifically, this includes fine-tuning the script generation model using this knowledge base to enable it to generate automated acceptance scripts based on acceptance test cases. For example, in a bank account balance query function, if the acceptance test case is described as "User A should return the correct result when querying the balance during concurrent access," the model needs to generate a corresponding automated script to simulate the concurrent access scenario. A fine-tuned script generation model is generated, capable of generating automated acceptance business code based on acceptance test cases. Here, acceptance test cases are descriptions of test scenarios used to verify the completeness of requirement-level functions, such as "User A should return the correct result when querying the balance during concurrent access." Acceptance scripts are the script code that automatically executes the acceptance test cases. Through fine-tuning, the script generation model learns the mapping relationship between acceptance test cases and scripts, thereby generating automated scripts that can cover requirement-level verification scenarios, improving the efficiency and comprehensiveness of acceptance testing.

[0054] Based on task requirements, subtasks are broken down, and acceptance test cases are automatically generated for each subtask. A finely tuned code generation agent generates initial business code, and the correctness of the code is verified using acceptance test cases. If verification fails, the failure cases and error analysis are fed back to the code generation agent, driving it to regenerate the adjusted business code until all acceptance test cases pass verification. After completing the subtask code, all code is assembled to form the requirement-level functionality, and an automated acceptance script is generated using a finely tuned script generation model. After executing the acceptance test cases, if acceptance fails, the system will locate the defects and selectively trigger iterative optimizations at the subtask level (such as modifying subtasks, acceptance test cases, or code) to ultimately ensure that the required functionality passes acceptance testing.

[0055] In another implementation scenario, a dynamic knowledge base update mechanism is introduced during the fine-tuning training of the code generation agent and script generation model. By collecting data in real-time, including sub-tasks after task requirement breakdown, unit-level acceptance test case execution results, and acceptance test case feedback, the model's training knowledge base is dynamically updated. This allows the model to continuously learn the mapping relationship between the latest generated test cases and code. Incremental training includes dynamically integrating newly generated test case and code pairs through incremental learning algorithms (such as online learning or transfer learning) during the model fine-tuning training phase to update model parameters. Feedback-driven updates include using failed unit tests or acceptance tests and their corresponding error analysis results as new training data to trigger local parameter updates in the model.

[0056] By dynamically updating the knowledge base, the model can adapt to constantly changing requirements and testing scenarios, avoiding model obsolescence issues caused by a static knowledge base, thus enhancing model adaptability. When generating code, the model can adjust its generation strategy based on the latest test cases and error feedback, reducing code defects caused by historical data bias and improving code generation accuracy. The dynamic update mechanism reduces the frequency of manual intervention, enabling the model to quickly adjust its generation logic after test failures, shortening the code iteration cycle and improving closed-loop optimization efficiency.

[0057] In another implementation scenario, a multimodal input mechanism is introduced during the subtask-level acceptance test case generation phase. This mechanism combines task requirements described in natural language, code structure information (such as function call relationships and variable types), and historical test case data to generate more comprehensive acceptance test cases. Multimodal feature fusion includes using a multimodal learning model to extract joint features from the task requirement text, code structure graph, and historical test cases to generate more comprehensive test scenarios. Context-aware generation includes analyzing critical paths and potential boundary conditions in the code logic to supplement and generate test cases for abnormal scenarios (such as input parameter out-of-bounds errors, concurrent access conflicts, etc.).

[0058] The multimodal input mechanism captures implicit requirements in task specifications and code logic, generating test cases that cover both normal processes and abnormal scenarios, thus improving test case coverage. By combining code structure information, the generated test cases can accurately locate key logic points in the code, reducing code defects caused by testing blind spots and enhancing defect localization capabilities. This significantly reduces the workload of manual test case review, allowing developers to quickly confirm the completeness of test cases, accelerating the development process and optimizing development efficiency.

[0059] In another implementation scenario, a multi-stage generation strategy is introduced during the code generation phase, dividing the code generation process into three stages: framework generation, detail filling, and logic verification. Each stage is iteratively optimized based on different test case constraints. The framework generation stage includes generating a code framework (such as function structures and variable definitions) based on subtask descriptions and the input / output constraints of unit-level acceptance test cases. The detail filling stage includes filling in the specific implementation logic based on the framework and the intermediate state constraints of unit-level acceptance test cases (such as the expected values ​​of variables within functions). The logic verification stage includes verifying the correctness of the code logic by dynamically executing unit-level acceptance test cases and adjusting the detail filling strategy based on failure feedback.

[0060] A phased generation strategy ensures a high degree of alignment between the code framework and test case constraints, reducing test failures caused by structural design errors and improving code structure rationality. Verification of intermediate state constraints allows for the discovery of potential problems within the code's internal logic, rather than relying solely on the final output, increasing the depth of logic verification. Multi-stage generation reduces redundant code generation attempts, allowing the optimization process to focus more on key logic points, shortening overall development time, and improving optimization efficiency.

[0061] In another implementation scenario, causal reasoning analysis is introduced into the unit test failure feedback mechanism. By analyzing the root causes of test failures (such as code logic errors, test case design flaws, or model generation deviations), the code generation strategy or test case generation rules are dynamically adjusted. Causal graph modeling includes constructing a causal graph between test failures and code generation logic / test case design, identifying key factors leading to failure. Feedback-driven rule updates include automatically updating the training rules of the code generation model (e.g., adding specific constraints) or adjusting the test case generation strategy (e.g., supplementing boundary condition tests) based on the causal analysis results.

[0062] Causal reasoning can distinguish the true causes of test failures, avoiding ineffective code optimizations due to misjudgments and improving feedback accuracy. By specifically adjusting training rules, the model can avoid known generation biases, improving code generation stability and enhancing model robustness. Causal analysis results can guide adjustments to test case generation strategies, ensuring that generated test cases cover potential defect scenarios and improving test case effectiveness.

[0063] In another implementation scenario, a dynamic dependency analysis mechanism is introduced during the acceptance script generation phase. By parsing the code dependencies of the requirements-level functions, the execution order and script logic of acceptance test cases are automatically adjusted to ensure the comprehensiveness and executability of the acceptance tests. Dependency graph construction includes: building a dependency graph of acceptance test cases based on module call relationships and data flow in the code, and identifying the preconditions and execution order between test cases. Dynamic script generation includes: dynamically adjusting the execution logic of the acceptance scripts according to the dependency graph; for example, in concurrent testing scenarios, prioritizing the execution of precondition test cases to avoid test failures due to incorrect execution order.

[0064] Dependency analysis ensures that the execution order of acceptance test cases aligns with the code logic, reducing false positives due to incorrect execution order and improving the reliability of acceptance tests. Dynamically adjusting script logic can cover potential issues in code dependencies (such as uninitialized data, resource contention, etc.), enhancing test scenario coverage. Automated dependency analysis reduces the workload of manually adjusting acceptance scripts, shortens the execution time of requirement-level verification, and improves acceptance efficiency.

[0065] The software automatic generation method provided in this embodiment solves the problem of separation between testing and coding in existing technologies through a two-level closed-loop mechanism. During the code generation phase, acceptance test cases serve as mandatory constraints to ensure that the code logic is consistent with test expectations, avoiding the subjectivity and omission risks of manual debugging. If an acceptance test case discovers an error in the account balance calculation logic, it is automatically fed back to the code generation agent, generating corrected code. A strategy adjustment mechanism after verification failure enables the code generation agent to dynamically optimize the generation logic, reducing redundant attempts and shortening the iteration cycle. By deeply binding test cases with code generation, the accuracy of code generation is significantly improved, while automated closed-loop verification ensures code quality, forming a complete quality assurance chain from requirements to functionality.

[0066] Optionally, the generation strategy of the code generation agent can be adjusted based on the verification failure result to generate the adjusted business code, including: adjusting the generation strategy of the code generation agent according to the verification failure result corresponding to the acceptance test case; and using the adjusted code generation agent to generate the adjusted business code.

[0067] In one example, when verification fails, the specific error information of the failed case is analyzed, and the failure result is fed back to the code generation agent. The code generation agent adjusts its generation strategy based on the failure result and regenerates the business code. This process is repeated until all unit-level acceptance test cases pass verification. The verification failure result is the specific error information indicating that the business code output is inconsistent with the expected output after executing the unit-level acceptance test cases, such as "function return value does not match expectation." Adjustments to the generation strategy can include dynamically modifying the generation logic of the code generation agent based on the error analysis results of the failed cases, such as adjusting model input prompts or optimizing the code structure.

[0068] By dynamically adjusting the code generation strategy through a failure feedback mechanism, the code generation agent can optimize the generation logic in a targeted manner. In financial system development, if an acceptance test case finds an error in the account balance calculation logic, this error is fed back to the code generation agent, which then generates corrected code. This shortens the code iteration cycle, reduces the need for manual debugging, and improves the accuracy and efficiency of code generation.

[0069] Optionally, the subtasks and acceptance test cases are input into the code generation agent to generate initial business code, including: based on a dynamic knowledge base update mechanism, real-time integration of the execution results of the subtasks after the task requirements are split, the acceptance test cases corresponding to the subtasks, and the feedback data of the acceptance test cases, and updating the training parameters of the code generation agent.

[0070] In one example, when generating initial business code, the code generation agent integrates in real-time the sub-tasks derived from the task requirements, the execution results of unit-level acceptance test cases, and the feedback data from those test cases. This dynamically updates the model's training parameters, enabling the model to adapt to the mapping between the newly generated test cases and the code. For instance, when developing a bank account balance query function, if a new test case for a concurrent access scenario is added, the model will quickly adapt to the new requirement through incremental learning, generating code logic that supports concurrent processing. The dynamic knowledge base update mechanism includes a technical process of integrating new data and updating model parameters in real-time through incremental learning algorithms (such as online learning or transfer learning). Training parameters may include model parameters used internally by the code generation agent to generate code, such as weight matrices or attention mechanism parameters.

[0071] The adaptability of the code generation agent is enhanced through a dynamic knowledge base update mechanism. When requirements change or test cases expand, the code generation agent can learn new data in real time and adjust its generation strategy, avoiding the problem of model obsolescence caused by static knowledge base, thereby improving the accuracy and robustness of code generation.

[0072] Optionally, corresponding acceptance test cases can be generated for each subtask, including: combining task requirements, code structure information and historical test case data to generate acceptance test cases for each subtask, with acceptance test cases covering normal processes and abnormal scenarios.

[0073] In one example, a multimodal input mechanism is used to generate unit-level acceptance test cases covering both normal processes and abnormal scenarios, combining task requirement text, code structure information, and historical test case data. For instance, when developing a bank account balance query function, the system not only generates a normal test case of "entering a balance of 1000 and requesting an amount of 500," but also generates abnormal scenario test cases such as "entering a negative amount" and "concurrency access conflict" based on code structure analysis. The code structure information includes structural descriptions such as module call relationships and variable types, for example, "function A calls function B." Abnormal scenarios include abnormal inputs or boundary conditions that may be triggered during code execution, such as "entering a negative amount."

[0074] Enhance the coverage of acceptance test cases through a multimodal input mechanism. During development, capture implicit requirements in task requirements and code logic to generate test cases that cover boundary conditions and abnormal scenarios, reducing code defects caused by test blind spots, thereby enhancing the depth of code verification and quality assurance capabilities.

[0075] Optionally, the process of inputting subtasks and acceptance test cases into code to generate an intelligent agent and generate initial business code further includes: generating an intelligent agent based on the description of the subtasks and the input / output constraints of the acceptance test cases to generate the code structure of the initial business code; supplementing the logic of the initial business code by combining the intermediate state constraints of the acceptance test cases; verifying the correctness of the logic of the initial business code by dynamically executing the acceptance test cases, and iteratively optimizing based on failure feedback.

[0076] In one example, the code generation process is broken down into three stages: framework generation, detail filling, and logic verification. The framework generation stage generates the code structure based on the description of subtasks and the input / output constraints of unit-level acceptance test cases. The detail filling stage supplements the specific logic by incorporating intermediate state constraints from unit-level acceptance test cases. The logic verification stage verifies the correctness of the code logic by dynamically executing acceptance test cases and adjusts the detail filling strategy based on failure feedback. Intermediate state constraints are the expected descriptions of the states of variables or functions within the code in unit-level acceptance test cases, such as "the value of variable X should be Y after function execution." Logic verification includes the technical process of verifying the correctness of the internal logic of the code through dynamic execution of test cases.

[0077] A phased generation strategy ensures both reasonable code structure and in-depth logic verification. The framework generation phase prioritizes defining function structures and variable types; the detail filling phase generates specific logic based on intermediate state constraints; and the logic verification phase discovers potential problems within the code's internal logic through dynamic test case execution, thereby improving the efficiency and quality of code generation.

[0078] Optionally, adjusting the generation strategy of the code generation agent based on the verification failure results further includes: analyzing the verification failure results to obtain the reasons for the verification failure; dynamically updating the training rules of the code generation agent based on the reasons for the verification failure; and / or adjusting the generation strategy of acceptance test cases.

[0079] In one example, causal reasoning analysis is used to analyze the root causes of test failures (such as code logic errors, test case design flaws, or model generation biases), and the training rules of the code generation agent are dynamically updated (e.g., adding specific constraints) or the test case generation strategy is adjusted (e.g., supplementing boundary condition tests) based on the analysis results. Causal reasoning analysis is the technical process of identifying key factors leading to failure by constructing a causal graph between test failures and code generation logic and test case design.

[0080] Improve feedback accuracy through causal reasoning analysis. When verification fails, it can distinguish the true cause of the failure, avoid invalid code optimizations due to misjudgment, and thus improve the robustness of the code generation agent and the effectiveness of test cases.

[0081] Optionally, the method also includes: based on a dynamic dependency analysis mechanism, parsing the code dependencies of the requirements-level functions and constructing a dependency graph for acceptance test cases; and adjusting the execution order and script logic of the acceptance test cases according to the dependency graph.

[0082] In one example, a dynamic dependency analysis mechanism is used to parse the code dependencies of requirement-level functions, construct a dependency graph for acceptance test cases, and dynamically adjust the execution order and script logic of the acceptance test cases based on the dependency graph. For instance, in a concurrent testing scenario, the system will prioritize executing precondition test cases to avoid test failures due to incorrect execution order. The dynamic dependency analysis mechanism is the technical process of constructing a test case dependency graph by parsing code module call relationships and data flows.

[0083] In another example, after the dynamic knowledge base is updated, a multi-stage code generation strategy (framework generation, detail filling, and logic verification) is combined with a causal reasoning feedback mechanism to form a two-level closed-loop verification process. For example, in requirement-level acceptance testing, if the test fails, the system will trigger sub-task-level optimization, and simultaneously locate the root cause of the defect through causal reasoning analysis, dynamically adjusting the code generation strategy or test case generation rules. The two-level closed-loop verification process is a joint verification mechanism for task-level unit testing and requirement-level acceptance testing.

[0084] By integrating multi-stage generation strategies with causal reasoning feedback mechanisms, a complete two-level closed-loop verification process is formed. For example, the system can achieve fully automated verification from task-level unit testing to requirement-level acceptance testing, significantly improving development efficiency and code quality, and ensuring that the final functionality meets business requirements.

[0085] Dynamic dependency analysis improves the reliability of verification tests, ensuring that the execution order of test cases is consistent with the code logic, reducing test misjudgments caused by incorrect execution order, and thus improving the comprehensiveness and executability of verification tests.

[0086] Figure 5 This is a schematic diagram of the structure of a software automatic generation device provided in an embodiment of this application, such as... Figure 5 As shown, the software automatic generation device 50 provided in this embodiment includes:

[0087] The splitting module 501 is used to obtain task requirements, split and generate sub-tasks based on task requirements, and generate corresponding acceptance test cases for each sub-task.

[0088] The generation module 502 is used to input subtasks and acceptance test cases into the code to generate an intelligent agent and generate initial business code.

[0089] The verification module 503 is used to execute acceptance test cases to verify the initial business code. If the verification fails, the generation strategy of the code generation agent is adjusted based on the verification failure result to generate the adjusted business code until all acceptance test cases pass the verification and the target business code is obtained.

[0090] In one possible implementation, the verification module 503 is specifically used to: adjust the generation strategy of the code generation agent based on the verification failure result corresponding to the acceptance test case; and use the adjusted code generation agent to generate the adjusted business code.

[0091] In one possible implementation, the generation module 502 is specifically used to: based on the dynamic knowledge base update mechanism, integrate in real time the execution results of the subtasks after the task requirements are split, the acceptance test cases corresponding to the subtasks, and the feedback data of the acceptance test cases, and update the training parameters of the code generation agent.

[0092] In one possible implementation, module 501 is split into modules that are specifically used to: combine task requirements, code structure information and historical test case data to generate acceptance test cases for each subtask, with the acceptance test cases covering normal processes and abnormal scenarios.

[0093] In one possible implementation, the generation module 502 is further specifically used to: generate an input code generation agent based on the description of the subtask and the input / output constraints of the acceptance test case, and generate the code structure of the initial business code; supplement the logic of the initial business code by combining the intermediate state constraints of the acceptance test case; verify the correctness of the logic of the initial business code by dynamically executing the acceptance test case, and perform iterative optimization based on failure feedback.

[0094] In one possible implementation, the verification module 503 is further specifically used to: analyze the verification failure results to obtain the reasons for the verification failure; dynamically update the training rules of the code generation agent based on the reasons for the verification failure; and / or adjust the generation strategy of acceptance test cases.

[0095] In one possible implementation, the software automatic generation device is also specifically used to: parse the code dependencies of requirement-level functions based on a dynamic dependency analysis mechanism, and construct a dependency graph of acceptance test cases; and adjust the execution order and script logic of the acceptance test cases according to the dependency graph.

[0096] The software automatic generation device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0097] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 60 may include a memory 601 and a processor 602. Optionally, the electronic device may also include a transceiver 603, wherein the memory 601 and the processor 602 communicate; for example, the memory 601, the processor 602 and the transceiver 603 may communicate via a communication bus 604, the memory 601 is used to store a computer program, and the processor 602 executes the computer program to implement the method of the above embodiments.

[0098] Optionally, the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps in the method embodiments disclosed in this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0099] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the methods in any of the above method embodiments.

[0100] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods in any of the above method embodiments.

[0101] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

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

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

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

[0105] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

[0106] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0107] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0108] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0109] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0110] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0111] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0112] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0113] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0114] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0115] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A software-automatic generation method, characterized in that, The method includes: Obtain the task requirements, break them down into subtasks based on the task requirements, and generate corresponding acceptance test cases for each subtask. Input the subtasks and the acceptance test cases into the code to generate an intelligent agent and generate the initial business code; The acceptance test cases are executed to verify the initial business code. If the verification fails, the generation strategy of the code generation agent is adjusted based on the verification failure result to generate the adjusted business code. This process continues until all the acceptance test cases pass the verification, and the target business code is obtained.

2. The method according to claim 1, characterized in that, The adjustment of the code generation strategy of the code generation agent based on the verification failure result, and the generation of adjusted business code, includes: Based on the verification failure results corresponding to the acceptance test cases, adjust the generation strategy of the code generation agent; The adjusted code is used to generate an intelligent agent, which in turn generates the adjusted business code.

3. The method according to claim 1, characterized in that, The step of inputting the subtasks and the acceptance test cases into the code to generate an intelligent agent and generate initial business code includes: Based on the dynamic knowledge base update mechanism, the execution results of the sub-tasks after the task requirements are broken down, the corresponding acceptance test cases, and the acceptance test case feedback data are integrated in real time to update the training parameters of the code generation agent.

4. The method according to claim 1, characterized in that, The generation of corresponding acceptance test cases for each of the sub-tasks includes: Based on the task requirements, code structure information, and historical test case data, acceptance test cases are generated for each subtask, covering both normal processes and abnormal scenarios.

5. The method according to claim 3, characterized in that, The step of inputting the subtask and the acceptance test case into the code to generate an intelligent agent and generate initial business code further includes: Based on the description of the sub-task and the input / output constraints of the acceptance test case, the code generation agent is input to generate the code structure of the initial business code; Based on the intermediate state constraints of the acceptance test cases, the logic of the initial business code is supplemented. By dynamically executing the acceptance test cases, the correctness of the logic of the initial business code is verified, and iterative optimization is performed based on failure feedback.

6. The method according to claim 2, characterized in that, The adjustment of the code generation strategy based on the verification failure result also includes: The reasons for the verification failures are analyzed. Based on the reasons for the verification failure, the training rules for the code generation agent are dynamically updated, and / or the generation strategy for the acceptance test cases is adjusted.

7. The method according to claim 1, characterized in that, The method further includes: Based on the dynamic dependency analysis mechanism, the code dependency relationships of the requirement-level functions are parsed, and the dependency graph of the acceptance test case is constructed. Based on the dependency graph, the execution order and script logic of the acceptance test cases are adjusted.

8. A software automatic generation device, characterized in that, The device includes: The splitting module is used to obtain task requirements, split and generate sub-tasks according to the task requirements, and generate corresponding acceptance test cases for each sub-task. The generation module is used to input the subtasks and the acceptance test cases into the code to generate an intelligent agent and generate the initial business code; The verification module is used to execute the acceptance test cases to verify the initial business code. If the verification fails, the generation strategy of the code generation agent is adjusted based on the verification failure result to generate the adjusted business code until all the acceptance test cases pass the verification and the target business code is obtained.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images