Test case generation method and device, equipment and storage medium

Abstract

The invention discloses a test case generation method and device, equipment and a storage medium, and the method comprises the steps: firstly obtaining an updated test scene keyword corresponding to a test scene keyword model, then determining an original test scene keyword corresponding to the updated test scene keyword, indexing a benchmark test case associated with the original test scene keyword, and generating a test case according to the benchmark test case. And finally, dynamically updating the benchmark test case and the updated test scene keyword to generate a corresponding new test case, thereby solving the problems that the current test case needs to jointly formulate a reasonable and effective test range by related personnel, so that missing test and missing test are easily caused; and comprehensive and effective function testing is realized only by manpower accumulation in a short time, so that the technical problems of high difficulty coefficient and unobvious effect are solved.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to a test case generation method, device, equipment and storage medium. Background Art

[0002] Scrum is an agile software development framework for developing, delivering, and continuously supporting complex products. It is an iterative and incremental method that is commonly used in software development, but can also be used in other fields. The existing business development model is based on the rapid iteration of scrum. In addition to the regular version, emergency versions will be arranged for online support at any time due to reasons such as fixing online problems. Due to time constraints and insufficient assessment of demand changes, insufficient demand design leads to insufficient assessment of subsequent development scope and test scope. Therefore, it is particularly important to design relatively comprehensive and effective test cases in a short period of time.

[0003] Test cases are a key component of the software testing process, which define how to verify that a specific feature or component of the software works as expected. A good test case should include a series of detailed steps to ensure that all aspects of the software are fully tested.

[0004] Usually, when designing test cases, it is necessary to first clarify the scope of this modification, and then organize code design reviews and case reviews by relevant personnel such as the person who proposed the requirements, developers, and testers to jointly formulate a reasonable and effective test scope. However, since each responsible person is only familiar with his or her own module, some previously used functions will be ignored, resulting in missed tests and under-testing, which will cause a certain range of impact after going online and affect the user experience.

[0005] Therefore, the test cases need to be jointly formulated by relevant personnel in a reasonable and effective test scope, which is more likely to lead to missed tests and under-testing. In addition, relying solely on manpower to achieve comprehensive and effective functional testing in a short period of time is a technical problem with high difficulty and unclear effects. This is an issue that needs to be urgently addressed. Summary of the invention

[0006] The present application provides a test case generation method, apparatus, device and storage medium, which first obtain an updated test scenario keyword corresponding to a test scenario keyword model, then determine the original test scenario keyword corresponding to the updated test scenario keyword, index the benchmark test case associated with the original test scenario keyword, and finally dynamically update the benchmark test case to generate a new test case corresponding to the updated test scenario keyword. This solves the current problem that test cases need to be jointly formulated by relevant personnel to have a reasonable and effective test scope, which is more likely to lead to missed tests and under-tests, and that comprehensive and effective functional testing can be achieved in a short period of time by simply relying on manpower accumulation, resulting in a high degree of difficulty and unclear results.

[0007] In view of this, the first aspect of the present application provides a test case generation method, the method comprising:

[0008] Obtaining updated test scenario keywords corresponding to the test scenario keyword model;

[0009] Determine an original test scenario keyword corresponding to the updated test scenario keyword, and index a benchmark test case associated with the original test scenario keyword;

[0010] The benchmark test case is dynamically updated according to the updated test scenario keyword to generate a corresponding new test case.

[0011] Optionally, the step of determining an original test scenario keyword corresponding to the updated test scenario keyword, and indexing a benchmark test case associated with the original test scenario keyword specifically includes:

[0012] Indexing the original test scenario keyword corresponding to the updated test scenario keyword in the test scenario keyword model, and indexing the benchmark test case associated with the original test scenario keyword;

[0013] The updated test scenario keyword is compared with the original test scenario keyword to determine the corresponding update action.

[0014] Optionally, the step of comparing the updated test scenario keyword with the original test scenario keyword to determine a corresponding update action may further include:

[0015] updating the updated test scenario keyword and the updated action to the test scenario keyword model;

[0016] The benchmark test case is associated with the updated test scenario keyword model.

[0017] Optionally, dynamically updating the benchmark test case according to the updated test scenario keyword to generate a corresponding new test case specifically includes:

[0018] Analyze the type of the update action and determine whether the update action of the corresponding benchmark test case is an overall update action or a field update action;

[0019] The benchmark test case is dynamically updated according to the update test scenario keyword and the type of the update action to generate a corresponding new test case.

[0020] Optionally, dynamically updating the benchmark test case according to the update test scenario keyword and the type of the update action to generate a corresponding new test case, the method further includes:

[0021] The updated test scenario keyword is updated according to the test scenario keyword model, and the update time is saved.

[0022] Optionally, before obtaining the updated test scenario keyword corresponding to the test scenario keyword model, the step further includes:

