How to write effective test cases

A test case is a document about specific test steps, which describes the input parameters, conditions, configuration and expected output results of the test, so as to judge whether the software under test works normally.

Designing, writing and executing test cases is an important part of testing activities, and test cases are usually managed by test case management systems or tools.

There is no doubt about the importance of test case, which is the core of the whole process of software testing and the basic basis of test execution. Principles for writing test cases:

Features:

A good test case should have a high probability of finding an undiscovered error, while a successful test case can find an undiscovered error. Usually, a good test case has the following characteristics:

Test cases can't be designed seamlessly, and can't completely meet the coverage of software requirements. During the test execution, some test paths or data will definitely not be reflected in the use case, so they should be added to the use case library afterwards to facilitate other and subsequent versions of the test.

There is a lot of information in the test case, which can be added or deleted according to the actual situation. Generally speaking, an excellent test case should include the following information:

These information suggestions can be automatically generated by test cases.

The test level is explained as follows:

6. Test types: functional test, boundary test, abnormality 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 and multilingual test.

7. Preset conditions: describe the special conditions or configuration of the test.

8. Test steps: describe the test process in detail, and the recommended operation steps are less than 15.

9. Expected results: expected test results.

For example, suppose we are currently testing whether cmnet SMS Gateway can send SMS to China Unicom Internet Gateway correctly, and the test case is designed as follows:

(1) test case ID: TC 00000 1

(2) Test case name: GSM mobile phone users of China Mobile successfully send short messages to mobile phone users of China Unicom.

(3) Test function point: GSM mobile phone users of China Mobile successfully send short messages to mobile phone users of China Unicom, and the gateway of China Unicom returns a success status report.

(4) Test purpose:

A. Can cmnet SMS Gateway correctly handle SMS messages sent by GSM users to Unicom users?

B. Can cmnet SMS Gateway correctly handle the success status report returned by China Unicom's Internet SMS Gateway?

(5) Test level: basic function test.

(6) Test type: functional test

(7) Preset conditions: all gateway entities are well connected according to the relationship in the networking diagram, and the connection and communication between entities are normal.

(8) Test steps:

A. GSM mobile phone users of China Mobile (1390100001) send MO short messages to mobile phone users of China Unicom (1300 1000 1) with the content of "test" and the destination number.

B, China Unicom Internet SMS Gateway successfully sent SMS to China Unicom users, and returned a success status report to cmnet SMS Gateway.

(9) Expected results:

A. China Unicom's mobile phone user (1300100001) receives a short message with the content of "test", and the source number is China Mobile Global Access User Number (13901000065438);

B. Generate SMO bill on cmnet SMS gateway, in which "SMS sending status" is 0 (indicating success), "source mobile phone number" is 1300 1000 1 and "destination mobile phone number" is13001.

The following is a template for a complete test case:

For a brand-new product, the first thing to understand is the relationship between product requirements documents and product modules. Then you need to write all the main path test cases and smoke testing test cases corresponding to the requirements from the requirements document, which will also contain certain basic path test cases and even detailed test cases. At this time, because there is no direct experience of the product, the scope of writing test cases should be wide and not too detailed. Then read the product function definition document and write relevant test cases directly. At this time, it is best to have some contact with the program itself and deepen the understanding of the program, so as to write better and more comprehensive test cases. Finally, in the actual test, it is necessary to constantly expand and modify the previous test cases to get a complete basic function test case and detailed test case. For a product with a certain or most cases, whether the tester is familiar with the product or not, its main task is to read and check the requirements and related changes, and then understand, expand and modify the original case. This is the reuse/reuse of cases. When designing test cases, you need to have a clear test idea, know what to test, in what order and what requirements to cover. Test case writers should not only master the technology and process of software testing, but also have a thorough understanding of the design, functional specifications, user trial scenarios and program/module structure of the software under test.

Test case design generally includes the following steps:

1, test requirements analysis Find out the requirements of the software/module to be tested from the software requirements document, and clarify what functions the tested object has through its own analysis, understanding and sorting into test requirements. The characteristics of test requirements are: including software requirements and testability.

Test requirements should be summarized, classified or subdivided on the basis of software requirements to facilitate the design of test cases. There is a many-to-one relationship between test sets and test requirements in test cases, that is, one or more test case sets correspond to one test requirement.

2. The test of business process analysis software is not only a black-box test based on function, but also a test of internal processing logic of the software. In order not to miss the test points, it is necessary to clearly understand the business process of software products. It is suggested that the business process of the software should be drawn before designing complex test cases. If there is already a business process design in the design document, you can supplement the existing process from the perspective of testing. If the business process cannot be obtained from the design, the test engineer should read the design documents, communicate with the developers, and finally draw the business process diagram. Business flow chart can help to understand the processing logic and data flow direction of software, thus guiding the design of test cases.

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

First, what is the main process?

B. what is the conditional substitution process?

C. what is the data flow direction?

D. What are the key judgment conditions?

3. Test case design

After completing the test requirements analysis and software process analysis, we began to design test cases. The types of test case design include functional testing and edge testing.

Boundary test, anomaly test, performance test, stress test, etc. In use case design, in addition to functional test cases, we should also consider boundaries and differences as much as possible.

Often, performance, in order to find more hidden problems.

The test case design methods of black-box testing include: equivalence class division, boundary value division, causality diagram analysis and wrong guess, white-box testing.

Example design methods include sentence coverage, judgment coverage, conditional coverage, judgment/conditional coverage and multiple conditional coverage. This paper mainly discusses black box testing.

Just try it. When designing test cases, we can use the software test case design method, combined with the previous requirements analysis and software process analysis.

Instrument:

Function test: test whether a function meets the definition of requirements and whether the function is correct and complete.

Appropriate technology: functional testing and equivalence class division from business requirements and design specifications.

Boundary test: Test the boundary of the function.

Applicable technology: boundary value division

Abnormal test: For some functions, boundary conditions cannot be easily understood or some operations are not completely correct but may occur.

Situations like this need to write related exception tests.

Applicable technologies: special business processes derived from business requirements and design specifications, wrong guess, boundary value analysis, internal boundary value test,

Performance test: check whether the system meets the performance specified in the requirements. Performance mainly includes understanding the internal and external performance factors of the program. Internal performance factors include the configuration of test environment and the use of system resources; External factors include response time, throughput, etc.

Appropriate technology: business requirements testing and design specification output

Stress testing: Stress testing, also known as strength testing, mainly checks the system's ability to run software under extreme conditions, such as giving considerable load or network traffic to application software compatibility testing: testing the functional compatibility of software products under different platforms, different tools and different versions of the same tool.

4. Test case review

After the test case design is completed, in order to confirm whether the test process and method are correct and whether there are any missing test points, it is necessary to review the test case.

Test case review is generally arranged by the test leader, and the participants include: test case designers, test leaders, project managers, development engineers and other related development and test engineers. After the test case review is completed, the test engineer will modify the test case according to the review results and record the modification log.

5. Test cases are updated and improved.

After the test case is written, it needs to be improved continuously. After the software product has new functions or update requirements, the test cases must be modified and updated. In the process of testing, it is found that the design of test cases is not well considered and needs to be modified and improved; After the software is delivered for use, customers feedback software defects, which are caused by loopholes in test cases and need to be improved. Generally speaking, minor modifications and improvements can be made in the original test case document, but the document should have a change record. When the software version is updated, the test cases should usually be updated. Test cases are "alive" and are constantly updated and improved during the software life cycle.