Test Case Specification v2.0

1. Introduction

The software Test specification is written to provide a guide to testers in the process of writing test cases.

Test purpose

Test is the software delivery user before the use of an indispensable link, it exists for the purpose of four: 1) to find as much as possible to find the bug;2 in the system) to focus on the needs of users; 3) analyze and evaluate the quality risk of the software according to the final results of the test; 4) find defects in the software development process. Specific content can be online query.

2. Understand the business

Before writing test cases to understand the business logic of the system, the system to each subsystem module refinement, from macro to micro, from the same level of relations, subordinate relations and interface between the various systems to understand the interaction.

Just like the table of contents, look at all the headlines first, then look at the headlines under the headline, and then look at the specific content of each page.

For example: Freshman admission-freshman admissions Manager

Specific business needs personal understanding + more communication with project developers

3. Writing use case specification

3.1, Number specification

. NET version of the university cloud platform use cases will eventually be filled in Zen road management, referring to the prototype map navigation bar.

Format requirements: Number (System initials +001) + module name + page name + query case

For example:

3.2. Pre-conditions

Preconditions in use cases are optional. But if there is a premise, write it.

Like what:

1) Delete Student information, to select Secondary School information (check box) can be deleted

2) performance management, need to finish test, there is data to conduct this testing

3.3. Write test steps

Writing test cases, simply speaking, is the operation step/input action, according to the classification of the Operation steps (correctness test, fault tolerance test, interface test, database test), to obtain the expected results. When the procedure is completed, the actual results are obtained.

3.3.1, correctness test

Enter the user's actual data to verify that the system meets the requirements of the requirements specification; Test points in test cases should be guaranteed to cover at least the functions in the requirements specification and are normal.

Example: qx001-Cloud Platform-Application Management-default list background use case

3.3.2, fault tolerance test

Enter illegal data (illegal type, non-conforming data, overflow data, etc.), the program should be able to give hints and handle accordingly.

Example: qx001-Cloud Platform-Application Management-default list background-add system use cases

3.3.3, inter-interface testing

Test the coordination between each module, the consistency and correctness of data input and output.

3.3.4 , Database testing

According to the database design criterion, the database structure of software system, data table and the data call relation are tested.

Example: qx001-Cloud Platform-Application Management-default list background-add system use cases

4. Test cases in other ways

4.1. Null value test Case

For each required item, a use case is generated (except for null values, such as a drop-down box without a null value, a group of radio buttons with default values), and the expected result indicates that the data item is empty.

For example: xsrx001-Student management-a3 Perfect student personal information use case

4.2. Overflow test Case

Enter a test case outside the value range for the Data entry box. The prompt box can prompt for values out of range.

For example:

Pre-conditions

All organizations: Academy of Health Sciences, School of Letters, Faculty of Arts, Institute of Foreign Languages

Priority range: positive integers between 1~99

College Phone: Maximum length cannot be greater than 11

4.3. False speculation

Based on the experience of the testers and the intuition developed during the testing process, a possible error is raised (for junior testers, there is a lot of difficulty and deviation to do this, so try to accumulate experience!). ）

4.4. Understandable

Ease of understanding and use of the system (interface-friendly)

Comprehensible testing, the tester can stand at the user's point of view, the system to operate, to see if the expected results can be obtained.

For example: xsrx001-Student Management-A3 Perfect Student Information page--Personal information use case

Understand how each module operates

5. Use Case control

5.1 Use-case levels

In the process of writing use cases according to the priority of the function, write the use case level is also different, generally we divide 3-4 levels.

How do you determine the class of use cases? It is generally determined by the tester's understanding of the requirements and the project plan, the importance of the function or whether the project is in the development phase or the optimization phase.

The smaller the number, the higher the priority

The use-case level is a good reference when assigning test tasks.

5.2 Granularity Control

Writing test Cases there is one more granular issue to be aware of. Granularity can be large and small, written use cases can be an interface for a use case, you can also write multiple use cases for a function.

How to determine the size of the granularity? 1, according to the level of use cases to determine the degree of ease of use 2, according to test leader requirements of the test case granularity size.

In the university cloud Platform, the evaluation of teaching, basic, freshman admission and the authority of four subsystems, the granularity required to reach the functional level. Individual functional granularity can be negotiated with the leader.

Interface level: The interface function is very simple, can be written as interface level use case;

Functional Level: Each function is one or more use cases;

Combination function: Several functions are associated, and the written one can be reused after several times;

6. Use case-Zen Road 6.1, demonstration

The use case has been written, but I do not know which module to fill the Zen path.

A. Open the Zen Road and build a new use case

B, add use cases. The product module is the corresponding branch of the university cloud Platform + right blue box.

6.2, the problem example:

1) System selection error (refer to 6.1 A)

Note: All of the above image content is for reference only, and the writing use case should be based on the testers ' understanding of the requirements.

Summary: After writing this document, there is a different understanding of the test case. Tools and documentation combine to improve efficiency and ability to work.

Theoretical can look at the previous article "Test Case Specification V1.0"

Test Case Specification v2.0