[0023] Generate benchmark scenarios based on the historical logic of the invoked code;

[0024] A corresponding benchmark test case is generated through the test scenario keyword model and the benchmark test scenario.

[0025] Optionally, before obtaining the updated test scenario keyword corresponding to the test scenario keyword model, the step further includes:

[0026] Get at least 2 test scenario keywords and generate corresponding test case dictionaries;

[0027] The corresponding test scenario keyword model is generated by using the test case dictionary and the preset benchmark dictionary model.

[0028] A second aspect of the present application provides a test case generation device, the device comprising:

[0029] An acquisition unit, used for acquiring an updated test scenario keyword corresponding to the test scenario keyword model;

[0030] An indexing unit, configured to determine an original test scenario keyword corresponding to the updated test scenario keyword, and index a benchmark test case associated with the original test scenario keyword;

[0031] The test case generation unit is used to dynamically update the benchmark test case according to the updated test scenario keyword and generate a corresponding new test case.

[0032] A third aspect of the present application provides a test case generation device, the device comprising at least one processor; and

[0033] a memory communicatively connected to the at least one processor; wherein,

[0034] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the steps of the test case generation method as described in the first aspect above.

[0035] A fourth aspect of the present application provides a non-volatile computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed by one or more processors, the one or more processors can execute the method of the first aspect above.

[0036] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0037] In the present application, a test case generation method, apparatus, device and storage medium are provided, which first obtain an updated test scenario keyword corresponding to a test scenario keyword model, then determine the original test scenario keyword corresponding to the updated test scenario keyword, index the benchmark test case associated with the original test scenario keyword, and finally dynamically update the benchmark test case to generate a new test case corresponding to the updated test scenario keyword. This solves the current problem that test cases require relevant personnel to jointly formulate a reasonable and effective test scope, which is more likely to lead to missed tests and under-tests, and that comprehensive and effective functional testing can be achieved in a short period of time by simply relying on manpower accumulation, resulting in a high degree of difficulty and unclear results.

[0038] At the same time, in the present application, according to the benchmark test case corresponding to the original test scenario keyword index, the benchmark test case is associated with the updated test scenario keyword and the update action, thereby realizing an overall update or field update of the benchmark test case alone, thereby avoiding the loss of test scope due to insufficient evaluation by all parties.

[0039] Furthermore, the test scenario keyword model is updated with the test scenario keyword, and the update time is saved so that a historical record index can be available when the test case is called again in the future, so as to further query the historical logic. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 A method flow chart of a test case generation method in an embodiment of the present application;

[0041] Figure 2 This is a schematic diagram of the structure of a test case generating device in an embodiment of the present application;

[0042] Figure 3 A schematic diagram of the structure of the test case generation device in the embodiment of the present application. DETAILED DESCRIPTION

[0043] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0044] The present application designs a test case generation method, which first obtains an updated test scenario keyword corresponding to a test scenario keyword model, then determines the original test scenario keyword corresponding to the updated test scenario keyword, indexes the benchmark test case associated with the original test scenario keyword, and finally dynamically updates the benchmark test case to generate a new test case corresponding to the updated test scenario keyword. This solves the current problem that test cases require relevant personnel to jointly formulate a reasonable and effective test scope, which is more likely to lead to missed tests and under-tests, and that comprehensive and effective functional testing can be achieved in a short period of time by simply relying on manpower accumulation, resulting in a high degree of difficulty and unclear results.

[0045] For easier understanding, see Figure 1 , Figure 1 The method flow chart of the test case generation method in the embodiment of the present application is as follows: Figure 1 As shown, specifically:

[0046] S101, obtaining an updated test scenario keyword corresponding to a test scenario keyword model;

[0047] In this embodiment, when a test case needs to be generated, the updated test scenario keyword is obtained, and the original test scenario keyword corresponding to the updated test scenario keyword in the test scenario keyword model is indexed;

[0048] The updated test scenario keyword is compared with the original test scenario keyword to determine the corresponding update action. It can be understood that the update action can be a keyword field update, or multiple keywords are combined into a field, or the keyword field is directly tested, etc.

[0049] It should be noted that before obtaining the update test scenario keyword corresponding to the test scenario keyword model, the following steps are also included:

[0050] generating a benchmark scenario based on historical logic of the code being called;

[0051] A corresponding benchmark test case is generated through the test scenario keyword model and the benchmark test scenario.

[0052] It can be further understood that, before obtaining the updated test scenario keyword corresponding to the test scenario keyword model, the following steps are also included:

[0053] Get at least 2 test scenario keywords and generate corresponding test case dictionaries;

[0054] The corresponding test scenario keyword model is generated through the test case dictionary and the preset benchmark dictionary model.

