Automatic software testing method based on behavior-driven development

Abstract

The invention discloses an automatic software testing method based on behavior-driven development, belongs to the technical field of software testing, and remarkably reduces repeated work of manual coding by automatically generating a test script. Based on a test scene described by a natural language, the system directly converts a structured test model into an executable test code by utilizing a predefined template library and a dynamic code generation technology. For example, key actions and parameters are extracted from a user story written by a Gherkin language through an analyzer and mapped to a code template of a framework such as Selenium or JUnit, and scripts do not need to be written manually line by line. The hierarchical design of the test model further simplifies the script generation process, supports batch processing of multi-scene test tasks, greatly shortens the test preparation period, improves the overall test efficiency, is compatible with various programming languages and test frameworks, and can adapt to project requirements of different technology stacks.

Description

Technical Field

[0001] The present invention belongs to the technical field of software testing, and in particular relates to an automated software testing method based on behavior-driven development. Background Art

[0002] Software testing methods are a general term for the various strategies and techniques used to assess the quality of software products, identify defects, and verify whether they meet specified requirements. These methods are classified according to different test objectives, scopes, execution stages, or technical means, forming a diverse system. Common classification dimensions include: based on the test level, they can be divided into unit testing (verifying the minimum testable unit), integration testing (verifying the interfaces and interactions between modules), system testing (verifying the complete system functions and performance), and acceptance testing (verifying user requirements satisfaction); based on whether the code is reviewed, they can be divided into white box testing (based on code structure), black box testing (based on requirements specifications), and gray box testing (something in between); based on the test purpose, there are various specialized methods such as functional testing, performance testing, security testing, and compatibility testing, which together constitute an important means of ensuring software quality.

[0003] However, traditional software testing methods often rely on detailed documentation and manual test case execution, which is time-consuming and error-prone. With the rise of agile development models, behavior-driven development (BDD), an approach that emphasizes teamwork and cross-functional communication, has gained increasing attention. However, existing technologies for implementing BDD have limitations, such as large, difficult-to-maintain test scripts and insufficient test coverage. Summary of the Invention

[0004] The purpose of the present invention is to provide an automated software testing method based on behavior-driven development in order to solve the above-mentioned problems.

[0005] The technical solution adopted by the present invention is as follows: an automated software testing method based on behavior-driven development, the method comprising the following steps:

[0006] S1: Based on the Gherkin language specification, functional modules and specific test scenarios are defined in the Given-When-Then format, ensuring that non-technical personnel can describe the expected behavior of the system in natural language and promoting cross-team collaboration;

[0007] S2: Extract key actions, parameters, and dependencies in the test scenario through semantic analysis, and generate a structured test model consisting of Feature nodes, Scenario nodes, and Step nodes. It supports storage and expansion in JSON or XML format.

[0008] S3: Select predefined templates based on the target programming language and test framework, map the actions in the test model to specific code logic, automatically fill in parameterized data, and generate automated test scripts that support frameworks such as Selenium and JUnit;

[0009] S4: Initialize hardware devices, software dependencies, and network conditions, clean and preset initial database data, and load parameterized test data through CSV or JSON files to ensure consistency and repeatability of the test environment;

[0010] S5: Call the generated test script and use distributed tools to implement multi-device parallel testing, record operation logs in real time, and automatically capture screenshots and screen recording files of key steps to enhance problem reproduction capabilities;

[0011] S6: Count the test case execution status, capture exception stack information, use code coverage tools to analyze test coverage, and generate HTML reports and defect distribution charts through tools such as Allure to intuitively display test results;

[0012] S7: Classify the cause of test failure as script logic error, system function defect or environment anomaly, quickly locate the fault point by combining logs, screenshots and screen recordings, and provide reproducible context information to assist in repair;

[0013] S8: Adjust the test scenario description based on test feedback, add or modify steps to cover untested functions, and run regression tests regularly to verify the repair effect to ensure system stability and consistency with requirements;

[0014] S9: Embed the testing process into the CI / CD tool chain to automatically trigger testing tasks, use historical data to train machine learning models to predict high-risk functional modules, prioritize testing potential defect areas, and dynamically optimize testing strategies.

