【推薦】極限編程的十二大原則——測試

測試：一個功能存在的前提是有一個測試能夠驗證它，任何有被破壞的可能的代碼就必須有一個對應的測試。

以前當硬體環境有限的時候，程式的編寫非常講究效率，對記憶體的使用都要精打細算。很快的，硬體環境極大的改善，開發工具越來越“傻瓜”，程式員們再也不用精打細算的過日子了，然而漸漸的，程式員的簡潔意識也越來越薄弱，所以，記憶體泄露的問題越來越嚴重。

我印象非常深刻的就是以前聽過一個同事講過這樣一件事情：他們做軟包的部門有一次將測試完成後的程式交給外方，結果外方根據他們的測試案例逐一驗收，結果當一個操作重複進行了將近500次的時候，程式崩潰了。當外方將這個資訊反饋給中方人員的時候，他們的第一個反應就是“這幫人瘋了，誰會去重複做一個操作這麼多次啊！”，因為他們在測試的時候就是做一次，得到一個結果正確了就算通過了。

測試原則在我理解中應該是敏捷開發中最重要的原則。因為對于敏捷開發，它是歡迎變化的，也就意味著頻繁的修改。如果這種頻繁的修改沒有測試做保證的話，那麼最終的結果只能是一堆錯誤百出、隱患重重的垃圾。這其實也是很多敏捷開發的實踐活動沒有取得成功的重要原因：在實踐中沒有抓住測試這個環節，忽視了測試的重要性，或者就是根本沒有能力做到符合標準的測試的能力就急急忙忙的進行敏捷開發的實踐。

和很多人談起敏捷開發、極限編程的時候，大家對於結隊編程、工作40小時、減少文檔這類特點最感興趣、羨慕不已，彷彿敏捷開發的這些特點才吸引了他們去關注敏捷開發的。卻忽視了對測試、重構這些真正需要我們認真思考的原則，一說起測試的問題，他們就會說這些我們現在也在做啊！可是，我們有沒有認真地考慮過我們現在做的測試是否全面了，對測試的目的、意義、方法的認識是否到位了？

極限編程中對測試總結了7種類型，來看看吧，我們目前的測試能做到哪些？：

（1）自動化迴歸測試（Automated regression test）

    運行自動化測試代碼來驗證當前的修改沒有破壞已有的功能。

（2）單元測試（Unit test）

    驗證單元層級的代碼工作是否正常。

（3）公用API測試（Public API test）

    驗證被第三方開發人員調用的API可正常工作，並且得以文檔化。

（4）私人API測試（Private API test）

    驗證內部使用的API工作是否正常。

（5）命令列測試（Command-line test）

    驗證在命令列輸入的命令工作正常。

（6）使用者介面測試（User interface test）

    驗證介面層的功能是否正常。

（7）“狗糧”測試（Dog-food test）

    這裡用了一個有趣的名字“Dog-food test”，自己的“狗糧”自己先嘗嘗！在企業內部使用自己開發的產品，通過這種實際地使用來確保功能正確，滿足使用要求。

 

開發人員會有一種長期沉積的觀點：測試，那是測試人員的事情！我們雖然要求提交測試之前要有自測，可是我看到的也僅僅是一個自測報告，我們自測的時候是否有測試案例？是否有測試代碼？這些測試代碼都是否做了很好的儲存，以便將來修改程式時能夠複用作迴歸測試？

在以前的軟體Team Dev中，我們要求對所有的資料層（java程式）都要有單元測試代碼，用來測試輸出的XML格式資料，並將這個XML格式資料作為介面提交給介面層（javaScript、HTML）測試介面功能，同時還要對中間的業務層（java程式）作單元測試驗證業務功能的輸出輸入。這些都是開發人員自己利用Junit架構編寫的測試案例和代碼，而所有這些也都跟來源程式一樣規劃目錄結構，作為來源程式結構的一部分進資料列版本設定。這些方法就保證了當人員的變動時、當程式需要修改時，通過這些單元測試代碼可以有效地保證軟體變更後的功能驗證。

其實我一直都覺得，無論軟體、硬體開發，測試人員應該是有豐富的開發經驗，並且要有比開發人員更深入的思考水平。如果進行敏捷開發實踐的話，開發與測試人員的區別無非是負責編碼和負責編寫測試代碼的區別，而從編碼難度上，兩者是沒有什麼差距的，甚至從思考的程度上，編寫測試代碼要更想得更多、更深入一些。

可以看出，敏捷開發中對測試的要求如此之高，也就對所有希望進行敏捷開發實踐的團隊提出了一個很高的要求：我們是否能夠有能力將測試提到如此高的層面？我們是否有能力如此之高的測試人員？我們能夠堅持無論任務多麼緊張，都不能裁減測試的原則？所有的這些問題從本質上說其實都是對長期以來沉澱的觀點、思維習慣的一種挑戰。因此，敏捷開發與其說是一種開發方法，不如說是一種開發理念，它需要的其實是我們觀念上的變革！