[0055] For example, first define the test scenario keywords, such as saving contacts. Using keywords when defining test scenarios can help standardize the description of test cases, making the test cases clearer and easier to understand. The use of keywords also helps in the writing and maintenance of automated test scripts. The following are some commonly used test scenario keywords, as well as their definitions and uses in test cases: Preconditions: Define the conditions that must be met before executing the test. For example: "The user must have registered and logged in to the system." Test Data: Specify the specific input data required to execute the test steps. For example: "Username: 'testuser', Password: 'password'." Test Steps: List the steps required to execute the test case in detail. For example: "Step 1: Open the application. Step 2: Click the login button." Expected Results: Describe the expected output or system behavior after executing the test steps. For example: "Expected result: The system displays the user welcome interface." Actual Results: Record the actual output or behavior of the system after the test is executed. Used to compare with the expected results. Test Outcome: Indicates the execution result of the test case, such as "passed", "failed", "blocked", etc. Priority: Indicates the importance of the test case, such as "High", "Medium", "Low". Test Type: Specifies the type of test case, such as "Functional Test", "Performance Test", "Security Test", etc. Automated: Indicates whether the test case is automated, as well as related automation script information. Tags: Assign tags to test cases for easy classification and search. For example: "Login Function", "User Management". Notes: Provide additional information or notes to help understand the context of the test case. Author: Records the name of the tester who created the test case. Date Created: Records the date the test case was created. LastModified: Records the date the test case was last modified. Version: Records the version number of the test case, used to track change history. Environment: Specifies the environment in which the test case is executed, such as "Development Environment", "Test Environment", "Production Environment". Dependencies: Lists other test cases or conditions that need to be completed before the test case is executed.

[0056] Using these keywords can help create consistent test cases, and also facilitate the parsing and execution of automated testing tools. In actual applications, some keywords may be added or reduced according to the specific needs of the project.

[0057] Build test scenarios based on the historical logic of the code and actual usage scenarios, such as saving / modifying / deleting the main borrower, saving / modifying / deleting the co-borrower, saving / modifying / deleting the spouse, etc.

[0058] Design benchmark test cases. For example, to save the main borrower scenario, refer to the following use cases:

[0059] Basic fields such as name, ID card, gender, nationality, and work unit are checked for valid values, invalid values, empty values, and field length. The association between multiple fields needs to be checked. For example, if the marital status is married, it is necessary to check whether the spouse information is entered and whether the spouse information is complete and legal.

[0060] The association fields between the main borrower and other borrowers, such as whether the association is a co-borrower, obligee, guarantor, etc., whether they are from the same work unit, and whether the information of the associated persons is complete and valid;

[0061] Refer to the test scenario constructed in the second step to design other related scenario use cases; in this example, we can design scenarios for modifying and deleting the principal borrower and other associated persons;

[0062] The above benchmark cases are then saved in the test system case library, and the test system automatically scans for relevant code changes and dynamically updates valid cases.

[0063] S102, determining an original test scenario keyword corresponding to the updated test scenario keyword, and indexing a benchmark test case associated with the original test scenario keyword;

[0064] Determining an original test scenario keyword corresponding to the updated test scenario keyword, and indexing a benchmark test case associated with the original test scenario keyword specifically includes:

[0065] Indexing the original test scenario keyword corresponding to the updated test scenario keyword in the test scenario keyword model, and indexing the benchmark test case associated with the original test scenario keyword;

[0066] The updated test scenario keyword is compared with the original test scenario keyword to determine the corresponding update action.

[0067] For example, if there is a modification to a field of the principal borrower, the relevant use cases can be retrieved by entering the keyword "principal borrower" in the test system. For example, if the length of the principal borrower's name field needs to be updated, the developer can adjust the length of this field only, and the tester can also perform corresponding tests on this field. The remaining regression tests can be targeted at the use cases we retrieved to ensure that the modification of a single field will not affect other functions.

[0068] The step of comparing the updated test scenario keyword with the original test scenario keyword to determine the corresponding update action further includes:

[0069] updating the updated test scenario keyword and the updated action to the test scenario keyword model;

[0070] The benchmark test case is associated with the updated test scenario keyword model.

[0071] It can be understood that the test case keyword model is a technique used for automated testing and test case management, which describes the behavior and expected results of test cases by defining a set of predefined keywords. This model makes test cases more standardized and easy to understand, and also facilitates the parsing and execution of automation tools. Here are some common components of the test case keyword model: Test Case ID: A unique identifier for each test case. Test Title: A title that briefly describes the test case. Preconditions: The conditions that must be met before the test case is executed. Test Steps: Detailed steps required to execute the test case. Test Data: Specific input data required when executing the test steps. Expected Results: The expected results after the test execution. Actual Results: The actual results after the test execution. Test Status: The execution status of the test case, such as passed, failed, blocked, etc. Priority: The importance level of the test case, such as high, medium, and low. Test Type: The type of test case, such as functional test, performance test, security test, etc. Automation Script: If the test case is automated, the associated script or code. Notes: Any additional information or comments. Created by: The tester who created the test case. Creation Date: The date the test case was created. Modified by: The person who last modified the test case. Modified date: The date when the test case was last modified.

