本书介绍了如何在通常的业务条件下测试消费软件和商业软件，实在而且实用。我们曾经为硅谷中快速成长的著名软件公司测试软件，管理其测试人员。我们撰写本书的目的在于为员工提供培训和工作指南。
已经有很多很好的书在讲授有高可靠性要求的软件产品的测试方法。人命关天的和金融领域的应用程序，事先都得到了详细的定义和设计，质量保证和测试活动的经费充足，软件测试人员能够完全接触系统源代码，并有充分的时间阅读它们。在这样的前提下，这些书籍介绍了如何进行完整的软件测试工作。
计算行业的大多数人，包括个人计算机业的绝大部分人，都在努力开发有用且可靠的软件产品，但这些软件并不要求很高的可靠性。就像买车你可以选性能良好的经济型轿车或中档轿车一样，大多数的程序不必成为劳斯莱斯（而且大多数人是买不起劳斯莱斯的）。消费软件、普通商务软件、学术研究软件和个人软件的开发人员的测试预算相当有限，时间紧迫，人手短缺，然而很多程序却具有令人满意的质量。他们是如何做到的呢？本书介绍了其中的测试工作部分。
书不能解决全部问题
有些书认为，如果一个软件项目没有得到“合理”的控制，书面规格说明始终没有完成且不是最新的，代码没有依据所谓流行的方法进行适当组织的话，那么必须要努力做到。这些书讲到的测试是建立在每个人都依据“规定”行事的基础之上的。
本书介绍的测试，假定的前提是你的同伴现在没有、将来也不会并且也没必要遵循这些规定。
消费软件项目通常的特点是，预算非常有限、人手非常少、交付时间非常紧迫而且不可能推迟、开发人员之间拥有共同的认识和承诺。
大型软件产品的质量掌握在那些负责设计、编程、测试、撰写文档的个人手上，每个人都很重要。无论是标准、规格说明、指导/协调委员会和变更控制都不能保证质量，软件公司也没有指望它们起到这样的作用。能够确保软件质量的，是个人追求卓越的承诺、熟练使用工具的技巧和协同工作的能力，而不是这些规定。
开发小组对所要创建的东西有了认识，对尽可能实现梦想达成了承诺，并且意识到不得不通过试验和错误来充实这些细节。当产品某一部分的所有细节工作都完成时，他们会形成一个只有一两个人能完全理解的工作说明。这个说明就是所谓的“规格说明”。“规格说明”并不是刻在石头上一成不变的，随后会被评审和修正，以便与系统其他部分保持一致。大多数的修正是根据软件测试人员的建议进行的。
在现实世界中，产品变更一般发生在开发阶段的后期。当你正开发一个公开发售的软件产品时，你的客户或潜在客户不一定会同意你的设计。如果竞争对手开发出更具吸引力的产品，你要马上作出反应。
由于没有时间实现，预想的功能往往被取消掉。代码重写也被搁置一边，即使是需要完成这些代码重写工作把勉勉强强提交的第一版本改得稍微专业一些。认真负责的程序员也许会自觉地，甚至是“偷偷地”完成这项工作。在项目的后期，他可能在没有通知其他任何人的情况下对软件包做了重要修改。这些努力是在每周40小时工作时间之外完成的，可能会极大地改进软件质量，但也可能使软件质量变得极其糟糕。不管结果如何，软件质量的改进是通过个人的积极性来实现的。
后期的变更是不可避免的。我们的目标是尽可能平稳地来处理这些必要的变更。我们不打算建立什么规章制度来抑制变更的产生。作为测试人员，你如果处理不好变更，就会有麻烦。解决之道不在于单纯抱怨或是竭力阻止它们。
本书的读者对象
本书的读者对象是从事软件测试且常常测试他人代码的人员。我们认为所选主题和讨论水平反映了读者感兴趣或对读者有益处的内容。因此我们摒弃某些学术性内容（如程序正确性证明），讨论通常在测试教科书中并未强调的内容。例如，我们经常谈论到人际关系和企业文化问题。连最初级的软件测试人员也必须评判他人的工作—这就是测试工作的根本。在将他们的判断与别人进行交流的过程中，测试人员容易受到指责（有时也是“罪有应得”）。他们工作的重要程度往往与其地位不相称，从而导致他们容易成为人际矛盾的靶子或替罪羊。我们没有办法解决其地位问题，但我们确实提出了一些建议来提高测试效率和避免某些陷阱。
我们也讨论项目管理问题。软件测试的估算、计划和时间安排很棘手，因为软件测试没有真正的终点，测试总是没完没了，如果不做就会有更多的风险。每个测试人员都必须明白这种平衡关系。他们需要安排时间来充分考虑这些因素。例如，某个测试人员可能为了更好地完成其他任务而推迟了重要的测试，但是，后来发现由于时间已用完，再也无法进行这些测试了。本打算将工作做得更好，却弄巧成拙。这种情况很常见，而且非常令人沮丧。因此，优先级和效率是本书主要关注的问题。
测试人员还要处理设计错误。按照糟糕的规格说明实现的程序，其质量必定是糟糕的。大多数有关软件可靠性和测试的书籍没有涉及用户界面，而将其作为人为因素分析员的工作范围。我们不同意这种观点。（我们之中就有一位人为因素分析专家，他也不赞同。）系统的可靠性取决于其各部分是如何协同工作的，包括使用它的人员在内。
作为测试人员，你的任务是发现并指出产品中存在的问题，为改进产品质量服务。无论问题的源头出在何处，关于人－机系统可靠性差的报告都是适当和重要的。你是少数几个能在产品发布前详细检验整个产品的人之一。还有哪些地方能产生这种反馈呢？
我们对用户界面问题的讨论并不能让你成为专家，你仍然会遗漏很多重要问题。你的一些设计建议可能是笨拙的，但你依然应该递交这些报告，它们很重要。其中一些报告将导致产品改进，除此之外，别无他法。
人命关天的软件
在某些条件下，编程人员或他们的经理如果违背标准化的方法是绝对不能接受的。核反应堆的控制程序必须文档齐备，并得到彻底地详细说明，仅在精确计算之后方可进行变更。如果发生了失误，测试文档将是非常重要的法律证据。像这样的项目，负担得起大批质量保证人员和巨大的测试预算。对于这种项目的质量保证人员，测试方面的其他书籍比本书更适合他们。
.然而，即使在这些项目中，最后常会有一个验收测试过程。这些测试人员不属于开发队伍的核心，他们得到的预算非常少，他们的时间限期简直是不可能的。整个质量保证机构看不起他们的工作。他们接触产品的时间有限，无法采取“正确”的方式来进行“真正”的测试。如果你是在这种环境下工作，我们认为本书比其他经典教科书更适合你。
这是一本教科书吗
我们曾经面试并雇用了很多测试人员。但我们还没有见到在大学里学到了足够测试知识的计算机专业的毕业生。
1991年，美国计算机协会（Association for Computing Machinery，ACM）与IEEE计算机学会出版了《计算课程1991》（Computing Curricula 1991），在之后的十年中深刻影响了大学计算机学位课程的设计。但是，它给软件测试技术的必修时间少得可怜—四年学习期间只有几个小时而已。这一课程指导建议设立一个选修课程“高级软件工程”，其中包括关于软件测试的主题，但它没有提及是否开设一门以测试为主要内容的课程。
往后十年，我们也不能期望计算机专业的毕业生在大学中能学到足够的软件测试知识。
我们不知道为什么学校不去填补这个空白。我们认为，学过几门测试课程、同时又辅修了一些入门的编程和项目管理课程的理工科毕业生，应该能够很容易找到工作。测试人员的起薪也比较高。我们认为，大学教育应为这样的工作培养人才。
本书中所做的很多修订是为在校学生所做的，他们可能在头脑中从未形成对软件测试实验室的认识。对于那些尚未设置通用商业软件测试课程的院校，我们希望本书能对他们设置课程提供帮助。
如果你拥有理工科学位，我提醒你可以考虑从事测试工作。具备理工科教育背景并学过一些测试课程便能入门，但仅满足于此还不够。我们强烈建议你在适应了基本工作之后，最好在业余时间立即去修相关课程。
