Software testing process

Unit Test

Integration Test

System Test

The general steps of the program, but in the actual software production process, these steps are far from being possible. Subject to availability.

Why can't I do it?

This is related to many factors, such as the size and nature of the company, the size and nature of the software, the type of software development (some are just demo versions), and one reason is derived from the above, the team Management system (Is there any force to do some friendly steps, such as unit testing, everyone knows, why not do it?);

Unit Testing:

General R&D Department The leaders are all asking developers to write unit test code, because leaders can realize the importance of unit testing by their own experience, and basically write unit tests for every small function. Although it is a test, it does not have to be written after the code is written. Because unit testing has its own particularity, before developing a function, there is no doubt that the engineer has made detailed thoughts on the implementation of each small function in the module. And planning, how a function should be implemented, the heart knows everything, in this premise, you can pre-write unit test cases, and write unit tests, but also a comprehensive analysis of any bugs that may occur in a function (this is a very important Analyze the process, which will largely avoid some mistakes. In reality, this kind of problem appears too much. It gives the impression that the programmer just implements the function blindly, without considering the integrity of the function implementation. So robust, so, as long as the program is written, Lima can know the quality of the code. Another advantage is that the unit test can "listen" the code changes and module connection in the future development. Most of the mistakes that have occurred, so as to avoid the new bugs to the greatest extent, this is the knife that will not be mistakenly cut.

Integration Testing:

I used to think that the theory of the book is not as good as the experience of the actual application. After a while, I found that it is not; my summary is that When your growth encounters a bottleneck, the theory comes into play. What I want to say is the concept of cohesion and coupling that is said in Software Engineering. I didn't understand his true meaning when I was a beginner, and now I feel his importance when I use it. For the developer of the module, just like building an airplane, the programmer's job is to produce an airplane wing or make an airplane wheel. If the main realization of the wheel you made is still relying on the main structure of the fuselage itself, and the module itself does not have much new things, just change the color and increase the pattern, you can see that this wheel can not be from the plane Picking it off, or taking it off is very laborious, and can't be used, it loses its meaning; its core is the fuselage, not the wheel itself, and if you make the wheel, the whole function theme is on the wheel, the aircraft uses When you only need to hang up, if the aircraft does not want to use it, you can pick it up and change it; this is just like the cohesion and coupling concept seen by the program module, so that each module can try not to affect the use. Improve cohesion and reduce coupling between modules. This has the advantage of facilitating the reuse of modules, facilitating the positioning of problems, and facilitating the neatness of the overall structure of the program; (personally think that the idea of ​​class also has such advantages, and other classes One role is reuse, reuse to reduce the amount of code); in software testing, integration testing is the longest, most repetitive, most important Most bugs are discovered at this stage. The most common thing I feel during the test is that the coupling between the modules is not well handled, causing the function of changing one module to indirectly trigger the function of other modules. Complete program requirements and detailed design are important factors in generating such bugs, and it is always difficult for programmers to be aware of such problems when they are modified, which also makes it difficult to locate bugs.

The regression test at this stage is a tiring repetitive process. After each program change, in order to avoid the bug of the associated module, the relevant regression test should be carried out after the change. The depth of the regression is basically Design all relevant modules on it, so this kind of test, using automated test with manual test is more practical;

System test:

The last round of test before the program is submitted, actually this round The test can be thought of as an industrial "trial car", which is on-site commissioning. It involves all aspects of the use of the program, because it is tested in the on-site environment, so the bugs tested at this stage are more practical; in general, this step is to do more complex integration testing steps in the actual environment, to avoid The main reason for the bug is the accuracy of the demand; the more bugs at this stage are generally, the network aspect, generally involves the network background, the stability of the network, and this is often ignored in the integration test.

侃 会 老 老 老 老 老 老 老 老 老 老 老 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会 会However, reality makes people cry;

Why do you say this? (User)

1, is the company's efficiency, light test

2, the program size is small, do not need system testing

3, the programmer is basically not developed into a unit Test habits

4, team management has no tough principles

5, some programs have no requirements specifications, what to talk about, demand analysis

general outsourcing procedures, both Is a simple test, even the need to submit a bug is not, while testing and correcting (in the end such a program needs to do bug management, I do not know), there is no requirement specification, no demand analysis; I am thinking about the development cycle If a relatively small program does a complete development test process, it will not be worth the time, because the small program bug is still relatively small. The formulation of any process rules seems to be the best based on reality. It is not necessary to follow the inherent principles and use Long live! Large programs still need to do a complete process;

What is the standard to decide whether you need to do bug management?

A trade-off between cost and quality