初級測試和高級測試，差的不是工具，是這7個習慣

剛入行時我以為，高級測試工程師厲害在“會得多”——更牛的框架、更花哨的 mock、更高級的壓測。我拼命學這些，以為學會就能升級。

后來我跟一群真正的測試老兵共事。我發現他們的用例，一點都不炫。

但奇怪的是——需求變了一輪又一輪，別人用例改崩了，他們的用例永遠穩穩跑通，每次都能精準截住回歸 Bug。

后來我才明白：初級和高級的差距，根本不在“會多少工具”，而在 7 個習慣。跟用 Pytest 還是 JUnit 沒關系，它們決定的就三件事——漏測多不多、報錯好不好查、用例別人接手要花多久看懂。

下面這 7 條，每一條配一個真實業務場景，一起來康康。

習慣1、先把“不滿足條件”的情況攔在外面

場景：你要測試“退款”功能。前提是：訂單已支付、而且還沒退過。

新手常常這么寫——像套娃一樣，每個條件套一層：

def 測試退款():
訂單 = 創建訂單()
if 訂單存在:
支付(訂單)
if 訂單狀態 == "已支付":
if 訂單沒退過:
退款(訂單)
assert 退款成功
else:
報錯("已退過")
else:
報錯("沒支付")
else:
報錯("沒訂單")

剛寫完覺得沒問題。但后來產品說要加“風控檢查”，你再套一層；再過兩周加“優惠券退回”，又套一層。最后真正干活的“退款”那行代碼被埋在最里面，你自己過兩個月回來看都得懵。

高級測試怎么干？反過來——把不滿足條件的全部先踢出去：

def 測試退款():
訂單 = 創建訂單()
assert 訂單 is not None, "訂單都沒生成，跑啥？"
支付(訂單)
assert 訂單狀態 == "已支付", "沒付錢不能退"
assert 訂單沒退過, "重復退了，兄弟"
# 走到這里，說明前面都OK，放心測
退款(訂單)
assert 退款成功

TIPS： 前置條件先卡死，主邏輯頂格寫，誰看都清楚。

習慣2、給測試用例起個備注名字

場景：你要測“給有效訂閱用戶發續費提醒”。

新手經常寫：

def test_1():
...

半年后你自己看都不知道這是測什么。更可怕的是，跑完自動化測試，報告里一堆 test_1、test_2，失敗了都不知道是哪個業務場景掛了。

高級測試這么寫名字——直接用業務場景當名字：

def test_給有效訂閱發續費提醒_應該成功():
...
def test_給過期訂閱發續費提醒_應該跳過():
...

TIPS： 用例名就是你的報告，要讓人一眼看懂測的是什么業務。

習慣3、在“外部依賴”外面包一層，別硬編碼

場景：你的測試要模擬微信支付的回調。

新手直接硬寫：

def 測試微信回調():
請求數據 = {
"user_name": "張三",
"status": "ACTIVE"
}
調用接口(請求數據)
assert 返回成功

一個用例這么寫沒事，十個用例都這么寫就有事了。突然有一天微信把字段名 user_name 改成了 userName，你的十個用例全掛，一個一個改到吐血。

高級測試怎么做？在外面包一個“翻譯函數”：

def 造微信數據(用戶):
return {
"user_name": 用戶.名字, # 如果微信改名，我只改這一行
"status": 用戶.狀態
}
def 測試微信回調():
請求數據 = 造微信數據(測試用戶)
調用接口(請求數據)
assert 返回成功

TIPS： 外部的東西變數大，用一層函數隔開，你的測試代碼就穩了。

習慣4、別讓“不可能存在”的訂單狀態出現在測試里

場景：你要測試退款，需要各種狀態的訂單。

新手圖省事，用個字典，所有字段都可填可不填：

訂單 = {
"id": None,
"狀態": "已支付",
"已退款": False
}

因為全是可選的，你隨便亂組合都行。結果有一天你手滑造了一個“已退款”但“狀態”還是“已支付”的怪物訂單，測試居然跑過了，但線上真實邏輯根本不會出現這種組合，結果漏測了一個嚴重 Bug。

高級測試會怎么干？用工廠函數，只生成“合法的”訂單：

