A software requirement verification method, device, equipment and storage medium

Abstract

The application discloses a software requirement verification method, device and equipment and a storage medium, and comprises the following steps: binding a simulation test network topology created by a user with a software installation package; capturing operation events of the user for the software to be tested through a target node, and generating an automatic script corresponding to the software to be tested according to the operation events; binding the test case after configuration with the automatic script in response to parameter information configured by the user for each test case; identifying the dependency relationship between the test cases, constructing a directed acyclic graph corresponding to the test case, generating a test case execution plan according to the directed acyclic graph; and parsing the test case execution plan after the user creates a verification task, and performing full-link verification on the software to be tested according to the parsing result. The technical scheme of the embodiment of the application can form a complete verification process which is standardized, reusable and flexibly adaptable to multiple scenes, build a retention traceability mechanism covering all elements of software requirement verification, and ensure the delivery quality of the software.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a software requirements verification method, apparatus, device, and storage medium. Background Technology

[0002] Currently, requirements verification of software is an important technical means to check whether the software meets the real needs of users and to avoid the subsequent development of products that do not meet expectations.

[0003] In existing technologies, software requirements verification typically relies on testers manually. This involves testers setting up a real physical network environment or a simple virtual machine environment, installing the software under test and its dependent components on the target host, executing the test steps according to the requirements description, and finally observing and recording the verification results. The entire verification process involves multiple stages, including environment setup, software deployment, test execution, and result recording, all of which depend on manual operation.

[0004] Existing verification methods suffer from the following technical drawbacks: they only support fixed simulation or real physical environments, resulting in long verification preparation cycles, high manpower costs, and the need to redo all deployment work after each environment reset or migration, making it impossible to guarantee environmental consistency across multiple verifications; they use fixed preset test scripts, making it impossible to flexibly adjust the test process, requiring script rewriting or manual testing for new test tasks, leading to poor process reusability and low iteration efficiency; the parameters and verification logic of test cases are fixed and singular, only enabling standardized testing under fixed conditions, and cannot adapt to differentiated testing needs across multiple scenarios and gradients; existing test cases are all executed independently at single points, lacking the ability to orchestrate dependencies between test cases, and cannot simulate the real business chain of continuous closed-loop software; they only support single test execution, unable to simulate high-frequency, long-term operating scenarios, resulting in incomplete test dimensions; test data is scattered and disordered, making it impossible to achieve process reproduction, problem tracing, and auditing, and when defects are found during verification, it is impossible to accurately reproduce the complete environmental state at that time, which is detrimental to software iteration optimization and test quality control. Summary of the Invention

[0005] This invention provides a software requirements verification method, apparatus, device, and storage medium, which can form a standardized, reusable, and flexibly adaptable complete verification process for multiple scenarios, and construct a retention and traceability mechanism covering all elements of software requirements verification to ensure the quality of software delivery.

[0006] According to one aspect of the present invention, a software requirements verification method is provided, applied to a software verification management platform, the method comprising: In response to the user-created simulation test network topology and the user-uploaded software installation package, the simulation test network topology is bound to the software installation package; The system captures user operation events on the software under test through the target node and generates an automated script for the software under test based on the operation events. In response to the parameter information configured by the user for each test case, the configured test cases are bound to the automation script; Identify the dependencies between the test cases, construct a directed acyclic graph corresponding to the test cases based on the dependencies, and generate a test case execution plan based on the directed acyclic graph; After detecting that a user has created a verification task, the test case execution plan is parsed, and the software under test is subjected to full-link verification based on the parsing results.

[0007] Optionally, in response to the user-created simulation test network topology and the user-uploaded software installation package, the simulation test network topology is bound to the software installation package, including: In response to the topology parameters defined by the user in the pre-stored simulation network topology template, a simulation test network topology is generated based on the topology parameters; In response to the user-uploaded software installation package and the specified target node, the simulation test network topology is bound to the software installation package according to the target node.

[0008] Optionally, user operation events on the software under test are captured through the target node, and an automated script corresponding to the software under test is generated based on the operation events, including: Through the target node, the operation events of the user executing verification of the test cases associated with the software under test are captured in real time, and the operation events are converted into instruction sequences; The instruction sequence is converted into an automated script corresponding to the software under test, and the association between the automated script and the test cases is established.

[0009] Optionally, in response to the parameter information configured by the user for each test case, the configured test cases are bound to the automation script, including: Provide the test case library to the user and receive the parameter information configured by the user for the test cases associated with the software under test in the test case library; Bind the configured test cases to the automation script, and create a traceability chain for the software requirements, the configured test cases, and the automation script.

