How to write effective test cases

Reprint how to write effective test cases

A test case is a document about a specific test step that describes the input parameters, conditions, and configuration of the test, as well as the expected output, to determine whether the software being tested is working properly.

Designing, writing, and executing test cases is an important part of a test activity, and test cases are typically managed by a test case management system or tool.

First, the principle of writing test cases

The importance of test cases is beyond doubt, it is the core of the whole process of software testing, is the basic basis for testing execution. Test case writing should follow the principles:

1. Test cases to reach the maximum coverage of the functional point of the software system.
2. Test cases should have an accurate definition of the test function points, test conditions, test steps, input values, and expected results.
3. The design of the test case should include various types of test cases. In the design of test cases, in addition to meet the basic functional requirements of the system, you should also consider the various anomalies, boundary conditions and the ability to withstand pressure.
4. Management of test cases. Use a test case management system to manage test cases.

Characteristics:

A good test case should have a high probability of discovering a bug that has not yet been discovered, and a successful test case can find an error that has not yet been discovered, usually a good test case has the following characteristics:

1. Probability of having a high discovery error
2. Steps for no redundancy testing and redundancy
3. Test is "best category"
4. Neither too simple nor too complicated
5. Cases are reusable and easy to follow
6. Ensure that the system meets functional requirements

Test cases can not be designed seamlessly, and can not fully meet the requirements of software coverage, test execution will certainly find some test paths or data in the use cases are not reflected in the case, then it should be added to the use case library, in order to facilitate others and subsequent version of the test.

Second, how to write test cases

There is a lot of information about the test cases, which can be added and deleted according to the actual situation, in general, a good test case should contain the following information:

1. Product-related information

1. The name of the SOFTWARE PRODUCT or project
2. Version of a software PRODUCT or project
3. Function Module Name
4. Function description
5. Test platform These information suggestions can be selected manually in the test case.

2. Basic record information

1. Test Case Warehousing
2. Test Case Storage Time
3. Test Case Updater
4. Test Case Update Time

These information suggestions can be generated automatically by test cases.

3. Properties of test Cases

1. Test case ID: ID of the test case (automatically generated by the case management system for easy tracking management)
2. Test Case Name: The name of the test case
3. Test function points: functional checkpoints for testing
4. Test Purpose: Test purpose of the test function point
5. Test level: Master path test, smoke test, basic function test, detailed function test.

Description of the Test level:

• Master Path testing: Test cases where the main path of the key modules and functions of the requirements is controlled, the main paths are tested for the design probe module, the testability of the program is tested (Testability also includes the success of the installation test)
• Smoke test: Control the main function path of all modules in the requirements, the main path test case is a subset of smoke test cases, smoke test for the main basis for the regression test case.
• Basic Functional testing: the basic functional path of all modules and functions in the control of requirements and overall design, the basic function test is the main basis for testing the non-important level module of software PRODUCT, writing the complete automatic test script.
• Detailed functional testing: to test each module and function of each level, various types, against the functional path of all modules and functions in the overall design. Detailed functional test case for key modules, the main basis for error-prone modules

6. Test type: Functional test, boundary test, anomaly test, performance test, stress test, compatibility test, safety test, recovery test, installation test, interface test, start/stop test, document test, configuration test, reliability test, usability test, multi-language test.
7. Preset conditions: Description of special conditions or configurations of the test
8. Test steps: Detailed description of the test process, the operation of the case of fewer than 15 recommendations.
9. Expected results: expected test results

Example description

For example: If the current test of China Mobile interconnection SMS gateway can send SMS to the Chinese unicom Internet connection, test cases are designed as follows:
(1) test Case id:tc000001
(2) test case name: China Mobile Global Mobile phone users to successfully send SMS to China Unicom mobile phone users
(3) Test function point: China Mobile Global Mobile phone users successfully SMS to China Unicom mobile phone users, China Unicom Gateway back to a successful status report
(4) Test Purpose:
A, China Mobile Internet Message Gateway can correctly handle the global users sent to the Chinese unicom users SMS;
B, China Mobile Internet Message Gateway can correctly handle the Chinese Unicom connected SMS Gateway returns a successful status report.
(5) Test level: basic function test
(6) Test type: Functional test
(7) Pre-set conditions: each gateway entity in accordance with the relationship between the Network diagram, the connection between the entities and communication is normal.
(8) Test steps:
A, China Mobile Global mobile phone users (13901000001) to the Chinese Unicom mobile phone users (13001000001) to send MO text messages, the content of "testing", the purpose of the number of China Unicom to fill the mobile phone number;
B, China Unicom connected text message gateway to the Chinese Unicom users after the successful, to China Mobile Internet Message gateway to return an identity successful status report.
(9) Expected Result:
A, China Unicom mobile phone users (13001000001) received a text message, the content of the "test", the source number is China Mobile global user number (13901000001);
B, in the China Mobile Internet Message Network on the production of SMO, wherein the "short message sent status" filled 0 (indicating success), "source phone number" 13001000001, "the purpose of mobile phone number" is 13001000001.

