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

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

回归测试?要啥自行车啊!

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

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

*.png

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

掉链子的四个后果

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

    • 软件功能失效
  • 影响心情:我不只一次看到一边上链子一边气急败坏的场景

    • 降低用户体验
  • 耽误工夫:赶时间的情况下,上链子可能造成延误

    • 功能延期使用,造成业务损失
  • 安全问题:要是正在加速猛蹬的时候突然掉链子,轻则腿抻一下,劲大了没准能掉下去

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

掉链子的原因

  • 路况不好,过于颠簸

    • 基础设施较差,运维磕磕绊绊
  • 负重过大,导致后轮不正或变形

    • 一次上线范围过大,团队不堪重负
  • 链条和轮盘不在一条直线

    • 团队内耗,一盘散沙
  • 链子松了

    • 需求膨胀,开发点数膨胀
  • 缺油

    • 再衰三竭,缺乏士气

可能的修复方式

  • 避免颠簸路段

    • 改造基础设施,提升运维效率
  • 避免过度负重

    • 留有一定的缓冲区,用于需求估点不准或紧急问题修复
  • 调整链条和轮盘至同一水平线上

    • 建立积极、公开透明的团队文化
  • 紧链条,或者把链子反过来,外圈换到里圈用

    • 控制膨胀,协调资源
  • 上油

    • 团队激励

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

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

*.png

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

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

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

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

*.png

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

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

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

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

回归 · 三大原则

*.png
  • 凡变必测:一有变化必须测试,并评估变化范围,进行相应的回归测试。

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

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

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

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

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

*.png

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

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

*.png

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

*.png

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

All rights reserved
Except where otherwise noted, content on this page is copyrighted.