《LoadRunner 沒有告訴你的》之五——無所不在的性能測試 (已完稿)

提到性能測試，相信你們能夠在網上找到不少種不一樣的定義、解釋以及分類方法。不過歸根結底，在大多數狀況下，咱們所要作的性能測試的目的是「觀察系統在一個給定的環境和場景中的性能表現是否與預期目標一致，評判系統是否存在性能缺陷，並根據測試結果識別性能瓶頸，改善系統性能」。

本文是《LoadRunner沒有告訴你的》系列的第五篇，在這篇文章中，我但願能夠跟你們一塊兒來探討「如何將性能測試應用到軟件開發過程的各個階段中，如何經過儘早的開展性能測試來規避由於性能缺陷致使的損失」。

所以，本文的結構也將依據軟件開發過程的不一樣階段來組織。

另外，建議您在閱讀本文前先閱讀本系列文章的第三篇《理髮店模型》和第四篇《理解性能》。

 

需求階段

咱們不可能將一輛設計載重爲0.75噸的皮卡改裝成載重15噸的大型卡車，若是你面對的正是這樣的問題，那麼恐怕你只能重作一輛，並且客戶不會爲你以前那輛付錢。對於一個已經完成的應用系統來講也是如此。

若是咱們在系統結構肯定以前就可以瞭解到系統的將要面對的壓力，用戶的使用習慣和使用頻度，咱們就能夠更早也更有效的提早解決或預防可能發生的性能缺陷，也將會極大的減小後期返工和反覆調優所帶來的工做量。若是咱們預期到系統的容量將會不斷的增加，咱們還能夠給出相應的解決方案來低成本的解決這類問題，就像上面那輛皮卡，也許你能夠有辦法把20輛皮卡捆在一塊兒，或者把15噸的東西分由20輛來運。

 

分析設計階段

系統性能的優化並非要等待整個系統所有集成後才能開始的，早在分析設計階段，咱們就能夠開始考慮系統的技術架構和數據庫部分的優化。

數據庫一般位於整個系統的最底層，若是直到系統上線前才發現由於數據庫設計不合理而致使性能極差，一般使用任何一種方法來優化都已經於事無補了。要避免這類問題，最多見的作法是在數據庫結構肯定後，經過工具或腳本向數據庫中注入大量的數據，並模擬各類業務的數據庫操做。根據對數據庫性能的觀察和分析，對數據庫表結構和索引進行調整以優化數據庫性能。

在系統的技術架構方面，要明白先進的技術並非解決問題的惟一方法，過於強調技術的做用反而會將你帶入歧途。例如：某些業務雖然常常面臨着巨大的壓力，而且業務自己的複雜性決定了經過算法的優化來提升系統的性能收效甚微。可是咱們知道用戶對於該業務的實時性要求並不高，而且返回結果對於不一樣用戶來講是相同的。那麼咱們徹底能夠考慮將每次請求都動態生成返回結果的方式改成每次用戶請求都返回一個按期更新的靜態頁面。

另外，所謂「先進技術」一般都會在帶來某一方面改進的同時帶來另外一方面的問題，未經試驗就盲目的在系統中加入各類流行元素未必是最好的選擇。例如ORM能夠提供一些方便，可是它生成的SQL是未經優化的，有時甚至比人工編寫的SQL效率更低。

最後，要知道不一樣廠家的設備性能是不一樣的，並且不一樣的硬件設備搭載不一樣的操做系統、數據庫、中間件以及應用服務器，表現出來的性能也是不一樣的。若是有足夠的資源，應當考慮提早進行軟硬件平臺的對比選型；若是沒有足夠的資源，能夠考慮經過一些專業的組織或網站來獲取或購買相關的評估報告。

 

編碼階段

一片樹葉在哪裏最難被發現？——當這片樹葉落在一堆樹葉裏面的時候。

若是你只是在系統測試完成後纔開始性能測試，那麼即便發現系統存在性能缺陷，而且已經有了幾個可供懷疑的對象，可是當一段由於使用了不當的算法而致使執行效率很低的代碼藏身於一個龐大的系統中時，找出它是很是困難的。避免這種狀況出現的方法是儘早開始核心業務代碼的性能測試，重點集中在對算法和實現方法的優化上。

另外，及早開始的測試也能夠幫你更容易找到內存泄漏的問題。

 

測試階段

產品終於交到咱們手上了，搭建測試環境，設計測試場景，執行測試，找到系統的最佳併發用戶數和最大併發用戶數，將系統進行分類，評判系統的性能表現是否知足需求中定義的目標——若是有需求的話 ^_^

