《莊子·山木篇》里記載著一則“方舟濟河”的寓言。你乘舟行于河上，若有一艘空船撞來，即便性子再急躁，也會隨手推開，斷不會動怒；可若船上有人，你定會高聲呼喊示意其避讓，一呼未應，再呼仍無動靜，三呼便難免怒火中燒、惡語相向。

莊子繼而拋出叩問：先前不生氣，如今卻動怒，根源在哪里？原因就是：前者只是純粹的物理碰撞，后者卻被你強加了“冒犯”的意念。我們真正為之動怒的，從來不是事情本身，而是那個被自己臆想成“帶著惡意針對我”的人。

測試工作中，這樣的“碰撞”是家常便飯。需求臨時變更、開發推諉甩鍋、上線問題背責，樁樁件件都牽動著情緒。

若能明白莊子“虛己以游世”的智慧，不被主觀意念裹挾，便能在跨部門協作的繁雜里，守住一份情緒的平和，繼而積極作為。這一點，我從朋友小伊的遭遇里看得愈發真切。

一、小伊的煩惱

上周末，小伊約我在咖啡館見面。我向來不愛喝咖啡，只點了杯熱可可，看著她端起冰美式猛灌，眉頭擰成打了結的繩，便知她這一周，又被測試工作折磨得心力交瘁、滿肚子委屈。

“你是沒見我上周有多狼狽。”她放下咖啡杯，指尖還沾著杯壁的涼意，語氣里裹著卸不下的疲憊。

“我負責的那個電商項目，原定周五晚上線，周四下午我就跑完了最終輪回歸測試，版本也順利封板，就等著按點發布、好好歇個周末。結果周四晚上九點，我剛到家換好睡衣，產品經理的電話就炸了進來，語氣急得像熱鍋上的螞蟻。”

小伊學著產品經理那副急促又理所當然的口吻復述著，語氣里滿是無奈：“小伊，加個緊急需求，商品詳情頁補個‘限時秒殺’的標簽，開發那邊都改完了，你趕緊回公司測一測，今晚必須驗證通過，明天上線絕不能耽誤！”

她翻了個大白眼，語氣激動起來：“我當時就懵了！版本封板的意義他不懂嗎？那個標簽看著只是個UI小改動，實則要關聯秒殺活動接口，還得適配十幾款低版安卓機，光機型兼容測試就得耗上大半天，怎么可能是‘幾分鐘’就能搞定的事？”

“我跟他據理力爭，說清出工作量和風險，結果人家就輕描淡寫回句‘就一個小標簽，開發說半小時就改完了，你辛苦下，加個班’，直接把所有壓力都甩給了我。”

拗不過項目進度的壓力，也怕耽誤上線影響用戶體驗，小伊還是抓起外套趕回了公司。可一測才發現，麻煩遠比想象中棘手：標簽在低版本機型上顯示錯亂，還和原本的“新品”標簽重疊在一起，更要命的是，秒殺接口壓根沒做異常處理，一旦活動過期，頁面會直接報未知錯誤。

她把問題逐一反饋給開發，對方反倒不耐煩地懟回來：“你也太較真了，現在誰還在用低版本安卓機？先測核心流程能跑通就行，這些細節后續再優化。”

“我就這么硬扛著，熬到凌晨兩點才把所有場景測完、問題閉環，第二天還得準時到公司跟進上線。”小伊的聲音低了下去，眼底藏著掩不住的委屈，“結果上線沒兩小時，就有用戶投訴標簽重疊、頁面報錯，領導第一時間找到我，上來就質問‘測試的時候怎么沒發現這些問題？’。”

“那一刻，所有的疲憊、委屈一下子全涌了上來，我攥著鼠標的手都在顫抖，硬是咬著牙沒讓眼淚掉下來，連一句辯解的話都擠不出口——好像所有的努力都成了徒勞，錯的永遠是測試。”

她端起咖啡又喝了一大口，勉強壓住了翻涌的情緒，又說起了上個月的糟心事。“核心交易鏈路測出個Bug，用戶提交訂單后，偶爾會跳轉失敗，報錯提示還模糊不清，根本沒法定位問題。”

“我把操作步驟、測試環境配置、完整日志截圖整理得明明白白，提交給開發后，人家就回了一句‘在我環境是好的，無法復現’，之后就再也不回消息了，徹底把問題晾在了一邊。”

為了復現這個Bug，小伊特意換了和開發同款的設備、相同的網絡環境，反復測試了幾十次，才確認這是個偶現問題。她再次找開發同步情況，希望對方能配合排查日志，可得到的卻是輕飄飄的質疑：“是不是你操作有誤？配置不對？我這邊測了十幾次都沒問題，應該不是代碼的事。”

