Product design-test

Transferred from
Http://www.pmcaff.com/forum.php? MoD = viewthread & tid = 4532.

If the Scope Verification is used to verify the "right", the main task of quality testing is to "correct" and try to use extreme test cases to verify the stability of the product. In theory, the trial and error should be done by the test department, and only sampling is required when the PM receives the test. Because quality testing requires three conditions as support, professional technical capabilities, rich experience, and a large amount of time, these three products are often not available, so even if we conduct quality testing, it is only an enhanced version for Scope Verification.

For example, assume that the registration form has a function that determines the city based on the user's IP address, and then automatically selects a default city for the user. It is difficult to manually test this function. The tester needs to write a test script and randomly extract 1000 known IP addresses. Based on the interfaces opened by the Development Department, the tester reads the return value of the city ID of the 1000 IP addresses, and determine the accuracy. If this function is tested by product personnel, there are many restrictions. The usual practice is to shout a scorpion in the QQ group and ask friends from all over the world for help.





As mentioned above, it is not suitable. However, due to the lack of testing in some companies, PM still needs to undertake more testing work. For testing, you need to read relevant professional books. Here you can only briefly introduce the two points that you think are important.



1. compile test cases properly.



An important preparation before testing is to compile test cases. Writing Test cases depends on personal experience and company history. The Use Case format is similar to the following table. To write the expected choices and expected results, not only the correct data, but also the boundary data and error data must be included. For specific design test case methods, you can view Professional Books, including equivalence class division, Boundary Value Analysis, error inference, and cause-of-failure analysis. Writing three or five thousand test cases for a function is very common, so you must accumulate them in a written manner, so that you can use the same requirements for reference next time (not directly for use !).



Number Title operation expected results

1. In the user name dialog box, enter four Chinese characters and leave the focus dialog box, prompting you to enter the correct information.

2. Enter a Chinese character focus in the user name dialog box and leave the dialog box. An error message is displayed.

3. Enter 5 Chinese characters in the user name dialog box and leave the focus dialog box. An error message is displayed.

2. In the user name dialog box, enter the English-only user name. After leaving the focus dialog box, an error message is displayed.

3. Enter Chinese characters in the user name dialog box and leave the English focus dialog box. An error message is displayed.

4 ............







2. classification error.



A: System error. (The page cannot be opened. The system reports an error and returns an endless loop)

B: Functional error (link failure, unexpected results)

C: general error (incorrect word or error diagram)

D: User Experience (page deformation, error line, page access speed, change comment)

E: Stress Testing



As shown in the table above, General page bugs are classified as the above five types. Class E errors are not considered (No conditional test), and the harm of other errors is sorted by A-D. Generally, a new PM employee reports all the problems found during acceptance and all the suspected problems. Although there is no big mistake in doing so, there are three troubles: 1. the bug list is a long string, and you will be scared first. 2. It will cause a lot of trouble for developers to troubleshoot the problem. 3. It will be despised as "unprofessional" (in fact, it is not a professional test. ^_^ ).



The correct method is to list the bugs in your hands and classify them first. The suggestion class is put aside, and the error class is labeled as ABCD. Class A errors are reported first. This level is almost solved, and the new AB and accumulated Class C problems are reported, report all remaining issues and suggestions at one time.