测试工程师职责

测试工程师的测试活儿，说穿了就是工程找茬。找茬找得专业，师职找得系统，测试找得让开发心服口服，工程这才是师职本事。我刚入行那年，测试带我的工程老张让我测一个支付模块，我照着用例点了一下午，师职觉得界面流畅、测试按钮灵敏，工程万事大吉。师职老张走过来，测试没碰鼠标，工程只是师职盯着屏幕看了几秒，然后输入了一个负数金额。系统直接崩溃了。 那一刻我明白，测试不是“试试能不能用”，而是“想尽办法让它不能用”。你得像一个处心积虑的破坏者，同时又得是一个冷静的记录员。每个bug背后都藏着逻辑漏洞、边界疏忽，或者产品经理没想清楚的需求黑洞。测试工程师的日常，就是跟这些黑洞较劲。 职责第一条，需求评审时就得较真。别等开发把代码写完了，你才说“这里逻辑不对”。那叫亡羊补牢，羊都跑光了，你补个栅栏给谁看？我见过最靠谱的测试，在需求文档刚出草稿时就拿着红笔圈问题——这个按钮点了没反馈怎么办？网络断了是报错还是转圈？用户误操作能不能撤销？这些问题问得越早，后面返工越少。有些测试觉得自己是执行者，其实你应该是第一个用户，而且是脾气最差的那个用户。 然后是测试设计。这一环最考验功力，也最容易被外行低估。写用例不是把功能列表抄一遍，而是要分优先级、划场景、埋边界。比如登录功能，正常人只测正确密码和错误密码，但真正的高手会去测空密码、超长密码、密码里有特殊字符、连续输错五次、账号被锁定后还能不能找回密码。每一步都是跟开发捉迷藏，你得预判他们会在哪里偷懒。老张教我的时候常说：“开发写代码是画一条直线，测试要做的，是沿着这条线走，但每走一步都要往旁边踹一脚，看有没有悬崖。” 执行阶段，枯燥是常态。同一个版本，今天测完明天又改了，改了还得回归。这活儿磨人，但磨出来的责任心特别扎实。你得记录每一步操作，截图、录屏、附日志，把复现路径写得像菜谱一样精确——什么环境、什么数据、点了哪个按钮、出现了什么现象。写得模糊的bug单是废纸，开发看了只会回你一句“我这儿复现不了”，然后你俩就开始互相拉扯。这种拉扯我经历过太多次，后来我学乖了，提交bug时连网络状态、系统语言都写清楚，让开发挑不出刺来。 自动化测试是近几年的重头戏，但别迷信它。UI自动化脆弱得要命，页面改个class名字，脚本就全红了。真正有价值的是接口层和单元层的自动化，跑得快、稳得住，能帮你盯住回归。我现在的团队，每天凌晨跑一遍接口回归，早上来了先看报告，红了就去翻日志，通常都是开发半夜改了东西没通知。这种时候，你既是侦探，又是消防员。 最后，别忘了跟人打交道。测试夹在产品、开发、运维中间，像三明治里的那片生菜，谁都觉得你只是点缀，但缺了你整个汉堡就腻得慌。你得学会催开发改bug，催产品定方案，催运维给环境。催得有技巧，别硬刚，拿数据说话——这个bug影响多少用户、堵住了多少交易，比嗓门管用。 干这行久了，你会养成一种职业病：用任何软件都下意识找破绽。朋友点外卖，你在想优惠券叠加有没有漏洞；打车时，你在猜定位偏移会不会导致计费错误。这毛病改不掉，但我挺喜欢。毕竟，能让用户少踩一个坑，就是测试工程师最实在的成就感。

(责任编辑：知识)