1. Eight elements of general test cases
1. Use case number;
2. Test items;
3. Test title;
4. Importance level;
5. Preset conditions;
6. Test input;
7. Operation steps;
8. Expected output
At the same time, I have also prepared a software testing video tutorial for everyone (including interviews, interfaces, automation, performance testing, etc.), which is below. If you need it, you can watch it directly, or you can directly click on the small card at the end of the article to get the information document for free.
Where to watch software testing video tutorials:
Bilibili Fengshen’s interface testing tutorial, complete 70 projects in 30 days (including automated testing and performance testing), you will be employed immediately after completing the course, and you will be free of charge forever!
2. Detailed analysis of the eight elements of general test cases
1. Use case number
It is generally a string composed of numbers and characters, which can include (underscores, word abbreviations, numbers, etc.), but it should be noted that try not to write Chinese Pinyin, because Pinyin may have several meanings, which may cause Garbled code;
The use case number is unique and easily identifiable. (For example, we uniquely identify a person: No. xx, xx District, Shanghai, China - xx Building - xx Room - xxx. This identification will be unique.)
There are different rules for case numbering of test cases at different stages:
(1) System test case: product number-ST-system test item name-system test sub-item name-XXX
(2) Integration test case: product number-IT-system test item name-system test sub-item name-XXX
(3) Unit test case: product number-UT-system test item name-system test sub-item name-XXX
**The product number is also called the project identification. Each company has several different projects or products. How to distinguish them? This requires a product number. Each company has its own set of rules for defining product numbers, and the number of each existing product has been formulated, so you can just use it.
**ST, IT, and UT after the product number correspond to the system test stage, integration test stage, and unit test stage respectively. In actual work, some companies will omit the product number and testing stage.
**After the test phase is the name of the test project, which corresponds to the larger and more systematic test points.
**After the test project name is the name of the test sub-project. Some tests do not have sub-project names. Only when the test item is relatively strong will there be a Chengdu sub-item (for example: we want to test whether the user can successfully log in to this Function, then we can divide it into many sub-items, QQ login, email login, etc.).
**After the test sub-item name is the specific use case number, which can be a number: 01, 001, 002, etc.
2. Test items
The test item corresponds to the sub-item name in the test case.
(1) System test case: corresponds to a function point (functional test), performance indicator (performance test), interface control (GUI test), etc.
(2) Integration test cases: correspond to integrated module functions or interface functions.
(3) Unit test case: corresponding function name.
3. Test title
The test title considers how to complete the test project, or from which angle the test project is tested. Some companies also name it test purpose. The test title must be simple and summary; it should reflect the starting point and focus of the test.
4. Importance level
The importance level of use cases is generally divided into three levels: high, medium and low.
High level: Corresponds to use cases that ensure the basic functions, core business, important features, and actual frequency of use of the system;
Medium level: Corresponds to test cases with an importance between high and low;
Low level: Test cases corresponding to modules or functions that are not frequently used in practice and have a relatively large impact on system business functions.
**Take an example of a mobile phone:**
(1) High-level requirements: normal call function and text message function;
(2) Medium-level requirements: taking photos, contacts, MP3;
(3) Low-level needs: step counting, radio, etc.
Also note that test cases for **normal situations** have a higher importance level than test cases for **abnormal situations**.
5. Preset conditions
Test cases need to meet some preconditions before execution, otherwise the test case cannot be executed. These preconditions are preset conditions.
Preset conditions are divided into two situations:
(1) Environment settings.
For example: to test the function of opening files in Word, the preset condition is: the file to be opened needs to be prepared in advance;
For example: the preset condition for successful login is: the username has already been registered.
For example: the preset conditions for successful product purchase are: the product, shipping area, and payment method have been configured in the backend. (2) Other test cases that need to be run first. Some operating systems are more complicated. If they all start from the very beginning, it will be more troublesome to write the use cases. In this way, the test cases to be run first can be set in the preset conditions. Later use cases only need to write subsequent operations.
For example: when testing an automatic teller machine, there is a test for entering account information, and there is a test for entering the amount to withdraw money. The preset conditions for the latter can be written as a test case for entering correct account information.
Note: Different companies will have their own regulations regarding the specific preset condition settings. For example, some companies do not allow the second situation to occur.
6. Test input
The external information that needs to be processed during use case execution includes manual input, files, database records, etc., depending on the specific circumstances of the software test case.
Do not use too much descriptive language. If it is a file, you will be prompted to select a path. It is best to be specific so that others can understand and operate it easily.
7. Operation steps
Clearly describe the specific operating steps during the test execution process so that the test executor can complete the test case execution according to the operating steps.
8. Expected output
Expected output is a very important part of the test case. The expected output can verify whether the object under test is working normally. If our expected output is not written completely and comprehensively, the entire test case will be affected.
We can consider the following three aspects when writing expected output:
(1) Interface display: After the operation steps are completed, the interface will be displayed; for example, if we test the user login function, the interface may display successful login or failed login.
(2) Database changes: After the operation steps are completed, the records in the database will undergo corresponding changes, such as the test of the delete function. After clicking delete, the record in the database will be deleted.
(3) Changes in related information: After the execution of the operation steps, some information related to the object under test will change, such as: testing the logout function. After clicking logout, the previously accessible pages will no longer be accessible.
3. Test case template
4. Summary
PS: Here is a collection of self-study tutorials for software testing. It should be very helpful for those who are developing in the testing industry. In addition to basic introductory resources, bloggers also collect a lot of advanced automation resources. From theory to practice, only by integrating knowledge and action can you truly master it. The full set of content has been packaged on the network disk, and the total content is close to 500 G.
☑ 240 episodes - a complete set of video courses from zero to mastery
☑ [Courseware + Source Code] - complete supporting tutorials
☑ 18 sets - source code of practical testing projects
☑ 37 sets - testing tool software package
☑ 268 - real interview questions
☑ 200 templates - Interview resume template, test plan template, software test report template, test analysis template, test plan template, performance test report, performance test report, performance test script case template (complete information)
These materials should be the most comprehensive and complete preparation warehouse for friends who do [software testing]. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you! Everything must be done early, especially in the technical industry, where technical skills must be improved.
