Test Case Specification v2.0 and test case Specification v2.0

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".