测试工作干久了，测试最怕听到一句话：“这个功能很简单，工作不用测了吧。建议”说这话的和意可能是产品经理，也可能是测试开发，甚至有时候是工作项目经理。我每次听到都想回一句：那你敢不敢让财务直接把这个月的建议工资打到我卡上，不用对账？和意
去年我们团队接了一个后台权限重构的需求。开发跟我说改动很小，测试就动了两个接口的工作鉴权逻辑。我多问了一句，建议那两个接口分别被多少个页面调用？和意他愣了一下说不知道。后来我花了一个下午梳理调用链，测试发现其中一个接口被七个前端页面复用，工作其中三个页面的建议权限模型跟新逻辑完全不兼容。如果按他说的“简单测一下”，上线后至少有三个业务线会出问题。这件事之后我养成了一个习惯：任何人跟我说“改动很小”，我都会先画一遍影响范围图。
测试工作的核心不是找bug，是控制风险。找bug只是手段。很多人把测试当成质检员，觉得你的价值就是在上线前拦住几个问题。这个定位太低了。真正有价值的测试，是在需求评审阶段就能说出“这个方案在并发场景下会有问题”，是在开发写代码之前就把边界条件列清楚，是在上线之后能快速判断一个线上告警是不是误报。
我见过不少测试同学，每天勤勤恳恳点页面，用例写了一千条，但线上还是出事故。为什么？因为他们的用例是照着需求文档抄的，需求文档没写的场景，他们就不测。需求文档说“用户输入手机号”，他们就只测正常的手机号。但用户会输入“+86 13800138000”，会输入带空格的，会输入“138-0013-8000”，会在输入框里粘贴一长串乱码。这些需求文档不会写，但线上一定会遇到。
有个做支付的朋友跟我讲过一个案例。他们的测试用例覆盖了所有正常支付流程，退款流程，对账流程。上线三个月没出问题。第四个月，有个用户用了一个非常冷门的银行，支付成功但回调超时。系统自动发起了重试，重试了三次都超时。然后用户手动点了“取消支付”，但银行那边其实已经扣款了。最后用户投诉，客服查了两天才搞清楚。这个场景，需求文档里没有，测试用例里也没有。但它是真实存在的。
所以我的建议是：测试用例的设计不能只依赖需求文档。你要去跟客服聊，看他们最近接到什么奇怪的投诉；你要去看线上日志，看哪些错误码出现的频率在上升；你要去跟运维聊，看最近有没有什么网络抖动或者第三方服务的不稳定。这些信息比需求文档有价值得多。
另外一点，别把自动化测试当成万能药。我见过团队花了半年搭自动化框架，覆盖率冲到80%，然后呢？线上该出问题还是出问题。为什么？因为自动化跑的都是已知场景，未知场景它跑不了。自动化真正的价值在于回归，在于把那些重复的、稳定的、每次都要跑的用例交给机器。但探索性测试、边界测试、异常场景测试，这些还是得靠人。
还有，测试报告别写太长。我见过一份测试报告写了二十页，前面十五页都是“测试背景”“测试范围”“测试环境”这种废话。老板想看的是：这次测了什么，发现了什么问题，哪些问题必须修，哪些可以下个版本修，不修会有什么后果。就这五点，一页纸够了。写多了没人看，等于没写。
最后说一个我自己的教训。刚工作那会儿，我发现一个bug，开发说“这不是bug，是需求就这样”。我跟他争了半天，最后去找产品经理。产品经理说“确实不是bug”。我当时觉得很挫败。后来我学乖了，再遇到这种情况，我不说“这是bug”，我说“这个行为跟用户预期不一致，我们看看怎么处理”。把“bug”这个词换成“用户预期不一致”，沟通顺畅多了。开发不觉得你在指责他，产品也会认真考虑这个场景。测试工作，技术是一方面，沟通是另一方面。技术决定你能不能发现问题，沟通决定你发现的问题能不能被解决。