一個理想的項目應該是單元測試和壓力測試的平衡。掌怕壓力測試的方式，成功發現它的極限狀況，對于程序資源的調用是有很強的指導意義的。
軟件測試的概念最早是大學時從老師那里記來的兩句話(其他都丟光了)：開發是盡可能地讓程序通過;而測試，則是盡可能地讓程序通不過。兩者的區別，在于選取測試實例在設計上的指導思想的不同。這句話雖然簡單，但易記，自已也覺得真是收益菲淺。當時還沒有什么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多后就再也上不去了，后者未來前者已經終結。
這幾天為了測試網站的負載極限，根據朋友的推薦先后使用了幾個壓力工具，上面的WebCT/WebRunner是其中之一， LoadRunner80我一看要裝300大M就又打了退堂鼓，要知道我幾年的機子一裝就不用跑了。微軟的WAS和Jmeter就成了試用的主要方式，這也是目前可以隨便找到的輕易負載工具中比較完善的兩種。WAS設置簡單，運行結果也具備可重復性。不過呢，報告不直觀，而且不能連續動態運行并報告;更糟的是，它沒有驗證請求是否正常的功能(或者是我不會用，沒有找到)，這樣只是發出了請求，至于請求是不是完整執行還是實際上返回一個空文件，真是天知道。某種情況下，它也就是發出一大堆的request,讓網頁轉一轉而已。所以我對WAS的理解是重點不是看它本身的輸出日志，而是著重于從被測試者本身在調高測試強度后是本身記錄日志中檢查是否有異常，以及達到極限狀態下是否能夠恢復上作出結果判斷。
相比之下Jmeter就好一點，這東西使用上也不難，相關的文章一看就基本上會用了。它有驗證請求是否正常執行的功能，也能夠通過持續請求觀察響應變化和背離情況，可以比較容易地發現不同的服務器設置對性能帶來的細微差別;就優化服務器來說，它比WAS強。不過Jmeter似乎有BUG，反正我試過幾次要啟動啟動不了，要關閉關閉不了的情況。
無論是使用WAS還是JMETER，都輕易把服務器會話計數打上了幾千。但怪就怪在，如果使用我自已那套土裝的代理服務器模擬Ddos攻擊時，按請求頻率，很快就會讓目標靶機進入極限狀態，甚至應用crash,必須重啟。但用WAS/JMETER，無論如何調大負載，都只是響應變慢一點，靶機都是死不了;直到我自已的測試機死了，靶機不一會又生蹦活跳地活轉過來。道理在那里，我也沒有什么譜;估計與代理服務器的工作方式有關;我發現靶機方面的記錄計數比我實際發出的線程請求要高出一兩倍。
無論如何，如果打算長期使用一個單元測試的工具測試Web應用負載的話，Jmeter應該是一個不錯的選擇;另備一個WAS也不算浪費。LoadRunner和其他動不動張口要錢的主兒，暫時就免了吧。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
