返工率從35%降到8%！測試左移3個月，我們團隊發生了什么？

"這個功能明明按需求做的，為什么測試說不對？"

"需求文檔寫得很清楚啊，怎么開發出來完全不是那么回事？"

如果你的團隊經常出現這樣的對話，那么你們遇到的不是技術問題，而是需求理解的問題。根據我10年+的測試經驗，超過60%的生產問題其實在需求階段就已經埋下了隱患。

多年前，我所在的團隊接手了一個電商平臺的改造項目。項目初期，我們每個迭代都要返工30%以上的功能，團隊士氣低落，客戶頻繁投訴。后來我們在需求階段引入了測試左移實踐，3個月后，返工率降到了5%以下，交付周期縮短了40%。

這篇文章將通過這個真實案例，分享我們是如何在需求階段實施測試左移的，包括具體的操作方法、遇到的問題和解決方案。

問題的發現：一次失敗的迭代

1.1項目背景

這是一個中型電商平臺的優惠券系統改造項目：

• 團隊規模：8人（產品1人，開發5人，測試2人）
• 迭代周期：2周一個迭代
• 業務復雜度：涉及多種優惠券類型、疊加規則、使用限制

1.2第一次迭代的災難

第一次迭代的需求是"滿減券功能優化"。需求文檔只有簡單的一頁紙：

需求：優化滿減券功能

目標：提升用戶體驗，增加優惠券使用率

功能點：

1. 支持多檔滿減（滿100減10，滿200減25）

2. 支持跨品類使用

3. 優化券的展示樣式

看起來很簡單對吧？但開發完成后，測試發現了23個問題：

• 典型問題列表：
• 多檔滿減的計算邏輯不明確（按訂單總額還是按商品分類？）
• 跨品類使用的限制條件缺失（是否包含特價商品？）
• 與其他優惠的疊加規則未定義（能否與店鋪券同時使用？）
• 券的有效期判斷邏輯不清晰（是按領取時間還是使用時間？）
• 庫存扣減時機未說明（下單時扣還是支付時扣？）

更糟糕的是，開發人員、測試人員、產品經理對這些問題的理解完全不同。我們花了整整一周時間開會討論、修改代碼、重新測試。原本2周的迭代，最終用了3周半才勉強上線。

1.3問題根源分析

復盤會上，我們分析了問題的根本原因：

• 原因一：需求文檔過于簡單
• 只描述了"做什么"，沒有說明"怎么做"
• 缺少邊界條件和異常場景的說明
• 沒有明確的驗收標準
• 原因二：需求評審流于形式
• 評審會只有產品經理講解，其他人聽
• 沒有人提出質疑和問題
• 會議結束就算評審通過
• 原因三：測試介入太晚
• 測試人員在開發完成后才開始介入
• 發現問題時代碼已經寫完，修改成本高
• 測試人員對需求的理解不夠深入

解決方案：建立"三方評審"機制

2.1機制設計

我們決定建立一個"三方評審"機制，讓產品、開發、測試在需求階段就深度協作。

• 會議設置：
• 時間：每個需求開發前，安排1小時的評審會
• 參與人：產品經理、開發負責人、測試負責人（必須參加）
• 產出物：完善的需求文檔 + 測試場景清單 + 驗收標準
• 會議流程：

1. 產品講解（15分鐘）：介紹需求背景、目標、功能點

2. 開發質疑（15分鐘）：從技術實現角度提出問題

3. 測試質疑（20分鐘）：從測試角度提出問題

4. 討論確認（10分鐘）：三方討論并達成一致

2.2測試質疑清單

為了讓測試人員能夠系統地發現需求問題，我設計了一個標準化的質疑提問清單：

• 功能完整性檢查：
• 正常流程是否完整？
• 異常情況如何處理？
• 邊界條件是什么？
• 與現有功能的關系如何？

• 數據準確性檢查：
• 數據來源是什么？
• 數據格式和范圍是什么？
• 數據校驗規則是什么？
• 數據異常如何處理？

• 業務規則檢查：
• 業務規則是否明確？
• 規則的優先級是什么？
• 規則沖突如何處理？
• 規則變更的影響范圍？

• 用戶體驗檢查：
• 用戶操作路徑是否合理？
• 錯誤提示是否友好？
• 響應時間是否可接受？
• 是否考慮了不同用戶場景？

2.3第二次迭代的實踐

第二次迭代的需求是"新增積分兌換券功能"。這次我們嚴格按照三方評審機制執行。

評審會實錄（節選）：

• 產品講解：
• "用戶可以用積分兌換優惠券，100積分可以兌換一張10元券..."
• 測試質疑：
• Q1：積分不足時如何提示？
• Q2：兌換后積分什么時候扣除？
• Q3：兌換的券有效期多久？
• Q4：用戶可以兌換多少張？有沒有限制？
• Q5：兌換失敗（比如網絡異常）如何處理？
• Q6：積分扣除了但券沒發放成功怎么辦？

• 開發補充：
• Q7：積分余額從哪個系統獲取？接口響應時間多久？
• Q8：如果積分系統不可用，是否需要降級方案？

• 討論結果：
• 產品經理當場補充了8個之前沒有考慮到的場景，并承諾會在需求文檔中詳細說明。

