13年UI测试老兵的失败反哺心法

　　去年一月份那场大崩，我现在想起来还后怕。凌晨三点被运维电话炸醒，说用户登录按钮点击率暴跌到平时的十分之一。我原以为又是哪个新来的实习生把元素ID写错了，结果爬起来看日志——好家伙，是前端组件库升级后，旧版动画参数和新版冲突，导致整个交互链卡在中间状态。最离谱的是，这问题在测试环境根本没复现，因为我们的测试机都是统一配置的，而用户设备千奇百怪。

文章配图，仅供参考

　　后来复盘的时候，老板拍着桌子说：“以后所有组件升级必须做灰度发布！”我低头翻测试报告，发现去年Q3的用例覆盖度其实达到了百分之九十二，但问题出在那些“边缘场景”根本没被当回事。比如我们测试了“正常网络下点击按钮”，但没测“4G切换到WiFi时点击按钮”；我们验证了“新用户首次登录”，但没验证“老用户清除缓存后首次登录”。这些场景在测试用例里都被标成了“低优先级”，结果现在全成了地雷。

　　我原以为“优胜劣汰”就是砍掉那些用例覆盖率低的模块，结果发现根本不是这么回事。上周竞对的产品更新了，我蹲在站长平台里翻他们近半年的截图——好家伙，人家把所有交互反馈都做成了动态效果，连错误提示都带微交互。而我们还在纠结“按钮颜色要不要从蓝色改成绿色”。更气人的是，他们测试团队就三个人，但用例里全是“极端场景”，比如“设备电量低于百分之五时点击按钮”“系统语言切换为阿拉伯语时点击按钮”。我盯着他们的版本日志看了半天，突然意识到：我们所谓的“全面测试”，其实只是在重复验证那些“肯定不会出问题”的场景。

　　现在我的测试用例表里多了个“脏数据”专栏——专门记录那些在真实环境中可能出现的异常状态。比如用户手动修改了本地时间、比如系统字体被替换成了非标准字体、比如存储空间不足时触发交互。这些用例在评审会上总被质疑“概率太低”，但我知道，去年一月份那场崩盘，就是因为我们忽略了“用户可能手动关闭了动画效果”这种“低概率”场景。现在每次写用例，我都会在备注里加一句：“这个场景在真实环境中出现过。”

　　昨天下班前，实习生小李拿着用例表来找我：“这个‘网络中断后重连’的测试步骤，要不要细化到‘重连后第N秒点击按钮’？”我盯着他的屏幕看了三秒，突然笑了：“不用，你就写‘网络中断后，在任何可能的时间点点击按钮’。”他愣住了，我拍了拍他肩膀：“去年我像你这么大的时候，也觉得测试得越细越好。现在才知道，真正的‘全面测试’，是承认我们永远测不完所有场景，但至少要保证那些‘可能出问题’的场景，都被测过。”

　　茶凉了，我端起来喝了一口——还是苦的。窗外的天已经黑了，运维群里还在飘着各种报错截图。我揉了揉眼睛，继续改今天的测试用例。这次我把“兼容性测试”从“可选”改成了“必选”，还在备注里加了一句：“如果发现某个浏览器版本下按钮点击无效，直接标记为‘阻断级’——别问我为什么，去年一月份的教训还不够吗？”

　　其实我现在也不确定，这种“反哺”到底有没有用。但至少，当下次再遇到“低概率”场景时，我不会再拍着胸脯说“肯定没问题”了。毕竟，在这个用户设备比测试用例还多的时代，所谓的“全面测试”，不过是在用有限的资源，去对抗无限的未知而已。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!