[0015] In a preferred embodiment, in step S1, based on the Gherkin language specification, the Given-When-Then format is used to define functional modules and specific test scenarios. Each Feature file must contain a clear description of the functional objectives, and the Scenario must strictly follow the logical structure of Given defining the initial conditions, When defining the triggering operation, and Then defining the expected results. The test scenario file is stored with the extension .feature. The development team needs to collaborate with the business team to verify the grammatical correctness of the scenario to ensure that the natural language description is unambiguous. Scenario writing needs to split independent functional points to avoid logical intersections. For example, the user login function needs to be divided into multiple independent Scenarios such as successful authentication, incorrect password, and account lockout. Each Scenario only covers a single test target.

[0016] In a preferred embodiment, in step S2, Cucumber or a custom parser is integrated to parse the feature file and extract keywords, actions and parameters in the natural language. The parser needs to be configured with predefined action mapping rules to convert the Given-When-Then steps into executable instructions. For example, "the user enters the correct username" needs to be mapped to a simulated input operation, and the parameter "username" and its value need to be extracted. The generated test model uses JSON format and contains a hierarchical structure of Feature nodes, Scenario nodes and Step nodes. The Step node needs to be labeled with type, description, action mapping function and parameter list, and the dependency relationship is represented by a directed graph to ensure the execution order. The model needs to support dynamic expansion and allow the addition of action mapping rules through configuration files.

[0017] In a preferred embodiment, in step S3, a predefined template library is selected based on the target programming language and test framework, such as Python using Selenium templates to generate Web automation code, and Java using JUnit templates to generate unit test code. The code generator traverses the test model, maps Scenario to independent test methods, and maps Step to specific function calls. Parameterized data is dynamically filled in through placeholders, such as reading a username and password combination from a CSV file. The generated code must include test class initialization and cleanup logic, such as WebDriver instantiation and resource release. Multi-framework integration is supported, and the generated script must be compatible with tools such as Selenium, Appium, or Postman to ensure direct execution.

[0018] In a preferred embodiment, in step S4, the test environment needs to deploy the target application version, install a browser driver such as ChromeDriver or GeckoDriver, and configure database connection parameters and network proxy. Hardware resources need to support distributed execution, and multi-node parallel testing must be configured through Selenium Grid. The database initialization script needs to execute SQL operations to clear historical data and insert test user records, such as "DELETE FROM users; INSERT INTO users VALUES('test_user','encrypted_password');". External test data files need to be stored in CSV or JSON format, with fields containing input parameters, expected results, and priority tags. The format integrity must be verified when loading data, and missing fields will trigger an alarm and terminate the process.

[0019] In a preferred embodiment, in step S5, the generated script is called by a test framework such as pytest or TestNG, and the command line parameters specify the test scope and environment variables. Distributed execution tools such as Jenkins Pipeline define parallel tasks and run tests for different browsers or device types. The logging module needs to capture operation timestamps, step descriptions and status at the INFO level, and automatically take screenshots before and after key assertions and save them as PNG files. The screen recording function records the entire test process through the FFmpeg command. The video file is named and stored according to the test scenario name and timestamp. When an exception occurs, the last N frames are retained to assist in troubleshooting.

[0020] In a preferred embodiment, in step S6, the native report of the test framework needs to be converted into structured data to record the pass rate, failure reason and execution time of each scenario. Code coverage tools such as JaCoCo are integrated into the build process to generate coverage reports in HTML format, marking uncovered code lines and branches. The Allure reporting framework aggregates logs, screenshots and screen recordings to generate interactive HTML pages to display test trends, defect distribution modules and historical comparison data. Custom scripts analyze the stack traces of failed use cases, extract high-frequency error types such as element positioning timeouts or interface response exceptions, generate defect classification statistical charts and associate them with code versions.

[0021] In a preferred embodiment, in step S7, the failed use cases are classified into script logic errors, system functional defects or environmental anomalies according to the error type. Script errors require checking element positioning strategies or data-driven logic, system defects require comparing the requirements document to verify the function implementation, and environmental problems require checking network delays or database connection timeouts. The root cause analysis tool associates error logs with code submission records and marks the modules that have been recently changed. Screenshots and screen recording files are archived according to test scenarios and timestamps, and the corresponding log entries are matched by unique identifiers. The automated script generates a root cause report, which includes reproduction steps, environment configuration snapshots and associated code submission hashes, and pushes it to the defect management system.

