摘要
本文描述了如何使用開源的FitNesse來實現真正的測試先行開發過程，并讓客戶、需求提報工程師、開發人員、以及測試人員進行協同工作，達到需求更精準、減少需求更改、測試數據與Junit單元測試代碼分離的目的，讓這一切更簡潔、更易于維護。
作者：Stephan Wiesner
譯者：陳海青(joson)
在過去的幾年里，我在開發測試工作中擔任過各種角色，使用過服務器端的JavaScript，Perl，PHP，Struts，Swing以及模型驅動架構等各類技術。盡管項目不同，但是他們有一些共同點：項目結束的時間越晚，就越難以達到客戶的真正需求。
每個項目都有一些需求，有的非常詳細，有的卻只有幾頁紙，這些需求一般要經歷以下三個階段：
---由客戶或者承包人來書寫或采納一些官方的驗收標準
---測試者試圖根據需求來找出軟件中不符合要求的地方
---項目開發完畢進入驗收測試, 可是客戶突然又提出對軟件需求進行補充或變更的要求
最后一個階段將導致項目發生變化，開發期甚至要超出最后期限，使開發人員的工作壓力劇增，從而導致發生更多的錯誤。Bug的數量將快速增長，系統的質量將下降。聽上去是不是很熟悉？
現
在讓我們看一下在上述的項目開發中發生了哪些錯誤：客戶、開發、測試人員沒能協同工作；需求已經確認通過，但是在不同位置的人可能還用不同的需要未考慮。
另外，開發者一般會寫一些自動測試代碼，測試人員也試圖進行自動化測試，但是他們往往不能充分協同，許多項目被重復測試，但另一些（經常是更困難的部分）
卻沒能被測試，客戶也沒參與到測試工作中。本文所介紹的就是通過自動測試與項目需求相結合的方式來解決這些問題的一種方案。
版權聲明：任何獲得Matrix授權的網站，轉載時請務必保留以下作者信息和鏈接
作者:Stephan Wiesner ;joson(作者的blog:http://blog.matrix.org.cn/page/joson)
原文:http://www.javaworld.com/javaworld/jw-02-2006/jw-0220-fitnesse.html
Matrix:http://www.matrix.org.cn/resource/article/44/44507_FitNesse.html
關鍵字:FitNesse;Test
開始FitNesse
FitNesse
是一個增加了可觸發Junit
測試等附加功能的wiki程序。如果這些測試能夠與業務需求結合起來，就會使業務需求更加清晰。而且，測試數據的組織更有邏輯性。使用FitNesse更
重要的是學習隱含在其中的一些思想，某些部分需求可以作為測試的一部分，這意味著，這些需求是可以測試的，或者說是可以進行校驗的。
利用
FitNesse，開發的工作過程可以這樣描述：需求工程師使用FitNesse書寫業務需求（取代了一般文檔）。他試圖盡可能讓客戶參與其中，當然這并
不是每天都能做到的。而測試者在反復研究這些文檔，并從第一天起就開始提問各種問題，因為他們考慮問題的方式不同，不是在考慮“軟件應該實現些什么”？而
是在考慮“怎樣才能讓軟件出錯？如何讓軟件中斷運行？”等。開發者更象一個需求工程師，他更想知道“軟件必須要完成它的功能是什么”？
測試人員可以更早地開始測試，甚至在需求沒有全部完成前，而且可以把測試寫進業務需求中，這些測試不僅僅成為需求的一部分，而且也將成為需求評審和驗收的重要過程，并具有以下幾方面的重要優點：
---客戶也會被吸引來開始考慮關于測試的事情，通常他們還會參與到建立測試的工作中來（你也許會吃驚，他們怎么對這些這么感興趣了。）
---相關規范將更詳細、更周密，因為測試總比單純的文字要準確.
---通過這種方式，可以更清晰明確地了解軟件（象一個軟件原形，但是功能更多）,因此可以更早地考慮真實的運行場景，提供測試數據和測算結果。
最后，需求將提交給開發人員，他的工作要比以前要更容易些，因為需求都附帶具體的實例，因而更貼近實際需求，因此減少了被突然改變的機會。下面，就讓我們看一下這個過程是如何使開發者工作更輕松的吧。
測試先行的實現
通
常情況下，測試先行開發中最困難的是沒人愿意花費那么多的時間來寫測試，而更愿意去考慮如何讓軟件工作起來。按照上述的過程，開發者把功能測試看作合同的
一部分，他的任務要從“按要求編程，檢測并修改”轉變為“讓測試運行起來”。現在，在確定應該做什么，何時完成，項目的定位等方面，我們有了更好的方法。
并非所有的測試都可以自動進行，并非所有的部分都可進行單元測試。我們通常將測試劃分為以下幾種類別：
---數據驅動的測試，需要通過單元測試來完成，如計算就是一種典型的例子.
---關鍵字驅動 (Keyword-driven) 測試，常自動化進行。這是一些系統測試，要求應用程序能夠運行，按鈕能夠被點擊，數據可以被鍵入，而輸出的結果中包含規定的值。測試團隊一般都能實現這種測試，但是可能開發者更容易完成這些工作。
---手工測試。這類測試適用于或者實現自動化測試的代價太昂貴并且是對出錯的要求不高的情況，或者是一些基礎功能（如，起始頁面不能顯示），可以很容易地發現錯誤的情況。
我是在2004年首次接觸FitNesse,我曾經嘲笑過它并揚言它是不可能工作的。把測試寫入wiki并自動進行測試，這個主意看起來太荒唐。但是，我錯了，FitNesse真的象看起來得那樣簡單高效。
FitNesse的簡單是從安裝時就開始體現了，只要完全下載了FitNesse的發行包，并解壓縮就可以了。在以下的討論中假設解壓到了c:\fitnesse目錄中。
運
行C:\fitnesse 下的run.bat(linux
下運行run.sh)來啟動FitNesse，FitNesse作為一個web服務運行在80端口上，當然你可以指定端口，如設定81，在運行腳本的首行
加上 –p 81 即可，這就是設置的全部工作?，F在你可以用http://locahost:81來訪問你的FitNesse了。
在本文，我使用windows平臺的java版FitNesse,當然，這些例子也可以用于其它版本和其它平臺（如Python,.net等）
一些測試
你
可以從FitNesse的在線文檔提供了一些例子（可以與有名的Junit的貨幣用例相提并論）開始做起，這些例子非常適合學習如何使用
FitNesse，但是它們還不算是解決復雜問題的例子。因此，我將使用一些在我最近項目中的真實的用例。我已經簡化了問題、代碼，而不是直接取自項目
中，并寫了一些說明。盡管如此，這些例子還是足夠復雜，能夠充分展示FitNesse簡潔直觀的威力
現在，假設我們正在從事一個為一個大型的保險公司開發開發項目，這是一個復雜的基于java的企業級應用。產品將涵蓋公司的全部業務，包括客戶和合同管理，以及支付業務，在我們的例子里，我們只關注其中的極小的一部分。
在瑞士，父母有權利獲得給每個孩子的兒童津貼，經過確認家庭環境后，將根據情況得到相應的津貼。以下是這個需求的簡化版本，我們將從一個傳統的需求開始，并把它遷移到FitNesse中。
兒童津貼的發放存在幾種狀態。有關條款規定在孩子出生月份的第一天開始生效，在孩子達到規定年齡、就業或死亡的所在月份的最后一天失效。
按規定在到了12歲所在月份的第一天，就可以領到190瑞士法郎（瑞士官方貨幣）的補貼。
根據父母全職或兼職工作等情況，依據不同的條款，如表1所示進行分類.
圖 1. 兒童津貼資格表.
就業率要根據工作合同來計算，合同需要被確認是有效的，如果有終止日期，還要確認是否在“有效期”內。表2顯示了根據孩子年齡的不同等條件，父母可以得到的補貼數量。
圖 2. 年齡相關條款
正常情況下，每兩年要對款項進行有規律地調整。
第一次看到這些需求，也許會認為這些需求是很明確的，開發人員有能力輕松地實現它，但是，我們真的確定了這些邊界條件了嗎？該如何測試呢？
邊界條件
邊界條件是指達到、超過、低于某個給定的輸入輸出之的情況。經驗表明，在邊界條件附近的測試比其他測試更有價值,典型的例子就是著名的“只執行一次”的條件跳轉和程序段.
場景對于查找例外條件和邊界條件有很大幫助，因為這是得到關于商業規則的行業經驗的好方法。
場景
對
大部分項目而言，是由需求工程師來提供給開發人員的需求規格說明書，然后開始學習了解需求，提問，然后開始設計、編碼、測試。再后來，開發人員把軟件提供
給測試團隊，在經過幾番改寫和修補后，最后交付給客戶（客戶也許更喜歡考慮提出一些意外的需求）。如果采用了FitNesse,將不會改變這一過程，只是
要增加一些測試用例、場景，和測試意愿。
場景在啟動測試過程中具有特別的的幫助。以下是一些例子，在回答將支付多少兒童津貼等為題上，就要分清多種情況：
---瑪麗亞是單親家庭，她又兩個兒子 (鮑勃, 2歲,??彼得 15歲) ，從事兼職秘書工作 (每周工作20個小時).
---瑪麗亞失業了，后來她找到一個每周工作10個小時的商店助手和每周工作5個小時的臨時照顧幼兒的工作
---保羅和拉瑞（Lara）有一個17歲的女兒麗莎（Lisa），她是一個殘疾人，還有一個兒子弗蘭克，18歲，還在上大學。
即使是僅談論一下這些場景，也有助于測試工作的開展，哪怕是軟件中手工運行這些例子，也幾乎可以確信會發現程序的遺漏，難道因為沒有原型就不做這些嗎？為什么不做呢？
關鍵字驅動（Keyword-driven）的測試
關
鍵字驅動的測試常用于模擬原型，FirNesse允許定義關鍵字驅動的測試類型（詳見“完全的數據驅動自動化測試”（“Totally
Data-Driven Automated
Testing”））甚至在沒有軟件支持的情況下(不能自動運行)，運行基于關鍵字驅動的測試也會很有好處。
圖 3. ActionFixture 測試
圖3
展示的是關鍵自驅動測試的示例。第一列描述的是來自FitNesse的關鍵字，第二列描述的是java類的方法（開發者根據這里的描述，在Java程序使
用這些名字來命名）。第三列描述的是來自第二列的方法所產生的數據。最后一行演示了測試失敗的情形（測試通過為綠色）。正如你所看見的那樣，找出錯誤是很
容易的。
這會使人很容易甚至很樂意去建立這些測試。測試者不必具備編程技能，經過簡短介紹后，客戶也會很容易的讀懂。
用這種方法定義的測試，幾乎就是業務需求，并具備傳統測試用例沒有的重要優勢, 甚至不必去自動生成也有很多優勢:
---測試內容很容易獲得，不必特別訓練就可以輕松完成。
---與其改變需求，到不如先改變測試，這樣反而更直觀(這與使用某些工具的情況完全不同)
---在確定新需求或修改需求時，可以隨時運行測試來看看需要修正哪些內容。
為自動運行測試，需要建立一個簡單的軟件層，用于代表真實的測試代碼。這些測試在自動化測試GUI操作時特別有用。我曾開發過一個基于HTTPUnit的自動測試web頁
這里就是FitNesse自動運行的代碼：
package stephanwiesner.javaworld;
import fit.ColumnFixture;
public class ChildAllowanceFixture extends ColumnFixture
{
?? public void personButton() {
??????System.out.println("pressing person button");
?? }
?? public void securityNumber(int number) {
??????System.out.println("entering securityNumber " + number);
?? }
?? public int childAllowance() {
??????System.out.println("calculating child allowance");
??????return 190;??
?? }
?? [...]
??}
在FitNesse中的運行結果如圖4所示，很有助于調試。與Junit相比，Junit抑制了調試信息的輸出，但我認為在自動Web測試中這些輸出絕對是有必要的。
圖 4. 標準輸出
在測試基于Web的應用時，錯誤也將被包含在FitNesse頁面里，并被顯示出來，這是的條施工作比使用log文件更容易。
數據驅動的測試
關
鍵字驅動的測試是GUI自動測試的最佳選擇，同樣，數據驅動測試也是各類計算類項的首選測試方式。如果你曾經寫過單元測試，那么測試中什么是最令人厭倦的
呢？也許，你會認為是數據。你的測試要進行數據填充，但是數據經常改變，使維護工作變成了可怕的惡夢，測試不同的組合，需要不同的數據，這也許會使你的測
試工作變得日益復雜，變成了”丑陋的怪獸”。
使用數據驅動的測試，數據將從代碼中分離。一般情況下，建立幾種類型的表格，存儲為CSV文件，由測試代碼來讀取。如果再使用FitNesse,我們就可以更便利地進行存儲、改變，以及訪問這些測試數據。
現
在，讓我們把圖2種的表格轉變成一個測試吧。首先，將表格拷貝到Excel中，進行修改，然后使用FitNesse的EXCEL導入功能輸入。這是一個有
用的功能，因為在FitNesse中，表越大越難以維護。輸入的結果如圖5所示。每一行表示一個測試，有問號的列表示需要寫Java方法，沒有問號的行表
示輸入的測試數據。
圖 5. 數據驅動測試表Data-driven test table.
再
重復一次，在閱讀了業務需求后，這種測試就非常容易理解了。如果你曾經擔心如何在你的測試用例里的進行等值測試的話，那就看看這里吧。最后一行大概是最重
要的，因為需求并沒有說明如何處理非法數據，或者處理20歲以上的孩子但仍在上學等情況，這里的關鍵字“error”表明需要處理異常了。
常見問題解答
這里討論使用FitNesse在需求、測試和開發過程中遇到的未解決的問題的解決辦法，以下是部分答案。
手工測試會遇到什么問題？
手
工測試者最常做的就是重復的手工回歸測試，不但代價昂貴，而且容易出錯。自動化測試可以減少但不能消除這種工作的工作量。測試者可以有更多的時間去從事更
有趣的測試,例如在應用程序在復雜的場景下的不同處理等，盡管測試就是要花費更長的時間找到錯誤，但比不意味著因此而要付出更高的代價.
用戶驗收測試不再有必要了嗎？
也許有人會這樣認為。如果客戶在需求中定義了所有的測試，當所有測試測試都變綠（通過了）時，軟件就“完工”了。我的實踐經驗是，客戶仍會提出附加的需求來，盡管如此，他們的需求變化會更少，并更容易地結合實際變化進行分類（同時也會帶來追加的款項）。
在FitNesse書寫比Word documents更有優勢嗎？
甚至在沒用測試的情況下，使用wiki 來寫業務需求也能帶給你更多好處。文檔可以自動用在Web 服務器上，可以被多人并發訪問，可以全文檢索，可以被鏈接。我發現還有以下兩個特點：
---更容易建立數據字典，并鏈接上明細內容。更重要的是，具有查找被引用位置（"where-used"）的功能。 如果修改某個細目，就會立即找到是否被引用過，以避免發生沖突.
---由于Bugzilla (或者 Jira，二者均為缺陷跟蹤系統，譯者注) 是基于Web的, 我們可以方便地在兩個系統之間互相鏈接文檔(artifacts) (bugs, 任務, 討論等),便于提高工作效率。
FitNesse 允許按照確定的順序運行測試，而JUnit 禁止這樣做，你有何體驗？
使
用JUnit,需要對同一個對象分別建立許多setUp() 和tearDown() 方法.
在某些情況下，可以在一個FitNesse頁面里放上所有的相關測試，并能夠給定執行順序.
因此，第一個測試可以建立一個”人”，下一個測試可以對它進行修改，最后一個可以進行刪除操作.如果第一個測試失敗了，而且那個”人”沒有被建立，這該怎
么辦？沒問題，因為第一個測試失敗了，隨意在把它修正好之前，我是不會繼續的. 我一般不會經常使用這種順序執行方式,但有時它會給我帶來很大方便.
FitNesse 可以用于大項目嗎？
大
部分開發者會明白，FitNesse的優勢就是簡單易用。但沒有技術背景的人，如果不使用自動檢查特性以及所見即所得風格的編輯器，工作起來會很困難。一
個簡單的例子就是FitNesse 只有允許使用三種類型的標題, 但現在我們需要五種，這就需要我們就可以對FitNesse 進行擴充.
FitNesse 不包含輸出為類似PDF文件的功能。我曾經使用過長度達到60頁的Word文檔，盡管編輯起來有些困難,但是可以輕松打印出來. 但是當我把它轉到FitNesse里后,我就難以打印了，因為被分解為幾個不同的頁面，最后不得不通過編程解決.
FitNesse
具有一個簡單的機制可以顯示那些文檔被修改了，被誰修改了,但不能顯示修改了什么,
權限管理有局限。使用FitNesse重開一個項目要比改寫一個運行的項目更容易.對中小型項目而言，我極力推薦FitNesse.
大項目也可以使用，但是進行更仔細的評估后再實施會更好.
結論
我認為FitNesse是需求分析的好工具，對測試優先開發很有幫助，它是很有利用價值的。我被迫花費幾個周來適應FitNesse及其處理過程，我的項目目前尚未完成，但是我已經看到了需求質量和軟件質量均得到明顯提高，而對測試者而言，工作起來會獲得更多的樂趣 。
關于作者
Stephan
Wiesner 是瑞士盧賽恩Löwenfels Partner AG的測試管理人員。他是“Learning Jakarta
Struts 1.2”(伽利略出版社，德語版，ISBN：3898426130；英語版：ISBN: 190481154X)的作者，” Java
der Code”(由德國MITP出版社發行，ISBN:
3826614623)。另外還在德文雜志上寫過大量的與java相關的文章。他有著豐富的開發和測試經驗，是一位ISTQB認證的測試管理員和認證的
Scrum主管（ScrumMaster，Scrum是一種敏捷開發方式，譯者注）。
陳海青(joson)，本文譯者，生活在中國的山東省煙臺市，先后從事軟件開發、數據庫管理、系統管理等工作，2001年獲得高級程序員資格。
相關資源
---Matrix-Java和中間件社區:http://www.matrix.org.cn
---“完全的數據驅動自動測試”（"Totally Data-Driven Automated Testing" ），作者Keith Zambelich ，詳細闡述了數據驅動和關鍵字驅動的測試: http://www.sqa-test.com/w_paper1.html
---以下站點提供了更多的關于優化FitNesse的內容: http://fitnesse.testmanager.info
---官方的FitNesse網站，經常更新: http://fitnesse.org/
---下在完整的FitNesse發行版: http://fitnesse.org/FitNesse.DownLoad
---部分資料可以在譯者的站點找到:http://www.chq.name/