用戶故事要經過 DoR 的考驗才能被研發團隊接受，只有扛住 DoD 的考核才能邁出走向客戶第一步。在敏捷開發中，想要評估一個故事是否達到客戶對需求的期待，就要讓它去接受「驗收標準」的考驗：用戶故事必須「通過」所有的驗收標準，才算是真正地產生價值。

DoD 是對迭代中「所有」工作事項或用戶故事的「基本要求」，而驗收標準則是對「特定」用戶故事的「需求細節」進行的逐一驗證。

一個工作項目是否能如質如期地完成，最重要的部分就取決于開工前是否有明確的「驗收標準」。

一、 驗收標準的目的

---

01 描述明確的需求范圍

通過對驗收標準的討論，團隊可以了解產品負責人與利益關系人對需求的期待，也能更明確地掌握需求的范圍，方便估計時程與測試涵蓋范圍。

02 描述錯誤的案例處理

編寫驗收標準條例可以全方位地考慮需求可能會出現的限制與錯誤情況，并延伸對應的處理方式。在開發過程中，實現快樂路徑（Happy Path）相對簡單，但「錯誤／例外處理」卻常常被遺漏掉。

03 增加共識的討論模式

透過對驗收標準的討論，產品負責人和開發團隊能夠一次又一次地理解需求目的，確保對需求持有相同的理解，才能在最后的展示階段完整地呈現結果。

04 提早列舉出測試案例

書寫驗收標準的過程也是測試人員和產品負責人向開發團隊說明和同步測試最低標準的過程。這樣才不會出現開發產出越過測試，或待測試項目未完成開發等情況。

05 時程工期的有效估計

只有完成驗收標準的討論后，開發團隊才能更好地明確需求和測試的范圍，對需求開發做出更準確的估計，其中包括時間、人力的絕對估計，以及點數、大小的相對估計。

二、 驗收標準的寫法

---

常見驗收標準的寫法有三種，分別是情景式、規則式和習慣式。

01 情境式寫法 Scenario-based

「情境式寫法」是面向場景的，其信息描述最為完整，也因此在敏捷團隊中被更廣泛地傳播和應用。

情境式寫法的結構包含了以下五個元素，傳遞了「測試用例」和「價值交付」兩方面信息。

• 情境 Scenario：描述用戶使用的場景／情景

• 假定 Given：描述驗收標準的預先設定條件

• 當 When：描述用戶在什么情況／操作下

• 然后 Then：描述預期會發生的結果

• 而且 And：描述預期會發生的更多結果

舉個例子說明一下：

情境 用戶帳號登錄

Given 用戶進入「賬號登錄」頁面，

When 用戶輸入錯誤的用戶名或登錄密碼時，

Then 登錄頁面會彈出「密碼錯誤」的提示，

And 登錄頁面也會呈現「忘記密碼」跳轉入口。

02 規則式寫法 Rule-based

「規則式寫法」是用條列的方式列出所有需要驗證的測試案例，通常是一份清單形式的文件。相比情景式寫法，規則式的驗收標準能覆蓋更多、更廣的測試范圍，但也省略了對需求價值的描述和說明。

測試案例「用戶賬號登錄」的驗證規則如下：

• 用戶輸入正確的賬號、密碼時，可以登入賬號頁面查看賬號信息；

• 用戶輸入存在的賬號、錯誤的密碼時，需要出現提示信息「密碼錯誤」；

• 用戶輸入不存在的賬號時，需要出現提示信息「該賬號不存在」；

• 用戶連續輸入錯誤的密碼超過三次時，需要出現提示信息「密碼已錯誤三次，請重設密碼（附跳轉）」。

03 用戶角度的習慣寫法 Customer-based

有些測試人員可能會用流程圖、思維導圖、檢核表等方式書寫驗收標準，但寫法不是重點，能清楚呈現「驗收標準」，說明客戶需求期望的就是好方法。

三、 驗收標準的八點誤區

---

工作項目完成后才進行驗收標準的討論。

驗收標準事無巨細，單一功能就有不同組合的測試。

驗收標準范圍太廣，已經超過本次要進行的范圍。

驗收標準不是用戶看到的情境，而是底層的技術細節。

團隊對驗收標準還沒有達成共識就開始工作。

驗收標準無法獨立，需要其他驗收標準的配合才能進行測試。

測試的條件是充滿變數的，無法模擬的。

只由測試人員或產品負責人單向設計出的驗收標準，開發團隊事前不知情。

原文作者：Vince Huang

文章來源：Medium【文思不藏私】專欄

「LigaAI」的趣味分享與敏捷實踐，請關注 LigaAI@CSDN，持續接收更多干貨分享~ 進一步了解我們的產品，請訪問 LigaAI -新一代智能研發協作平臺

總結

以上是生活随笔為你收集整理的研发需求的验收标准应该怎么写？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。