本节书摘来自华章出版社《软件测试价值提升之路》一书中的第3章，第3.1节，作者：杨晓慧编著，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
第2部分
扫 门 前 雪
作为一个测试团队，基本的职责是：测试产品，发现缺陷，报告结果，使每个版本的测试水准稳步提升。这些价值是作为一个测试所必须具备的，发挥这些价值能够让测试获得研发团队的基本信任。
这类价值分为3部分：
1）拦截缺陷，即对产品进行测试，尽可能把产品的缺陷拦截在研发阶段。
2）提供数据，即提供产品的质量结论，并且给出支撑这些结论的数据。
3）测试过程可控，提升测试团队和测试工程师的能力，使得产品测试的效率、质量、成本都处于可控状态。
“扫门前雪”说明这些价值基本上是测试的本职工作，价值的发挥是依靠测试自身或者以测试为主进行能力建设。当然，这并不是说测试必须将这些价值发挥到极致，测试工程师们还需要权衡成本和收益，找到合适的“度”。
第3章
Chapter 3
拦 截 缺 陷
拦截缺陷是测试最基本的价值，尽可能多地发现缺陷，尽可能在版本发布前发现并解决影响用户使用的缺陷，这是测试这个职业存在的基础。
一个测试团队或者测试工程师，如果经常将基本功能缺陷漏出去，那是无论如何也得不到信任的。这也不是说只要产品到客户那里有遗留缺陷，测试活动就一定有问题，拦截缺陷的能力就一定需要改进。通常还是会视缺陷的影响程度而定。
为了方便说明问题的解决办法，这里按照缺陷的激活条件（产品中的错误在特定条件下被激活，导致产品出现故障，这个“特定条件”就是激活条件），把缺陷分为4类：
基本功能缺陷。用户进行正常业务的基本操作时，由于缺陷导致业务操作无法完成。这类缺陷对用户的影响最大，是研发需要最优先解决的问题。
常规使用缺陷。用户大部分情况下能完成正常的业务操作，但在特定的条件下进行业务操作时，缺陷被激活导致操作无法完成，产品绝大部分的缺陷都属于这一类。想要减少这类缺陷，需要进一步按故障的影响范围和严重程度找到优先解决的重点。
受攻击暴露的缺陷。产品出现故障并非由于用户的业务操作，而是由于软硬件或网络环境发生异常、业务请求量超出预期而造成过载、受到黑客攻击等。这类缺陷对用户的影响很大，但用户会基于成本来考虑解决的方式，不一定全部是通过增强软件能力来解决。
随机出现的缺陷。产品出现故障的条件不明确，如果故障的影响范围大、严重程度高、出现频次高，也会对缺陷进行专项分析。
本章将分别介绍拦截各类缺陷的一般原则、常用方法，以及具体可参考的方法和工具。
3.1 用户无法正常使用
3.1.1 问题案例
我遇到最狼狈的问题是有一次切换数据库，切换的过程是先导出数据，升级程序，然后导入数据恢复系统。在实验室经过详细验证的切换脚本，在客户那里始终卡在第三步，导入数据失败。从凌晨两点一直折腾到凌晨五点，也没能让数据成功导入，最后不得已回退到升级前系统。把数据拿回研发分析，发现是由于2个数据库支持的字库略有差别，有一个用户的名字使用了生僻字，原来的数据库支持这个字，新数据库的默认字库中不支持这个字。
在日常生活中，软件无法正常使用的例子也很常见，比如，下载的手机APP一打开就闪退，游戏升级后原来的过关记录都丢了。曾经有一段时间，我每次升级完某度客户端，追的书就停止更新，直到两三天后才恢复。
这类缺陷典型的有：安装或升级过程中出错，新研发特性的基本功能有错，升级后原本正常使用的功能出错，产品在正常使用中数次崩溃，正常使用中有导致用户直接经济损失或信息泄露的错误。
3.1.2 解决问题的思路
【一般处理原则】
产品安装或升级后，基本的功能出错或者完全不能使用，这对于测试的信誉是极大的伤害，如果这类错误经常反复发生，测试需要把拦截缺陷作为最优先的任务。
【解决方法】
这类缺陷的发现条件是：只要测试时覆盖到了这个功能或特性，就能够发现缺陷。因此，在遇到这类问题的时候，推荐的解决思路是：
1）建立基本测试用例基线（测试用例基线类似代码基线，是产品截止到某个版本时，产品全部测试用例及其测试结果的集合，这是产品下一个版本测试的基础，故称基线。基本测试用例基线是测试用例基线的一个子集），基本测试用例集包含产品最常见的业务场景，覆盖绝大部分功能特性。
2）尽可能实现100%自动化测试，在每次启动测试、产品发布之前都将基本测试用例全部测试一遍。
3）有时候出现问题还与客户数据、环境、使用方法有关，那么基本用例基线的测试用例就需要包含客户的数据、环境、应用场景等信息，并按版本、客户进行管理。
无论是否有专业的测试团队，产品在发布之前一定是验证过基本功能的。安装或升级后仍出现无法启动、异常退出、原有基本功能不能用、新增特性基本功能错误等这些缺陷，虽然看上去像是根本没有测试过，但事实却并非如此。缺陷没有被拦截，实际上大部分原因是：
新增的功能测试了，原有的老功能没有全部测试。
原有老功能测试了，但是结果检查不完整，例如只检查特性相关的特殊结果数据，常规的结果数据没有检查。
新、老功能都测试了，但是测试用例和用户的常用使用场景有出入；测试环境的基础数据、开关设置、终端类型、操作系统版本等和用户常用的使用数据有出入。
针对以上原因，基本用例相当于确定了：在这样的条件下，可以通过这样的操作过程，正常地实现这个业务场景。建立测试用例基线是确定了产品的常见使用场景；而自动化是固化成果，确保每次发布常规场景都能正常使用。
3.1.3 建立测试用例基线
我们的主要产品都要求建立测试用例基线，用例基线包含基本用例、常规用例、生僻用例。基本用例就是上一小节提到的基本用例集。常规用例包含绝大部分正常和异常用例，一般在老特性修改或者新特性对老特性影响较大时，会测试老特性的常规用例。生僻用例是一些使用非常规手段才能实施的测试，比如暴力攻击、断电、代码注入等，这些用例很少会重复测试，只有在可靠性、安全机制做架构升级时才会考虑重新测试。
测试用例基线的建设标准包含基本要求和附加要求2部分，基本要求主要关注测试用例基线的完整性；附加要求主要关注测试用例基线是否易于使用。
【基本要求】
1）建立产品级测试用例基线，基线覆盖产品的全部特性功能和所有质量属性（功能、性能、可靠性、安全性、可服务性、资料）。产品级的含义是，一个产品一个用例集基线，而不是一个版本一个用例基线，这是为了随时都能根据用例的测试结果得到产品质量的整体视图。
2）测试用例基线中的用例集或用例，包含与产品特性、产品需求的对应关系。这是为了在测试结束时，按特性或需求进行测试结果分析。
3）测试用例基线包含基本用例集，基本用例100%覆盖产品特性。这要求每个产品特性都至少有一个用例在基本用例集中。
4）测试用例基线的用例不存在空用例、拷贝用例、自动化脚本和文本不一致等情况。这是用例质量最基本的要求。
【附加要求】
1）测试用例基线覆盖产品的全部需求。
2）有针对测试用例基线的更新、审核机制。测试用例基线要做到和产品同步更新，每个版本根据特性变更情况刷新基线，保证基线不腐化。
3）有管理用例基线的工具，工具管理了用例及其执行过程和结果的全部的信息，并可以根据版本、客户、业务等条件方便地查询，并进行测试结果演变过程分析。
在基本要求中，要求测试用例基线覆盖产品特性；在附加要求中，要求测试用例基线覆盖产品需求。特性的粒度比功能需求大，比如支持语音通话计费是一个特性，而本地、漫游、长途有不同费率，欠费、低余额做不同处理，不同品牌不同套餐的不同优惠等这些都是功能需求。
测试用例对应到需求更容易进行准确的挑选，也更便于在需求变更时，同步更新测试用例。但是从测试用例的管理难度上看，对应到到需求比对应到特性难度要大。对应到需求的主要难度是，通常开发团队对产品只管理到特性，每个特性有特定的代码；但需求通常没有有效的管理，因为需求经常变化并不像特性那样稳定。
在附加要求中，要求测试用例基线和产品同步更新。有些团队的做法是，老用例从不更新，特性有变更时，写一批新用例加入基线。后一种做法实施起来更简单一些，但是这样一来，测试用例基线中就遗留了无效的用例，长期积累下来，就很难从测试用例基线中找到特性的有效用例全集了。
建立测试用例基线的目的是为了复用，如果老特性永远也不会需要重新验证，比如某些游戏，那么可以选择不建测试用例基线，千万不要为了让测试工作看起来有一些积累的，而去做这个事情。
这个标准只包括对大部分产品都适用的做法，前面提到的，用例应该包含客户数据、环境、应用场景，并具备版本和客户标识，这是产品根据自身的情况再增加的内容。有些产品还会建立起用例和缺陷（尤其是客户报告的缺陷）的对应关系，这样做的好处是，对重要的客户，至少可以通过用例的覆盖保证出过的缺陷不再重复出现。
对于测试用例基线的管理，我们的测试团队用的是自行研发的一个工具，工具中用例集的结构如图3-1所示，按特性和测试项分层管理。管理的最小颗粒是单个测试用例，用例的内容结构如图3-2所示，包含用例的描述、自动化脚本、每次执行的结果、所有的分类标签和标识。在工具上能完成用例所有信息的编辑、存储，按各种条件挑选用例，也能和自动化工具、研发管理的电子流同步数据。
说明：测试项和测试子项通常对应一个测试目的，例如“××接口测试”“××参数测试”。
要做一个这样的用例管理工具成本还是很高的，用常规的配置管理工具配合用例文档的一些规范也可以实现基本的用例管理。
3.1.4 测试用例基线要同步优化管理和质量
在常用的、久经考验的软件中，也不乏“用户无法正常使用”的例子。
某天，我需要把信用卡提前还款，恢复信用额度，以应付接下来的支付需要。通过网银查询账单如图3-3所示。
点击链接进入快速还款，发现应还款金额为零，与账单查询到的不一致，如图3-4所示。
查询未出账单，发现此笔已经自动还款，因此上述应还金额为零可能是对的。但是还款之后的消费，无论是否入账，都无法选择提前还款，如图3-5所示。这样，还是无法恢复信用额度（以前曾经这样操作成功过）。
查询账单、快速还款，这些功能单独看起来都是对的，但是组合起来，却无法实现我所希望的应用场景。打电话到客服，对这个问题也没有解释，最后就是临时调高信用额度了事。
想要在测试的时候发现这个缺陷，必然需要有业务场景用例基线，覆盖已出账单、未出账单的快速还款。这样在新版本验证的时候，才能够发现出现了特性丢失、有的业务场景已经不能实现的缺陷。
有些时候，“用户无法正常使用”的缺陷显得匪夷所思，无法接受。我在某购书网站上找一套《给孩子的哲学》，得到的查询结果如图3-6所示。
在这个例子中，搜索结果的书名信息和搜索关键字“给孩子的哲学”毫无关系，但是除了书名以外，其他的内容都是正确的，书籍的整个购买流程也可以正确地实现。也就是说，即使有“搜索并购书”这一基本业务流程的自动化用例，并且在版本上线之前进行了自动化验证，也不一定能够发现如此“明显的”缺陷，除非在基本业务流程的每个操作环节，都在验证操作前后数据的一致性。
业务场景：完成一次业务处理的一组操作，例如用户开户、一次网购下订单、一个客户投诉的处理等。以“搜索并购书”为例，业务场景的基本流程是：用关键字搜索图书→点开其中一个图书链接→浏览图书信息→加入购物车。
通常，一个业务场景就是一组有明确目标的操作序列。
从这两个例子可以知道，建立测试用例基线绝非简单地把现有的用例实现自动化并管理起来，很可能需要改善用例的质量，一方面需要根据业务场景设计用例，另一方面在预置条件、操作步骤、中间和最终结果检查方面需要更严谨。
在我们的产品中，最开始部分产品出于自己的业务需要，建立基本测试用例集并实现自动化、形成基线，在每个版本中作为冒烟测试的基础用例使用，并随着产品版本的演进，同步进行维护和更新。由于这种做法很好地控制了基本功能的质量，后来逐步在产品间推广，把建立基本测试用例基线作为对全部产品的基本能力要求。
在各个产品进行这项能力建设的过程中，有些产品直接把特性测试时的基本功能验证用例拿来构造基本测试用例基线，使用后发现并不能拦截“用户无法正常使用”的缺陷，于是觉得基本测试用例基线“没有用”。但事实上并不是基本测试用例基线这种方法没有用，而是基线中的用例并没有覆盖用户的正常使用场景，或者覆盖了场景但是结果检查的内容不完整。
3.1.5 找对症结建立测试用例基线
新团队或新产品经常会遇到这类问题，由于这类问题直接影响产品的销售，因此研发通常急于解决这类问题，但是从无到有建立自动化的基本用例集绝非一日之功。因此，在建立测试用例基线工作的前期，我建议和服务代表、市场代表、研发经理做充分的沟通，切忌盲目铺开或者孤立的看待每个问题。
沟通前，首先进行缺陷分析，明确基本用例集需要包含哪些方面的测试用例，导致缺陷遗漏是因为缺少用例？还是操作方法不对或结果检查不完整？是否需要和具体的环境、客户数据、应用场景建立关联？根据这些信息估计用例数量、手工测试工作量和自动化工作量。
然后和市场代表或者研发经理讨论策略，一种是先把用例集整理出来手工测试，再逐步实现自动化；一种是按缺陷出现的频率和业务影响排优先级，先把风险最大的部分整理用例集并实现自动化。后一种策略有更明显的商业成功导向。
发生这类问题的另一个原因是测试工程师对客户的业务流程、使用习惯、网络环境、产品部署不了解。因此，基本用例集中功能测试的环境、操作步骤、测试数据、结果检查项，都最好能够和客户或者市场代表进行确认。这样做的好处不仅是让用例更贴近用户的真实情况，还有利于测试工程师掌握客户的业务和要求的第一手信息。
总之，解决这一类问题，最好进行思路上的转变：测试的角度由设计验证转变为需求验证、应用场景验证；首先考虑的是业务问题的解决而不是自动化的方法。