[0010] Optionally, the dependencies include resource dependencies, state dependencies, and data dependencies; generating a test case execution plan based on the directed acyclic graph includes: Receive the execution strategy configured by the user for the directed acyclic graph, and generate a test case execution plan based on the execution strategy; The execution strategy includes parallel execution of test cases, serial execution, retry strategy after execution failure, and the number of executions.

[0011] Optionally, the test case execution plan is parsed, and full-link verification is performed on the software under test based on the parsing results, including: The test case execution plan is parsed, and a test case task queue is generated based on the parsing results; The simulation test network topology is instantiated, the software under test is deployed on the target node, and the initialization script is executed. Obtain the actual parameters defined by the user for the simulation test network topology, and traverse and execute each test case task in the test case task queue according to the actual parameters.

[0012] Optionally, after iterating through and executing each use case task in the use case task queue, the following may also be included: If the test case task fails to execute, the test case task is executed repeatedly according to the retry strategy. After the number of repeated executions reaches a preset threshold and the test case task still fails to execute, the subsequent execution path is determined according to the branch conditions in the directed acyclic graph. After all test case tasks have been executed, a requirement verification report for the software under test is generated based on the execution information of each test case task.

[0013] According to another aspect of the present invention, a software requirements verification apparatus is provided, applied to a software verification management platform, the apparatus comprising: The topology orchestration module is used to bind the simulation test network topology to the software installation package uploaded by the user in response to the user-created simulation test network topology. An automated recording module is used to capture user operation events on the software under test through a target node, and generate an automated script corresponding to the software under test based on the operation events. The test case management module is used to bind the configured test cases to the automation script in response to the parameter information configured by the user for each test case; The test case orchestration module is used to identify the dependencies between the test cases, construct a directed acyclic graph corresponding to the test cases based on the dependencies, and generate a test case execution plan based on the directed acyclic graph. The requirement verification module is used to parse the test case execution plan after detecting that a user has created a verification task, and to perform full-link verification on the software under test based on the parsing results.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to said at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the software requirements verification method according to any embodiment of the present invention.

[0015] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the software requirements verification method according to any embodiment of the present invention.

[0016] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the software requirements verification method described in any embodiment of the present invention.

[0017] The technical solution provided by this invention, in response to a user-created simulation test network topology and a user-uploaded software installation package, binds the simulation test network topology to the software installation package. It captures user operation events on the software under test through target nodes, generates automated scripts corresponding to the software under test based on these operation events, binds the configured test cases to the automated scripts in response to the parameter information configured by the user for each test case, identifies the dependencies between test cases, constructs a directed acyclic graph (DAG) corresponding to the test cases based on the dependencies, and generates a test case execution plan based on the DAG. After detecting the user-created verification task, it parses the test case execution plan and performs full-link verification of the software under test based on the parsing results. This technical approach can form a standardized, reusable, and flexibly adaptable complete verification process for multiple scenarios, constructing a retention and traceability mechanism covering all elements of software requirement verification to ensure software delivery quality.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1This is a flowchart of a software requirements verification method provided according to an embodiment of the present invention; Figure 2 This is a flowchart of another software requirements verification method provided according to an embodiment of the present invention; Figure 3 This is a flowchart of another software requirements verification method provided according to an embodiment of the present invention; Figure 4 This is a directed acyclic graph for use case execution provided by an embodiment of the present invention; Figure 5 This is a timing diagram for executing a verification task according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a software requirements verification device according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device that implements the software requirements verification method of this invention. Detailed Implementation

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

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] Figure 1 This is a flowchart illustrating a software requirements verification method provided in an embodiment of the present invention. This embodiment is applicable to situations involving software requirements verification. The method can be executed by a software requirements verification device, which can be implemented in hardware and / or software and configured in a software verification management platform, such as... Figure 1 As shown, the method includes: Step 110: In response to the user-created simulation test network topology and the user-uploaded software installation package, bind the simulation test network topology to the software installation package.

[0024] In this embodiment, the software verification management platform can display a visual topology configuration interface. Users (i.e., testers) can use this interface to customize and build a simulated test network topology and upload the installation package of the software to be tested. The simulated test network topology refers to building a virtual network environment in a computer to simulate real network devices, links, traffic, protocols, and faults, and to perform experiments, verifications, performance analyses, etc., without occupying real hardware or affecting the production network.

[0025] Once the software verification management platform detects that the simulation test network topology has been built, it can bind the simulation test network topology with the installation package of the software under test and the running parameters of the software under test to achieve integrated automatic execution of environment startup, software deployment, and parameter configuration.

[0026] The advantage of this setup is that it ensures that when subsequent verification tasks are started, the instantiation of the simulation test network topology and the deployment of the software are completed simultaneously. This solves the problems of separation between environment setup and software deployment in existing technologies, which is time-consuming and prone to errors, and ensures the high consistency and reproducibility of the verification environment.