def 造已支付訂單():
return 訂單(id=生成ID(), 狀態="已支付", 已退款=False)
def 造已退款訂單():
return 訂單(id=生成ID(), 狀態="已退款", 已退款=True)

這樣你測試退款時，只能傳“已支付訂單”，你傳“已退款訂單”的話，寫代碼時就會報錯（或者斷言失敗），根本輪不到上線才發現。

TIPS： 讓測試數據只允許合法的狀態，錯誤在寫的時候就暴露，比線上炸了再查強一萬倍。

習慣5、把“期望結果”算清楚，和“實際操作”分開來

場景：測試退款成功后，賬戶余額對不對。

新手這么寫：

def 測試退款():
訂單 = 造已支付訂單(金額100)
退款(訂單)
assert 賬戶余額 == 100 - 手續費 # 這里直接算，但手續費規則可能變

如果手續費計算規則改了，你得改所有測試里的斷言，煩不煩？

高級測試會單獨寫一個“計算期望”的函數：

def 計算退款后余額(原金額, 費率=0.006):
return 原金額 - 原金額 * 費率
def 測試退款():
訂單 = 造已支付訂單(金額100)
退款(訂單)
期望余額 = 計算退款后余額(100)
assert 賬戶余額 == 期望余額

這樣，如果手續費規則變了，我只改一個函數，所有用到這個計算的測試自動跟著變。

TIPS： 把“算期望”和“執行操作”分開，你的測試更好維護，也更容易單獨驗證規則對不對。

習慣6、測試失敗時，讓報錯信息出提示

場景：你斷言接口返回 200，結果返回了 500。

新手報錯就是一句話：

AssertionError: assert 500 == 200

你看到這個信息能干嘛？只能去翻日志，猜是哪個訂單、什么參數、為什么失敗。半夜出問題，簡直想哭。

高級測試會這樣寫斷言——把上下文全帶出來：

def 斷言退款成功(響應, 訂單):
if 響應.status != 200:
raise AssertionError(
f"退款失敗！訂單號：{訂單.id}，狀態：{訂單.狀態}，"
f"請求參數：{請求數據}，返回內容：{響應.text}，"
f"追蹤ID：{響應.headers.get('X-Request-Id')}"
)

這樣一失敗，你立刻知道是哪個訂單、發了什么、返回了什么，拿著追蹤 ID 去日志里一搜，分分鐘定位問題。

TIPS： 別讓你的斷言只輸出“對還是錯”，要讓失敗信息自帶診斷報告。

習慣7、提交測試代碼時，一次只干一件事

場景：你完成了一個退款功能，跑通了，很開心，提交了一個 PR，里面塞了：

• 新增退款測試
• 改動了訂單工廠
• 順手重構了登錄測試
• 更新了配置文件
• 加了個風控測試

審查你代碼的同事一臉懵：哪些改動是必須的？哪些是順手改的？萬一出問題要回滾，一撤銷把登錄測試也給撤了，那不亂套？

高級測試會把這些拆成好幾個小 PR：

1. 第一個 PR：只重構訂單工廠（不改任何測試結果）
2. 第二個 PR：只新增退款測試（依賴第一個）
3. 第三個 PR：只加風控測試（獨立）
4. 第四個 PR：清理舊配置（獨立）

每個 PR 講一個清楚的故事：“我改了啥，為啥改，對測試有什么影響”。審查的人看得清楚，出問題回滾也安全。

TIPS： 代碼不是在你電腦上跑通了就算完，而是要“別人能看懂、能審查、能安全回滾”才算完。

別急著學那些高大上的工具。從今天起，寫下一個測試用例時，挑一個習慣用上。半年后再看，你寫的用例會穩定、好懂、不坑人。

這，就是變強的樣子。想漲薪、想走得更遠，最穩妥的辦法永遠是投資自己的技能。

?想漲薪、想走得更遠，最穩妥的辦法永遠是投資自己的技能。

?可如果行業的天花板已經壓到頭頂，與其在原地內卷，不如借AI的東風換個賽道。

?AI，正是個低門檻、高成長的方向。

可以戳??????

公主號【Atstudy技術社區】，內含項目實戰等各種資料包