"Software Test" the fifth time operation

The whole book begins with the history of software engineering, from the beginning to the application, to the various changes that have been experienced. The next step is to become code to understand the strength of the group, to win the cooperation, to tell us about unit testing, regression testing, performance analysis tools. Then the middle part of the book mentions the conditions to become a software engineer:1. accumulate knowledge about software development and improve technical skills. 2. accumulate knowledge and experience in problem areas. 3. understanding of general software design ideas and software engineering. The second half of this "walk, after the development will be how, so no", how to do it, how to do wrong. For example, what is the macro perspective, what is best practice, what is called scrutinise. Like drawing a decision tree, to which branch to go, the result will be what, clear, clear, convincing people. The power of the whole is infinite. The final link introduces several models of teamwork, as well as several development processes in the team. Let me know from now on should focus on developing their own sense of teamwork.

　　This book from the actual software development at all stages, the detailed analysis of the software engineering aspects, such as: demand analysis, design implementation, user experience, software testing has been the final release and so on.

To talk about code style, a good code style specification is a software developer's minimum requirements, even if the program is very good, with a broad market application prospects, but if the back is a messy code, then the software will have a lot of negative impact on the future, Especially in the post-maintenance and version iterations, the nonstandard code is a nightmare for future maintainers, so good code specifications are important, especially when it comes to developing commercially valuable projects, or working in a team of software projects, and code specifications are important.

Pair programming, this is a very interesting new word for me, although this term can be traced back to the last century, whether we are independent of the development of the project or a few people to form a small team to develop, the most basic or need everyone to write code (independent), but in the mode of pairing programming, is developed by the developer, on an equal and complementary basis, whether it is design, analysis, coding, testing. The greatest benefit of pair programming is that the code that is actually developed can be constantly in the process of "review", can find the problem in time, can solve the problem in time, and can greatly avoid bringing the problem to the final test or release stage.

Finally, software testing, not just the book, almost all of the introduction of test-related books, have told a lot about the test, when it comes to testing, we are most familiar with the black box, white box testing, to write a good test, first of all to have a good test method, such as: Unit Test , Function Test , Structure Test , System Test and so on, a variety of test methods, the key is how to find the right test method best to complete the test, how to write a Test case? this seems to be very troublesome, you must first know and familiar with this requirement, to write a complete test process, to consider the test of the boundary value of the selection, extreme cases of the robustness of the program, so write a test is not simple.

After reading this book in general, I have the following questions:

1. for a few lines of code, how to do a quick and accurate test.

2. How to make changes based on someone else's code, with minimal impact on other code.

　　3. How the team works with each other to drive the growth of the project.

4. How to check for bugs.

5. how to become a good programmer.

"Software Test" the fifth time operation