那个凌晨两点还在工作的测试，后来怎么样了

《庄子·山木篇》里记载着一则“方舟济河”的寓言。你乘舟行于河上，若有一艘空船撞来，即便性子再急躁，也会随手推开，断不会动怒；可若船上有人，你定会高声呼喊示意其避让，一呼未应，再呼仍无动静，三呼便难免怒火中烧、恶语相向。

庄子继而抛出叩问：先前不生气，如今却动怒，根源在哪里？原因就是：前者只是纯粹的物理碰撞，后者却被你强加了“冒犯”的意念。我们真正为之动怒的，从来不是事情本身，而是那个被自己臆想成“带着恶意针对我”的人。

测试工作中，这样的“碰撞”是家常便饭。需求临时变更、开发推诿甩锅、上线问题背责，桩桩件件都牵动着情绪。

若能明白庄子“虚己以游世”的智慧，不被主观意念裹挟，便能在跨部门协作的繁杂里，守住一份情绪的平和，继而积极作为。这一点，我从朋友小伊的遭遇里看得愈发真切。

一、小伊的烦恼

上周末，小伊约我在咖啡馆见面。我向来不爱喝咖啡，只点了杯热可可，看着她端起冰美式猛灌，眉头拧成打了结的绳，便知她这一周，又被测试工作折磨得心力交瘁、满肚子委屈。

“你是没见我上周有多狼狈。”她放下咖啡杯，指尖还沾着杯壁的凉意，语气里裹着卸不下的疲惫。

“我负责的那个电商项目，原定周五晚上线，周四下午我就跑完了最终轮回归测试，版本也顺利封板，就等着按点发布、好好歇个周末。结果周四晚上九点，我刚到家换好睡衣，产品经理的电话就炸了进来，语气急得像热锅上的蚂蚁。”

小伊学着产品经理那副急促又理所当然的口吻复述着，语气里满是无奈：“小伊，加个紧急需求，商品详情页补个‘限时秒杀’的标签，开发那边都改完了，你赶紧回公司测一测，今晚必须验证通过，明天上线绝不能耽误！”

她翻了个大白眼，语气激动起来：“我当时就懵了！版本封板的意义他不懂吗？那个标签看着只是个UI小改动，实则要关联秒杀活动接口，还得适配十几款低版安卓机，光机型兼容测试就得耗上大半天，怎么可能是‘几分钟’就能搞定的事？”

“我跟他据理力争，说清出工作量和风险，结果人家就轻描淡写回句‘就一个小标签，开发说半小时就改完了，你辛苦下，加个班’，直接把所有压力都甩给了我。”

拗不过项目进度的压力，也怕耽误上线影响用户体验，小伊还是抓起外套赶回了公司。可一测才发现，麻烦远比想象中棘手：标签在低版本机型上显示错乱，还和原本的“新品”标签重叠在一起，更要命的是，秒杀接口压根没做异常处理，一旦活动过期，页面会直接报未知错误。

她把问题逐一反馈给开发，对方反倒不耐烦地怼回来：“你也太较真了，现在谁还在用低版本安卓机？先测核心流程能跑通就行，这些细节后续再优化。”

“我就这么硬扛着，熬到凌晨两点才把所有场景测完、问题闭环，第二天还得准时到公司跟进上线。”小伊的声音低了下去，眼底藏着掩不住的委屈，“结果上线没两小时，就有用户投诉标签重叠、页面报错，领导第一时间找到我，上来就质问‘测试的时候怎么没发现这些问题？’。”

“那一刻，所有的疲惫、委屈一下子全涌了上来，我攥着鼠标的手都在颤抖，硬是咬着牙没让眼泪掉下来，连一句辩解的话都挤不出口——好像所有的努力都成了徒劳，错的永远是测试。”

她端起咖啡又喝了一大口，勉强压住了翻涌的情绪，又说起了上个月的糟心事。“核心交易链路测出个Bug，用户提交订单后，偶尔会跳转失败，报错提示还模糊不清，根本没法定位问题。”

“我把操作步骤、测试环境配置、完整日志截图整理得明明白白，提交给开发后，人家就回了一句‘在我环境是好的，无法复现’，之后就再也不回消息了，彻底把问题晾在了一边。”

为了复现这个Bug，小伊特意换了和开发同款的设备、相同的网络环境，反复测试了几十次，才确认这是个偶现问题。她再次找开发同步情况，希望对方能配合排查日志，可得到的却是轻飘飘的质疑：“是不是你操作有误？配置不对？我这边测了十几次都没问题，应该不是代码的事。”

