软件测试中的《清单革命》

《清单革命》来自Atul Gawande，他曾是白宫最年轻的健康政策顾问、影响奥巴马医改政策的关键人物。

image.png

在书中，作者提到了在复杂的环境中，专家们要应对两大困难。

第一种困难是:人类记忆和注意力的谬误。在重压之下，人们特别容易忽视一些单调的例行事项。
第二种困难是:人们会麻痹大意，会故意跳过一些明明记得的步骤。

这时候，而“清单”的作用就体现出来了。清单可以帮助我们记忆关键步骤，并且清晰地列出了操作过程汇总必不可少的基本步骤。有了非常详尽的清单，在工作中逐项确认，从而提高团队成员“一次性就把事情做对”的能力。在高度复杂和压力的情况下，光靠态度积极努力、工作细致认真是不能够保障这种能力的，必须依靠清单来实现。

上述思路与笔者在实际工作中的实践比较契合。笔者也一直在团队中探索，如何将老司机的测试经验、之前踩过的坑，能够形成组织资产，能够很好地传承下去。通过实践发现，提供一个检查表，一个清单，往往可以很好的解决这些问题。在本文中，笔者将结合实际工作，介绍几个“亲测可用”的测试清单。

几个常见问题

1. 接到一个测试任务， 测到什么程度才算完成？除了测试功能，性能要不要测，安全要不要测?
2. 如何让不让发布成为翻车现场？
3. 如何让团队中的新人能够快速上手，达到团队的平均水平？
4. 有没有一个好的根因分析套路，让头脑风暴不再光是拍脑袋？
5. 一个系统的回归测试，给你一周，你怎么测试，给你半天，你怎么测试？

要测试？先点单

上馆子吃饭，我们通常第一件事就是点菜。在策划测试工作时，无非就是回答以下的问题： 在什么时候，需要做什么测试？要做到什么程度？ 根据CMMI/ISTQB中对于测试的策划，回答上述问题就是把产品生命周期中的测试工作划分为几个阶段(Phase)，然后在各个阶段做某些级别(Level)的测试，这些测试又表现为某些类型(Type)。 团队如果能把上述Phase-Level-Type通过组织协商，形成一个约定的工作清单，就能在各项测试任务中，依照清单有条不紊地展开测试工作了。 在采用敏捷的工程团队中，阶段的划分不会那么明显，更多地是采用迭代、冲刺等TimeBox的方式来交付，但是上述的套路依旧是适合的。在制定测试策略时，我们也可以通过菜单的形式将测试工作服务化。

案例1

以下是来自证券期货业软件测试规范 的案例： 《规范》根据软件生命周期和测试周期自然形成的阶段，测试级别包含单元测试、集成测试、系统测试、系统集成测试、验收测试。 待上线系统应经过五个测试级别及全市场测试之后，才能达到上线要求，允许上线。

image.png

《规范》还给出了各个类型的测试的测试内容

image.png

如何不让版本发布变成翻车现场？

什么时候，在什么情况下版本可以发布？这个版本还有几个bug没修，能不能发？这是测试人员或者测试负责人经常需要回答的问题。这个时候如果有一个事先约定的清单，来作为一个发布准则，则可以（拿来做挡箭牌）减少很多的人为因素干扰。 作为一个完成准则，一般会包括度量项目以及各项目的度量值这两方面的内容。对于软件测试来说，可能就需要考虑以下2个方面的问题：

• 做哪几种类型的测试？即关注做什么工作。
• 各类型测试的质量指标是什么？即关注工作完成的质量。

案例2

笔者曾经在行业杂志上写过一篇《HRC 拉动的大型软件测试 》，介绍了一款已近20年历史、服务全球数万家客户、拥有数千万行代码、由分布全球的近千人研发工程团队开发的产品，如何通过建立RC(Release Criteria)，以及通过HRC（Historical RC）实现测试工作的拉动以及持续改进，供行业同仁参考。这个准则也可能被称为测试退出标准，或者在推行敏捷的公司被叫做完成标准(Definition of Done,DoD)。如果加上相关的版本或者产品发布的工作，也可能叫做软件发布准则。