若是發現系統的性能表現與預期目標相去甚遠，則須要根據執行測試過程當中收集到的數據來分析和識別性能瓶頸，優化系統性能。

在這個階段還有不少值得咱們深刻思考和討論的東西，在本系列後續的文章中，咱們將會更多的關注這一部分的內容。

 

維護階段

維護階段一般遇到的問題是須要在實驗室中模擬客戶環境，重如今客戶那裏發現的缺陷並修復缺陷。相比功能缺陷，性能缺陷與某一具體環境和場景的關聯更加密切，因此在測試前須要檢查生產環境中各服務器的資源利用率、系統訪問日誌、應用服務器的日誌、數據庫的日誌。若是客戶使用了專門的系統來監測各個服務器的軟硬件資源使用狀況的話，檢查該系統是否記錄下了軟硬件資源的異常或者警告。

 

與性能測試相關的其餘測試

可靠性測試（Reliability Testing）    對於一個運營商級的系統來講，可以保證提供7×24的連續穩定的服務是很是重要的。固然，你能夠經過一些「高可用性（High Availability）」技術方案來加強系統的可靠性，可是對於系統自己的可靠性測試是不能被忽略的。

經常使用的測試方法是使用必定的負載長時間向服務器加壓，並觀察隨着加壓時間的延長，響應時間、吞吐量以及資源利用率的變化。要注意的是，所使用的負載應當是系統的最佳並併發用戶數，而不是最大併發用戶數。

可伸縮性測試（Scalability Testing） 對於一個系統來講，在一個給定的環境下，它的最佳併發用戶數和最大併發用戶數是客觀存在的，可是系統所面臨的壓力卻有可能隨上線時間的延長而增大。例如，一個在線購物站點，註冊用戶數量不斷增多，訪問站點查詢商品信息和購買商品的人也不斷的增多，咱們應該用一種什麼樣的方案，在不影響系統繼續爲用戶提供服務的前提下來實現系統的擴容？

一種經常使用的方案是使用負載均衡（Load Balance）和集羣（Cluster）技術。可是在咱們爲客戶提供這種方案以前，須要先本身進行測試，保證該技術的有效性——咱們是否真的能夠經過簡單的增長服務器數據和修改某些參數配置，就可以使得系統的容量獲得線性的增加？

可恢復性測試（Recoverability Testing）      雖然咱們已經能夠準確的估算出系統上線後將要面對的壓力，而且能夠保證系統的最佳併發用戶數和最大併發用戶數是足以應對這些壓力的，可是這個世界上老是有些事情上咱們所沒法預料到的——例如9.11事件發生後，AOL的網站訪問量在短期內增加到了平時的數十倍。

咱們沒法保證系統能夠在任何狀況下都能爲用戶正確無誤的提供服務，可是咱們須要確保當意外過去後，系統能夠恢復到正常的狀態，並繼續後來的用戶提供服務——就像從未發生過任何事情同樣。

若是要實現「可恢復性測試」，咱們能夠藉助於測試工具或腳原本逐漸的增大併發用戶數，直至併發用戶數已經超過了系統所能承受的最大併發用戶數，並致使軟硬件資源利用率飽和，響應時間無限延長，大量的請求由於超過響應時間要求或沒法得到響應而失敗；以後，咱們逐漸的減小併發用戶數，並觀察資源利用率、響應時間、吞吐量以及交易成功率的變化是否與預期目標一致。

 

固然，這一切的前提是在系統負載達到峯值前，Server一直在頑強的掙扎着而沒有down掉 ^_^

 

 

性能測試，並不是網絡應用專屬

軟件的性能和性能測試都是伴隨着網絡應用的興起而逐漸被重視起來的，可是軟件性能和性能測試卻並不是網絡應用的專屬名詞，由於單機版的應用一樣須要考慮性能問題。下面舉幾個簡單的例子來方便你們的理解：

1.               當使用Word來編輯一個500多頁，幷包含了豐富圖表、圖片和各類格式、樣式信息的文檔時，是否每次對大段的文字或表格的修改、刪除或從新排版，都要等待系統花幾秒鐘的時間進行處理？

2.              當在Excel中使用嵌套的統計和數學函數對幾萬行記錄進行統計分析時，是否每次都要兩三分鐘才能看到結果？

3.              殺毒軟件是否每次都要花費兩個小時才能完成一次對全部的分區的掃描？

4.              是否每次在手機的通信簿中根據姓名搜索某我的的聯繫方式都要三四秒鐘纔有響應？

若是你們有興趣，也能夠經過Google搜索到更多的有關單機應用性能測試的資料。