电子书免费下载 Software Testing Techniques, Second Edition

I started to write the first edition of Software Testing Techniques in 1978. It was published in 1983, but most of the references predated 1980: the first edition was a book for the 80s that reported on the state of software testing as of the late 70s. This edition will be published at the beginning of a new decade. The years between have been a decade of intensive research and development in software testing as an art and science; a decade in which the vocabulary of testing evolved from idiosyncratic usages into an accepted set of concepts and terms for those concepts; a decade that saw intensive research on the relative strength of different testing techniques; a decade in which testing emerged as a discipline in its own right; a decade that began with evangelism for proper testing and ended with widely accepted testing norms; a decade that saw testing change from a mostly manual process to an intensely automated process; the decade in which PCs and workstations became ubiquitous personal data management, programming, and test tools.

A new edition was needed to update the technical material, but also for other reasons: software testing and quality assurance evangelism is no longer needed; there’s less about which to be iconoclastic; some of the “hot” ideas of the 70s have passed into obscurity while formerly obscure concepts have come to the fore; testers have emerged as skilled professionals along with “programmers” and “system analysts.” Most important of all, many professional testers who began the decade as the whipping boys of software developers are ending it with the roles reversed. The final reasons for a new edition is the shift in audience. Although I wrote the first edition for all programmers (because testers as such hardly existed), Software Testing Techniques became one of the standard reference books on the professional tester’s shelf. A new edition was needed to shift the focus from a book for programmers (and testers) to a balanced book for testers and programmers.

The most obvious change was the removal of Chapter 8—Data—Base-Driven Test Design. Its remnants are now in Chapter 6—Domain Testing, Chapter 13—Implementation, and scattered elsewhere. I removed material that the reader can find, better said, in Software System Testing and Quality Assurance (BEIZ84). The material based on a manual test development process, unaided by workstations and PCs, had a quaint ring to it—so that went. I also removed other process material that I’ve subsequently learned must be taken for granted if there’s to be testing worth the doing—data dictionaries, to name one. Finally, I wanted to sharpen the focus of this book even more toward techniques and farther away from process because process is too big and too important to treat superficially. It is covered more thoroughly in BEIZ84, and there are many other sources for process information, which was not the case when I wrote the first edition.

As for additions, the biggest changes reflect the rapid development of automated aids to programming and testing. Advanced testing techniques are processing-intensive and can’t be applied without tools. The first edition did not meet the needs of test tool builders or users. The final major addition is the section on testability tips in most chapters. We’ve gone full circle, back to putting the primary responsibility for software quality on the programmer. This approach requires that all test techniques be interpreted in the light of design for testability.

Software testing and quality assurance can be looked at from three points of view: (1) our tools and techniques, (2) what we are testing, (3) and the process by which testing is done and quality is assured. This book concerns test techniques and tools. What we test can likewise be divided into three domains: components (units), integration, and systems. Component testing is also covered in this book because most techniques are most easily applied to components. The rest of the subject is fully covered in Software System Testing and Quality Assurance (BEIZ84). The two books are inseparable. As befits their contents, I expect that individual testers and programmers will have the greatest use out of this book, and system engineers, testers, managers and QA/QC workers out of the other.

This book is intended for four kinds of readers, as follows:

Programmers (including designers, system analysts, system architects, database managers, be it for new systems or for the maintenance of old systems). A solid foundation in test techniques will make your own testing and debugging easier and more predictable at the cost of being less exciting. The techniques in this book, though usually applied to units or components, are also fundamental to integration and system testing. The most important thing you can get out of this book is testability: to use testing technique knowledge to change your design so that it can be verified and integrated with much less testing than you might think is necessary—that is, to design testable software.

Testers (including independent testers, system testers, beta testers, functional testers, software buyers, quality assurance specialists, test tool buyers). Testing is your stock in trade and, directly or indirectly, comprises half of your tool kit. The test tools you may buy are often based on deep properties of specific testing techniques—and it is difficult to understand how such tools work, or what their limitations and strengths might be, without understanding the underlying technique. Your task has always been to do a good job of testing with inadequate resources: your resources will always be inadequate when compared to a virtual infinity of justifiable tests but if you understand the techniques and where they are best applied, you’ll have an easier time of effectively allocating your scant resources.

Teachers (including university professors and testing trainers). This book is intended to be a cohesive structure around which testing training can be organized. That means a consistent mainstream terminology, a structure, a portal to the more advanced literature, and many hooks on which you can hang your personal perspective and needs, be it theory on the one hand or practice on the other.

Researchers and Developers (including testing theorists and test tool builders). The literature is vast, the terminology conflicting and confused, the time is short and the need is urgent. If this book helps you get on board, then it has done for you what I intended it to do.

I hope all readers will find this book to be what I want it to be: a clear presentation of the state of the art that bridges the often awesome gap between theory and practice: a recapitulation and synthesis of the important concepts with guidance on their practical application. Also, I hope that you will benefit from the combined glossary/index, which has proved a time saver in other books. Readers of the first edition will see a clarification of concepts that were sometimes muddy, new material and a consistent vocabulary with more formal definitions mostly based on ANSI/IEEE 729, Glossary for Software Engineering (ANSI83A). The single biggest change was to replace “element” in the first edition with “component” in the second. I have also stuck to the use of “bug” and “symptom” rather than “fault” and “failure,” respectively, because I find that people in the field tend to confuse the two terms, perhaps because they both start with an “f” and also because “bug” is one of the most frequently used word in this book, coming just after “the,” “a,” and “test.”

If you’ve read this far, I don’t have to sell you on the importance of testing. But I recognize that you may have a selling job to do to your management or peers. I hope that within these pages you find arguments that can help you to make the sale.