Test Case Specification v2.0 and test case Specification v2.0
1. Introduction
The software test specification is written to provide a guide for testers during the preparation of test cases.
Purpose
Testing is an indispensable step for Software Delivery users. It has four purposes: 1) find as many bugs as possible in the system; 2) Pay attention to user needs; 3) analyze and evaluate software quality risks based on test results; 4) identify defects in software development. You can query the content on the Internet.
2. Understand the business
Before writing test cases, you must understand the business logic of the system, refine the system to the modules of each subsystem, from the macro to the micro level, from the peer level, understand the relationship between superiors and subordinates and interface interaction between systems.
Just like viewing directories, read all the headlines first, then the subtitles under the headlines, and then view the specific content of each page.
Example: new student admission-new student admission Administrator
Personal understanding is required for specific business + communication with project developers
3. Compile the use case Specification
3.1 numbering rules
The Use Cases of the. NET cloud platform for colleges and universities will be filled in the Zen road for management. Refer to the prototype diagram navigation bar.
Format requirements: No. (first letter of the system + 001) + Module name + Page name + query case
For example:
3.2 prerequisites
The prerequisites in the use case are optional. However, if you have any premise, write it down.
For example:
1) To delete student information, You must select the student information (check box) to delete it.
2) Score Management: This test can only be performed after the test is completed and data is available.
3.3 write test steps
Write test cases. In simple terms, the operation steps/input actions are classified according to the operation steps (correctness test, fault tolerance test, Interface Test, and database test) to obtain the expected results. After the operation is completed, the actual result is displayed.
3. 3.1. correctness Test
Input the user's actual data to verify that the system meets the requirements of the requirement specification. the test points in the test case should first ensure that the functions in the requirement specification should be at least covered and normal.
Example: qx001-cloud platform-Application Management-default list background Use Cases
3. 3.2 Fault Tolerance Test
When illegal data is input (illegal data type, non-conforming data, and overflow data), the program should be able to give a prompt and handle it accordingly.
Example: qx001-cloud platform-Application Management-default list background-add System Use Cases
3.3. Inter-Interface Test
Test the coordination between modules and ensure the consistency and correctness of data input and output.
3. 3.4
, Database Testing
Test the database structure, data tables, and data calling relationships of the software system according to the database design specifications.
Example: qx001-cloud platform-Application Management-default list background-add System Use Cases
4. Other Test Cases
4.1 null test cases
A use case is generated for each required data item (except null values are not provided, such as a drop-down box without null values and a single-choice button group with default values). The expected result indicates that the data item is null.
Example: xsrx001-Student Management-A3 improve student personal information use cases
4.2 overflow Test Cases
Enter a test case out of the value range in the data input box. The prompt box prompts that the value is out of the range.
For example:
Prerequisites
All organizations: Shengke College, Shuxin College, liberal arts college, Physical Education College, foreign language college
Priority: 1 ~ Positive integer between 99
College phone number: the maximum length cannot exceed 11
4.3 incorrect speculation
Based on the rich experience of the testers and the intuition they have developed during the testing process, the possible errors are raised (for junior testers, it is still very difficult and difficult to achieve this, accumulate more experience !)
4.4 comprehensibility
Understanding and using the difficulty of the system (user-friendly interface)
The comprehensibility test allows the tester to operate the system from the user's perspective to see if expected results can be obtained.
Example: xsrx001-Student Management-A3 student information page-personal information use case
Understand how each module operates
5. Use Case Control
5.1 case level
In the process of writing a use case, the level of the write case varies according to the priority of the function. Generally, we have 3-4 levels.
How can we determine the level of the use case? Generally, it is determined based on the tester's understanding of the requirements and the importance of the functions in the project plan, whether the project is in the development or optimization phase.
The smaller the number, the higher the priority.
Case level is a good reference when assigning test tasks.
5.2 Granularity Control
Note the issue of granularity when writing test cases. The granularity can be large or small. You can write a use case on one interface or multiple use cases for one function.
How can we determine the granularity? 1. Determine the ease of use cases based on the test case level. 2. Determine the granularity of test cases as required by the test team lead.
On the cloud platform of colleges and universities, the four subsystems of evaluation, foundation, admission to new students, and permissions must all be functional. The granularity of individual functions can be negotiated with the team lead.
Interface level: the interface function is very simple and can be written as interface-level use cases;
Function level: each function is one or more use cases;
Combination functions: these functions are associated and can be reused multiple times after being written;
6. Use Cases-Zen road 6.1 and demonstration
I wrote the use case, but I don't know which module to fill in the Zen Road?
A. Open the Zen Road and create A new use case
B. Add use cases. The product module is the branch of the Cloud Platform + blue box on the right.
6.2. Example:
1) System Selection error (refer to 6.1)
Note: The content of all the above images is for reference only. The compiling case should also be based on the tester's understanding of the requirements.
Conclusion: After writing this document, I have a different understanding of the test cases. Tools and documents are combined to improve efficiency and work ability.
Theoretically, you can refer to the previous article "Test Case Specification V1.0".