由實例驅動的驗收測試 驗收測試方法
人們一直將測試看做開發義務不可或缺的一部分，代碼和測試用例都是敏捷項主旨重要產出。然而，在許多敏捷團隊中，相較驗收測試而言，單元測試和集成測試的地位要更為顯著。Gojko Adzic和Lisa Crispin建議采取方法，將驗收測試作為開發義務的一部分。
Gojko認為有必要以實例編寫研究會的形式來支持驗收測試。他認為：在下個迭代起頭前，團隊應該大致了解一下下個迭代要開發哪些功能。在不干擾以后迭代義務的前提下，有些團隊成員能夠參加實例編寫研究會。這個研究會要重點研究如何編寫有現實意義的例子，以后好把它們轉換成驗收測試。在Gojko看來：
研究會的主旨，是要在開發人員、業務人員和測試人員之間建立奇特的了解，讓大家知道接下來兩周的義務主旨。研究會更詳細的主旨，就是發作現實的實例，可供以后轉換為驗收測試。
……
因為實際的例子是經過討論并撰寫下來的，所以如果大家對需求的了解有什么不一致，在這個階段很隨便發現，也就能夠為開發階段的義務打下堅實基礎。當與會每個人都贊成編寫的實例已經夠用而且足夠清晰之后，研究會也就能夠結束了。同時，以后迭代要用到的驗收測試應該延續一直地進行簡化，并以更好的形式組織。
Lisa Crispin也著重指出了實例在定義驗收測試中的重要性。不過，她尤其提醒不應深入過多細節，這樣反而會降落效率。在Lisa看來，她認為測試策略應該是這樣的：
1。 先跟產品負責人開會討論需求的滿意條件，能夠提問題，得到實例，切分大故事
2。 迭代規劃
3。 高級別的驗收測試和其他的準備義務，比喻獲取測試數據和其他更多實例
4。 詳細說明測試用例
5。 編寫可自化運行的FitNesse測試(面向業務的測試，可用來指導開發)
6。 探索性測試，自動化GUI冒煙測試
每個用戶故事都要進行4-6這三個步驟。
因此，驗收測試應該作為每個迭代中開發義務的一部分。關鍵在于讓業務團隊和開發團隊先碰面，并發作足夠的實際例子，并以之創建有用的驗收測試。
文章來源于領測軟件測試網 http://www.k11sc111.com/