“那段時間我快被逼瘋了，一邊要趕其他功能的測試進度，一邊要抽碎片時間死磕這個偶現Bug。”小伊揉了揉發脹的太陽穴，語氣里滿是疲憊。

“我逐行核對接口日志，模擬高并發、緩存過期、網絡波動等各種極端場景，熬了兩個晚上才摸清規律——得同時觸發高并發和緩存過期，這個Bug才會顯現。”

“我把完整的復現路徑、日志分析結果一起發給開發，他就輕描淡寫地改了行代碼，連句‘辛苦’都沒有，好像我熬的夜、費的勁，都是測試崗位理所當然要做的事，連一點認可都得不到。”

最讓她寒心的，是之前一個跨團隊項目的復盤會。上線后出了個低級邏輯Bug，未付款的訂單竟然能重復生成相同訂單號，導致部分訂單沒法正常發貨，公司還因此受了損失。

“復盤會上，我剛想說明前因后果：‘這個Bug是開發私下修改了訂單生成邏輯，既沒同步給我，代碼評審也沒覆蓋到，我是按原需求邏輯設計的測試用例，根本覆蓋不到這個變更點……’”

話還沒說完，就被項目負責人生硬打斷：“測試的核心職責就是把控產品質量，你沒測出來就是你的失職。”

小伊的聲音帶著抑制不住的哽咽：“更可氣的是，那個修改邏輯的開發就坐在旁邊，全程沉默不語，既不承認自己隱瞞了變更，也不解釋代碼評審的疏漏。其他跨團隊的同事也跟著附和，說我應該考慮到所有邏輯可能性，不能被動等開發同步。”

“那一刻，所有的辯解都堵在喉嚨里，明明是別人的失誤，最后卻要我來背鍋，那種孤立無援的無力感，讓我當場就想摔桌子辭職。”

二、情緒穩定的方法

小伊說著，眼眶泛起了些許濕潤。窗外飛來一只麻雀，撲棱著翅膀落在窗臺上，怯生生地躲在墻角，警惕地打量著周遭，像極了此刻滿心委屈、亟需慰藉的小伊。我伸手輕輕拍了拍她的肩膀，放緩語氣道。

“你有沒有聽過《莊子》里‘方舟濟河’的寓言？其實你剛才說的這些事——產品臨時加需求、開發甩鍋無法復現、復盤會莫名背責，就像那艘‘載著人的船’，你下意識就把它們解讀成了‘故意針對你’：產品故意折騰你加班，開發故意為難你排查，領導故意否定你的工作。”

“可若是試著把這些事，當成一艘撞過來的‘空船’，剝離掉哪些‘主觀惡意’，只關注事情本身，從解決問題出發就事論事，你會發現，情緒會先穩住大半。”

小伊愣了愣，眼里滿是疑惑地看著我。我笑了笑，繼續說道：“你先別急著反駁，我不是讓你忍氣吞聲，而是教你用更聰明的方式守住邊界、解決問題，不讓自己被情緒內耗。”

“首先，得給你們的團隊協作‘劃定航道、立下規矩’。就像渡河要定航行規則，不然船只難免亂撞。你可以主動推動團隊明確幾個核心準則：版本封板后，除非是重大線上故障，堅決不新增需求，確需緊急變更，必須走書面審批流程，同時相應延期上線，絕不拿測試質量換進度；”

“開發修改核心業務邏輯，必須第一時間同步測試，同步更新需求文檔和用例，未同步導致的問題，明確由開發承擔主要責任；”

“提測前，產品、開發、測試三方必須召開對齊會，逐一審核需求細節和測試范圍，避免你按一套邏輯測、他按另一套邏輯改。這樣一來，很多摩擦從源頭就能避免，你也不用再被動承受各種‘臨時突襲’。”

“其次，要學會‘留好后手’，用客觀證據代替口頭辯解。你之前遇到開發說‘無法復現’、復盤會被甩鍋，之所以覺得委屈又無力，就是因為空口無憑，道理說不清楚。以后再遇到這種情況，就多留個心眼：”

“測到偶現Bug，不僅要整理操作步驟和日志，還要錄下完整操作視頻，標注出關鍵觸發條件，甚至幫開發圈定可能影響的代碼范圍，降低他的排查成本；”

“日常溝通中，不管是需求變更、邏輯調整，還是問題同步，都要保留文字記錄，把聊天截圖、會議紀要、用例評審記錄都歸檔好。遇到一句話需求，就把自己的理解郵件發產品經理進行確認。等再遇到推諉甩鍋，你不用跟人爭辯，把這些證據擺出來，事實自然一目了然。

??想了解更多漲薪技能提升方法

??可以到公主號【Atstudy技術社區】,即可加入領取 ??????

轉行、入門、提升、需要的各種干貨資料

內含AI測試、 車載測試、AI大模型開發、BI數據分析、銀行測試、游戲測試、AIGC