[0072] For example, if you are testing the "Add to Cart" feature of an online shopping website, a keyword-based test case may look like this: Test Case ID: TC-01

[0073] Test title: Test adding items to the shopping cart

[0074] Prerequisites: The user has logged in to the website and the product page has been loaded.

[0075] Test steps:

[0076] Open the product page.

[0077] Click the 'Add to Cart' button.

[0078] Test data: The product ID is 12345.

[0079] Expected result: The item is displayed in the shopping cart with a quantity of 1.

[0080] Actual result: [Fill in after test execution]

[0081] Test Status: [Fill in after test execution]

[0082] Priority: High

[0083] Test type: Functional test

[0084] Automation Script: [provide script name or ID if applicable]

[0085] Note: None

[0086] Created by: Zhang San

[0087] Creation Date: 2024-08-27

[0088] Modifier: [Fill in after modification]

[0089] Modification date: [Fill in after modification]

[0090] Using keyword models can help test teams manage and execute test cases more efficiently, while also facilitating integration with automated testing tools.

[0091] S103: Dynamically update the benchmark test case according to the updated test scenario keyword to generate a corresponding new test case.

[0092] Dynamically updating the benchmark test case according to the updated test scenario keyword and generating a corresponding new test case specifically includes:

[0093] Analyze the type of the update action and determine whether the update action of the corresponding benchmark test case is an overall update action or a field update action;

[0094] The benchmark test case is dynamically updated according to the update test scenario keyword and the type of the update action to generate a corresponding new test case.

[0095] As mentioned above, updating the benchmark test case to generate a corresponding new test case according to the update test scenario keyword and the type of the update action dynamics can be an important step to ensure software quality and functional integrity. Testing the test field accordingly is an important step to ensure software quality and functional integrity. Test fields usually refer to input fields in the software interface, such as text boxes, drop-down lists, check boxes, etc. The following are several key aspects to consider when testing test fields: Input validation: Test whether the field accepts the correct data format (such as numbers, dates, email addresses, etc.). Check whether the field rejects invalid or illegal input. Boundary value testing: Test the maximum and minimum length of the field. Test whether the field handles boundary values ​​correctly. Special character testing: Check whether the field can handle special characters, such as spaces, punctuation marks, quotation marks, etc. Data type testing: Verify whether the field accepts the expected data type (such as text, numbers, Boolean values, etc.). Required field testing: Ensure that required fields prevent form submission when there is no input and give appropriate error prompts. Field length testing: Test whether the field limits the length of the input and gives feedback when the limit is reached. Field dependency testing: If there are dependencies between fields, ensure that when the value of one field changes, the related fields can respond correctly. Security testing: Check whether the fields are vulnerable to security threats such as SQL injection and cross-site scripting (XSS). User experience testing: Ensure that the labels of the fields are clear and users can understand what type of data needs to be entered. Test whether the fields display correctly on different devices and resolutions. Multilingual and localization testing: If the software supports multiple languages, ensure that the fields can correctly handle input in different languages. Accessibility testing: Ensure that the fields meet accessibility standards, such as keyboard navigation, screen reader compatibility, etc. Performance testing: Test the performance of the fields under high load to ensure that the input and response time meet the performance requirements. Compatibility testing: Ensure that the fields behave consistently in different browsers and operating systems. Recovery and fallback testing: Test whether the fields allow users to easily correct the errors after input errors. Automated testing: If possible, write automated scripts to repeatedly test the fields to improve testing efficiency. Regression testing: After each software update, retest the fields to ensure that no new problems have been introduced. Through these tests, you can ensure that the fields work properly in various situations and provide a good user experience. Test fields are an important part of software testing, and the test plan should be customized according to the specific requirements and functions of the software. User acceptance testing: Involve end users in the testing process to ensure that the software meets their needs and expectations. Continuous integration: Implement continuous integration during the development process, and perform automated testing after each code submission to detect problems as early as possible. Test case review: Review test cases regularly to ensure that they are still consistent with current business requirements and software status. Feedback loop: Establish a feedback mechanism to learn from test results and continuously improve test strategies and test cases.

[0096] As mentioned above, SQL Injection is a common network security attack technique that allows an attacker to insert or "inject" one or more SQL statements into the original query, allowing the attacker to execute unauthorized database commands. This attack usually occurs when the input to the application is not properly sanitized or validated. How SQL injection works: Unvalidated input: The application accepts user input, such as username, password, query parameters, etc., without proper validation or sanitization. Constructing malicious input: The attacker tries to change the original SQL command by entering a specially constructed string. Executing malicious SQL: If the application directly splices the user input into the SQL query, the malicious input will be executed by the database, allowing the attacker to access, modify, or delete data.

