软件测试实战（微软技术专家经验总结）--前两章（软件测试基础、缺陷报告）读书笔记

前言

一方面，总结了测试专家的见解和方法，将其精华内容综述在本书之中，以帮助读者提高学习效率、快速地掌握综合性技能；另一方面，将经验和反思融入书稿，使它反映出在工作中使用的策略、方法和技巧。总之，这是一本注重实效的书，尝试用理论结合实践的方式来解决现实的问题。

本书的组织方式

第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、定期阅读缺陷报告是一项有益的学习活动，能够帮助测试人员更好地测试。