[0022] In a preferred embodiment, in step S8, the test model is updated according to the test feedback, a new Scenario is added to cover boundary conditions such as excessively long input or concurrent operations, and the Step parameter mapping rules are modified to adapt to changes in interface elements. The regression test suite must include historical defect use cases and core business process use cases, and the execution frequency is set to daily or before iterative release. Version control systems such as Git manage the change history of test models and codes, and support branch rollback and difference comparison. The optimized model needs to regenerate code and perform full testing, and the pass rate threshold is set to above 95%. Unsatisfactory scenarios trigger a manual review process.

[0023] In a preferred embodiment, in step S9, a CI / CD pipeline such as Jenkins or GitLab CI is configured with a Webhook trigger, which automatically triggers a test task when the code is submitted to the main branch or released. The test results are bound to the pipeline status. In case of failure, the deployment process is blocked and the responsible person is notified. The machine learning module uses historical test data to train a classification model. Features include code change modules, defect distribution density, and test execution time. It predicts high-risk functions and generates a priority queue. The test strategy is dynamically adjusted, and the number of test rounds and coverage are increased for high-risk modules, while sampling tests are used for low-risk modules. Intelligent reports regularly generate test performance indicators such as defect detection rate and average repair cycle to drive the team to optimize test case design and resource allocation strategies.

[0024] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0025] 1. The present invention significantly reduces the repetitive work of manual coding by automatically generating test scripts. Based on test scenarios described in natural language, the system uses a predefined template library and dynamic code generation technology to directly convert structured test models into executable test code. For example, user stories written in Gherkin language extract key actions and parameters through a parser and map them to code templates of frameworks such as Selenium or JUnit, eliminating the need for manual line-by-line script writing. The hierarchical design of the test model further simplifies the script generation process, supports batch processing of multi-scenario test tasks, significantly shortens the test preparation cycle, and improves overall test efficiency.

[0026] 2. The present invention is compatible with multiple programming languages ​​and test frameworks, and can adapt to project requirements of different technology stacks. By configuring the template library, the system can generate test scripts adapted to Selenium, Appium, or Postman for Python, Java, or JavaScript. For example, the same test model can simultaneously generate web interface automation scripts and API interface test code to meet cross-platform, multi-terminal testing scenarios. The external data-driven mechanism allows parameterized inputs to be loaded from files such as CSV and JSON, supports dynamic adjustment of test data and execution logic, and ensures the wide applicability of the method in different business scenarios.

[0027] 3. In this invention, the test model adopts a modular design, supporting rapid expansion and optimization to adapt to changing requirements. When adding new functional modules, simply add the corresponding scenario description to the feature file, and the parser will automatically update the test model and generate code. For example, boundary condition testing for payment functions can be covered by adding a new scenario without refactoring existing code. Model dependency management and version control integration ensure that test scripts are iterated synchronously with system requirements. Furthermore, machine learning predicts high-risk areas and dynamically adjusts test coverage strategies, achieving continuously optimized testing capabilities.

[0028] 4. In this invention, the use of natural language tools lowers the threshold for non-technical personnel to participate in test design and promotes cross-functional team collaboration. Business personnel can directly write user stories using Gherkin syntax, and the development team generates test code based on a unified requirements description, avoiding the ambiguity of traditional documents. For example, the description of the "user login failure" scenario is jointly confirmed by the product manager and the test engineer to ensure that the test logic is consistent with the business objectives. Visual reports and automated feedback mechanisms further simplify test result analysis, allowing non-technical personnel to intuitively understand test progress and defect distribution, thereby improving team collaboration efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 It is a schematic diagram of the process principle of the present invention. DETAILED DESCRIPTION

[0030] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0031] Example:

[0032] Reference Figure 1 , an automated software testing method based on behavior-driven development, comprising the following steps:

[0033] S1: Based on the Gherkin language specification, functional modules and specific test scenarios are defined in the Given-When-Then format, ensuring that non-technical personnel can describe the expected behavior of the system in natural language and promoting cross-team collaboration;

[0034] S2: Extract key actions, parameters, and dependencies in the test scenario through semantic analysis, and generate a structured test model consisting of Feature nodes, Scenario nodes, and Step nodes. It supports storage and expansion in JSON or XML format.