案例3

前述案例还主要是测试方面的工作，如果是发布版本，可能还需要做其它一些方面的检查，才能具备版本的发布。这就是所谓的《版本发布检查表》

• 检查版本的代码基线
• 检查质量门禁结果（单元测试、静态扫描结果是否达标）
• 测试准出结果（案例2中的产出物）
• 测试报告评审结果
• 版本验收报告
• 运维版本评审报告
• 二进制部署冒烟测试是否通过

在实施DevOps自动化流水线较为先进的公司，可能很多工作已经可以通过在流水线中通过软件定义质量来实现所谓的质量内建。如果还是需要很多手工交接和人工评审的公司，特别是受到强监管的机构科技机构，那么有一个这样的检查表还是可以在紧急版本发布版本的时刻做到有条不紊。

回归测试如何不背锅？

测试同学最不愿意听到的话，经常是开发同学说，这个版本我没改啥需求，就是升级了一下底层框架，要么你全回归一下？这个时候，测试同学往往内心就是崩溃的。不回归吧，指定不哪里会漏缺陷，如果回归呢，Sprint也不会因此而延长，只能靠自己加班。能不能回归完？那就测起来看吧。反正前紧后松，到时候来不及就把剩下的部分挑几个随便跑跑就是了。 所以，测试同学需要回答 给你一周回归，你怎么测试，如果只给你半天，你怎么测试? 测试老司机一个秘而不宣的经验是，得提前准备一个回归测试用例筛选表 ，从若干个维度来筛选回归测试用例。

案例4

譬如以下的一个回归用例筛选方式:

1. 首先是自动化用例。如果时间来得及，尽可能把自动化用例都回归了。当然现在也有团队的节奏已经快到到，必须实施“精准测试”来筛选自动化测试用例了。
2. 产品视角- 最多客户使用的功能 从产品经理或者运营部门拿到这样的列表。按照二八原则，大部分功能其实是相对少有用户使用的。
3. 产品视角- 基本/重要的功能。冒烟测试往往首选这些功能。
4. 用例新旧- 本迭代/上迭代新增用例。按照“杀虫剂效应”，陈旧的用例往往已经很难找到缺陷了。只有最近新增的用例，才能提高找到缺陷的几率。笔者曾经统计过，超过3个月以上的用例，其回归测试通过率在99%左右。这样的用例纳入回归范围，对于执行人员来说，是一次非常Frustrating的经历。
5. 缺陷- 把本迭代/上迭代新增的缺陷再次回归下，也包括客户或者运维报告的漏测缺陷。"Regression Test"另外一层意思就是，当开发修复一个缺陷时，围绕着这个缺陷的修复做一次测试。在《探索式软件测试》一书中，还提到了一个“买一送一”测试法，在一个缺陷的周围探索一下，经常能找到另外一个错误。因此，除了缺陷本身的回归验证，可以在其上下左右也再顺道探索下。

通过类似上述1-5个维度的一个清单，就可以按图索骥，从回归用例库中筛选出需要执行的用例。如果给定的时间无法完成，那就继续再逐个做减法，当然这个得是先按照清单中考虑维度讨论出优先级。另外一个说法是，即使产品上线了，回归测试也可以继续。当然前提是，新的测试任务没有完全挤占测试人员的时间。

根因分析

对于一个测试团队来说，缺陷漏测是不可避免的。如何能从事件中举一反三，实现问题归零 ，如果有一个根因分析的清单，简单如传统的“人机料法环”或者"五个why?"，则会让团队同学在分析问题时能更能得心应手。团队也可以从历次的根因分析中，逐步提炼出来容易造成问题的原因清单，作为RootCause List，下次再发生问题，就可以从这个清单中寻找是否是复发问题，就知道如何应对了。

清单是工具，同时也可以是个人、组织的核心资产。一个测试团队的所有清单构成，基本上决定了这个团队的过往积累。这些积累的存在和有效运行，就不会因为某几个核心岗位人员的离开，导致团队迅速坍塌。定期通过PDCA循环来检视、优化改进清单，则保障了测试团队交付能力、交付质量不会随着时间而衰退。