The concept of software testing and software quality is inseparable. Test is a means, quality is the purpose. With regard to software quality, this problem has been considered when the software engineering, but it is not deep. Now just let the idea become the process of writing, talk about my own ideas, talk about my opinion. When reading a book, I have a lot of friends with my different professional friends, buildings, bridges, machinery, and more. They have a common part of my different, often back a big wooden board, mechanical drawing is their very important course. I and my students learn to design, learn the structure and principles of computers. We tend to complain that the principle of compilation of operating system is too complicated, but look at the house structure mechanical parts that are detained by the boss, accurate to 0.1 mm inner diameter, reinforced concrete constituent structure and anti-this The ability, I think it is simple to consider, the two do not directly compare the complexity of at least in a magnitude. I also know engineers in various industries, including my aunt is a bridge designer, my father is a mechanical mold designer. I am very impressed from the child's volume paper from the child. Father never tick a plane on a white paper, I didn't seem to be a mess, but according to it cropped with raw materials, the processing became a real product. At that time, I felt amazing, now I want to come, this is a very solid knowledge. During the entire process of design drawings, there is nothing tools and methods to check if there are errors or omissions, and the drawings that eventually send them to workers must be correct, otherwise the raw materials become waste. As an engineer, ensuring that the work is correct, it is very important for engineers. What happens if the architect can't make our house is very strong because of lazy blindness? The house will collapse and we have to be hurt. Suppose GM engineers do not do a final test for automotive brakes. When we need to brake, it may not work properly, and maybe accidents. So when the engineer answers a question about how to work, it must be confident that you are correct, you must be sure that you have not forgotten what. To do this, you need a lot of work. The software industry is very different. It is also when he is still studying, I have asked himself, the same engineer, why can't the engineer in the software industry can have such a confidence in the quality of their work like the engineers in the traditional industry? In many ways, the programming designer still has considerable convenience. For example, in the process of starting the code until the final software finished product, whenever a function, a module, a code segment, or the simplicity programmer can compile, track the use of various tools. The debugging procedure discovers hidden errors or omissions. Even because it is lazy, there is no big bug in the final product, it seems that the market is still acceptable, and the user is still use. There are two data to explain the work quality of the programming designer: people find that even if there is more experience programmers, the score of the programming is only 7.8 / 14. In the code written by experienced programming, there will be a bug per 150 lines. What caused this situation? Is the programmer's heart, the responsibility is not strong? Is the complexity of the software industry far exceeding the traditional industry? Is the industry's specialty caused the market and the user to accept this high error rate? Still what is the reason? I have given yourself so much, but I don't know how to answer. For the first question, this is indeed a large number of programmers. A large number of problems generated here is indeed seriously affected the quality of software products. For the second question, I remembered a classic dialogue: Program Design Hipster said: "Any procedure, no matter how small, there is a mistake." Novice did not believe in the hipster.
"If a program is small to only perform a single function, is this?" He asked. "This program will not have any meaning." Hipster said. "If such a program exists, the operating system will eventually invalid because of an error." Novice is not satisfied. "If the operating system does not fail?" He asked. "There is no operating system that does not fail." Hipster said. "If such an operating system exists, the hardware will eventually be invalid due to the error." Novice still feels dissatisfaction. "If the hardware does not fail?" He asked. The hipster sigh sigh. "There is no hardware that doesn't fail." He said. "If there is such a hardware, the user will have to make a different thing. This is also an error." There is no mistake, it is ridiculous, it is impossible to exist. If there is a program without any errors, then the world will not exist. This story gives an irresponsible programmer. But is the fact that is really so serious? For hardware, high-intensive electronic component integration makes it easy to understand it is unstable, but from the real situation, the hardware is much higher than the software stability. Perhaps, the continuous expansion of software scale has increased its complexity index, and personal capacity is unable to complete. The team's running is also a hidden danger that generates a mistake. But in the traditional industry, this situation is also uncommon. Yangpu Bridge, Oriental Pearl, and Jin Trade Building are not a person to complete design. Is it a good way to lack an experience without a moving team? How much is the software design? Is it more complicated to avoid the extent to avoid errors? I think this is not a question that is easy to answer. For the third question, I think it is also a major factor. Although every programmer each company knows, reducing errors can win the favor of users, defeating competitors. However, it is generally, the market's identity has contributed to the mentality of companies and programmers, after all, reducing the mistake is to pay at the price. In many companies and programmers, bugs and tests seem to be closely associated. The programmer only cares about the code, thinks if there is a bug that BUG test is known. It is impossible to truly solve the software quality problem. Test is not the fundamental initiative to solve the error, just a auxiliary means. But it is a must-have, I want someone to ask now. "If the programmer is more careful, will the test do not need?" This kind of problem is. The primary task of software test is to find errors. Find errors may spend a lot of cost. Because the test is complex, there is no good way to make each test are effective. There is such a sentence: If there is two or more methods for something, there is a method that leads to a disaster ending, then there will be another way to lead to the same end. The complexity of the test and the complexity of the software are consistent. That is to say, due to the complexity of the software, the test is complex. Test proposes basic and confusing puzzles. If we never want to detect all possible inputs, paths, and status of the test system, what should I choose? When should I stop? If we must rely on testing to prevent certain failures, how do we design it is both test and effective systems? How do we write a test package that can detect a combination of sufficient messages and status to illustrate the operation without failure, but from the practicality it is sufficient? The second purpose is to give a given test package, indicating that the measurement system is in line with the requirements described. Therefore, I think the test activity is harmonized and bad to coordinate with the software process, and there is an important impact on the effectiveness of the test. If the development of the test is performed at the beginning of a project, then the test will be very effective. Consider testability, early test design, and implementation of testing as early as possible, and improve the method of strong preventive mistakes. These processes forced designers to achieve more careful consideration of demand and statute, and results may improve application design. With regard to architecture, detailed design and encoding practice, early decision-making can make testing more easily and more economical.
