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

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

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

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

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

問題的發(fā)現(xiàn)：一次失敗的迭代

1.1項目背景

這是一個中型電商平臺的優(yōu)惠券系統(tǒng)改造項目：

• 團隊規(guī)模：8人（產(chǎn)品1人，開發(fā)5人，測試2人）
• 迭代周期：2周一個迭代
• 業(yè)務(wù)復雜度：涉及多種優(yōu)惠券類型、疊加規(guī)則、使用限制

1.2第一次迭代的災難

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

需求：優(yōu)化滿減券功能

目標：提升用戶體驗，增加優(yōu)惠券使用率

功能點：

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

2. 支持跨品類使用

3. 優(yōu)化券的展示樣式

看起來很簡單對吧？但開發(fā)完成后，測試發(fā)現(xiàn)了23個問題：

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

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

1.3問題根源分析

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

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

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

2.1機制設(shè)計

我們決定建立一個"三方評審"機制，讓產(chǎn)品、開發(fā)、測試在需求階段就深度協(xié)作。

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

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

2. 開發(fā)質(zhì)疑（15分鐘）：從技術(shù)實現(xiàn)角度提出問題

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

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

2.2測試質(zhì)疑清單

為了讓測試人員能夠系統(tǒng)地發(fā)現(xiàn)需求問題，我設(shè)計了一個標準化的質(zhì)疑提問清單：

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

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

• 業(yè)務(wù)規(guī)則檢查：
• 業(yè)務(wù)規(guī)則是否明確？
• 規(guī)則的優(yōu)先級是什么？
• 規(guī)則沖突如何處理？
• 規(guī)則變更的影響范圍？

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

2.3第二次迭代的實踐

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

評審會實錄（節(jié)選）：

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

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

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

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

功能：積分兌換優(yōu)惠券

1. 兌換規(guī)則

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

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

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

2. 兌換流程

- 用戶點擊兌換按鈕

- 系統(tǒng)校驗積分余額（調(diào)用積分系統(tǒng)接口，超時時間3秒）

- 積分充足：扣除積分 → 發(fā)放優(yōu)惠券 → 提示成功

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

3. 異常處理

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

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

- 網(wǎng)絡(luò)超時：提示用戶刷新頁面查看兌換結(jié)果

4. 驗收標準

- Given：用戶積分余額為150

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

- Given：用戶積分余額為50

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

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

Then：提示"今日兌換次數(shù)已達上限"

2.4實施效果

第二次迭代的結(jié)果讓我們驚喜：

數(shù)據(jù)對比：

團隊反饋：

- 開發(fā)："需求更清晰了，開發(fā)過程中幾乎不需要回頭問產(chǎn)品"

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

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

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

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

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

一個真實的例子：

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

??轉(zhuǎn)崗軟件I測試/野路子技能提升

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

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

即可加入領(lǐng)取 ??????

轉(zhuǎn)行、入門、提升、需要的各種干貨資料

內(nèi)含AI測試、 車載測試、AI大模型開發(fā)、BI數(shù)據(jù)分析、銀行測試、游戲測試、AIGC

3.2Given-When-Then格式

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

• 格式說明：
• Given：前置條件（系統(tǒng)處于什么狀態(tài)）
• When：用戶操作（用戶做了什么）
• Then：預期結(jié)果（系統(tǒng)應(yīng)該如何響應(yīng)）

• 改進后的驗收標準：

場景1：首次登錄失敗

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

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

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

場景2：第三次登錄失敗

Given：用戶已連續(xù)輸錯2次密碼

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

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

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

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

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

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

場景4：鎖定期滿后登錄

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

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

Then：登錄成功，錯誤次數(shù)清零

場景5：登錄成功后錯誤次數(shù)清零

Given：用戶已輸錯1次密碼

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

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

3.3邊界條件的識別

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

• 數(shù)值邊界：
• 最小值、最大值、零值
• 臨界值（如優(yōu)惠券滿100減10，測試99、100、101）
• 時間邊界：
• 開始時間、結(jié)束時間
• 跨天、跨月、跨年的情況
• 時區(qū)問題
• 狀態(tài)邊界：
• 初始狀態(tài)、中間狀態(tài)、結(jié)束狀態(tài)
• 狀態(tài)轉(zhuǎn)換的各種路徑

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

優(yōu)惠券使用的邊界條件：

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

Given：用戶有一張"滿100減10"的優(yōu)惠券

When：下單金額為100元，使用該優(yōu)惠券

Then：優(yōu)惠10元，實付90元

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

Given：用戶有一張"滿100減10"的優(yōu)惠券

When：下單金額為99.99元，嘗試使用該優(yōu)惠券

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

場景：優(yōu)惠券在使用時剛好過期

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

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

Then：可以正常使用

場景：優(yōu)惠券在使用時剛剛過期

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

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

Then：提示"優(yōu)惠券已過期"

未完待續(xù)，后面將繼續(xù)為大家介紹遇到的挑戰(zhàn)與解決方案、實施建議與關(guān)鍵要點、三個月后的成果及總結(jié)。