1.1 developers and software testing
1.1.1 Testing and Debugging
Software development and debugging difficult reasons:
· Failure symptoms and causes of defects may be far apart, highly coupled Program Structure aggravated this situation;
· Failure symptoms may disappear temporarily or disappear after another bug fixes ;
· Failure symptoms caused by human error is not easy to track;
· Failure symptoms may be caused by a couple of different reasons.
Backtracking:
· Place incorrect results emerging from the program starts, running along the path to the program to the upstream to find the source of the error until you find the actual location of bugs;
· Cases, the program has 5000 rows, the test found that the final result is wrong, the use of backtracking, 4500 is now the first line of instrumentation, check intermediate results are correct.
① If correct, the error is likely to occur between 4500 and 5000 the first line;
② If correct, then in 4000 the first line of instrumentation, and so on, until the program error to find the exact location.
1.1.2 Developer Testing
1.1.3 PIE model
Defects at different stages of different names and their meanings:
· Fault (fault): fault is still present in the faulty code program, sometimes referred bug (the Defect); (doctors want to find out the origins of diseases such as virus) (Example: traversing the array subscript never 1 start)
· Error (error): error indicates the error status after running buggy code caused; (the patient's body because the virus is abnormal, such as high blood pressure, irregular heartbeat, etc.)
· Failure (failure): failure is the bug to spread outside the state is perceived phenomenon. (The patient tells the doctor his symptoms, the body is not healthy to work)
Three necessary conditions of a defect is detected (PIE Model):
· Propagation (propagation): Error intermediate state must be propagated to the outside and is observed;
· Infection (infection): program must be infected with a wrong intermediate state;
· Execution (run): tests must be run to program code that contains defects.
1.2 developer testing methods and techniques
Static tests and dynamic tests: depending on whether you need to run the program;
White box and black box testing: based on the need to understand the internal structure of the software.
1.2.1 static testing and dynamic testing
Static test:
· Do not run the test program , but by hand or with the aid of special software testing tool to check the software documentation or program meets the standards, procedures measure static information, review the problems and deficiencies in the software, in order to reduce the probability of occurrence of software defects.
dynamics test:
· Run the program under test , test input data, check the operating results and expected results are consistent with the test program to test the function correctly.
· Test case contains at least two aspects: test input data and test the expected output .
To static and dynamic binding techniques to test.
1.2.2 black box and white box
Black Box Testing:
· Test method does not need to know the internal structure of the software;
Multi-dynamic test;
White box:
• The need to understand the structure of the internal software testing methods;
· The most common white-box testing methods: coverage test program code;
· Both static testing (code review, etc.) also have a dynamic test (logic coverage test);
Gray box testing:
· Only Test Methods section of program code information.
1.2.3 Failure to reproduce
When the test found that the software bug, that is discovered after a software failure, developers need to reproduce the failure to carry out the failure to understand and modify the defects. (Most of them have great difficulty)
1.3 Developer Testing Tools
Presentation Tools