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
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 characters;
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.)
The use case numbers of test cases in different stages have different rules:
(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: photos, contacts, MP3;
(3) Low-level needs: step counting, radio, etc.
It should also be noted that the importance level of test cases for **normal conditions** is higher than the importance level of test cases for **abnormal conditions**.
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 user name 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 setting of specific preset conditions. 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.
It is forbidden to use too much descriptive language. If it is a file, you will be prompted to choose 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 incomplete and incomplete, the entire test case will be affected.
When we write the expected output, we can consider the following three aspects:
(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 login success or login failure.
(2) Database changes: After the operation steps are completed, the records in the database will change accordingly, such as testing the delete function. After clicking delete, the record in the database will be deleted.
(3) Changes in related information: After the operation steps are completed, 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