[0097] Types of SQL Injection

[0098] Error-based injection: The attacker uses the error information returned by the database to obtain database structure information. Boolean-based blind injection: The attacker infers database information by observing the response of the application (such as page display or behavior changes). Time-based blind injection: The attacker infers information based on the response time by asking the database to perform time-consuming operations (such as waiting for a certain condition to be met).

[0099] Strategies to prevent SQL injection: Use parameterized queries: This is the most effective way to prevent SQL injection. Parameterized queries ensure that user input is processed by the database as data rather than SQL code.

[0100] SELECT*FROM users WHERE username=? AND password=? ;

[0101] Here, ? is a parameter placeholder, and the user input will be passed as a parameter instead of being directly spliced ​​into the SQL statement.

[0102] Use prepared statements: In many database interfaces, prepared statements can automatically handle parameterization, thus preventing injection.

[0103] Input validation: Validate all user input and reject input that does not conform to the expected format.

[0104] Use ORM (object-relational mapping): ORM frameworks usually automatically handle data escaping and parameterization, reducing the risk of SQL injection.

[0105] Principle of least privilege: Ensure that the database account used by the application has only the permissions to perform necessary operations.

[0106] Use a Web Application Firewall (WAF): A WAF can help detect and block SQL injection attacks.

[0107] Regular updates and patches: Keep applications and database systems updated to fix known security vulnerabilities.

[0108] Error handling: Do not display database structure information in error messages, as this might help an attacker.

[0109] Among them, Cross-Site Scripting (XSS) is a common network security vulnerability that allows attackers to inject malicious scripts into web pages that other users visit. This attack usually takes advantage of the problem that web applications do not strictly validate or improperly handle user input.

[0110] Types of XSS: Stored XSS: The attacker's script is stored on the target server and executed when other users visit the page. This usually happens in forums, message boards, or any system that allows users to submit data. Reflected XSS: The attacker's script is sent to the server as part of the user's request, and the server then returns the script directly to the user as part of the response. This usually happens in scenarios such as search queries, error messages, etc. DOM XSS: The attacker's script does not go through the server, but directly modifies the DOM (Document Object Model) in the client's browser. This type of XSS usually occurs when the JavaScript code of the web page incorrectly handles user input.

[0111] Hazards of XSS attacks: Stealing user information: Attackers can steal sensitive information such as user login credentials, session cookies, etc. Destroying web page content: Attackers can modify web page content to mislead users. Redirecting users: Attackers can redirect users to malicious websites. Executing malicious actions: Attackers can execute any JavaScript code on the user's browser, including downloading malware, launching DDoS attacks, etc.

[0112] Strategies to prevent XSS: Input validation: Perform strict validation on all user input and reject input that does not conform to the expected format. Output encoding: Encode user input appropriately before outputting it to the web page. For example, HTML entity encoding can prevent scripts from being executed by the browser. Use Content Security Policy (CSP): CSP is an additional layer of security that can reduce the risk of XSS attacks. It allows website administrators to define which dynamic resources are trusted. Use HTTP headers: Setting appropriate HTTP headers such as X-Content-Type-Options: nosniff and X-XSS-Protection: 1; mode=block can provide additional protection. Avoid using dangerous HTML and JavaScript functions: Avoid using functions such as eval(), innerHTML, etc. that may execute malicious code. Use security features of frameworks and libraries: Many modern web development frameworks and libraries provide built-in XSS protection features. Update and patch regularly: Keep applications and dependent libraries updated to fix known security vulnerabilities. Educate users and developers: Raise awareness of XSS attacks among users and developers and let them know how to handle user input safely. Specifically, dynamically updating the benchmark test case according to the updated test scenario keyword and the updated action to generate a corresponding new test case, which also includes

[0113] Performing the test scenario keyword update on the test scenario keyword model, and saving the update time;

[0114] Furthermore, the benchmark test case may be dynamically updated according to the updated test scenario keyword and the updated action to generate a corresponding new test case.

[0115] Test cases are a key component of the software testing process, defining how to verify that a specific feature or component of the software works as expected. A good test case should include a series of detailed steps to ensure that all aspects of the software are fully tested. The following are the elements that are usually considered when creating a test case: Test Case ID: A unique identifier used to track and reference the test case. Test Title: A brief description of the purpose of the test case. Test Objective: Detailed description of the test case's goals and expected results. Preconditions: Conditions that must be met before the test can begin, such as specific system states or data. Test Steps: Detailed steps required to execute the test case, usually listed in sequence. Test Data: Input data required to execute the test steps. Expected Results: The expected results after executing the test steps. Actual Results: The actual results recorded after executing the test steps. Test Status: The current status of the test case, such as "Passed", "Failed", "Blocked", "Not Executed", etc. Priority: A priority assigned based on the importance and risk level of the test case. Test Type: The type of test case, such as functional test, performance test, security test, interface test, etc. Automation Script: If the test case is automated, the name or reference of the script needs to be provided. Notes: Any additional information or notes, such as test constraints, special considerations, etc. Created By: The tester who created the test case. Created Date: The date the test case was created. Modified By: The person who last modified the test case. Modified Date: The date the test case was last modified.

