測試是非常重要的，是軟件成敗的關鍵。但是目前國內對測試并不關注，或是假裝關注。這樣就無法保證軟件的質量。測試有很多種，我們這里要說的是和需求息息相關的測試，就是接收測試（Acceptance Test）（關于這個詞，可能不同的文章會有不同的譯法）。
Surely you aren’t going to assume you’re getting what you need. Prove that it works! Acceptance tests allow the customer to know when the system works, and tell the programmers what needs to be done.
上面這段話摘自『XPInstalled』。接收測試有兩個作用：首先是讓客戶明白系統能夠做什么，然后是讓程序員明白該讓系統做些什么。
有一種測試的方法是把測試留到最后才做，讓客戶去發現錯誤。千萬別這么做。原先花費1塊錢就可以改正的錯誤，到了這個時候，可能需要花費1000塊錢才能解決。這是軟件開發的放大效應。因為很多的工作已經基于這個錯誤建立了，開發人員也已經對這個錯誤沒有映像了。
XP中有一個很重要的價值，叫做反饋（Feedback）。Kent Beck在Extreme Programming Explained中有句話講得非常好："樂觀是編程的職業病，反饋則是其處方。"從需求的識別，到根據需求構建的系統交付給客戶，客戶提出意見。這就是一個反饋過程。反饋過程所花費的時間越少越好。接受測試就是解決客戶反饋的一個有效的手段�？蛻艟帉懣芍貜偷�測試腳本，開發人員開發出的軟件要經受這個測試腳本的考驗。這種的反饋速度是很高的，能夠有效的解決反饋的問題。
因此，客戶在要求實現需求時，同時也有義務提供相關的接收測試：
if it’s worth having the programmers build it, it’s worth knowing that they got it right.
一個有價值的功能一定是可測試的，如果不是，那么這個功能要么是沒有價值，要么是尚未描述清楚。
要注意，這個測試必須是可重復的。這是因為需求的易變性。需求在不斷變化，這就意味著代碼在不斷的變化。因此，原先已經用接收測試證明過了的代碼還需要再次證明。這就要求測試是可以重復的。
大量的測試，甚至重復的測試引出了一個新的問題：全憑手工進行測試會浪費大量的時間。因此，易變的需求對測試提出了一個新的要求：自動化測試。只有自動化的進行測試，才可以完成如此大量的測試工作。目前，最好的自動化測試工具，應該就是Xunit系列。關于這方面的問題，大家可以參考相關的資料，這里我們不作深入的討論。
接收測試最可能的一種形式就是自然語言的說明，外帶一組的測試數據。需要強調的一點是，這個測試數據一定要包括輸入和輸出。這樣才可以做出比較。如果只有輸入沒有輸出。測試很可能就是白費勁。所以，計算這個輸出是手工計算的，它也是必要的。
除了接收測試，還有一個很重要的概念就是單元測試（Unit Test）。但是單元測試和設計的關系比較大，和需求沒有過多的關系，我們這里就只是點一下。大家如有興趣，可以參考相關的資料。
7、分解
對于需求來說，需要用到的最多的技能可能就是分解的技能了�？梢哉f軟件科學最重要的思想就是"分而治之"的思想。不是嗎？面向對象是不是一種分解的思想。類、組件、包，這種層級結構不正是體現了"分而治之"嗎？當然我這里可能把包和組件弄混淆了。但我的主要目的是要指出這種分解的方法在軟件開發中是無處不在的。對于需求也是一樣。我們最早做的業務建模就是為了得到一個系統的概貌圖。然后到了細節需求階段，我們會把這張圖放大，細分，一直到我們有把握處理為止。
如何把100塊磚累起來呢？如果一塊一塊的累，那很容易就倒了。一種比較好的做法，就是先10塊10塊的打包，這樣，100塊磚就變成了10個磚包，再把它們累起來就容易的多了。面向對象其實就是這么做的，當然，面向對象的實現比累磚要難多了。
我們看看XP中是如何處理分解的。XP中最大的周期叫做發布版（release），一個發布版需要一個月或幾個月的時間，一般不超過6個月。發布版的末期，需要向客戶提供一個可以運行的軟件的發布版。然后，XP還定義了次級的周期，稱為迭代（iteration），一次的迭代大概需要一周或幾周的時間。每一次的迭代都是一個"偽發布版"（pretend release），就是說，迭代的最后也必需要提供一個可以工作的軟件，這個軟件隨時都可以發布。為了定義一次迭代中要處理的事情，XP還定義了素材（story），一份素材代表了客戶希望在軟件中出現的一項功能（feature），一份素材是很小的，它只需要花費一個開發人員幾天或幾周的時間。素材已經很小了，但是還需要細分到任務（task），一項任務只需要1到4天的工作量。這并不是最小的單位，XP還把任務劃分到測試（test），但這已經到個人級別上了。
我們看到，XP從客戶到每一個開發人員，定義了5級的單位，并把時間精確到了天、小時。所以我有時候聽人說，XP好像對開發人員的要求不嚴格。錯了，XP可以說是目前要求最為嚴格的方法，這種分類方法可見一斑。這種分類有什么好處呢？
首先，我們來看發布版，發布版的最短時間是一個月，也就是說，最頻繁是一個月向客戶交付一次軟件。這樣，就在很大程度上保證了反饋的迅速進行。避免了傳統的開發方法中最后客戶發現問題時已經太遲了的現象。
再看迭代，迭代之所以被稱為偽發布版，就是因為它的產出物的性質和發布版是一樣的。都是可以交付的產品，但是迭代的功能比較少，沒有必要交付給客戶。我們知道，在傳統的軟件開發中，整合是一個大問題。整合必然會出現問題，但是沒人知道問題在哪兒。所以呢，XP通過不間斷的整合，避免了這個問題。
但是，迭代的周期如此之短，能夠做些什么呢。這就是素材出現的原因。素材由客戶提出，由客戶決定優先級，由客戶決定放在哪一次的發布版和迭代中。同時，如上面我們談到的，客戶需要為素材制定接收測試。
一份素材的周期是幾天或幾周，而一次迭代的時間也就幾周。這說明素材對迭代而言，單位過大了。所以要把素材再次分解為任務。每一個任務都需要一個開發人員認領，簽字。在分解素材的過程中，我們可以發現有一些任務是多個素材共享的，這個概念和用例中的使用的概念是一致的。開發人員會估計自己的任務所需要的時間。從而得出一個迭代周期的總時間。這個時間的估計是基于以往的經驗的，因此隨著項目的進行，這個估計往往會越發的準確。
我們這里講XP的分解哲學，并不是要求大家也依樣畫葫蘆，你真要那樣做也不行。因為XP的各項實踐都是一體的，只有實現了所有的實踐，才能體現其威力。我們這樣斷章取義是行不通的。但是其中的思想我們是可以借用的。分解、歸類、排序、估計。這種分析問題的方法，也是我們值得借鑒的。這里有幾點要注意：
最早的分解依據往往是客戶要求的時間。例如，客戶希望在3個月內看到什么什么。在客戶和開發放商議之后，決定制定兩次的發布版。這個決定雖然開發方可以提供參考意見，但是決定權在客戶方；
素材的提出，素材的優先級，素材的安排，這些都是客戶的權利�？蛻粢灿袡嗬∠�、增加、修改素材，或是改變其優先級；
客戶投入多少，就能夠看到多少的軟件�？蛻粢部梢匀∠壳暗捻椖�，而且，先前的投資也會有相應部分的軟件產出；
對于開發時間的估計是開發人員的權力，其它任何強加于開發人員的時間安排都是不對的；
任務的選擇也是出于開發人員自愿的原則；
如果開發人員估計出的總的時間和迭代的預計的時間有出入，絕對不能犧牲開發人員的額外時間換取迭代在限定時間內完成。這種做法無異于飲鴆止渴。比較好的做法是去掉一些任務。
8、客戶如何參與
這是一個純粹的補充問題。一次，一位讀者寫信來問我，中國的客戶素質比較低，對計算機不了解，XP強調的現場客戶現實中根本做不到。
XP要求開發人員在開發軟件的過程中隨時予以支持。誠然，要做到這一點是很難的。我自己也遇到過這種難題，知道問題的棘手程度。我想，這個問題可以分為兩個方面。
一種是定制的軟件。對于這種項目，你需要解決用戶的參與問題，往往客戶方的老總愿意投入資金，但是卻不愿意投入支持的人力。我也曾見過客戶方專門招了一個應屆生來對付需求的情況。遇到這種情況，如果你沒有能力克服它，那么這個項目絕對是失敗的。即便項目最后成功了，申請了什么"重大攻關"之類的獎項，你我都很清楚，這只不過是表面功夫而已。造成這種問題的原因有很多，你需要分析它們，列舉出最深層的原因，并且保證列出的這些原因之間并不會相互影響。然后再試著來解決它。一般而言，如果客戶方是真正愿意實現這個軟件的話，事情并不是不可解決的。
另一種是產品化的軟件。我們可以把這種軟件的客戶分為三類：市場人員、領域專家、最終用戶。市場人員往往對軟件有最初的認識，但是這種認識往往不夠深入。所以，在開發產品化的軟件時，一定要配備專門的市場人員，他們對客戶的需求最了解，是需求的第一手來源。既然你的老板想要開發這個軟件，說明對軟件的未來市場有期待，市場人員加入的要求應該是可以得到滿足的。其次是領域專家，現在很多的軟件公司都配備有領域專家，他們的作用可不小，和市場人員相比，他們也同樣熟悉需求，因為他們自己就是資深的用戶，并且他們還熟悉理論，能夠為軟件開發出大力氣。最后是最終用戶，前面的兩類人的參與還不夠，如果最終用戶不認可軟件，那還是沒有用。所以，要求市場人員找尋可能的目標客戶，試用軟件，提出意見，是非常重要的。我們常說的Beta測試也就是這樣做的。
9、結語
最早這片文章的想法是來自于一個信貸系統（以文章的觀點來看，這個系統是一個失敗的案例）。除此之外，還加上了一些以前的項目的經驗，以及朋友的一些經驗。最后綜合成了這一篇文章。
這個系列的文章的寫作時間的跨度很長。在這個期間，我的思想也經歷一個很大的轉變，所以在寫作中也出現過對已經完稿的部分大肆刪修的情況。這篇文章雖名為『需求的實踐』，但所提到的各種想法、方法，都有理論的依據。當然也是參考了很多的資料。而我個人的能力又極為有限，所以有些時候是心有余而力不足。在這樣的情形下，文章難免會出現很多的錯誤。還希望能得到讀者們的諒解和指正。
在寫作的過程中，也有很多的熱心人寫來信件，其中好些還成為了好朋友。曾經想把里面的問題整理出來，但是由于疏忽，其中的一部分已經找不到了。希望還能有機會做這件事情。
參考資料：
Karl Wieger:《Software Requirements》
Scott W. Ambler: AgileModeling: http://www.agilemodeling.com
Scott W. Ambler: The Object Primer 2nd Edition
Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process
GOF:《Design Patterns: Elements of Reusable Object Oriented Software》
Eric Gamma, Kent Beck: Junit: http://www.junit.org
Kent Beck，Martin Fowler:《Planning Extreme Programming》
文章來源于領測軟件測試網 http://www.kjueaiud.com/