[0027] Step 120: Capture user operation events on the software under test through the target node, and generate the corresponding automated script for the software under test based on the operation events.

[0028] In this embodiment, the target node can be the machine or device where the software under test is deployed. The user can perform refined test case breakdowns for the overall verification task based on the business verification requirements of the software under test, and run these test cases through the target node. During this process, the target node can record the user's operation process for each individual test case and generate an automated script corresponding to the software under test based on the event information of that operation process.

[0029] The advantage of this setup is that by capturing user operation events through the target node of the software under test, parameterized scripts independent of the software verification management platform can be generated, quickly converting manual testing processes into automated execution processes. This establishes a direct mapping between the verification requirements of the software under test and the executable scripts, thereby lowering the threshold for automated testing of the software under test and avoiding the problems of high labor costs and error rates caused by users manually writing test scripts.

[0030] Step 130: In response to the parameter information configured by the user for each test case, bind the configured test cases with the automation script.

[0031] In this embodiment, the software verification management platform can perform full lifecycle management of test cases associated with the software under test. That is, after detecting the variable parameters, test thresholds and judgment criteria of the user-configured test cases, the platform can bind the configured test cases with the automated script in step 120.

[0032] Optionally, the software verification management platform can predefine a test case library and a variable parameter table corresponding to each test case. Users can select test cases associated with the software under test from the test case library and configure each test case according to the parameter types specified in the variable parameter table.

[0033] The test case library contains multiple test cases, each with its own test case identifier, requirement identifier, test case name, precondition description, operation step sequence, expected result, bound script identifier, and variable parameter table. The variable parameter table defines parameters in the script that can be dynamically replaced during execution, including parameter name, parameter type, value range, default value, and parameter source (e.g., manual input, topology injection, upstream test case output, etc.).

[0034] The software verification management platform can establish a many-to-many binding relationship between test cases and automated scripts, supporting one test case to bind a main script and multiple preparatory scripts, such as environment initialization scripts, data preparation scripts, environment cleaning scripts, etc. This embodiment does not impose any limitations on this.

[0035] Step 140: Identify the dependencies between test cases, construct a directed acyclic graph (DAG) corresponding to the test cases based on the dependencies, and generate a test case execution plan based on the DAG.

[0036] In this embodiment, the software verification management platform can also orchestrate each test case, such as determining the execution order, pre-dependencies, post-associations, and serial-parallel execution modes between each test case, and integrating multiple scattered single-point test cases into a complete test case execution plan.

[0037] Specifically, the software verification management platform can parse the preconditions of each test case and identify the dependencies between test cases based on the parsing results, such as resource dependencies, state dependencies, and data dependencies. After identifying the dependencies, a Directed Acyclic Graph (DAG) can be constructed to correspond to the execution of the test cases. Nodes in the DAG represent test cases, and directed edges between nodes represent the execution dependencies between test cases. Users can configure execution strategies for each node in the DAG, including execution mode (serial or parallel), retry strategy, branch conditions, and execution count.

[0038] Step 150: After detecting that a user has created a verification task, the test case execution plan is parsed, and the full-link verification of the software under test is performed based on the parsing results.

[0039] In this embodiment, after receiving the verification task created by the user, the software verification management platform can parse the test case execution plan to obtain the execution order of each test case, then run the automated script in the instantiated simulation test network topology, capture the actual output results during the execution of the automated script, and finally automatically compare the actual output results with the expected results corresponding to the test cases, and generate the requirement verification report corresponding to the software under test based on the comparison results.

[0040] Optionally, the comparison method can be exact matching, regular expression matching, threshold comparison, and existence check, etc., and this embodiment does not limit this.

[0041] The advantage of this setup is that by automatically generating test case execution plans, the entire software requirements verification process can be completed automatically without manual intervention. The entire process, from requirements input to verification report output, can be automated. At the same time, the verification data can be completely retained during the verification process, which is convenient for testers to trace the verification process of the software under test and optimize the functionality of the software under test.