[0116] Example

[0117] Suppose you want to create a test case for a simple login function:

[0118] Test case ID: TC_LOGIN_01

[0119] Test title: Verify that a user can successfully log in with valid credentials

[0120] Purpose of test: Ensure that the system can accept the correct username and password and allow the user to log in.

[0121] Prerequisites: The system is up and running. User accounts have been created.

[0122] Test steps:

[0123] Open the login page.

[0124] Enter a valid User Name.

[0125] Enter a valid password.

[0126] Click the 'Login' button.

[0127] Test data: Username: testuser; Password: password123

[0128] Expected results:

[0129] The system displays a welcome message. The user is redirected to the main interface. Actual result: [Fill in after test execution]; Test status: [Fill in after test execution]

[0130] Priority: High

[0131] Test type: Functional test

[0132] Automation Script: [provide script name or ID if applicable]

[0133] Note: None

[0134] Created by: [Tester Name]

[0135] Creation Date: [Creation Date]

[0136] Modified by: [name of person making the modification]

[0137] Modified Date: [Modified Date]

[0138] This example shows a basic test case structure. Actual test cases may vary depending on the complexity of the software and the testing requirements.

[0139] It should be noted that the historical logic of code usually refers to the record of how the code evolves and is modified over time during the software development process. These records are very important for understanding the evolution of the software, conducting code reviews, troubleshooting, regression testing, and maintenance. The following are some common concepts and tools related to the historical logic of the code: Version Control System (VCS): used to track the change history of files and directories. Common version control systems include Git, SVN, Mercurial, etc. Commit: The changes made by developers to the code, these changes will be recorded in the version control system. Each commit usually contains a set of related changes and will have a description message. Branch: A code line used to develop new features or fix defects. Allows developers to develop without affecting the main code line. Merge: Merge changes from one branch into another branch. Usually after completing a specific feature or fix, the changes are merged back to the main branch. Tag: A tag used to mark a specific commit, usually used for version release. You can quickly locate a specific version through a tag. Diff: Display the difference between two versions. Used to review code changes and understand the changes. Rollback: Undo previous commits and roll back the code to a certain historical state. Usually used to undo incorrect changes. Code Review: Team members review code changes to ensure code quality and consistency. It can be a formal process or an informal discussion. Continuous Integration (CI): The process of automatically building and testing code. Each commit triggers a build and test to ensure that the new code does not break existing functionality. Historical Analysis Tools: Some tools can help analyze the history of the code, such as Git's git log, gitblame and other commands. Understanding the historical logic of the code is especially important for developers who are new to the project, because it can help them quickly understand the code structure and development history of the project. At the same time, good version control practices are also a key factor in ensuring software quality and maintainability. If you need more specific help, such as how to use a specific version control tool, I can provide further guidance.

[0140] A test case generation method provided by the present embodiment first obtains an updated test scenario keyword corresponding to a test scenario keyword model, then determines the original test scenario keyword corresponding to the updated test scenario keyword, indexes the benchmark test case associated with the original test scenario keyword, and finally dynamically updates the benchmark test case to generate a new test case corresponding to the updated test scenario keyword. This solves the current problem that test cases require relevant personnel to jointly formulate a reasonable and effective test scope, which is more likely to lead to missed tests and under-tests, and that comprehensive and effective functional testing can be achieved in a short period of time by simply relying on manpower accumulation, resulting in a high degree of difficulty and unclear results.

[0141] At the same time, in this embodiment, according to the benchmark test case corresponding to the original test scenario keyword index, the benchmark test case is associated with the updated test scenario keyword and the update action, thereby realizing an overall update or field update of the benchmark test case alone, thereby avoiding the loss of test scope due to insufficient evaluation by all parties.

[0142] Furthermore, the test scenario keyword model is updated, and the update time is saved so that the historical record index can be available when the test case is called again in the future, so as to further query the historical logic.

[0143] See also Figure 2 , Figure 2 Schematic diagram of the structure of the test case generating device in the embodiment of the present application. Figure 2 As shown, specifically:

[0144] An acquiring unit 201 is used to acquire an updated test scenario keyword corresponding to the test scenario keyword model;

[0145] An indexing unit 202 is used to determine an original test scenario keyword corresponding to the updated test scenario keyword, and index a benchmark test case associated with the original test scenario keyword;

