前言
一方面，总结了测试专家的见解和方法，将其精华内容综述在本书之中，以帮助读者提高学习效率、快速地掌握综合性技能；另一方面，将经验和反思融入书稿，使它反映出在工作中使用的策略、方法和技巧。总之，这是一本注重实效的书，尝试用理论结合实践的方式来解决现实的问题。
本书的组织方式
第1章阐述对软件测试的
基本观点，介绍测试的
价值观。
第2章讨论了测试人员最主要的工作产出--
缺陷报告，介绍了一批实践方法，帮助测试人员高质量报告缺陷，并利用该过程来改进测试设计。
第3章讨论作为测试辅助工具的
测试文档，介绍了编写和维护文档的原则和方法。
第4章介绍指导测试
设计的模型，通过应用组合测试，阐述了如何根据语境来完善测试模型，然后介绍测试建模的基本原则和常用方法。
第5章介绍一个
测试技术分类系统，以概览各类测试技术。
第6章讨论了
测试开发的基本分类，然后针对自动化测试、计算机辅助测试和大规模自动化测试，阐述了他们的基本概念、设计目标、开发策略和实作方法。
第7章讨论如何从测试视角来
研究软件产品和业务领域，介绍了静态分析、动态分析、关系人研究、需求评审、测试调查、网络调研、领域研究等。
第8章讨论如何从测试视角来
研究项目环境，介绍了团队分析、缺陷分析、源码分析、构建分析、自动化测试分析、基于风险的测试等。
第9章探讨测试人员如何有效地在
团队中
工作，以及如何恰当地实施
测试管理。
第10章分享实施
个人管理的基本方法，包含时间管理、个人学习、经验积累、专业发展等。
第1章 软件测试基础
1.1软件的复杂度已经
超过了人的理解能力
对于复杂的软件，任何人都不可能掌握全部的信息，测试人员应该从各种渠道获取信息，
多角度地研究软件；
软件如此复杂，在项目之初都不甚了解软单件，拟定的测试方案不完善，注重实效的测试人员，会迭代地进行测试，
持续评估和
反思逐步增强测试方案；
现实世界软件，
穷举测试不可行，任何实用的测试技术都是基于一定策略的采用，测试人员应该
积累多种测试技术，
综合运用他们，并随着项目发展积极
调整；
人们处理复杂问题的常用策略是分而治之，软件领域，建立合理的
抽象模型是应对软件复杂性的常见方式，测试领域，可以建立
产品模型来帮助测试；
大规模软件中，少量代码的
变更都不可以掉以轻心，只有运行
大规模的测试，才能保证代码变更的正确性；
单凭人的脑力已经难以应对软件的复杂度了，测试人员需要考虑利用
自动化测试开发强有力的测试策略；
1.2软件测试是获取信息的
技术调查
定义1：测试是为了
发现错误而执行程序的过程。1979年提出，启示：测试人员应该始终质疑并挑战软件；
定义2：测试是一个
获取信息的过程，用来降低决策风险。2008年提出，启示：测试是服务性的工作；低质量的信息不但无助于决策，还可能浪费团队时间，甚至做出错误的决策；团队的决定可能与我的期望不一致，要去理解导致该决定的其它信息；为了更全面地提供信息，除了运行软件，还需要更多的获取信息的方法；除了软件缺陷，测试还可以提供关于项目环境的信息；
定义3：软件测试是一种
技术调查，其目的是向关系人提供有关产品质量的实验信息。2006年提出，启示：测试应该系统地调查被测试对象；测试所提供的信息应该来自科学实验和中立观察；刑侦人员会利用多种方法，从各个信息源收集情报，因为很难预测何处会有重大发现；优秀的潜水员既能够通过浮潜去游历宽阔的水域，也可以利用水肺潜水去探索深海水域；
1.3测试是
迭代过程
测试不是一个线性过程，而是
螺旋向上的：初始的测试提供了正式测试设计所需的信息；正式的测试用例较系统地检查了系统；当正式测试揭示出软件风险时，快速机动地探索相关领域，以确定是否存在严重的问题，并为后续的正式测试提供信息。迭代最大优点就是能够快速获得测试设计的反馈，从而逐步完善测试用例；测试策略在需要保持动态变化。
1.4测试人员的工作效率取决于他对
软件和项目的理解，而不是他掌握的测试技术
产品是一种解决方案，测试人员需要了解软件产品和业务领域，才能设计有效的测试；测试是一种信息服务，要了解服务对象的需求；不同模块采用不同的技术，拥有不同的典型错误；测试设计可能包含错误，吸取经验，不断改进；测试遇到困难，需要知道从哪里寻找信息；人脉有时候极大地提高测试人员的工作效率；测试人员应该养成好的思维方法和测试风格，以便快速地学习并理解产品和项目；
1.5小结
本章介绍了软件测试的基本
价值观。
第2章 缺陷报告
缺陷报告是测试人员最主要的工作产出，是测试人员和项目团队广泛联系在一起的纽带。
2.1报告缺陷是为了让缺陷得到
修复
清楚地说明此问题
对用户价值的危害：测试人员在提交缺陷时最好使用自制的缺陷模板（减少工作量，提醒输入必要值）；要为使用软件的人仗义执言（代表用户报告反馈问题）；要放大格局，软件的关系人还包括程序员、测试人员、运维人员、销售人员等（站在关系人角度，提交缺陷报告）；为了提供有说服力的证据，测试人员可能需要做一些研究（调查问题的影响）；测试人员还需要找专家支持（对缺陷修复提供帮助）；
提供尽可能
多的技术信息，方便程序员调试（应包括
业务层面信息和
技术层面信息，帮助程序员更快修复）；
尽早提交缺陷报告（一是
第一时间提交缺陷；二是规划测试时，要使得测试策略能够
尽早发现严重的缺陷）；
报告发现的
所有缺陷，即便有些缺陷难以复现（注意重复提交的缺陷、提交不确定且需要深入调查的缺陷、提交难以重现的缺陷）；
2.2高质量的缺陷报告来自于
高质量的测试
测试是迭代过程，测试报告是其中重要一环，既是测试的结束，也是测试的开始，让缺陷报告来推动更深入的测试，让高质量的测试产生高质量的缺陷报告。
2.2.1
分配测试时间
提交缺陷时，测试人员常常需要考虑如何使用接下来的测试时间：继续调查当前缺陷，还是开始新的测试，需要测试人员
平衡调查时间和测试时间；继续测试该功能，还是测试其他功能，需要测试人员平衡所提供信息的
深度和广度；测试人员需要合理地分配该资源，以提供足够好的信息。测试人员可以考虑“
时间盒”来管理自己的时间。总体上，正常的时间盒是为了提供更好的缺陷报告，长时间盒是为了提高测试人员的知识和技能，它简单明了，又不失弹性。
2.2.2通过
技术调查发现更多的信息
做后续测试有两个好处：一是可能会发现
额外的信息，使得缺陷报告更完整；二是可能会发现一些
相似或者相关的缺陷；
后续测试的一个切入点是
评估当前缺陷的
风险（风险暴露的可能性及风险暴露的损失）；某些严重的缺陷可能需要更广泛的测试，可以参考James Bach提出的7大产品元素，多角度思考测试覆盖：结构（软件组成的元素）、功能（拥有的功能）、数据（使用的数据）、接口（软件提供的操作界面）、平台（依赖的软硬件环境）、操作（可能的适用方式）、时间（与时间相关的元素）；测试人员还可以利用漫游测试、基于典型缺陷的快速测试等，多样化测试获取更多信息，更多地评估缺陷风险。
2.2.3处理
难以重现的缺陷
难以重现的缺陷是测试人员最常遇到的工作挑战之一，需要从多个方面努力应对挑战。
第一、正确地
态度面对缺陷（缺陷可以重现）；
第二、应为潜在的缺陷
做好准备，当一个缺陷暴露时，可以收集
更多的信息（有些缺陷没重现，是因为第一次发现时没有记录足够的信息，可以考虑监控工具，挖掘更多诊断信息）；
第三、如果第一次收集的信息不能重现或定位缺陷，测试人员需要做
后续测试（可能因为软件不能获得某种操作系统资源；可能软件处于不正确的状态；可能因为操作顺序或时序不正确；可能是因为软件调用的软件或服务返回了不能处理的数据；可能是数据库返回了不能处理的数据；有些软件内建调试辅助功能，启动这些搜集信息）；
第四、测试人员应该用
科学实验的策略指导缺陷重现（根据假设或推断）；
第五、与软件调试类似，可以
借鉴调试原则和方法（理解系统；制造失败（列举因素）；观察先于思考；分而治之（隔离环境，快速测试）；一次只做一次修改；保持审计跟踪（记录细节）；检查基本假设（质疑假设）；获得全新视角（求助他人）；如果没有修复它就一直存在）；
第六、结束调查后，测试人员需要
提交缺陷报告（注明不能复现；估算重现概率；可能重现的情景；造成的后果；重现缺陷，做了哪些测试及发现；类似缺陷及提供的信息）；
2.3编写
高质量的缺陷报告
2.3.1为每一个缺陷
单独提交一份缺陷报告，小缺陷也是如此
避免一份报告中提交了几个缺陷，会导致一些问题（缺陷报告数目少于缺陷数目；缺陷报告中缺陷可能有不同的根源；缺陷报告中的缺陷可能有不同的优先级和严重性；不能很好标识缺陷，可能会被忽略）；
2.3.2仔细编写缺陷报告的
标题
阅读报告时，读者总是先读到标题；较好的模式是“条件--失败”
2.3.3像编写详细测试用例那样编写
重现步骤
参照测试用例的编写规则，使得重现步骤尽可能具体、无歧义（测试配置；步骤编号；清楚记录每一步操作；不包含不必要步骤；标明预期结果；标明实际结果；必要时添加附加信息）；
2.3.4使用缺陷
模板来提交缺陷
利用模板，提高了编写报告的速度；提醒测试人员报告一些必要的信息；
2.3.5在编写缺陷报告时，要考虑缺陷
查询
查询缺陷是一件常见的任务；
2.3.6
链接相关的缺陷
如果缺陷已经提交，测试人员可以将自己发现的信息补充到已有的缺陷报告中；症状相似的缺陷，可以将他们链接在一起；
2.3.7注意缺陷报告的
可读性
避免错别字和病句；尽量用数字列表记录重现步骤；尽量用符号列表罗列事实；用空行分隔报告的不同部分；屏幕截图、视频录像、内存转储等附件提供更多信息；
2.3.8客观
中立的书写缺陷报告
缺陷报告是对缺陷客观描述，只传递事实，不评价任何人的工作。
2.4对不予修复的缺陷进行
上诉
上诉之前，做一些准备工作（1、可以再做一些测试，研究缺陷的普遍性或严重性；2、改进缺陷报告，强调缺陷普遍性或严重性；3、与缺陷评审小组面对面交流；）；缺陷上诉的本质是说服别人采纳自己的建议，可以通过不断积累自己的人脉（持续提交高质量缺陷报告；帮助团队成员，让他人认可的能力和贡献）；
2.5周密地
测试缺陷修复
缺陷修复分为两类：普通影响力的缺陷修复；高影响力的缺陷修复。
对于普通的缺陷，测试人员需要尽快完成测试。
可能的测试策略：测试人员可以查看代码的变更集，了解当前设计，从而更有针对性地测试；可以考虑产品元素的7个分类，设计新的用例；对被修改的代码做影响分析，考虑被修代码输入、输出、副作用；考虑哪些功能与被修改功能集成或共享数据；针对缺陷类型做一些有针对性的测试；
对于高影响力的缺陷，需要细致地测试新设计。根据产品成熟度确定测试策略，并动态调整测试活动。
2.6坚持
阅读缺陷报告
测试人员应该持续阅读他人提交的缺陷报告，从而更好地理解项目进展，并激发测试灵感。
每天或每周阅读缺陷报告可以帮助测试人员更好的测试。
了解当前有哪些活跃的缺陷；学习测试技巧，完善测试设计；获得测试灵感；追踪软件设计；总结缺陷模式；
持续回顾缺陷报告能让测试人员更好地理解产品、技术和团队。阅读缺陷报告将成为一项团队学习的活动。
2.7小结
以缺陷报告为中心介绍了一批测试实践，与测试人员的日常工作紧密相关。
1、提交缺陷报告的目的是让正确的缺陷得到修复。
2、为了说服缺陷评审者，测试人员要通过测试去调查缺陷的普遍性（风险的可能性）和严重性（风险的危害性）。
3、为了帮助缺陷修复者，测试人员要通过测试去获得更多的技术信息。
4、测试调查可能需要大量的时间，测试人员可以用时间盒来控制时间。
5、好的缺陷报告是独立的、准确的、便于查询、完整的、易读的、客观的。
6、缺陷上诉的本质是说服别人采纳自己的建议，核心工作是发掘和收集有说服力的证据，并通过交流将证据传递给缺陷评审者。
7、测试人员的人脉来自高质量的缺陷报告、高水准的信息服务和乐于助人的工作态度。
8、测试缺陷修复不要重复已有的测试，应该引入新的测试，在深度和广度上拓展测试设计。
9、定期阅读缺陷报告是一项有益的学习活动，能够帮助测试人员更好地测试。