[0042] The technical solution provided by this invention, in response to a user-created simulation test network topology and a user-uploaded software installation package, binds the simulation test network topology to the software installation package. It captures user operation events on the software under test through target nodes, generates automated scripts corresponding to the software under test based on these operation events, binds the configured test cases to the automated scripts in response to the parameter information configured by the user for each test case, identifies the dependencies between test cases, constructs a directed acyclic graph (DAG) corresponding to the test cases based on the dependencies, and generates a test case execution plan based on the DAG. Upon detecting the creation of a verification task by the user, it parses the test case execution plan and performs full-link verification on the software under test based on the parsing results. This technical means can achieve integrated topology orchestration and software deployment. It adapts to the diverse testing environment requirements of software; it enables the rapid formation of standardized testing processes without manual coding, automatically generating reusable scripts to ensure consistency in testing processes; it builds a standardized test case system that supports variable parameters and multi-scenario adaptation, improving testing flexibility and scenario coverage; it combines scattered single-point test cases into a complete testing process that fits the software's business flow, meeting the verification needs of complex business scenarios; it achieves automatic scheduling and repeated execution of verification tasks, supports defining the number of test loops, integrates functional verification and continuous stability testing, and takes into account both functional and stability verification to comprehensively ensure the quality of software delivery; it builds a full-process testing system that systematically retains topology configuration, software deployment, test scripts, test case parameters, and execution logs, supporting problem tracing, process optimization, and process auditing to form a complete verification closed loop.

[0043] Figure 2 A flowchart of another software requirements verification method provided in an embodiment of the present invention is shown below. Figure 2 As shown, the method includes: Step 210: In response to the topology parameters defined by the user in the pre-stored simulation network topology template, generate the simulation test network topology according to the topology parameters; in response to the user-uploaded software installation package under test and the specified target node, bind the simulation test network topology to the software installation package under test according to the target node.

[0044] In this embodiment, the software verification management platform can pre-store simulation network topology templates. Users can select a simulation test network topology from the template, or customize topology parameters (such as network nodes, connection relationships, and link attributes) for a certain simulation network topology in the template, thereby obtaining the final simulation test network topology for verifying the software under test.

[0045] Users can also upload the software under test installation package to the software verification management platform, specifying the target node for deploying the software under test, the configuration script before installation, and the initialization script after installation. Furthermore, users can customize the parameters required by the software under test from the pre-stored parameter templates in the software verification management platform, and mark the parameter values ​​that need to be dynamically injected during the instantiation of the simulation test network topology.

[0046] Step 220: Through the target node, capture in real time the operation events of the user executing the verification of the test cases associated with the software under test, and convert the operation events into instruction sequences; convert the instruction sequences into the corresponding automated scripts of the software under test, and establish the association between the automated scripts and the test cases.

[0047] In this embodiment, the user can break down multiple functional requirements of the software under test, determine corresponding test cases based on the breakdown results, and perform verification on each test case at the target node. The target node can capture user operation events in real time, convert the operation events into instruction sequences, and record the verification environment context at the time the operation events occur.

[0048] The software verification management platform can convert the instruction sequence into an automated script based on the verification environment context. During the conversion process, dynamic values ​​in the operation events can be identified and replaced with parameter variables. After generating the automated script, it can be stored in a script library, and an association between the automated script and test cases can be established.

[0049] Step 230: Provide the test case library to the user and receive the parameter information configured by the user for the test cases associated with the software under test in the test case library; bind the configured test cases with the automation scripts, and create a traceability chain corresponding to the software requirements, the configured test cases, and the automation scripts.

[0050] In this embodiment, the user can configure parameter information for each test case associated with the software under test, including precondition description information, expected result information, etc. At the same time, the user can also define parameters that need to be dynamically replaced when the automated script is executed according to the variable parameter table. These parameters can include static parameters, topology injection parameters, and dynamically passed parameters.

[0051] The static parameters refer to the parameters manually specified by the user when the verification task is created; the topology injection parameters refer to the parameters automatically collected and injected when the simulation test network topology is instantiated; and the dynamic transmission parameters refer to the parameters automatically extracted from the execution output of the upstream test cases and transmitted to the downstream test cases.

[0052] The advantage of this setup is that by receiving the three parameter types defined by the user for the automated script, parameter values ​​can be automatically replaced during subsequent script execution, reducing manual intervention during script execution. At the same time, by defining dynamically passed parameters, the problem of data coupling between steps in complex verification processes can be solved, improving the scalability and orchestration flexibility of the verification process.

[0053] Step 240: Identify the dependencies between test cases, construct a directed acyclic graph corresponding to the test cases based on the dependencies, receive the execution strategy configured by the user for the directed acyclic graph, and generate a test case execution plan based on the execution strategy.

[0054] In this embodiment, dependencies include resource dependencies, state dependencies, and data dependencies. Execution strategies include parallel execution of test cases, serial execution, retry strategies after execution failure, and the number of execution attempts.

[0055] Specifically, when constructing a DAG based on the aforementioned dependencies, if a circular dependency is detected, an alarm message can be displayed to the user and the test case orchestration process can be terminated; if no circular dependency is detected, the nodes in the DAG can be sorted to determine the execution order of each test case.

