單元測試和壓力測試是軟件開發質量的保證

　　軟件測試的概念最早是大學時從老師那里記來的兩句話(其他都丟光了)：開發是盡可能地讓程序通過;而測試，則是盡可能地讓程序通不過。兩者的區別，在于選取測試實例在設計上的指導思想的不同。這句話雖然簡單，但易記，自已也覺得真是收益菲淺。當時還沒有什么javawindows之類的故事，所謂軟件，其實是C語言和匯編，不過這個思想我卻是覺得可以用到軟件開發和測試的幾乎方方面面。

　　一般說來，可用性測試和黑盒測試這類工作既引不起我的興趣也算不得是我的工作責任，除了在驗收時應應景以外，正常情況難得會多看一眼。而且，為了讓可用性測試少出點麻煩，早就養成習慣，只要不是requirement specifics(需求規格)中的項目，千萬不要多事，多做多錯。(不過如果項目不規范，壓根沒有規格說明時就另當別論，這時我會堅持需求自已出，等于自已做用例需求分析，這也是合理的要求了，可以省許多扯皮扯不清的麻煩)。在操作中真正需要操心的是白盒的單元測試，以及壓力測試;這兩者又偏偏是互相沖突的。

　　熱衷于單元測試說起來源于《艾柯卡自傳》中的一句話：產品出廠前發現故障，所花費的成本是出廠后發現故障的十分一。單元組件就是我的產品，單元測試就是出廠前的測試，與其出廠后給人扯著叫回來：“你的程序出錯了”，不如先自已把它測過透。所以我的習慣不知是好是壞了，不過測試是上心的，基本上每花一個 ManDay做開發，就要花一個ManDay做測試，包括寫測試例程，組織測試數據;(兩者合起來就是測試實例);文檔的時間還要另算。Junit,作為單元測試的工具，我只是在EJB的環境中使用過;這還是由于EJB的測試實在不容易，平常使用的埋設斷點，編寫測試類的方式在EJB容器全不管用， EJB也居然沒有提供針對EJB本身的類設定輸出日志的功能 ，一有錯就要滿系統日志翻可能只是幾十個EJB中的一個輸出的錯誤日志。相比之下，JUNIT 及其擴展象Junitee，提供了拋開其他部分單純測試EJB組件的功能。這其實也是Junit的基本思想，對于分層開發的實現固定接口的組件，與其自已一個個寫測試環境然后main，不如使用統一的測試框架。這也是高效開發不可缺少的一個部分，但對于其他的類，使用Junit我實在看不出有什么好處：類本身可以輸出斷點，又可以幾行代碼在Main中運行，還有什么比這樣的單元測試更有效的嗎?何必多此一舉跑到Junit中呢?

　　不過，單元測試強度越大，所謂越強壯，其實就是考慮的Case越多，if-else也越多，就單元來說固然是強壯了，但實際上消耗系統資源也越多;個個組件多一點，其實加起來整個系統的負載能力就下降得很可觀的。所以單元測試強度與最后的壓力測試是沖突的。只不過在不短的時間里，我只要管好自已的單元不出問題，就天王老子也咬我不進;至于整體性能，既不用考慮也輪不到我考慮。直到系統性能在運行時下降我成為第一個被“咨詢”的對象時，對于整體性能就不能不聞不問了。這時對于壓力測試的興趣一下子升了起來。負載測試在相當長的時間內是一個奢侈品，loadrunner不但是一個大家伙，貴，而且還不容易盜版，其中一個原因是測試畢竟不是我的主業，所以也不會專門弄一臺機玩這個;反正我從來拿不到一個長時間可以使用的版本，也沒有真正學會用這個玩意。另外，擔心歸擔心，真的因為負載太重造成當機的時侯不多，而且也總有應對辦法，如果不是重新處理新的項目，估計也不會再在這上面花太多的心思。

　　最初自已寫一個壓力測試的工具以失敗告終：線程按要求展開了，也發出了http請求，但是系統卻正常得仿佛沒事人一般;可是一放到工作環境就出負載報警。顯然，這是測試程序沒有達到目的，而不是系統真的如此強健。而原因，其實到今天我也不甚了了。不但如此，這兩天試用了webCt和 webrunner這兩個一心想要錢的國產軟件，結果和我當初寫的一模一樣，無論我如何設置加壓，那頭系統同樣是風不吹草不動——可千萬別以為是系統強壯。后來的辦法是使用jakarta HttpClient，調用proxy，這些proxy網上一大把，只要收集下來總有相當數量;這下子測本地局域網的測不了，但測網上網站倒是可以的;也的確復制出大訪問量情況下系統掛機半掛機，也可以檢驗出大概調用多少個proxy時達到掛機效果，要如何優化才不會掛機，變慢一會又恢復過來。勉強可能用，事實上是自已做了一個DDos攻擊的工具，檢查DDos應對狀況;不過搜集proxy真是麻煩而且缺乏日志統計(需要另寫程序啊);更加沒有 session,cokkie等等，只能進行簡單的網頁下載，然后驗證關鍵字，確保下載完全。而且，由于需要手工反復啟動，同時代理服務器應答也有一段時間，系統極限恢復也有一段時間;所以用這個辦法，把會話帶上700多后就再也上不去了，后者未來前者已經終結。

原文轉自：http://www.uml.org.cn/Test/200604242.htm