• 完善后的需求文檔（部分）：

功能：積分兌換優惠券

1. 兌換規則

- 兌換比例：100積分 = 1張10元券

- 每日限額：每個用戶每天最多兌換3張

- 積分要求：用戶積分余額 >= 100

2. 兌換流程

- 用戶點擊兌換按鈕

- 系統校驗積分余額（調用積分系統接口，超時時間3秒）

- 積分充足：扣除積分 → 發放優惠券 → 提示成功

- 積分不足：提示"您的積分不足，當前積分XX，需要100積分"

3. 異常處理

- 積分系統不可用：提示"系統繁忙，請稍后再試"

- 積分扣除成功但券發放失敗：記錄日志，后臺補發

- 網絡超時：提示用戶刷新頁面查看兌換結果

4. 驗收標準

- Given：用戶積分余額為150

Then：積分扣除100，獲得1張10元券，提示兌換成功

- Given：用戶積分余額為50

Then：提示"您的積分不足，當前積分50，需要100積分"

- Given：用戶今日已兌換3張券

Then：提示"今日兌換次數已達上限"

2.4實施效果

第二次迭代的結果讓我們驚喜：

數據對比：

團隊反饋：

- 開發："需求更清晰了，開發過程中幾乎不需要回頭問產品"

- 測試："提前介入讓我對需求理解更深，測試用例設計更有針對性"

- 產品："雖然前期花的時間多了，但后期省了更多時間，整體效率提升了"

深化實踐：驗收標準的編寫技巧

3.1為什么需要明確的驗收標準

在實踐中我們發現，即使需求文檔寫得很詳細，如果沒有明確的驗收標準，開發和測試對"做完"的理解仍然會有偏差。

一個真實的例子：

• 需求："用戶登錄失敗3次后，賬號鎖定30分鐘"
• 開發理解：連續輸錯3次密碼后鎖定
• 測試理解：24小時內累計輸錯3次后鎖定
• 結果：開發完成后，測試認為不符合需求，又花了0.5天修改。

??轉崗軟件I測試/野路子技能提升

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

??可以到我的個人號：atstudy-js

即可加入領取 ??????

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

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

3.2Given-When-Then格式

我們采用了Given-When-Then格式來編寫驗收標準，這個格式簡單易懂，能夠消除歧義。

• 格式說明：
• Given：前置條件（系統處于什么狀態）
• When：用戶操作（用戶做了什么）
• Then：預期結果（系統應該如何響應）

• 改進后的驗收標準：

場景1：首次登錄失敗

Given：用戶賬號正常，未被鎖定

When：輸入錯誤密碼點擊登錄

Then：提示"密碼錯誤，您還有2次嘗試機會"

場景2：第三次登錄失敗

Given：用戶已連續輸錯2次密碼

When：再次輸入錯誤密碼點擊登錄

Then：賬號被鎖定，提示"密碼錯誤次數過多，賬號已鎖定30分鐘"

場景3：鎖定期間嘗試登錄

Given：用戶賬號已被鎖定，距離鎖定時間10分鐘

When：輸入正確密碼點擊登錄

Then：提示"賬號已鎖定，請20分鐘后再試"

場景4：鎖定期滿后登錄

Given：用戶賬號鎖定已滿30分鐘

When：輸入正確密碼點擊登錄

Then：登錄成功，錯誤次數清零

場景5：登錄成功后錯誤次數清零

Given：用戶已輸錯1次密碼

When：輸入正確密碼登錄成功

Then：錯誤次數清零，下次輸錯從1開始計數

3.3邊界條件的識別

在編寫驗收標準時，特別要注意邊界條件。我總結了一個"邊界條件檢查清單"：

• 數值邊界：
• 最小值、最大值、零值
• 臨界值（如優惠券滿100減10，測試99、100、101）
• 時間邊界：
• 開始時間、結束時間
• 跨天、跨月、跨年的情況
• 時區問題
• 狀態邊界：
• 初始狀態、中間狀態、結束狀態
• 狀態轉換的各種路徑

• 數量邊界：
• 空集合、單個元素、多個元素
• 超出限制的情況
• 實際案例：

優惠券使用的邊界條件：

場景：訂單金額剛好等于滿減門檻

Given：用戶有一張"滿100減10"的優惠券

When：下單金額為100元，使用該優惠券

Then：優惠10元，實付90元

場景：訂單金額略小于滿減門檻

Given：用戶有一張"滿100減10"的優惠券

When：下單金額為99.99元，嘗試使用該優惠券

Then：提示"訂單金額不滿足使用條件，需滿100元"

場景：優惠券在使用時剛好過期

Given：用戶有一張優惠券，有效期至2024-03-01 23:59:59

When：在2024-03-01 23:59:59下單并使用該券

Then：可以正常使用

場景：優惠券在使用時剛剛過期

Given：用戶有一張優惠券，有效期至2024-03-01 23:59:59

When：在2024-03-02 00:00:00下單并使用該券

Then：提示"優惠券已過期"

未完待續，后面將繼續為大家介紹遇到的挑戰與解決方案、實施建議與關鍵要點、三個月后的成果及總結。