敏捷社區(qū)的一些成員探討了幾種表述何如進行用戶故事的驗收測試的技術，以及測試整個主題的方法。

　　Charles Bradley介紹了幾種不同的描述如何進行用戶故事驗收測試的方法：

　　列舉要點(Bullet points)
　　在一個用戶故事卡片或者wiki上，以列舉要點的形式，把對系統(tǒng)行為的期望結果和實際結果記錄下來。這種技術適用于較小的或者簡單的用戶故事。
　　測試場景/數據……
　　把你測試需要用到的任何場景、數據都記錄下來。比如，用正確的/錯誤的/空的密碼來測試密碼功能。跟之前的方法一樣，這種技術通常非常適用于小的或者簡單的用戶故事。
　　先測起來
　　先進行一些測試，再洋洋灑灑把你需要驗證的系統(tǒng)功能記錄下來。這是一種比較易學的技術。這種方法適用于簡單的測試，也是其他方法不適用時的萬能鑰匙。
　　Given/When/Then
　　使用三段式：Given，When，Then。在Given部分，羅列出前提條件，測試環(huán)境，測試輸入以及系統(tǒng)狀態(tài)。在When部分，則列出一些觸發(fā)點或者狀態(tài)轉換事件。在Then部分，記錄系統(tǒng)行為，期望的輸出，或者下一個系統(tǒng)狀態(tài)。這種技術對于有著很多前提條件或者有特定觸發(fā)點的測試非常適用。
　　概念形態(tài)上的，帶有實例的規(guī)格說明書(Specification By Example-Conceptual Form)
　　編制一張表格，包含測試輸入和期望輸出。所謂概念形態(tài)，就是不以特定的值來描述數據。如果能比較容易地做出這張表格，那么使用這種方法就很可能非常有效。
　　互相搭配
　　選擇多種不同的方法應對不同的測試角度。

　　Peter Stevens則提出一個名為“如何演示”的測試表單。這個表單本質上是一個簡單的流程，描述了如何向產品負責人演示完整的用戶故事。他寫道：

編制“如何演示”表單是梳理產品待辦事項表的一部分，也就是說，這項工作可以在估算/交付計劃會議的時候進行，可以安排在首輪Sprint計劃會議的時候，也可以在項目的任何時候。它是會話交互的一部分，所以最好別定太早。

　　Lisa Crispin介紹了采用一張思維圖來規(guī)劃測試，以明確要完成的整個主題。團隊用了五輪迭代來完成她所指的主題，也就是十周的工作量。Crispin和另一個測試人員一起著手測試，在一塊白板上畫出了要完成測試工作的思維圖。接下來，他們和開發(fā)團隊、產品負責人、管理者以及其他利益關系人討論了思維圖。

　　在主題的實現過程中，測試人員常常會參照他們的思維圖。Crispin寫道：

最終，我們信心滿滿，我們已經從所有角度想過并討論過流程以及它對系統(tǒng)其它部分的潛在影響，我們還和所有利益關系人都聊了他們各自的要求和擔憂，同時，不止從功能層面，還包括性能和可用性層面，我們都做了充足的測試。

it知識庫：敏捷測試的那些事兒，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。