面试一个三年经验的测试测试工程师，我问她怎么测一个登录功能。工程她答：输入正确用户名密码能登录，师需输错提示错误，掌握密码框显示星号。测试没了。工程我追问：连续输错五次呢？师需网络断了呢？登录后按浏览器后退键呢？她愣住。这不是掌握她笨，是测试没人告诉她测试的边界在哪。

很多人以为测试就是工程点点点，找bug。师需干了八年，掌握我越来越觉得，测试这行真正拉开差距的工程，是师需你能不能把“用户可能怎么用”翻译成“系统可能怎么坏”。这需要一套挺具体的本事。

拆需求比写用例更重要

产品经理给的需求文档，通常只写了正常流程。测试工程师的第一课，是学会从一句话里挖出隐藏的分支。比如“用户可以修改头像”——上传什么格式？gif动图支持吗？5M以上呢？上传到一半取消？修改后旧头像删不删？这些没人会主动告诉你。我习惯拿支笔，把需求里的每个名词和动词圈出来，挨个问“如果……会怎样”。这个笨办法，比任何用例模板都管用。

懂点代码，但别把自己当开发

不会看日志的测试，出了问题只能喊“开发大哥来看看”。能看懂接口返回的JSON，知道HTTP状态码401和403的区别，会用Postman发个请求，这些是基本功。再进一步，能写几行SQL去数据库里捞条数据验证，或者用Python写个脚本批量造测试数据，效率完全不一样。但我见过有人花两周搭了个自动化框架，结果项目下周就上线了，纯属自嗨。工具是拿来省事的，不是拿来炫技的。

沟通比技术更磨人

提bug是个技术活。你写“登录报错”，开发回你“我这儿好的”。你写“点击登录按钮后页面无响应，控制台报500，接口返回timeout”，开发默默去查了。描述清楚复现步骤、预期结果、实际结果，附上截图或日志，这是对别人时间的尊重。还有，别在群里直接@开发说“你又写bug了”。私下发个消息，语气正常点，大家都是为了把东西做好。我见过测试和开发吵到拍桌子的，最后项目延期，谁都没好处。

保持怀疑，但别钻牛角尖

测试做久了容易有职业病，看什么都觉得有问题。这是好事，但得有个度。一个按钮颜色从#333改成#000，你非要提个bug说视觉不一致，这就过了。分清主次：影响用户使用的、导致数据错误的、存在安全风险的，优先提。文案错别字、像素级偏差，攒着一起说。老板关心的是能不能按时上线，不是你的bug数拿了第一。

这行干久了，你会发现最值钱的不是会多少工具，而是那种“感觉这里会出问题”的直觉。直觉怎么来的？踩的坑多了，自然就有了。每次线上事故复盘，别光看开发改了什么代码，想想测试为什么没拦住。是用例漏了，还是环境不一样，还是压根没想到那个场景。把这些记下来，比背一百个面试题有用。

最后说句实在的，测试工程师的终极技能，是替用户把那些他们自己都没想到的坑，提前踩一遍。这活儿不风光，但挺重要。