“那段时间我快被逼疯了，一边要赶其他功能的测试进度，一边要抽碎片时间死磕这个偶现Bug。”小伊揉了揉发胀的太阳穴，语气里满是疲惫。

“我逐行核对接口日志，模拟高并发、缓存过期、网络波动等各种极端场景，熬了两个晚上才摸清规律——得同时触发高并发和缓存过期，这个Bug才会显现。”

“我把完整的复现路径、日志分析结果一起发给开发，他就轻描淡写地改了行代码，连句‘辛苦’都没有，好像我熬的夜、费的劲，都是测试岗位理所当然要做的事，连一点认可都得不到。”

最让她寒心的，是之前一个跨团队项目的复盘会。上线后出了个低级逻辑Bug，未付款的订单竟然能重复生成相同订单号，导致部分订单没法正常发货，公司还因此受了损失。

“复盘会上，我刚想说明前因后果：‘这个Bug是开发私下修改了订单生成逻辑，既没同步给我，代码评审也没覆盖到，我是按原需求逻辑设计的测试用例，根本覆盖不到这个变更点……’”

话还没说完，就被项目负责人生硬打断：“测试的核心职责就是把控产品质量，你没测出来就是你的失职。”

小伊的声音带着抑制不住的哽咽：“更可气的是，那个修改逻辑的开发就坐在旁边，全程沉默不语，既不承认自己隐瞒了变更，也不解释代码评审的疏漏。其他跨团队的同事也跟着附和，说我应该考虑到所有逻辑可能性，不能被动等开发同步。”

“那一刻，所有的辩解都堵在喉咙里，明明是别人的失误，最后却要我来背锅，那种孤立无援的无力感，让我当场就想摔桌子辞职。”

二、情绪稳定的方法

小伊说着，眼眶泛起了些许湿润。窗外飞来一只麻雀，扑棱着翅膀落在窗台上，怯生生地躲在墙角，警惕地打量着周遭，像极了此刻满心委屈、亟需慰藉的小伊。我伸手轻轻拍了拍她的肩膀，放缓语气道。

“你有没有听过《庄子》里‘方舟济河’的寓言？其实你刚才说的这些事——产品临时加需求、开发甩锅无法复现、复盘会莫名背责，就像那艘‘载着人的船’，你下意识就把它们解读成了‘故意针对你’：产品故意折腾你加班，开发故意为难你排查，领导故意否定你的工作。”

“可若是试着把这些事，当成一艘撞过来的‘空船’，剥离掉哪些‘主观恶意’，只关注事情本身，从解决问题出发就事论事，你会发现，情绪会先稳住大半。”

小伊愣了愣，眼里满是疑惑地看着我。我笑了笑，继续说道：“你先别急着反驳，我不是让你忍气吞声，而是教你用更聪明的方式守住边界、解决问题，不让自己被情绪内耗。”

“首先，得给你们的团队协作‘划定航道、立下规矩’。就像渡河要定航行规则，不然船只难免乱撞。你可以主动推动团队明确几个核心准则：版本封板后，除非是重大线上故障，坚决不新增需求，确需紧急变更，必须走书面审批流程，同时相应延期上线，绝不拿测试质量换进度；”

“开发修改核心业务逻辑，必须第一时间同步测试，同步更新需求文档和用例，未同步导致的问题，明确由开发承担主要责任；”

“提测前，产品、开发、测试三方必须召开对齐会，逐一审核需求细节和测试范围，避免你按一套逻辑测、他按另一套逻辑改。这样一来，很多摩擦从源头就能避免，你也不用再被动承受各种‘临时突袭’。”

“其次，要学会‘留好后手’，用客观证据代替口头辩解。你之前遇到开发说‘无法复现’、复盘会被甩锅，之所以觉得委屈又无力，就是因为空口无凭，道理说不清楚。以后再遇到这种情况，就多留个心眼：”

“测到偶现Bug，不仅要整理操作步骤和日志，还要录下完整操作视频，标注出关键触发条件，甚至帮开发圈定可能影响的代码范围，降低他的排查成本；”

“日常沟通中，不管是需求变更、逻辑调整，还是问题同步，都要保留文字记录，把聊天截图、会议纪要、用例评审记录都归档好。遇到一句话需求，就把自己的理解邮件发产品经理进行确认。等再遇到推诿甩锅，你不用跟人争辩，把这些证据摆出来，事实自然一目了然。

☑️想了解更多涨薪技能提升方法

✔️可以到公主号【Atstudy技术社区】,即可加入领取 ⬇️⬇️⬇️

转行、入门、提升、需要的各种干货资料

内含AI测试、 车载测试、AI大模型开发、BI数据分析、银行测试、游戏测试、AIGC