[0146] The test case generating unit 203 is used to dynamically update the benchmark test case according to the updated test scenario keyword and generate a corresponding new test case.

[0147] Optionally, the index unit 202 specifically includes:

[0148] A first indexing subunit, configured to index the original test scenario keyword corresponding to the updated test scenario keyword in the test scenario keyword model, and index a benchmark test case associated with the original test scenario keyword;

[0149] The update action subunit is used to compare the updated test scenario keyword with the original test scenario keyword to determine the corresponding update action. Optionally, the update action subunit is specifically used to update the updated test scenario keyword and the update action to the test scenario keyword model, and associate the benchmark test case with the updated test scenario keyword model.

[0150] Optionally, the test case generation unit specifically includes:

[0151] An update action analysis subunit, used to analyze the type of the update action and determine whether the update action of the corresponding benchmark test case is an overall update action or a field update action;

[0152] The trial case generation subunit is used to dynamically update the benchmark test case according to the update test scenario keyword and the type of the update action, and generate a corresponding new test case.

[0153] Optionally, it also includes:

[0154] The update time unit is specifically used to update the update test scenario keyword according to the test scenario keyword model and save the update time.

[0155] Optionally, it also includes:

[0156] The code history logic unit is used to generate benchmark scenarios based on the history logic of the called code;

[0157] The benchmark test case generation unit is further specifically used to dynamically update the benchmark test case according to the updated test scenario keyword and the updated action, and generate a corresponding new test case.

[0158] Optionally, it also includes:

[0159] A first acquisition unit, used to acquire at least two test scenario keywords and generate a corresponding test case dictionary;

[0160] The keyword model unit is used to obtain the corresponding test scenario keyword model generated by the test case dictionary and the preset benchmark dictionary model.

[0161] In the present embodiment, a test case generating device is provided, which first obtains an updated test scenario keyword corresponding to a test scenario keyword model, then determines the original test scenario keyword corresponding to the updated test scenario keyword, indexes the benchmark test case associated with the original test scenario keyword, and finally dynamically updates the benchmark test case to generate a new test case corresponding to the updated test scenario keyword. This solves the current problem that test cases require relevant personnel to jointly formulate a reasonable and effective test scope, which is more likely to lead to missed tests and under-tests, and that comprehensive and effective functional testing can be achieved in a short period of time by simply relying on manpower accumulation, resulting in a high degree of difficulty and unclear results.

[0162] At the same time, in this embodiment, according to the benchmark test case corresponding to the original test scenario keyword index, the benchmark test case is associated with the updated test scenario keyword and the update action, thereby realizing an overall update or field update of the benchmark test case alone, thereby avoiding the loss of test scope due to insufficient evaluation by all parties.

[0163] Furthermore, the test scenario keyword model is updated, and the update time is saved so that the historical record index can be available when the test case is called again in the future, so as to further query the historical logic.

[0164] The present application also provides another test case generation device, such as Figure 3 As shown, the device 10 includes:

[0165] One or more processors 110 and a memory 120 are described below by taking one processor 110 as an example. The processor 110 and the memory 120 may be connected via a bus or other methods, with connection via a bus being taken as an example.

[0166] The processor 110 is used to complete various control logics of the device 10, and it can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a single-chip microcomputer, an ARM (Acorn RISCMachine) or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination of these components. In addition, the processor 110 can also be any traditional processor, microprocessor or state machine. The processor 110 can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP and / or any other such configuration.

[0167] The memory 120 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as program instructions corresponding to the method for online processing of fixed asset data in the embodiment of the present invention. The processor 110 executes various functional applications and data processing of the device 10 by running the non-volatile software programs, instructions and units stored in the memory 120, that is, implements the method for online processing of fixed asset data in the above method embodiment.

[0168] The memory 120 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and applications required for at least one function; the data storage area may store data created according to the use of the device 10, etc. In addition, the memory 120 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 120 may optionally include a memory remotely arranged relative to the processor 110, and these remote memories may be connected to the device 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0169] One or more units are stored in the memory 120, and when executed by one or more processors 110, the following steps are implemented:

[0170] Obtaining updated test scenario keywords corresponding to the test scenario keyword model;

[0171] Determine an original test scenario keyword corresponding to the updated test scenario keyword, and index a benchmark test case associated with the original test scenario keyword;

[0172] The benchmark test case is dynamically updated according to the updated test scenario keyword to generate a corresponding new test case.

[0173] An embodiment of the present invention provides a non-volatile computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed by one or more processors, the above steps S101 to S103 are implemented.

[0174] As an example, non-volatile storage media can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) as external cache memory. By way of illustration and not limitation, RAM can be obtained in many forms such as synchronous RAM (SRAM), dynamic RAM, (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM). The disclosed memory components or memories of the operating environment described herein are intended to include one or more of these and / or any other suitable types of memory.