Three, the test case template

The following is a template for a complete test case:

Four. test Case design Process

The first thing you need to know about a brand new product is the relationship between the product requirements document and the product module. You then need to write the master path test case and smoke test case that corresponds to all requirements from the requirements document, and this time also includes a certain basic path test case or even a detailed test case. At this time, because there is no direct use of the product experience, writing test cases to consider a wide range of not too fine. Continue reading the product feature definition document and write all the functional definitions directly to the relevant test case, at this time, it is best to have a certain touch on the program itself, deepen the understanding of the program, in order to write better, more comprehensive test case. Finally, in the actual test, we also need to continue to expand, modify the previous test cases, to obtain a complete basic functional test cases and detailed test cases. For a product that already has a certain or a majority of cases, whether or not the tester is familiar with the product, the main task is to read, check the requirements and related changes, and then understand, expand and modify the original case. This is the reuse/re-use of the case. When designing a test case, you need to have a clear test idea, what to test, what order to test, and what needs to be covered. Test case writers should not only master the technology and process of software testing, but also have a thorough understanding of the design of the software under test, the functional specification, the user trial scenario, and the structure of the program/module.

The test case design typically consists of the following steps:
1, test requirements analysis from the software requirements document, to find out the requirements of the software/module to be tested, through their own analysis, understanding, collation as a test requirements, clear what the test object has the function. Testing requirements are characterized by the inclusion of software requirements and testability.

Test requirements should be summarized, categorized or subdivided on the basis of software requirements to facilitate test case design. The relationship between test sets and test requirements in a test case is a many-to-one relationship where one or more test case sets correspond to a test requirement.
2, business process analysis software testing, not simply a function-based black box testing, but also need to test the internal processing logic of the software. In order not to omit test points, it is necessary to have a clear understanding of the business processes of software products. It is recommended that you draw the business process of the software before making a complex test case design. If you already have a business process design in your design document, you can complement your existing processes from a test perspective. If the business process cannot be obtained from the design, the test engineer should communicate with the developer by reading the design document and finally drawing the business flowchart. Business flowcharts can help you understand the processing logic and data flow of the software, thus guiding the design of test cases.

From the business process, you should get the following information:

A, what is the main process
B. What are the conditional alternative processes?
C, what is the data flow
D, what are the key judging conditions?
3. Test Case Design
After completing the test requirements analysis and software process analysis, start to design test cases. The types of test case design include functional testing, edge

Testing, anomaly testing, performance testing, stress testing, etc. In use case design, in addition to the functional test with exceptions, should consider the boundary, different

and performance, so that more hidden issues can be found.

The test case design methods of black box test are: Equivalence class division, Boundary value Division, causality diagram analysis and error guessing, test of white box test

Examples of design methods are: statement coverage, decision coverage, conditional coverage, decision/condition coverage, multiple conditional overrides. Here we mainly discuss the black box test

Try. When designing test cases, you can use the Software test case design methodology, combined with previous requirements analysis and software process analysis to set up

Millions

Functional testing: Test whether a function meets the requirements of the definition, the function is correct, complete.

The right technology: Functional testing, equivalence class partitioning, derived from business requirements and design instructions

Boundary test: Tests the boundary condition of a feature.

Suitable technology: Boundary value Division

Exception testing: For certain functions, the boundary condition cannot be understood simply or some operations are not entirely correct, but they can occur

A situation like this requires writing a related anomaly test.

Suitable technologies: Special business processes, error guessing, boundary value analysis, internal boundary value testing, and

Performance testing: Check that the system meets the performance requirements specified in the requirement, and the performance mainly includes understanding the internal and external performance factors of the program. Internal performance factors include the configuration of test environment, system resource usage, external factors including response time, throughput, etc.

Suitable technology: Business requirements and design instructions exported tests

Stress testing: Stress testing, also known as strength testing, is mainly to check the operating environment of the system under the limit of the ability of the software to run, for example, to a considerable load or network traffic to the application software Compatibility test: Test software products on different platforms, different tools, the same tools under different versions of the compatibility of features.

4. Test Case Review

After the test case design is complete, in order to confirm the test process and method is correct, whether there are missing test points, the test case needs to be reviewed.

Test case reviews are usually arranged by the test leader, and the participants include: test case designers, test leader, project managers, development engineers, and other related development test engineers. The test case review is complete, and the test engineer modifies the test case based on the result of the review and records the modification log.

5. The test case is updated and perfected

After the test case is written, the test cases need to be perfected, the new features or update requirements of the software products must be modified, and the testing cases should be considered poorly when the test cases are found, and the test cases need to be modified, and the software defects of customer feedback after the software delivery is used. The defect is caused by the flaw of test case, and the test case should be perfected. General minor modifications can be modified on the original test case document, but the document must have a change record. The version of the software is updated, and the test case should generally be updated with the upgrade. Test cases are "live" and are constantly updated and perfected throughout the software lifecycle.

How to write effective test cases