軟體效能測試的幾個階段

　　對於網際網路應用軟體，效能是其質量的一個非常重要的組成部分。作為解決軟體效能問題的重要手段，軟體效能測試已經廣為人們所熟悉，並受到很高的關注。一般而言，效能測試都是在專案的後期才開展，被測試的物件通常是已經具備一定穩定性的產品。而實際上，效能測試應貫穿於整個軟體生命週期中，和功能測試一樣，效能測試也分為幾個階段。

　　軟體生命週期與效能測試

　　不論哪種 模型，需求分析、設計、編碼、測試和執行維護這幾個階段都是其中的基本要素，只是在不同的軟體生命週期模型中可能迭代、合併、拆分或重組這幾個階段，在此不做過多的描述。與其他幾個階段相對應，測試從軟體開發過程按階段可以劃分為：單元測試、整合測試、系統測試，在其他的書上可能還能見到諸如確認測試、驗收測試等名詞，但是前3種測試確實是最基本的測試活動，而其他的測試活動只是在某些軟體開發過程中會發生。

　　值得注意的是，通常在談論單元測試、整合測試和系統測試時，其實僅僅談論的是不同階段的功能測試;而當討論效能測試時，絕大多數的情況是，一個已經開發完畢或基本開發完畢的軟體，測試人員用一種或幾種效能測試工具，以儘量模擬真實使用者行為的方式對該軟體進行併發操作，收集並比較不同場景的結果，然後對軟體的效能進行分析，這個活動通常發生在系統測試階段，甚至更往後的階段，如執行維護階段。

　　一直以來，效能測試跟單元測試、整合測試似乎都是絕緣的。可是它們真的應該是絕緣的嗎?沒有任何理由可以說明效能測試跟單元測試、整合測試無關，除非你認為“這太難了，我不會做”(這正好是本章主要想說的)或者“做這個沒什麼意義，浪費時間”(那麼請接著往下看)。

　　眾所周知，把測試劃分為單元測試、整合測試和系統測試，而不僅僅是在最後關頭做一個系統測試，其主要原因有兩點：

　　1.同樣的缺陷在不同階段被發現，其修復成本差異極大，而越早發現缺陷，修復成本越小;

　　2.某些缺陷幾乎只能在某個階段被發現，即在其他階段需要投入巨大的人力才能發現這些缺陷或根本不可能發現這些缺陷。

　　簡而言之，對於不同階段的測試活動，總有一些缺陷是最適合被發現和修復的。對於功能性缺陷這點早已達成共識，而對於效能性缺陷，由於效能測試本身起步較晚、效能問題比較難以暴露、早期使用者對效能問題容忍度比較高、商業效能測試工具價格昂貴等原因，很多時候可能根本不會進行效能測試，或僅進行比較簡單的效能測試，因此雖然效能性缺陷同樣有這個特性，但卻被人們遺忘了。簡單地列舉幾個在不同階段進行效能測試的好處。

　　1.在單元效能測試中執行一遍後就能發現的記憶體洩漏問題，如果這個問題遺留到系統測試階段，可能需要花費幾天的時間才能找到問題的所在，尤其是當Dump 記憶體資訊後發現大量物件是到處都在使用的基本物件時，欲哭無淚可能是效能最佳化人員此時的真實寫照，這點筆者曾有幸體驗過;而實際上執行一遍單元測試的時間可能也就幾分鐘，此時發現問題極易解決。

　　2.異構系統之間的介面，通常是先完成介面，而呼叫介面的系統可能過很久才會完成。當然，可以等完成呼叫介面的系統後直接對該系統進行測試，介面的效能自然被測試到了，但是萬一很不幸——效能測試結果不佳，再花費一番力氣後終於確定是介面效能不佳，那可能就得大費周折地重新寫介面了。更倒黴的是別的系統已經在用新的介面了，而不巧的是新老介面又不相容(比如差一個引數什麼的)，那代價可就大了;如果進行過介面效能測試，問題早就發現並解決了，這時候真是想想都會笑了。

　　3.越早開始效能調優，調優工作就會越容易。當元件小規模的整合後即可執行並調優時，由於系統複雜度低，自然而然地效能調優的難度會比較低。很顯然，效能調優是以效能測試為基礎的，那麼較早階段的效能測試就很有必要了。

　　4.在執行維護階段，系統已經在穩定地為使用者提供服務了，這時候還需要進行效能測試嗎?需要。因為生產系統可能會表現出疑似效能問題的症狀，這時候效能測試是查詢問題的有效手段，有助於為使用者提供更好的服務;效能再好的系統也會有極限，當使用者數不斷增長的時候，透過效能測試來評估系統的容量，以確定系統應如何進行擴容或者需要更換新的架構，通常這稱之為容量評估。

　　很明顯，效能測試和功能測試一樣貫穿於多個階段。基本上，各階段的 包括以下幾種：單元效能測試、整合效能測試、系統效能測試、多系統效能測試、容量評估、介面效能測試。接下來看看這些不同階段的效能測試活動到底做些什麼。