The confusion of newcomers in the workplace about test cases is nothing more than the following points
1. What is a test case and why should you write a test case?
2. I don't know how to write, and I don't know whether the writing is complete.
1. What is a test case?
Wikipedia's definition:
A test case is a description of a specific software product testing task, embodying testing schemes, methods, techniques and strategies. Its content includes test objectives, test environment, input data, test steps, expected results, test scripts, etc., and finally forms a document.
Simply think that a test case is a set of test inputs, execution conditions, and expected results prepared for a special purpose to verify whether a specific software requirement is met.
Second, why design test cases?
1. Guide the testing work
Test cases can convert product requirements into actionable steps [steps, operations, inputs, outputs, priorities, etc.],
In order to guide the testers to test according to the department.
2. Verify whether the demand for the product is reasonable
The logical relationship of the product will be scrutinized and verified during the use case design, so as to draw corresponding conclusions.
3. Help review requirements and supplement requirements details
When writing test cases, various normal abnormal test scenarios [reverse thinking], data [boundary values, etc.], compatibility, performance and other tests will be considered, and certain supplements and improvements will be made to the processing of these details.
4. Deepen the testers' understanding and impression of the product
It may take two hours during the requirements review, and a requirement that requires two hundred hours of investment is talked about. Most of the content is just a general explanation. When writing a use case, the tester interprets the requirements sentence by sentence, so as to convert them into executable use cases. This stage is the moment when the test understands the requirements more thoroughly.
5. It is convenient for the test leader to follow up the test progress
The person in charge evaluates the corresponding test case execution man-hours according to the number and complexity of the use cases; judges the output of the test process with the test records; thus follows up the corresponding test progress and output.
6. Help discover and expand the scope of testing
Use case design can be combined with test methods to expand the scope of testing, not limited to the superficial content seen by the eyes.
7. It is convenient for regression testing to check whether the BUG will still appear
During regression testing, based on the results of a round of testing, focus on retesting the problematic use cases and functions, thereby avoiding disorderly and unfocused regression testing.
8. The test results can reflect the test pass rate as a product quality evaluation
Test results can be counted, and the statistical dimensions can include: use case execution rate, defect discovery rate, and one-round test pass rate
9. Train newcomers, improve the efficiency of newcomer testing, and save guidance time for newcomers
Newcomers to product guidance can read PRD, newcomers to development guidance can read code, and what to look at for newcomers to test guidance, of course, are use cases. As the core output of testers, use cases are also the testers' knowledge of the product.
3. How to design test cases
Test case design and analysis is a divergent process, and we have to consider various scenarios and data.
Writing test cases is a convergent process, and we need to convert divergent thinking into executable use cases one by one.
In order to avoid problems such as redundant, multiple, messy, repetitive, and invalid use cases, use case design usually follows the following principles.
From left to right, top to bottom:
The layout of elements and the user's operations are all customary "from left to right, from top to bottom", and this principle is also followed when designing use cases.
In the face of a requirement or a brand new functional module, in order to avoid loss of test objects and disorderly design of use cases when designing use cases, we follow the principle of "from left to right, from top to bottom". Use case design is performed on the test objects seen in turn, the test points diverge, and a complete test case is finally output.
The use cases written according to the above principles cover all measurable objects, and basically there will be no missing or missing test objects.
However, it is easy to miss the combination of multiple test object scenarios and application-type test scenarios.
From outside to inside, from point to surface:
For test scenarios with deep test paths and long links, we follow the design idea of "from outside to inside" and design objects on each layer of the test path one by one.
Then integrate paths and test objects "from point to surface" to enrich scenario-type, application-type, and combination-type use cases.
In this way, the use cases designed following the above principles include all test objects on each level, all test objects on each path, the combination of objects and paths, and the combination of paths and paths. test object.
In addition, combined with brainstorming, use case review and other means, the completeness and coverage of use cases are continuously promoted to a relatively high level.
Common tools for writing test cases include Excel and Xmin, and the corresponding templates are for reference:
Finally: The complete software testing video tutorial below has been organized and uploaded, and friends who need it can get it by themselves [Guaranteed 100% free]
Software Testing Interview Documentation
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Ali, Tencent, and Byte, and some Byte bosses have given authoritative answers. Finish this set The interview materials believe that everyone can find a satisfactory job.
All data acquisition