[0035] S3: Select predefined templates based on the target programming language and test framework, map the actions in the test model to specific code logic, automatically fill in parameterized data, and generate automated test scripts that support frameworks such as Selenium and JUnit;

[0036] S4: Initialize hardware devices, software dependencies, and network conditions, clean and preset initial database data, and load parameterized test data through CSV or JSON files to ensure consistency and repeatability of the test environment;

[0037] S5: Call the generated test script and use distributed tools to implement multi-device parallel testing, record operation logs in real time, and automatically capture screenshots and screen recording files of key steps to enhance problem reproduction capabilities;

[0038] S6: Count the test case execution status, capture exception stack information, use code coverage tools to analyze test coverage, and generate HTML reports and defect distribution charts through tools such as Allure to intuitively display test results;

[0039] S7: Classify the cause of test failure as script logic error, system function defect or environment anomaly, quickly locate the fault point by combining logs, screenshots and screen recordings, and provide reproducible context information to assist in repair;

[0040] S8: Adjust the test scenario description based on test feedback, add or modify steps to cover untested functions, and run regression tests regularly to verify the repair effect to ensure system stability and consistency with requirements;

[0041] S9: Embed the testing process into the CI / CD tool chain to automatically trigger testing tasks, use historical data to train machine learning models to predict high-risk functional modules, prioritize testing potential defect areas, and dynamically optimize testing strategies.

[0042] In step S1, based on the Gherkin language specification, the Given-When-Then format is used to define functional modules and specific test scenarios. Each Feature file must contain a clear description of the functional objectives, and the Scenario must strictly follow the logical structure of Given defining the initial conditions, When defining the triggering operation, and Then defining the expected results. The test scenario file is stored with the extension .feature. The development team needs to collaborate with the business team to verify the grammatical correctness of the scenario to ensure that the natural language description is unambiguous. Scenario writing needs to split independent functional points to avoid logical intersections. For example, the user login function needs to be divided into multiple independent scenarios such as successful authentication, incorrect password, and account lockout. Each scenario only covers a single test goal.

[0043] The operation algorithm for initializing the database or cleaning up legacy data is:

[0044] DELETE FROM users WHERE username='test_user';

[0045] INSERT INTO users(username,password)VALUES('test_user','123456').

[0046] The operation algorithm for test data loading is:

[0047] import json

[0048] with open('test_data.json','r')as file:

[0049] test_data = json.load(file).

[0050] In step S2, the feature file is parsed by integrating Cucumber or a custom parser to extract keywords, actions and parameters in the natural language. The parser needs to be configured with predefined action mapping rules to convert the Given-When-Then steps into executable instructions. For example, "the user enters the correct username" needs to be mapped to a simulated input operation, and the parameter "username" and its value need to be extracted. The generated test model uses JSON format and contains a hierarchical structure of Feature nodes, Scenario nodes and Step nodes. The Step node needs to be labeled with type, description, action mapping function and parameter list, and the dependency relationship is represented by a directed graph to ensure the execution order. The model needs to support dynamic expansion and allow the addition of action mapping rules through the configuration file.

[0051] The operation algorithms that support distributed execution are:

[0052] pipeline{

[0053] agent any

[0054] stages{

[0055] stage('Run Tests'){

[0056] parallel{

[0057] stage('Chrome'){steps{runTests('chrome')}}

[0058] stage('Firefox'){steps{runTests('firefox')}}

[0059] }

[0060] }

[0061] }

[0062] }.

[0063] In step S3, a predefined template library is selected based on the target programming language and test framework. For example, Python uses the Selenium template to generate web automation code, and Java uses the JUnit template to generate unit test code. The code generator traverses the test model, mapping scenarios to independent test methods and steps to specific function calls. Parameterized data is dynamically filled in through placeholders, such as reading username and password combinations from a CSV file. The generated code must include test class initialization and cleanup logic, such as WebDriver instantiation and resource release. Multi-framework integration is supported, and the generated scripts must be compatible with tools such as Selenium, Appium, or Postman to ensure direct execution.

