作者 | 于曉南
敏捷質量實踐中提倡測試左移，測試人員要盡早介入需求階段，越早越好。測試人員需要關注需求的有效性，以及在需求產生和傳遞的過程中，交付價值是否被準確的描述、理解和對齊。在這個過程中很容易遇到一個常見問題：驗收標準是驗收測試要測的嗎?驗收標準到底是不是測試用例?這兩者之間有什么區別和聯系?本文主要想解決的就是這個具體的困惑。
驗收標準是確保需求實現的最小集合
驗收標準是什么
回顧一下需求由厚厚的《軟件需求規格說明書》演化為一張用戶故事卡片的過程，在這個過程中我們舍棄了大量的細節描述，突出了需求需要交付的客戶/用戶價值。在需求交付的過程中，我們會一直關注價值，在保證價值的前提下，實現方式和技術細節都是可以討論的。
那么問題來了，既然很多內容都是可以討論的，我們怎樣確定一個用戶故事被實現完成了呢?驗收標準就是用戶故事實現完成的試金石。可以這樣說，一個用戶故事能否被標記為開發完成并進入測試階段，很大程度上取決于驗收標準是否全部通過。
通常來說，驗收標準就是一系列可以接受的條件或者業務規則，且與功能或特性相互匹配和滿足，同時也能被產品負責人和相關干系人接受。
敏捷實踐中，推薦使用行為驅動開發(Behavior-driven development，縮寫BDD)的方式來寫驗收標準，即使用GWT格式。
- Given (在什么樣的情景或條件下)
- When (采取了什么行動)
- Then (得到什么結果)
舉個例子：
- Given (假設) 我在搜索界面
- When (當) 我填寫入住城市，選擇住宿時間
- Then (于是) 我可以瀏覽該城市和該時間段內空閑酒店的名字和價格
在編寫驗收標準時，應重點關注可以驗證需求實現的用戶場景上，更多的是正向驗證用戶需求實現完成，切忌將驗收標準寫成測試點。
驗收標準在什么時候用
(1) 故事啟動(Story Kickoff)
在故事啟動時，需求涉及的全部角色：需求分析師、開發、測試、體驗設計師，大家需要坐在一起進行需求澄清，確保所有人對需求的理解一致，并約定好故事驗收時的驗收標準都有哪些。在這個過程中，任何人都可以針對驗收標準進行提問，或者補充更多的驗收場景。
(2) 故事驗收(Desk Check)
當開發人員完成代碼實現后，做一些基本的自測工作，并準備好驗收場景和數據，就可以約大家進行故事驗收了。驗收時，也需要需求設計的全部角色，大家坐在一起，聽開發講解實現細節，并逐一演示驗收場景。如果驗收標準全部驗證通過，大家也沒有其他問題，這個用戶故事就可以被標記為開發完成，準備進入測試階段了。
(3) 用戶驗收測試(User Acceptance Test)
除了研發團隊的測試外，迭代的交付還需要一定的用戶驗收測試。用戶驗收測試的設計和執行者有時是PO、或是提出需求的客戶及相關干系人，有時是小范圍內測或公測的真實用戶。在用戶驗收測試時，執行者也會在一定程度上參考驗收標準，檢驗驗收標準是否完備，是否都能滿足用戶預期的驗證通過。
驗收標準不是驗收測試
從上文的討論中，可以得出結論：驗收標準是定義用戶故事完成的標準。而驗收測試分為兩部分，一部分發生在用戶故事開發完成后，是研發團隊內部的驗收，另一部分是在測試完成后上線前，由客戶或真實用戶進行驗收。由此可見，驗收標準并不等于驗收測試，驗收標準是驗收的最小集，而驗收測試的范圍要更廣。
測試用例驗證了軟件功能的有效性
測試用例是什么
測試用例是指為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。簡單來說，測試用例就是用文字來描述以怎樣的步驟測試一個測試點，以及期望的測試結果是什么。
測試用例通常會包括：描述、優先級、前提條件、執行步驟、期望結果、實際結果和備注等信息。根據項目各自的特點，測試用例包含的信息不盡相同。
測試用例在什么時候使用
(1) 用例設計和評審
在測試設計階段，測試人員根據需求，采用多種設計思路來編寫測試用例，并提交至測試組或項目組進行用例評審。此時，測試用例承載了業務需求的測試點，以及測試人員基于專業經驗識別出的非業務需求類的驗證點。
(2) 測試執行
在測試執行階段，測試人員(有時也是用例編寫者)按照用例的詳細描述執行測試用例，并根據實際執行結果與預期結果是否一致，來判定該測試用例是否通過測試。不通過的用例需要分析原因，報缺陷或以其他方式進行跟進。
(3) 回歸測試
開發對用例相關的功能進行改進，或者修復了相關缺陷，就需要對指定用例進行回歸，確保功能沒有被改壞，或者缺陷確實被修復了。另外，有時在重大上線前，也需要按優先級選取一定量的測試用例來進行回歸測試，以確定主線業務流程功能正常。
() 溝通測試點
測試用例還有個很重要的作用，記錄具體的實現細節以及框定需求的測試范圍。多個迭代過去，大家在需要翻看歷史需求時，可能故事卡不足以還原全部的實現細節，測試用例集在這個時候就能夠完整的告訴大家：軟件是怎么實現的，當執行某些操作時，程序有什么表現，以及當時這個需求的測試范圍是什么。尤其在團隊成員上下文不足時，良好設計并編寫的用例集可以完美補齊這些知識。
驗收標準不是測試用例
以上我們討論了驗收標準和測試用例分別是什么，以及在什么階段使用。容易得出，驗收標準與測試用例是完全不同的兩件事，兩者的相同點在于它們都是可判定的用戶使用場景，可以根據預期來判斷是否通過，而兩者的區別體現在下表中的各個維度上。
本文我們還討論了驗收標準不是驗收測試。僅從覆蓋范圍來看，驗收標準、驗收測試、測試用例的關系可以參考下圖：
- 測試用例：覆蓋范圍最大，應該是確保軟件功能正常、滿足用戶預期的測試全集
- 驗收測試：覆蓋范圍比測試用例小，只覆蓋驗收需要的測試用例
- 驗收標準：覆蓋范圍比驗收測試小，只覆蓋驗證需求實現完成的測試用例
當然，驗收標準和測試用例除了使用時機外，兩者的區別也體現在不同的責任人和使用范圍。驗收標準的責任人是需求分析師，在團隊協作過程中使用，是多角色合作的基礎;而測試用例的責任人是測試人員，屬于測試專業上下文的內容。但在不同的組織結構下，對角色的定義會存在一定模糊的界限，因此，“全團隊為需求的驗收和質量負責”是比較推薦的理念。
相信經過本文的澄清，我們已經搞懂了驗收標準和測試用例到底是怎么回事。隨著行業的發展，為了測試左移，將有越來越多的測試人員需要懂需求;相應的，為了高效產出高質量的需求，也有越來越多的需求分析人員需要懂測試。需求分析人員與測試人員一起打造高質量的需求，將為交付高質量高價值的軟件奠定堅實的基礎。
