The history of common sense software development and use of software test has left many lessons learned from great financial resources and material loss due to software defects. These lessons forcing our test engineers must take strong testing measures to detect unspecified hidden software defects. The ultimate goal of production software is to meet customer needs. We use customer needs as standards for judging software quality, and the specific meaning of Software bug includes the following factors: • Software does not meet the functionality and performance of customer requirements; • • • • The software exceeds the scope of customer needs; • The software can not be tolerated; • Software use Failure to comply with customer habits and work environments. Considering the factors such as design, we can also think that software defects can also include software design does not meet the specifications, and failing to achieve best at specific conditions (funds, scope, etc.). Unfortunately, many of us are more inclined to see software defects as runtime, and think that software testing is limited to program submission. In the current domestic environment, we can't see a complete and accurate customer needs manual, and when the customer needs, it is changed, and the pursuit of perfect test is unlikely. So as an excellent tester, the perfectness of the pursuit of software is our aim, but it is our purpose, but it is clear that the software test reality and the ideal gap. On the software test, learn to pay and concessions, and have a hundred people in software testing. . Here are some common sense of software testing, understanding and application of these common sense will help us better grasp the scale of software testing when making software testing. • Test is incomplete (test incomplete), it is clear that due to the incompleteness of software requirements, the combination of software logic paths, the large number of input data, and the result of the results, even if it is an extremely simple program, Want to exhaust all logical paths, all results for all input data and verification are a very difficult thing. We give a simple example, such as the number of two integers. Its input information is two positive integers. However, if we test the number of the entire positive order, we can prove that such a test is not good in actual life, even if we can exhaust the procedure in a certain day, I am afraid We even have a grandchildren. For this purpose, as a software test, we generally use measures such as equivalence classes and boundary value analysis to perform practical software testing, find the minimum use of a collection that will become a necessary way to streamline the complexity. • Testing the use of immune (software defective immunity) software defects with terrible "immunity" as the virus, the more testing the tests used, the stronger the immunity, and it is more difficult to find more software defects. We can launch this conclusion by mathematically probability. Suppose 500 software defects in a 500,000 row and is evenly distributed, and a software defect can be found every 100 rows. We assume that testers use some way to find the energy of the software defects to X hours / 100 rows. When this is estimated, when there is 500 defects, we look for a software defect that requires X hours. When the software only exists, we need 100X hours each to find a software defect. Practice has proved that the actual testing process is more demanding than the above assumption, we must replace different test methods and test data. This example also shows that the software testing is not efficiently and complete in software testing, so software testing should be tested as much as possible. • Test is "Wild Test" (full test) I have always opposed software testing only after the program is completed. If a purely uses only the stage of the program design phase, the amplification effect generated by the defects of the demand phase and the defect of the design phase will increase. This is very unfavorable to ensure software quality. Demand defects, design defects are also software defects, remember "software defects have fertility." Software tests should span the entire software development process.
Demand Verification (Self-test) and design verification (self-test) can also be counted as a software test (recommended as: demand test and design test). Software tests should be a generic concept, covering the entire software lifecycle, so that each phase of the cycle can be banned. At the same time, there is also a third party to assess assessment (information system audit and software engineering supervision), that is, the test itself should also be tested, ensuring test itself reliability and efficiency. Otherwise it is unpredictable, unknown. In addition, it is also pointed that software testing is the necessary conditions for improving software product quality rather than sufficient conditions, software testing is the most direct and fastest means of improving product quality, but it is not a fundamental means. • 80-20 Principles 80% of software defects often have 20% of the software in software. This principle tells us that if you want to make the software test effectively, remember that it is often the high risk of "local". There is a lot of possibilities of software defects. This principle has significant significance for software testers to improve test efficiency and defect discovery rate. Smart testers will quickly find more defects based on this principle and stupid testers are still searching everywhere. Another situation of the principle of 80-20 is that we can find and avoid 80% of software defects in system analysis, system design, system implementation, and avoid 80% of software defects. Since then, the system test can help us find the remaining defects. 80%, the last 5% software defects may only have a wide range after the system is delivered, and will only be exposed after long use. Because software testing can only ensure that software defects as much as possible, it is impossible to ensure that all software defects can be found. 80-20 The principle can also be reflected in the automation of software testing, and the practice proves that 80% of software defects can be found by artificial testing, 20% of software defects can be found by automated testing. Since there is a cross part, there is still 5% of software defects that need to be discovered and corrected in other ways. • Test why we want to implement software testing, in order to improve the quality efficiency of the project to improve the overall benefits of the project. To this end, we don't have to get out our ability to implement the software test should be mastered. Software tests should find a balance between software test costs and software quality benefits. This balance is the degree we should follow when implementing software testing. Unilateral pursuits must damage the value and significance of software testing. Generally speaking, we should try to keep the software test simply in software testing. Do not over-complicate software testing, and physiologist Einstein is: Keep IT Simple But Not Too Simple. • The inevitability software test of the defects, due to the correlation of the error, not all software defects can be repaired. Certain software defects can be repaired but we will inevitably introduce new software defects during the repair process. Many software defects are contradictory, and a contradictory disappearance will inevitably lead to another contradiction. For example, we tend to bring defects in performing efficiency after solving versatility. What's more, during the repair of defects, we often follow the time, cost, etc., therefore cannot be effectively and completely repaired all software defects. Therefore, assess the importance of software defects, affect the scope, select a folded program or from non-software factors (such as lifting hardware performance) Considering software defects to become a fact that we have faced when we face software defects. • The software test must have expected results without the expected results of the results. Software defects have been contrast. This is just like a standard that cannot be measured. If we don't know in advance or unable to affiriate expectations, we must not understand the test correctness. This is easy to feel that if the blind is in general, many testers often use their own feelings to judge the occurrence of software defects, and their results are often judged as the correct result, so it often occurs. Phenomenon.
