上周帮同事排查一个订单金额计算错误的软件 bug，追了两个小时，测试最后发现是作业测试环境里一条两年前的脏数据在作怪。这种事在软件测试里太常见了——你以为在测代码，软件其实在跟数据、测试环境、作业时序较劲。软件

很多人对软件测试的测试理解还停留在“点点点”。点完一轮，作业没崩，软件就发版。测试真这么干，作业线上事故迟早找上门。软件测试的测试本质不是证明软件能用，而是作业想办法证明它不能用。这个思路一转，做事方式就完全不一样了。

测试用例不是越多越好

刚入行那会儿，我写用例恨不得把每个输入框都穷举一遍。一个登录页面写了八十条用例，用户名长度从1到20逐个试。执行完花了一整天，结果只抓到一个边界值问题。后来带我的老张看了一眼说：“你这不是测试，是体力活。”

他让我把用例砍到十五条。怎么砍？等价类划分、边界值分析这些方法先不说，核心就一句话：同一个逻辑分支只测一次，把精力留给异常路径。正常流程用户自己天天在跑，出错概率低。真正容易炸的是网络超时、并发写入、参数缺失这些场景。一条异常用例的价值，往往顶十条正常用例。

我现在的习惯是：拿到需求先画状态流转图，找出所有可能中断或回退的节点，针对这些节点设计用例。正常路径走一遍确认没大问题就行。

自动化测试的坑比想象中多

UI 自动化测试听起来很美，写一次脚本反复跑。实际维护成本高得吓人。前端改个按钮 id，几十条脚本全挂。页面加载慢了两秒，元素定位就超时。更头疼的是 flaky test——同一段脚本，今天过明天挂，查半天发现是异步请求返回顺序不固定。

我的判断是：UI 自动化只适合覆盖核心业务流程的冒烟测试，别指望它替代人工回归。接口自动化才是性价比最高的。接口稳定、执行快、维护成本低。一个项目接口自动化覆盖率做到70%以上，回归效率能翻倍。

但接口自动化也有坑。依赖第三方服务的接口，对方一挂你的测试全红。得做好 mock，把外部依赖隔离掉。还有数据准备的问题——每次跑测试前要保证数据库处于已知状态，不然用例之间互相污染，查问题查到怀疑人生。

缺陷报告写不好等于没提

见过太多这样的 bug 单：“登录报错，请修复。”开发看了想打人。复现步骤呢？环境信息呢？报错日志呢？截图呢？

一份合格的缺陷报告至少包含：精确的复现路径、预期结果与实际结果、环境版本号、必要的日志或截图。如果是偶现问题，写清楚出现频率和尝试过的复现条件。我还会附上自己初步排查的结论——比如“怀疑是缓存未失效导致”，帮开发省时间，也显得你专业。

另外提 bug 要注意语气。别写“这么明显的错误都测不出来？”或者“开发能不能用点心？”对事不对人。大家都是打工的，互相留余地。

测试左移不是口号

需求评审阶段就该测试介入。很多逻辑漏洞在 PRD 里就能发现，等代码写完再提，返工成本翻十倍。我养成了一个习惯：评审时逐条问“如果这里输入为空会怎样”“并发操作同一笔订单怎么处理”“超时重试会不会重复扣款”。产品经理有时候被问得答不上来，说明需求本身就没想清楚。

单元测试也该开发写，但测试可以推动这件事。代码覆盖率不要求100%，核心模块和复杂逻辑必须有。我见过一个团队强制要求新增代码单测覆盖率不低于60%，上线后严重缺陷数量直接降了一半。

软件测试没什么高深理论，核心就是细心、耐心、加上一点怀疑精神。别信“这次改动很小不会出问题”这种话。每次发版前老老实实跑回归，该测的边界一个别漏。线上少出一次事故，比什么都强。