[0056] When configuring execution strategies for a DAG, users can configure test case nodes with no dependencies to execute in parallel to shorten the time consumed by the entire verification process; configure test case nodes with dependencies to execute sequentially to ensure that the preconditions for each test case node are met; configure retry strategies (including retry thresholds) for test cases that fail to execute; and configure the global execution count for regression testing or stress testing scenarios.

[0057] Step 250: After detecting that a user has created a verification task, the test case execution plan is parsed, and a test case task queue is generated based on the parsing results.

[0058] In this step, users can create verification tasks through the software verification management platform. After receiving the verification task, the task scheduler can parse the test case execution plan and generate a test case task queue based on the execution order of each test case in the parsing result.

[0059] Step 260: Instantiate the simulation test network topology, deploy the software under test on the target node and execute the initialization script; obtain the actual parameters defined by the user for the simulation test network topology, and traverse and execute each test case task in the test case task queue according to the actual parameters.

[0060] In this step, for each test case task, the variable parameter values ​​of the test case task can be determined according to the parameter passing mapping table, and the corresponding automated script can be loaded on the target node. The parameters automatically collected during the instantiation of the simulation test network topology are injected, and then the automated script is executed to obtain the actual output results, thereby completing the execution of all test case tasks in the test case task queue.

[0061] In one embodiment of this example, after traversing and executing each test case task in the test case task queue, the method further includes: if the test case task fails to execute, the test case task is executed repeatedly according to the retry strategy; after the number of repeated executions reaches a preset threshold and the test case task still fails to execute, the subsequent execution path is determined according to the branch conditions in the directed acyclic graph; after all test case tasks have been executed, a requirement verification report corresponding to the software under test is generated based on the execution information of each test case task.

[0062] Specifically, if the number of repeated executions reaches a preset threshold and the test case task still fails to execute, and the corresponding branch condition in the DAG is "failure means termination", then the execution of subsequent test case tasks can be stopped and the software requirement verification under test can be marked as failed; if the corresponding branch condition in the DAG is "failure means continuation", then the execution of downstream test case tasks that depend on this test case task can be skipped and the remaining test case tasks can continue to be executed.

[0063] In this embodiment, after completing one round of execution on the specified test case node in the DAG, if the current global execution count is greater than 1, the simulation test network environment can be reset, and the next round of verification process can begin, until the global execution count reaches a preset threshold. After the global execution count reaches the preset threshold, a requirement verification report corresponding to the software under test can be generated based on the execution results of each test case in multiple rounds.

[0064] The technical solution provided in this invention generates a simulated test network topology in response to topology parameters defined by the user in a pre-stored simulated network topology template; binds the simulated test network topology to the installation package of the software under test according to the target node; captures in real time the operation events of the user executing verification of test cases associated with the software under test through the target node, and converts the operation events into instruction sequences; converts the instruction sequences into automated scripts, establishes the association between the automated scripts and test cases, provides a test case library to the user, and receives the parameter information configured by the user for the test cases associated with the software under test in the test case library; binds the configured test cases with the automated scripts, creating software requirements, configured test cases, and corresponding automated scripts. The traceability chain identifies the dependencies between test cases, constructs a directed acyclic graph (DAG) corresponding to the test cases, generates test case execution plans based on the user's configured execution strategy for the DAG, parses the test case execution plans to generate a test case task queue after detecting user-created verification tasks, instantiates the simulated test network topology, deploys the software under test on the target node, and executes the initialization script; it also obtains the actual parameters defined by the user for the simulated test network topology and iterates through and executes each test case task in the test case task queue based on the actual parameters. This technical approach can form a standardized, reusable, and flexibly adaptable complete verification process for multiple scenarios, and builds a retention and traceability mechanism covering all elements of software requirement verification to ensure the quality of software delivery.

[0065] Based on the above embodiments, to better explain the technical solution provided in this embodiment, please refer to... Figure 3 The flowchart shown illustrates the execution flow of the software requirements verification method, which includes: Step 1: Simulate and test the network topology and bind it to the installation package of the software under test; In this step, users can create or select a simulation test network topology, upload the software installation package to be tested deployed on a specified node, and customize configuration parameters according to the running parameter template. Then, the software verification management platform generates a topology template and deployment list.

[0066] Step 2: Requirement breakdown and automated recording; In this step, users can analyze the requirements of the software under test and break them down into multiple test cases. Then, they can verify each test case through a designated node. This node can record the corresponding instruction sequence of the user and convert the instruction sequence into an automated script. Finally, the association between the automated script and the test cases is established.

[0067] Step 3: Test Case Management; In this step, users can complete the test case information, including preconditions and / or predicted results, and bind the completed test cases to the automation scripts. Users can also define the variable parameters corresponding to the test cases, and then store the configured test cases in the test case library.