[0064] In step S4, the test environment must deploy the target application version, install browser drivers such as ChromeDriver or GeckoDriver, and configure database connection parameters and network proxies. Hardware resources must support distributed execution, and multi-node parallel testing must be configured through Selenium Grid. The database initialization script must execute SQL operations to clear historical data and insert test user records, such as "DELETE FROM users; INSERT INTO users VALUES('test_user','encrypted_password');". External test data files must be stored in CSV or JSON format, with fields containing input parameters, expected results, and priority tags. Format integrity must be verified during data loading; missing fields trigger an alarm and terminate the process.

[0065] In step S5, the generated script is called through a test framework such as pytest or TestNG, and the command line parameters specify the test scope and environment variables. Distributed execution tools such as Jenkins Pipeline define parallel tasks and run tests for different browsers or device types. The logging module needs to capture operation timestamps, step descriptions, and status at the INFO level, and automatically take screenshots before and after key assertions and save them as PNG files. The screen recording function uses the FFmpeg command to record the entire test process. The video files are named and stored according to the test scenario name and timestamp. When an exception occurs, the last N frames are retained to assist in troubleshooting.

[0066] The operation algorithm code of real-time logging is:

[0067] During the test execution, the operation log of each step is recorded in real time.

[0068] import logging

[0069] logging.basicConfig(level=logging.INFO)

[0070] def simulate_login(username,password):

[0071] logging.info(f"Logging in with username:{username}")

[0072] driver.find_element_by_id("username").send_keys(username)

[0073] driver.find_element_by_id("password").send_keys(password)

[0074] driver.find_element_by_id("login_button").click().

[0075] In step S6, the test framework's native report must be converted into structured data, recording each scenario's pass rate, failure reason, and execution duration. Code coverage tools such as JaCoCo are integrated into the build process to generate HTML-formatted coverage reports, annotating uncovered code lines and branches. The Allure reporting framework aggregates logs, screenshots, and screen recordings to generate interactive HTML pages displaying test trends, defect distribution modules, and historical comparison data. Custom scripts analyze the stack traces of failed test cases, extracting high-frequency error types such as element location timeouts or interface response exceptions, generating defect classification statistics charts, and linking them to code versions.

[0076] In step S7, failed cases are classified according to the error type as script logic errors, system functional defects, or environmental anomalies. Script errors require checking element location strategies or data-driven logic. System defects require comparing functional implementation against the requirements document. Environmental issues require troubleshooting network latency or database connection timeouts. The root cause analysis tool links error logs with code commit records, marking recently modified modules. Screenshots and screen recordings are archived by test scenario and timestamp, and corresponding log entries are matched using unique identifiers. The automated script generates a root cause report containing reproduction steps, environment configuration snapshots, and associated code commit hashes, which is then pushed to the defect management system.

[0077] In step S8, the test model is updated according to the test feedback, new scenarios are added to cover boundary conditions such as excessively long input or concurrent operations, and the Step parameter mapping rules are modified to adapt to changes in interface elements. The regression test suite must include historical defect use cases and core business process use cases, and the execution frequency is set to daily or before iterative release. Version control systems such as Git manage the change history of test models and codes, and support branch rollback and difference comparison. The optimized model needs to regenerate code and perform full testing. The pass rate threshold is set to above 95%, and unsatisfactory scenarios trigger a manual review process.

[0078] In step S9, a CI / CD pipeline, such as Jenkins or GitLab CI, configures a webhook trigger to automatically trigger a test task when the code is submitted to the master branch or released. The test results are tied to the pipeline status. In the event of a failure, the deployment process is blocked and the responsible person is notified. The machine learning module uses historical test data to train a classification model. Features include code change modules, defect distribution density, and test execution time. It predicts high-risk functions and generates a priority queue. The test strategy is dynamically adjusted, with increased test rounds and coverage for high-risk modules and sampling testing for low-risk modules. Intelligent reports regularly generate test performance indicators such as defect detection rate and average repair cycle, driving the team to optimize test case design and resource allocation strategies.

[0079] The algorithm code for recording the execution status (pass / fail / skip) of each test scenario and step during the result recording process is as follows:

[0080] {

[0081] "Scenario":"Successful login",

[0082] "Status":"Passed",

[0083] "Steps":[

[0084] {"Step":"User has registered an account","Status":"Passed"},

[0085] {"Step":"User enters the correct username and password","Status":"Passed"},

[0086] {"Step":"The system should display the welcome page","Status":"Passed"} ]

[0088] }.

