Why do we need to write a test case? Test students should all know the importance of test cases. Test cases are the basis for our testing and an indispensable test document in the testing process.
1. Use case writing specification purpose:
1. Improve the readability, executable and rationality of test cases.
2. Test cases will be read, reviewed or executed by development, products, etc.; they are also more likely to be used by other testers or new employees as a reliable basis for familiarizing themselves with the current product. It is the most direct and fastest way to understand without looking at requirements or interactions Product documentation.
2. Design use case process:
1. Participate in the requirements review meeting: that is, the product explains the requirements, and the requirements include the functions that need to be realized.
a. Before the requirements review, you should roughly read the requirements documents, and mark the sentences that you have doubts or do not understand;
b. When participating in the requirement document review meeting, keep up with the product idea, understand the background of the requirement, the content of the requirement, etc. And while listening, form the product form in your mind, find unreasonable and questionable places, and promptly raise and urge the product to be resolved;
c. The meeting determines the scope of the test on the spot, determines the test priority of each requirement, and determines the passing standard of the test.
2. Interpret the requirements document word by word, and be familiar with business requirements (high-level goals of the organization or customers), functional requirements (the software functions that developers must implement in the product), user requirements (from the perspective of customers, user goals, or user requirements) Tasks that require the system to be able to complete)
a. Split the demand points and sort out the functional modules:
- Business functions: functions directly related to the user's actual business
- Data constraints: the display range of data, the relationship between data
- Permission constraints: the processing of functions by different role permissions
- Edit Constraints: Required restrictions on data entry items
- Auxiliary function: some functions or details that assist in the completion of business functions
- Ease of use requirements: details of functions that are easy to use
- Performance Constraints: Performance requirements that must be met when performing a function
3. Write test cases
1. Design principles:
a. The test cases should cover all the functions in the requirements document.
b. Requirements and simulation of real scenarios: In the process of writing test points, real usage scenarios must be considered
c. Test case design should focus on the impact of new requirements on original functions
d. The design of test cases should focus on the association/reuse modules, and the modules whose functions affect each other
e. The design of test cases should include various types of test cases. When designing test cases, in addition to meeting the basic functional requirements of the system, various abnormal conditions, boundary conditions and the ability to withstand pressure should also be considered
f. Divide system/function modules and write according to module classification
g. The test case should have an accurate definition of test function points, test conditions, test steps, input values and expected results. On what page, what button to click, what data to enter
2. Writing content
a. Use case name: 1) The commonly used structure "subject, predicate, object"; 2) The name is concise and easy to understand, do not include specific operation steps;
b. Preconditions: 1) All prerequisites that need to be done before executing the use case test steps. In principle, all use cases have preconditions; 2) Complete and clear, including entry, account type, account authority, data preparation, etc.
c. Operation steps: 1) The operation steps are clearly described. For example: on what page, what link or button is clicked; the page entry, link, and button name must be written clearly; 2) There is a one-to-one correspondence between the operation and the result, but the result check should not be included in the operation; 3) The use case description does not include Hypothetical words are allowed, such as: if, maybe, maybe, when... etc.;
d. Expected result: 1) In principle, each use case must have an expected result, and the result cannot be empty; 2) The result can only contain results, and no steps; 3) When a result has multiple checkpoints, ensure the checkpoint whole;
Finally, the maintenance of test cases is also indispensable. After the end of our current project, we must file it in time and upload the svn or qc for subsequent viewing.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey, and I hope it can help you! Partners can click the small card below to receive