Software development and use of history has left us many lessons enormous financial and material loss due to a software flaw caused. These lessons are forcing us test engineers must take strong measures to detect hidden detect undiscovered software defects.
The ultimate goal is to produce software to meet customer demand, our customers demand as the evaluation of software quality standard that software defects (Software Bug) the specific meaning of several factors, including the following:
1. Software does not meet the functional and performance requirements of customers;
2. Software beyond the scope of customer demand;
3. The software error can not tolerate the emergence of customer demand;
4. Use of the software failed to meet the customer's habits and work environment.
Taking into account factors such as aspects of design, we can also think of software defects can also include software design does not meet specifications, such as failure to achieve the best in certain conditions (funding, scope, etc.). Unfortunately, many of us are more inclined to problems come up when the software defects as run that software testing procedures only after the submission.
In the current domestic environment, we could barely see the complete and accurate customer requirements specification, to be constantly changing customer needs, the pursuit of the perfect testing becomes less likely. So as a excellent testers, of course, the pursuit of the perfect software quality is our aim, but a clear software testing gap between ideal and reality, learn to trade-offs and concessions in software testing, software testing is has everything to gain and nothing to harm the .
The following are some of the software testing knowledge, understanding and application of these common sense will help us to better performing software testing grasp the scale of software testing.
First, the test is incomplete (not fully tested)
Obviously, due to the demand factors are not the integrity of the software, a combination of software logic paths, a large amount of input data and results of diversity, even if it is a very simple program, in order to exhaust all the logical path, all input data and verification All results are very difficult thing. We give a simple example, say the greatest common divisor of two integers. Two input information is a positive integer. But if we are positive integers entire digital domain for some tests, then, from the infinite number so we can prove to be tested in real life does not work, even if one day we can end the program, I'm afraid we even our children have long passed away. As software for this test, we generally use the equivalence classes and boundary value analysis measures actual software testing, find the minimum set of use cases as our test streamline complexity of a necessary way.
Second, the test is immune (autoimmune software defect)
Software bugs and viruses with the dreaded "immunity" as testers to test more of its adoption, the stronger their immune system, looking for more software defects more difficult. By the probability theory in mathematics we can launch this conclusion. Suppose a 50,000 line program 500 software defects and uniform distribution of the software error, each row 100 may find a software defect. We assume that the tester in some way to find software defects in the energy spent for the X-hour / 100 line. Basis of this projection, in the presence of 500 software defects, we need to look for a software defect X hours, when there are only five software error, we each need to find a software flaw 100X hours. Practice has proved that the actual testing process more demanding than the above hypothesis, for which we have to switch to a different test methods and test data. This example also illustrates the use of a single software testing methods can not efficiently and completely for all software defects, software testing should therefore use more possible to test a variety of ways.
Third, the test is "generic concept" (full test)
I have been opposed to only exists in software testing process is complete. If only a simple stage after the design phase of the program, then known as software testing, the amplification effect of defects in the requirements phase and design phase of the produce will increase. This is very detrimental to the quality of software. Demand defects, design defects are also software defects, remember "software defects fertile." Software testing should span the entire software development process. Demand verification (self-test), and design verification (self-test) can also be counted as software testing (recommended known as: needs test and design test) one. Software testing should be a generic concept, covering the entire software life cycle, so as to ensure that each stage of cycle withstand the test. While the tests themselves also need to have a third party evaluate (Information Systems Audit and software engineering supervision), that the test itself should be tested to ensure that test their reliability and efficiency. Otherwise itself is not correct, it is difficult to convince the people.
In addition also point out that software testing is to improve the quality of software products necessary condition but not a sufficient condition, software testing is to improve the quality of products the most direct and most efficient means, but by no means a fundamental means.
Fourth, the 80-20 principle
80% of software defects are often 20% survival in the software space. This principle tells us that if you want to make software testing effectively, remember that often visit the high-risk multiple "lot." Where the possibility of software defects found will be a large number. This principle is of great significance for software testers to improve test efficiency and defect detection rate. Smart testers will be based on this principle will soon find more defects and still stupid testers aimlessly around in search.
80-20 Another principle is that our system analysis, system design, system implementation phase of the review, a test program to recognize and avoid 80% of software defects, then the system test can help us find the remaining defects 80% of the last 5% of software defects in the system may be delivered through a wide range of users, after prolonged use will be exposed. Because the software testing can only guarantee as much as possible to find software defects, but can not guarantee that all software defects found.
80-20 principle also reflected in the automation of software testing up, proved that 80% of software defects can make use of manual testing and found that 20% of software defects can make use of automated testing can be found. Since both the inter-section having a cross, so there are about 5% of software defects need to be discovered and corrected by other means.
Fifth, for the benefit and the test
Why do we want to implement software testing is to improve the quality and efficiency of the project and ultimately to improve the overall effectiveness of the project. So we can easily come to us in the implementation of software testing should master's degree. Software testing should find a balance between the two software testing software quality and cost-effectiveness. The balance point is that we should follow in the implementation of software testing. Unilateral pursuit of software testing are there is bound to harm the value and significance. In general, software testing, we should try to maintain the simplicity of software testing, software testing Do not over-complicated, take the words of physicist Albert Einstein: Keep it simple but not too simple.
Sixth, the inevitability of defects
Software testing, due to wrong association, not all software defects can be repaired. Although some software defects can be repaired but the repair process, we will inevitably introduce new software defects. Among many software defects are mutually contradictory, a conflict will inevitably lead to the disappearance of another generation of contradictions. For example, we often bring defects on the efficiency After solving the versatility of defects. Not to mention a defect in the repair process, we often will be subject to restrictions of time, cost and therefore can not effectively and completely fix all software defects. It is therefore important to assess the degree of software defects, affecting the range, select a compromise solution or from non-software factors (such as to enhance hardware performance) to consider software bugs become a fact we must face in the face of software defects.
Seven, software testing must have the expected results
The results of the test are not expected unreasonable. After comparing software defects is derived out. It is like there is no standard measure can not be the same. If we do not know or can not be sure in advance the expected results, we can not necessarily understand test accuracy. It's easy then people feel like the elephant in general, many testers are often with their own feelings to judge the occurrence of software defects, which often results in the paradoxical result of things as the right to judge, so often appear the phenomenon of false positives.
Eight, the significance of software testing - a post hoc analysis
The purpose of software testing is to find defects just so simple? If "yes", then I can guarantee that the next software defects similar to software testing in the new project will happen. As the old saying goes, "I do not know the history of man is bound to repeat it." No serious analysis of the software test results, we can not understand the causes and countermeasures defects, the result is that we have to spend a lot of manpower and material resources to find software defects again. Unfortunately, at present most of the test team do not realize this, the test report lacks analysis of test results this link.
in conclusion:
Software testing is a process needed "consciousness" as a tester, failing to calm, holding scales, software testing has to deal with a correct understanding of fundamental, I hope this helps readers understanding of software testing.