[0068] Step 4: Use Case Orchestration; In this step, the dependencies between test cases can be identified, the DAG corresponding to the test cases can be constructed and the execution order can be determined. Then, the user can configure the execution strategy corresponding to the test cases, and finally the test case execution plan can be generated.

[0069] Optional, Figure 4 A directed acyclic graph can be executed for a use case, such as Figure 4 As shown, nodes A, B, C, D, and E represent test cases, and directed edges represent execution dependencies (e.g., A→B means B depends on A). Each node is internally labeled with a test case identifier, script identifier, execution mode, input parameter mapping table, and output parameter definition table. The edges connecting nodes are labeled with dependency types (e.g., resource dependency, state dependency, data dependency, etc.). Figure 4 Nodes A and C are initial nodes with an in-degree of 0 and can be executed in parallel. Node B depends on node A, node D depends on nodes B and C, and node E depends on node D, thus forming a mixed execution path of serial and parallel execution.

[0070] Step 5: Automated requirements verification execution; In this step, after the user creates a verification task, the scheduler can parse the test case execution plan to generate a task queue, instantiate the simulation test network topology and deploy the software under test on the specified node, and then traverse and execute each test case task in the task queue. If the execution fails, it is handled according to the retry strategy. When the number of loop executions of the entire verification process reaches the specified number, a requirement verification report of the software under test is generated.

[0071] Optional, Figure 5 This is a timing diagram for performing a verification task according to an embodiment of the present invention, such as... Figure 5 As shown, after a user creates a verification task, the task scheduler can request topology instantiation from the topology orchestration module. The topology orchestration module creates the simulation test network topology and deploys the software, and then returns a ready notification to the task scheduler. The task scheduler distributes test cases to the execution engine in DAG order; the execution engine executes the script through each node and sends the actual output results to the result comparator; the result comparator compares the actual output results with the expected results and feeds the comparison results back to the task scheduler so that the task scheduler can restart the next round of verification process; When the number of iterations of the entire verification process reaches a preset threshold, the report generator summarizes the execution information of each round and outputs a requirement verification report.

[0072] Figure 6 This is a schematic diagram of a software requirement verification device provided in an embodiment of the present invention. The device is applied to a software verification management platform and includes: a topology orchestration module 310, an automated recording module 320, a test case management module 330, a test case orchestration module 340, and a requirement verification module 350.

[0073] The topology orchestration module 310 is used to bind the simulation test network topology to the software installation package in response to the user-created simulation test network topology and the user-uploaded software installation package. The automated recording module 320 is used to capture user operation events on the software under test through the target node, and generate an automated script corresponding to the software under test based on the operation events. The test case management module 330 is used to bind the configured test cases with the automation scripts in response to the parameter information configured by the user for each test case; The test case orchestration module 340 is used to identify the dependencies between test cases, construct a directed acyclic graph corresponding to the test cases based on the dependencies, and generate a test case execution plan based on the directed acyclic graph. The requirement verification module 350 is used to parse the test case execution plan after detecting that a user has created a verification task, and to perform full-link verification on the software under test based on the parsing results.

[0074] The technical solution provided by this invention, in response to a user-created simulation test network topology and a user-uploaded software installation package, binds the simulation test network topology to the software installation package. It captures user operation events on the software under test through target nodes, generates automated scripts corresponding to the software under test based on these operation events, binds the configured test cases to the automated scripts in response to the parameter information configured by the user for each test case, identifies the dependencies between test cases, constructs a directed acyclic graph (DAG) corresponding to the test cases based on the dependencies, and generates a test case execution plan based on the DAG. Upon detecting the creation of a verification task by the user, it parses the test case execution plan and performs full-link verification on the software under test based on the parsing results. This technical means can achieve integrated topology orchestration and software deployment. It adapts to the diverse testing environment requirements of software; it enables the rapid formation of standardized testing processes without manual coding, automatically generating reusable scripts to ensure consistency in testing processes; it builds a standardized test case system that supports variable parameters and multi-scenario adaptation, improving testing flexibility and scenario coverage; it combines scattered single-point test cases into a complete testing process that fits the software's business flow, meeting the verification needs of complex business scenarios; it achieves automatic scheduling and repeated execution of verification tasks, supports defining the number of test loops, integrates functional verification and continuous stability testing, and takes into account both functional and stability verification to comprehensively ensure the quality of software delivery; it builds a full-process testing system that systematically retains topology configuration, software deployment, test scripts, test case parameters, and execution logs, supporting problem tracing, process optimization, and process auditing to form a complete verification closed loop.

[0075] Based on the above embodiments, the topology orchestration module 310 is also used for: In response to the topology parameters defined by the user in the pre-stored simulation network topology template, a simulation test network topology is generated based on the topology parameters; in response to the installation package of the software under test uploaded by the user and the specified target node, the simulation test network topology is bound to the installation package of the software under test based on the target node.

