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

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

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

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

掉链子的四个后果

• 功能失效：自行车失去动力无法向前，需要上链子才能继续

• 软件功能失效

• 影响心情：我不只一次看到一边上链子一边气急败坏的场景

• 降低用户体验

• 耽误工夫：赶时间的情况下，上链子可能造成延误

• 功能延期使用，造成业务损失

• 安全问题：要是正在加速猛蹬的时候突然掉链子，轻则腿抻一下，劲大了没准能掉下去

• 软件安全：隐私、匿名、盗号等

掉链子的原因

• 路况不好，过于颠簸

• 基础设施较差，运维磕磕绊绊

• 负重过大，导致后轮不正或变形

• 一次上线范围过大，团队不堪重负

• 链条和轮盘不在一条直线

• 团队内耗，一盘散沙

• 链子松了

• 需求膨胀，开发点数膨胀

• 缺油

• 再衰三竭，缺乏士气

可能的修复方式

• 避免颠簸路段

• 改造基础设施，提升运维效率

• 避免过度负重

• 留有一定的缓冲区，用于需求估点不准或紧急问题修复

• 调整链条和轮盘至同一水平线上

• 建立积极、公开透明的团队文化

• 紧链条，或者把链子反过来，外圈换到里圈用

• 控制膨胀，协调资源

• 上油

• 团队激励

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

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

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

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

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

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

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

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

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

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

回归 · 三大原则

• 凡变必测：一有变化必须测试，并评估变化范围，进行相应的回归测试。

• 凡测必补：一有手工测试，不管是新功能还是修缺陷，必须进行评估，明确是否有必要补充进回归测试用例集中。

• 人机搭配：自动化测试最有效的场景就是回归测试了，建议能自动化的用例都自动化掉，否则时间长了回归起来人要崩溃的。

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

本文讲的是回归，为什么叫像用户一样测试呢？原因是，当我们在思考回归测试的范围时，需要具备用户视角。假设我是用户：我最希望使用的产品功能是什么？哪些功能给我带来最大的价值，能帮助我带来收益或节约时间？哪些功能有问题是我完全不能容忍的？哪些功能我并不常用？哪些功能可有可无？思考这些用户视角的问题，有助于我们确定更精准的回归测试用例集，最大程度的做到关键时刻不掉链子。

不是有本讲哲学的书叫《禅与摩托车维修艺术》吗？本文的另一个标题就是《回归测试与自行车修理并没有艺术》。专业受限，文中提到的修车内容，希望各位修车老手不要介怀。

再分享一个有意思的事，我感觉共享单车似乎很少掉链子，又怕是个人错觉，于是便在小范围内做了一个关于共享单车掉链子感受的调研，分享给大家：

调研：大家【觉得】共享单车容易掉链子吗？容易扣 1，不容易扣 2，不骑的请忽略。

由此想到一些有趣的点：部分年轻的小伙伴可能没有除了共享单车以外、高频使用其他自行车的需求，不像 80 后可能需要长距离骑行上学或通勤，所以无从对比掉链子的频率。也有部分小伙伴开车或坐车通勤，并不骑车，仅有的几次骑行不足以作为科学的统计数据支撑，所以我在调研里加上了强调主观感受的词语，所以无所谓品牌，你们“觉得”就好。

戴上用户的眼镜，确实看到了很多作为测试看不到的东西，而这些东西竟有助于对测试的理解，实在是有趣。请借我一双慧眼吧，让我把这纷扰看的清楚、明白、真切。

0 人点赞

日记本