[0175] Of course, those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing related hardware (such as a processor, a controller, etc.) through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium, and the computer program can include the processes of the above-mentioned method embodiments when executed. The storage medium can be a memory, a disk, a floppy disk, a flash memory, an optical storage device, etc.

[0176] The present application provides a test case generation method, apparatus, device and storage medium, which first obtain an updated test scenario keyword corresponding to a test scenario keyword model, then determine the original test scenario keyword corresponding to the updated test scenario keyword, index the benchmark test case associated with the original test scenario keyword, and finally dynamically update the benchmark test case to generate a new test case corresponding to the updated test scenario keyword. This solves the current problem that test cases need to be jointly formulated by relevant personnel to have a reasonable and effective test scope, which is more likely to lead to missed tests and under-tests, and that comprehensive and effective functional testing can be achieved in a short period of time by simply relying on manpower accumulation, resulting in a high degree of difficulty and unclear results.

[0177] At the same time, in the present application, according to the benchmark test case corresponding to the original test scenario keyword index, the benchmark test case is associated with the updated test scenario keyword and the update action, thereby realizing an overall update or field update of the benchmark test case alone, thereby avoiding the loss of test scope due to insufficient evaluation by all parties.

[0178] Furthermore, the test scenario keyword model is updated with the test scenario keyword, and the update time is saved so that a historical record index can be available when the test case is called again in the future, so as to further query the historical logic.

[0179] It should be understood that the application of the present invention is not limited to the above examples. For ordinary technicians in this field, improvements or changes can be made based on the above description. All these improvements and changes should fall within the scope of protection of the claims attached to the present invention.

[0180] It should be noted that if software tools or components other than those of our company appear in the embodiments of the present application, they are only used for illustrative purposes and do not represent actual use.

Claims

1. A test case generation method, characterized in that: include: Obtaining updated test scenario keywords corresponding to the test scenario keyword model; Determine an original test scenario keyword corresponding to the updated test scenario keyword, and index a benchmark test case associated with the original test scenario keyword; The benchmark test case is dynamically updated according to the updated test scenario keyword to generate a corresponding new test case.

2. The test case generation method according to claim 1, characterized in that: The step of determining an original test scenario keyword corresponding to the updated test scenario keyword and indexing a benchmark test case associated with the original test scenario keyword specifically includes: Indexing the original test scenario keyword corresponding to the updated test scenario keyword in the test scenario keyword model, and indexing the benchmark test case associated with the original test scenario keyword; The updated test scenario keyword is compared with the original test scenario keyword to determine the corresponding update action.

3. The test case generation method according to claim 2, characterized in that: The step of comparing the updated test scenario keyword with the original test scenario keyword to determine a corresponding update action, further comprising: updating the updated test scenario keyword and the updated action to the test scenario keyword model; The benchmark test case is associated with the updated test scenario keyword model.

4. The test case generation method according to claim 3, characterized in that: Dynamically updating the benchmark test case according to the updated test scenario keyword and generating a corresponding new test case specifically includes: Analyze the type of the update action and determine whether the update action of the corresponding benchmark test case is an overall update action or a field update action; The benchmark test case is dynamically updated according to the update test scenario keyword and the type of the update action to generate a corresponding new test case.

5. The test case generation method according to claim 4, characterized in that: Dynamically updating the benchmark test case according to the update test scenario keyword and the type of the update action to generate a corresponding new test case, the method further includes: The updated test scenario keyword is updated according to the test scenario keyword model, and the update time is saved.

6. The test case generation method according to claim 1, characterized in that: Before obtaining the updated test scenario keyword corresponding to the test scenario keyword model, the following steps are also included: Generate benchmark scenarios based on the historical logic of the invoked code; A corresponding benchmark test case is generated through the test scenario keyword model and the benchmark test scenario.

7. The test case generation method according to claim 1, characterized in that: Before obtaining the updated test scenario keyword corresponding to the test scenario keyword model, the following steps are also included: Get at least 2 test scenario keywords and generate corresponding test case dictionaries; The corresponding test scenario keyword model is generated through the test case dictionary and the preset benchmark dictionary model.

8. A test case generating device, characterized in that: include: An acquisition unit, used for acquiring an updated test scenario keyword corresponding to the test scenario keyword model; An indexing unit, configured to determine an original test scenario keyword corresponding to the updated test scenario keyword, and index a benchmark test case associated with the original test scenario keyword; The test case generation unit is used to dynamically update the benchmark test case according to the updated test scenario keyword and generate a corresponding new test case.

9. A test case generation device, characterized in that: The device comprises at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the test case generation method described in any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by one or more processors, the one or more processors can execute the test case generation method described in any one of claims 1-7.

Images