[0076] Specifically, such as Figure 6 As shown, the topology orchestration module 310 deploys a topology template, a node configuration table, a software deployment list, and a topology instantiation controller.

[0077] The topology template refers to a predefined simulation network topology template, which is used by users to select an existing template or create a new simulation test network topology; the node configuration table stores the attribute information of each node; the software deployment manifest records the installation package of the software under test and its dependent components bound to the simulation test network topology; and the topology instantiation controller is used to instantiate the simulation test network topology into a runnable simulation network instance.

[0078] The automated recording module 320 is also used for: By using target nodes, the system captures in real time the operation events of the user executing verification of test cases associated with the software under test, and converts the operation events into instruction sequences; it then converts the instruction sequences into the corresponding automated scripts for the software under test, and establishes the association between the automated scripts and the test cases.

[0079] Specifically, such as Figure 6 As shown, the automated recording module 320 deploys an operation recorder and a script generator.

[0080] The operation recorder is a lightweight agent program deployed on the target node to capture user operation events on the node; the script generator is used to convert intermediate operation instruction sequences into repeatable automated scripts.

[0081] The use case management module 330 is also used for: Provide the test case library to the user and receive the parameter information configured by the user for the test cases associated with the software under test in the test case library; bind the configured test cases with the automation scripts and create a traceability chain corresponding to the software requirements, the configured test cases and the automation scripts.

[0082] Specifically, such as Figure 6 As shown, the test case management module 330 deploys a test case library, a variable parameter table, and a script binder.

[0083] The test case library stores each test case, including a test case identifier, requirement identifier, test case name, precondition description, operation step sequence, expected result, bound script identifier, and variable parameter table. The variable parameter table defines the parameters that the script can dynamically replace during execution, including parameter name, parameter type, value range, default value, and parameter source (such as manual input, topology injection, upstream test case output, etc.). The script binder is used to establish a many-to-many binding relationship between test cases and automation scripts, supporting one test case to bind a main script and multiple precondition scripts, such as environment initialization scripts, data preparation scripts, and environment cleaning scripts.

[0084] The test case orchestration module 340 is also used for: It receives the execution strategy configured by the user for the directed acyclic graph and generates a test case execution plan based on the execution strategy; the dependencies include resource dependencies, state dependencies, and data dependencies; the execution strategy includes parallel execution of test cases, serial execution, retry strategy after execution failure, and the number of executions.

[0085] Specifically, such as Figure 6 As shown, the use case orchestration module 340 deploys a dependency analyzer, a DAG builder, and a strategy configurator.

[0086] The dependency analyzer is used to parse the preconditions of each test case in the test case library and automatically identify the dependencies between test cases; the DAG builder is used to construct a directed acyclic graph for test case execution based on the dependencies; and the strategy configurator is used to configure execution strategies for nodes in the DAG, including execution mode, retry strategy, branch conditions, and execution count.

[0087] The requirement verification module 350 is also used for: The test case execution plan is parsed, and a test case task queue is generated based on the parsing results; the simulation test network topology is instantiated, the software under test is deployed on the target node, and the initialization script is executed; the actual parameters defined by the user for the simulation test network topology are obtained, and each test case task in the test case task queue is traversed and executed according to the actual parameters; If the test case task fails to execute, the test case task will be executed repeatedly according to the retry strategy. After the number of repeated executions reaches a preset threshold and the test case task still fails to execute, the subsequent execution path will be determined according to the branch conditions in the directed acyclic graph. After all test case tasks have been executed, a requirement verification report for the software under test is generated based on the execution information of each test case task.

[0088] Specifically, such as Figure 6 As shown, the requirement verification module 350 deploys a verification task scheduler, an execution engine, a result comparator, and a report generator.

[0089] The task scheduler is used to receive user verification task requests, determine the execution order of test cases according to the DAG constructed by the test case orchestration module 340, and instantiate the test cases into executable tasks; the execution engine is used to request the topology orchestration module 310 to instantiate the simulation test network, load and execute automated scripts on each target node, replace variable parameters in the scripts at runtime, and capture the actual output results during script execution. The result comparator is used to automatically compare the captured actual output results with the expected results in the test case library; the report generator is used to summarize the execution results of all test cases and generate a structured requirement verification report based on the execution results.

[0090] The above-described apparatus can execute the methods provided in all the foregoing embodiments of the present invention, and has the corresponding functional modules and beneficial effects for executing the above methods. Technical details not described in detail in the embodiments of the present invention can be found in the methods provided in all the foregoing embodiments of the present invention.

