像用户一样测试：别掉链子 | IDCF

软件场景的“掉链子”

“掉链子”是一句俗语，比喻在关键时刻出故障，或者重要的事情本该做好却没做好。

“掉链子”的说法来自于自行车：在骑行过程中，链条通过链轮传送，带动车轮滚滚向前。当链条从链轮上脱落，就无法进行传动，失去了对车轮的控制，脚蹬子就会空转，自行车就会失去向前的动力。假设这种情况发生在关键时刻，要赶时间或者正在过马路，就会让人格外恼火。

回到软件场景，关键时刻掉链子，就好比上线后遇到重大缺陷，需要紧急热更或回滚。造成的后果也很类似，那改进的措施会不会也类似呢？我们一起来看一下。

掉链子的四个后果

• 功能失效：自行车失去动力无法向前，需要上链子才能继续 → 软件功能失效
• 影响心情：我不只一次看到一边上链子一边气急败坏的场景 → 降低用户体验
• 耽误工夫：赶时间的情况下，上链子可能造成延误 → 功能延期使用，造成业务损失
• 安全问题：要是正在加速猛蹬的时候突然掉链子，轻则腿抻一下，劲大了没准能掉下去 → 软件安全：隐私、匿名、盗号等

掉链子的原因

• 路况不好，过于颠簸 → 基础设施较差，运维磕磕绊绊
• 负重过大，导致后轮不正或变形 → 一次上线范围过大，团队不堪重负
• 链条和轮盘不在一条直线 → 团队内耗，一盘散沙
• 链子松了 → 需求膨胀，开发点数膨胀
• 缺油 → 再衰三竭，缺乏士气

可能的修复方式

• 避免颠簸路段 → 改造基础设施，提升运维效率
• 避免过度负重 → 留有一定的缓冲区，用于需求估点不准或紧急问题修复
• 调整链条和轮盘至同一水平线上 → 建立积极、公开透明的团队文化
• 紧链条，或者把链子反过来，外圈换到里圈用 → 控制膨胀，协调资源
• 上油 → 团队激励

假设我现在遇到一个团队（还真遇到过），拥有理想的基础设施、理想的文化、理想的人，是不是就能保证不掉链子呢？可能在一定程度上会降低掉链子的频率，但确实保证不了不出问题，要么怎么说测试是门玄学呢。

通常情况下，这类团队质量内建做的相对较好，新开发的功能质量较高，测试能力也较强，能够保证本次上线新开发的功能是完全正常的。但没想到重大缺陷也是剑走偏锋，你越是想不到，越是认为没问题，越是稳定运行好几年的功能，往往越容易在关键时刻掉链子，原因五花八门，有时候匪夷所思到想破头都想不出来，完全无法预防，只能采取事后干预。

回归测试

排除掉那些不可预知的因素，还有两个常见的原因，一是功能被我们破坏了，二是功能被其他人破坏了。这两种情况都是可以通过上线前的回归测试来预知问题的。

回归测试，顾名思义，得先有功能，也有针对功能的测试，然后才能回归。每个团队都有一些积累下来的回归用例，我们把容易出问题的、涉及产品核心能力的、一旦出问题后影响惨重的功能，全部并入主流程回归用例集。在产品初期，主流程回归用例集的范围可能不是很大，手工测试大概率能快速覆盖掉。

随着产品功能的不断完善，上线和运营的经验不断积累，主流程回归用例集的范围会不断扩大，直到手工测试无法快速覆盖，这时自动化测试就要发挥重大作用了。我们把越来越多的回归用例用自动化方式来实现，并集成到持续集成流水线，设置一定的触发机制，比如每天早上十点定时触发，或者每次代码提交均触发，视需要而定。这样在一定的观察期内，一旦有历史功能被破坏，我们就会在第一时间知道。

有些场景下会被这个用例集叫做“常规回归用例集”，或者“程序健壮性测试（Sanity Test）”，也有的团队会以端到端自动化测试（E2E）的形式来进行回归。名字并不重要，我们只需要知道，这都是回归测试的范畴，只不过是实现的手段和范围有所区别而已。

在进入迭代时，已有的主流程回归用例集是回归测试的输入之一，输入之二是本次迭代的回归用例集，包括以下内容：在本次开发的新功能中，哪些可以纳入常规回归范围的用例？亦或是本次修改影响到的功能范围有哪些需要回归？主流程回归和本地迭代的回归一起作为上线回归用例集。

确定了回归范围后，需要测试团队以一定的频率，多次进行回归测试。每次的间隔最好留出一定的时间来定位和修复问题，并且在修复问题之后，统一进行下一轮的回归测试。经过多轮回归测试后，上线前能发现的缺陷就发现的差不多了，将这些缺陷进行评估，若符合要求，也一并纳入回归用例集，就像滚雪球一样，把用例集滚大。

然后我们就迎来了上线：上线部署完成后，也需要以线上允许的方式再次回归一遍。

回归测试不是上线了就完了，上线后，如果有线上重大问题，或者以前的已有功能被破坏，测试也需要把这些缺陷进行评估，并补充至回归用例集。

回归 · 三大原则

• 凡变必测：一有变化必须测试，并评估变化范围，进行相应的回归测试。
• 凡测必补：一有手工测试，不管是新功能还是修缺陷，必须进行评估，明确是否有必要补充进回归测试用例集中。
• 人机搭配：自动化测试最有效的场景就是回归测试了，建议能自动化的用例都自动化掉，否则时间长了回归起来人要崩溃的。

可以说，遵循以上三条原则，基本能保证回归测试的持续更新和持续有效。

总 结

本文讲的是回归，为什么叫像用户一样测试呢？原因是，当我们在思考回归测试的范围时，需要具备用户视角。

假设我是用户：

• 我最希望使用的产品功能是什么？
• 哪些功能给我带来最大的价值，能帮助我带来收益或节约时间？
• 哪些功能有问题是我完全不能容忍的？
• 哪些功能我并不常用？
• 哪些功能可有可无？

思考这些用户视角的问题，有助于我们确定更精准的回归测试用例集，最大程度的做到关键时刻不掉链子。

来源：圆小豆的美梦工场
作者：于晓南
声明：文章获得作者授权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原作者有其他考虑请联系小编删除，致谢。

5月每周四晚8点，【冬哥有话说】质量与测试专场。公众号留言“质量”可获取地址

• 0506 朱少民 《如何最大化软件测试效能》
• 0513 陈琦 《数据驱动测试》
• 0520 陈霁 《没错，去QA是提高质量最有效的方法！》
• 0527 施慧斌 《DevOps实践之持续测试》