我叫陈默，软件干了六年软件测试，测试从功能测试一路做到自动化测试工程师。工程刚入行时我以为这活很简单——点点按钮，师自找找bug，介绍谁都能干。范文直到有一次，软件我漏测了一个支付接口的测试边界值，线上用户用0.01元买走了价值199元的工程会员。那天晚上十一点，师自运维打电话把我从被窝里拽起来，介绍我盯着日志里那一串异常数据，范文后背全是软件冷汗。

那件事之后我才明白，测试测试不是工程找茬，是对代码最基础的尊重。我开始重新审视自己的工作方式。以前我习惯按测试用例一步步走，后来我学会先读需求文档，再去看开发写的代码逻辑——虽然不写业务代码，但能看懂代码，才能预判哪里容易出问题。有一次我盯着一个订单状态流转的接口，发现开发在状态更新时没加乐观锁，并发场景下两个请求同时进来，会导致数据覆盖。我把这个问题提给开发时，对方愣了几秒，然后默默回去加了版本号字段。

我喜欢拆解复杂系统。去年公司做电商中台重构，整个订单模块从单体应用拆成微服务，测试环境里服务间调用链乱成一团麻。我主动揽下接口联调测试的活，用Postman把三十多个服务的接口挨个过了一遍，画了一张调用关系图贴在工位上。同事路过时总爱看一眼，后来连架构师都来问我那张图是怎么理出来的。其实没别的窍门，就是一个个接口去试，把异常场景全列出来——超时、重试、幂等、消息丢失，每个可能性都要想到。

自动化测试这块我算半路出家。刚开始用Selenium写UI自动化脚本，跑一次要二十分钟，还经常因为元素定位不稳而报错。后来我换成Python加pytest，把接口测试和UI测试分开，再用Jenkins做定时任务。现在每次代码提交后，自动化套件能在十五分钟内跑完两百多个用例，出问题直接截图发到钉钉群里。开发看到消息都会自觉点开看，省了不少扯皮的时间。

说实话，这行干久了，最大的感受是测试的成就感不在找了多少bug，而在帮产品避免了多少次线上事故。我有一次在回归测试时发现，新上线的优惠券功能会把用户原有的积分清零，排查后才发现是缓存key写错了。这个bug要是上线，估计会让客服电话被打爆。当时产品经理拍着我肩膀说“幸好你测出来了”，那种感觉比加薪还实在。

当然，我也走过弯路。有一段时间我沉迷于追求测试覆盖率，想把所有分支都测到，结果用例数量翻了三倍，维护成本高得吓人，后来不得不砍掉一半。现在我的原则是：优先测核心业务链路和风险高的模块，其他部分用探索性测试补漏。毕竟测试资源永远有限，把好钢用在刀刃上才是真本事。

如果你问我这六年最大的收获是什么，我会说：学会怀疑，也学会沟通。怀疑代码里每个看似合理的逻辑，沟通时则要把bug讲得让开发心服口服——光说“这里有问题”没用，你得给出具体的输入、预期输出和实际结果。有一次我为了说服一个开发修一个低概率的并发bug，专门写了个模拟脚本，把1000次并发请求的结果打印出来，他看完数据就闭嘴了。

现在我的测试工具包里，除了JMeter和Postman，还有自己写的一堆小脚本，专门用来造测试数据和校验结果。有人问我怎么不直接用现成的工具，我总说：工具是死的，业务是活的，有时候自己动手写几十行代码，比折腾半天配置快得多。这大概就是测试工程师的浪漫——用最笨的办法，解决最棘手的问题。