[0091] Figure 7A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0092] like Figure 7 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) or a random access memory (RAM), communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 12 or loaded from the storage unit 18 into the random access memory 13. The random access memory 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, the read-only memory 12, and the random access memory 13 are interconnected via a bus 14. Input / output (I / O) interfaces are also connected to the bus 14.

[0093] Multiple components in electronic device 10 are connected to input / output interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of monitors, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0094] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processing (DSP) processors, and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as software requirements verification methods.

[0095] In some embodiments, the software requirements verification method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via read-only memory 12 and / or communication unit 19. When the computer program is loaded into random access memory 13 and executed by processor 11, one or more steps of the software requirements verification method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the software requirements verification method by any other suitable means (e.g., by means of firmware).

[0096] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0097] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0098] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0099] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a cathode ray tube (CRT) or a liquid crystal display (LCD)) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0100] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0101] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) in terms of management difficulty and weak business scalability.

[0102] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0103] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A software requirements verification method, characterized in that, The method, applied to a software verification management platform, includes: In response to the user-created simulation test network topology and the user-uploaded software installation package, the simulation test network topology is bound to the software installation package; The system captures user operation events on the software under test through the target node and generates an automated script for the software under test based on the operation events. In response to the parameter information configured by the user for each test case, the configured test cases are bound to the automation script; Identify the dependencies between the test cases, construct a directed acyclic graph corresponding to the test cases based on the dependencies, and generate a test case execution plan based on the directed acyclic graph; After detecting that a user has created a verification task, the test case execution plan is parsed, and the software under test is subjected to full-link verification based on the parsing results.

2. The method according to claim 1, characterized in that, In response to the user-created simulation test network topology and the user-uploaded software installation package, the simulation test network topology is bound to the software installation package, including: In response to the topology parameters defined by the user in the pre-stored simulation network topology template, a simulation test network topology is generated based on the topology parameters; In response to the user-uploaded software installation package and the specified target node, the simulation test network topology is bound to the software installation package according to the target node.

3. The method according to claim 1, characterized in that, By capturing user operation events on the software under test through the target node, and generating an automated script corresponding to the software under test based on the operation events, including: Through the target node, the operation events of the user executing verification of the test cases associated with the software under test are captured in real time, and the operation events are converted into instruction sequences; The instruction sequence is converted into an automated script corresponding to the software under test, and the association between the automated script and the test cases is established.

4. The method according to claim 1, characterized in that, In response to the parameter information configured by the user for each test case, the configured test cases are bound to the automated script, including: Provide the test case library to the user and receive the parameter information configured by the user for the test cases associated with the software under test in the test case library; The configured test cases are bound to the automation script, and a traceability chain is created for the software requirements, the configured test cases, and the automation script.

5. The method according to claim 1, characterized in that, The dependencies include resource dependencies, state dependencies, and data dependencies; Generate a test case execution plan based on the directed acyclic graph, including: Receive the execution strategy configured by the user for the directed acyclic graph, and generate a test case execution plan based on the execution strategy; The execution strategy includes parallel execution of test cases, serial execution, retry strategy after execution failure, and the number of executions.

6. The method according to claim 5, characterized in that, The test case execution plan is parsed, and based on the parsing results, a full-link verification is performed on the software under test, including: The test case execution plan is parsed, and a test case task queue is generated based on the parsing results; The simulation test network topology is instantiated, the software under test is deployed on the target node, and the initialization script is executed. Obtain the actual parameters defined by the user for the simulation test network topology, and traverse and execute each test case task in the test case task queue according to the actual parameters.

7. The method according to claim 6, characterized in that, After iterating through and executing each use case task in the use case task queue, the process also includes: If the test case task fails to execute, the test case task is executed repeatedly according to the retry strategy. After the number of repeated executions reaches a preset threshold and the test case task still fails to execute, the subsequent execution path is determined according to the branch conditions in the directed acyclic graph. After all test case tasks have been executed, a requirement verification report for the software under test is generated based on the execution information of each test case task.

8. A software requirements verification device, characterized in that, The device, used in a software verification management platform, includes: The topology orchestration module is used to bind the simulation test network topology to the software installation package uploaded by the user in response to the user-created simulation test network topology. An automated recording module is used to capture user operation events on the software under test through a target node, and generate an automated script corresponding to the software under test based on the operation events. The test case management module is used to bind the configured test cases to the automation script in response to the parameter information configured by the user for each test case; The test case orchestration module is used to identify the dependencies between the test cases, construct a directed acyclic graph corresponding to the test cases based on the dependencies, and generate a test case execution plan based on the directed acyclic graph. The requirement verification module is used to parse the test case execution plan after detecting that a user has created a verification task, and to perform full-link verification on the software under test based on the parsing results.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to said at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the software requirements verification method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the software requirements verification method according to any one of claims 1-7.

Images