[0089] The algorithm code to capture the exception information and stack trace of the failed step is:

[0090] try:

[0091] assert_welcome_page_displayed()

[0092] except AssertionError as e:

[0093] logging.error(f"Assertion failed:{e}")

[0094] Raise.

[0095] Coverage analysis:

[0096] The algorithm code for analyzing code coverage using tools (such as JaCoCo, Cobertura) is:

[0097] mvn cobertura:cobertura

[0098] The algorithm code for counting the number of defects in different modules and generating pie charts or bar charts is as follows:

[0099] (Using Python's matplotlib):

[0100] import matplotlib.pyplot as plt

[0101] defects={'Login':5,'Payment':3,'Profile':2}

[0102] plt.bar(defects.keys(),defects.values())

[0103] plt.title('Defect Distribution')

[0104] plt.show().

[0105] In the present invention, the repetitive work of manual coding is significantly reduced by automatically generating test scripts. Based on the test scenarios described in natural language, the system uses a predefined template library and dynamic code generation technology to directly convert the structured test model into executable test code. For example, user stories written in Gherkin language extract key actions and parameters through the parser and map them to code templates of frameworks such as Selenium or JUnit, eliminating the need for manual script writing line by line. The hierarchical design of the test model further simplifies the script generation process, supports batch processing of multi-scenario test tasks, significantly shortens the test preparation cycle, and improves overall test efficiency.

[0106] The present invention is compatible with multiple programming languages ​​and test frameworks, and can adapt to project requirements of different technology stacks. By configuring the template library, the system can generate test scripts adapted to Selenium, Appium, or Postman for Python, Java, or JavaScript. For example, the same test model can simultaneously generate web interface automation scripts and API interface test code to meet cross-platform, multi-terminal testing scenarios. The external data-driven mechanism allows parameterized inputs to be loaded from files such as CSV and JSON, supports dynamic adjustment of test data and execution logic, and ensures the wide applicability of the method in different business scenarios.

[0107] In this invention, the test model adopts a modular design, enabling rapid expansion and optimization to adapt to changing requirements. When adding new functional modules, simply add the corresponding scenario description to the feature file, and the parser will automatically update the test model and generate code. For example, boundary condition testing for payment functions can be covered by adding a new scenario without refactoring existing code. Model dependency management and version control integration ensure that test scripts are iterated synchronously with system requirements. Machine learning also predicts high-risk areas and dynamically adjusts test coverage strategies, achieving continuously optimized testing capabilities.

[0108] In this invention, the use of natural language tools lowers the threshold for non-technical personnel to participate in test design and promotes cross-functional team collaboration. Business personnel can directly write user stories using Gherkin syntax, and the development team generates test code based on a unified requirement description, avoiding the ambiguity of traditional documents. For example, the description of the "user login failure" scenario is jointly confirmed by the product manager and the test engineer to ensure that the test logic is consistent with the business objectives. Visual reports and automated feedback mechanisms further simplify the analysis of test results, allowing non-technical personnel to intuitively understand the test progress and defect distribution, thereby improving team collaboration efficiency.

[0109] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprises" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further limitations, an element defined by the sentence "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device that includes the element.

[0110] The above description is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An automated software testing method based on behavior-driven development, characterized by: The method comprises the following steps: S1: Based on the Gherkin language specification, functional modules and specific test scenarios are defined in the Given-When-Then format, ensuring that non-technical personnel can describe the expected behavior of the system in natural language; S2: Extract key actions, parameters, and dependencies in the test scenario through semantic analysis, and generate a structured test model consisting of Feature nodes, Scenario nodes, and Step nodes; S3: Select predefined templates based on the target programming language and test framework, map the actions in the test model to specific code logic, automatically fill in parameterized data, and generate automated test scripts that support Selenium and JUnit frameworks; S4: Initialize hardware devices, software dependencies, and network conditions, clean and preset initial database data, and load parameterized test data through CSV or JSON files; S5: Call the generated test script, use distributed tools to implement multi-device parallel testing, record operation logs in real time, and automatically capture screenshots and screen recording files of key steps; S6: Count the test case execution status, capture exception stack information, use code coverage tools to analyze test coverage, and use Allure tools to generate HTML reports and defect distribution charts to display test results; S7: Classify the cause of test failure as script logic error, system function defect or environment abnormality, and quickly locate the fault point by combining logs, screenshots and screen recordings; S8: Adjust the test scenario description based on test feedback, add or modify steps to cover untested functions, and run regression tests regularly to verify the repair effect; S9: Embed the testing process into the CI / CD tool chain to automatically trigger testing tasks.

2. The automated software testing method based on behavior-driven development according to claim 1, characterized in that: In step S1, based on the Gherkin language specification, the Given-When-Then format is used to define functional modules and specific test scenarios. Each Feature file must contain a clear description of the functional objectives, and the Scenario must strictly follow the logical structure of Given defining the initial conditions, When defining the triggering operation, and Then defining the expected results. The test scenario file is stored with the extension "feature". The development team must collaborate with the business team to verify the grammatical correctness of the scenario to ensure that the natural language description is unambiguous.

3. The automated software testing method based on behavior-driven development according to claim 1, characterized in that: In step S2, the feature file is parsed by integrating Cucumber or a custom parser to extract keywords, actions and parameters in the natural language. The parser needs to be configured with predefined action mapping rules to convert the Given-When-Then steps into executable instructions.

4. The automated software testing method based on behavior-driven development according to claim 1, characterized in that: In step S3, a predefined template library is selected based on the target programming language and test framework. Python uses Selenium templates to generate web automation code, and Java uses JUnit templates to generate unit test code. The code generator traverses the test model, maps scenarios to independent test methods, and maps steps to specific function calls.

5. The automated software testing method based on behavior-driven development according to claim 1, characterized in that: In step S4, the test environment needs to deploy the target application version, install browser drivers including ChromeDriver or GeckoDriver, configure database connection parameters and network proxy; hardware resources need to support distributed execution, and multi-node parallel testing must be configured through Selenium Grid.

6. The automated software testing method based on behavior-driven development according to claim 1, characterized in that: In step S5, the generated script is called by a test framework including pytest or TestNG, and the command line parameters specify the test scope and environment variables; the distributed execution tool includes Jenkins Pipeline to define parallel tasks and run tests for different browsers or device types respectively; the logging module needs to capture operation timestamps, step descriptions and status at the INFO level, and automatically capture screenshots before and after key assertions and save them as PNG files.

7. The automated software testing method based on behavior-driven development according to claim 1, characterized in that: In step S6, the native report of the test framework needs to be converted into structured data to record the pass rate, failure reason and execution time of each scenario; the code coverage tool is integrated into the build process to generate a coverage report in HTML format, marking the uncovered code lines and branches; the Allure reporting framework aggregates logs, screenshots and screen recording files to generate an interactive HTML page to display test trends, defect distribution modules and historical comparison data.

8. The automated software testing method based on behavior-driven development according to claim 1, characterized in that: In step S7, failed cases are classified according to the error type into script logic errors, system function defects, or environmental anomalies. Script errors require checking element positioning strategies or data-driven logic, system defects require comparing the requirements document to verify function implementation, and environmental issues require checking network delays or database connection timeouts. The root cause analysis tool associates error logs with code submission records and marks the most recently modified modules. Screenshots and screen recordings are archived by test scenario and timestamp, and the corresponding log entries are matched by unique identifiers; The automated script generates a root cause report containing reproduction steps, environment configuration snapshots, and associated code commit hashes, and pushes it to the defect management system.

9. The automated software testing method based on behavior-driven development according to claim 1, characterized in that: In step S8, the test model is updated according to the test feedback, a new scenario is added to cover the boundary conditions, and the step parameter mapping rules are modified to adapt to the changes in the interface elements; the regression test suite must include historical defect use cases and core business process use cases, and the execution frequency is set to daily or before the iterative release.

10. The automated software testing method based on behavior-driven development according to claim 1, characterized in that: In step S9, the CI / CD pipeline configures a Webhook trigger to automatically trigger a test task when the code is submitted to the master branch or released. The test results are bound to the pipeline status. In case of failure, the deployment process is blocked and the responsible person is notified. The machine learning module uses historical test data to train a classification model with features including code change modules, defect distribution density, and test execution time to predict high-risk functions and generate a priority queue.

Images