1.2.1 性能測試在軟件測試的周期位置
首先，軟件性能測試屬于軟件測試范疇，存在于軟件測試的生命周期中。一個軟件的生產過程通常遵循V型圖，如圖1-3所示。
圖1-3 軟件開發-測試V型圖
在通常的軟件生產周期中，先由用戶提出用戶需求或經系統分析核定以后提出系統需求，開發人員再經過需求分析提出軟件需求規格說明，進行概要設計，提出概要設計說明，進行詳細設計，提出詳細設計說明，最后就是對每個模塊進行編碼。到測試階段，測試按照開發過程逐階段進行驗證并分步實施，體現了從局部到整體、從低層到高層逐層驗證系統的思想。對應軟件開發過程，軟件測試步驟分為代碼審查、單元測試、集成測試、系統測試。
而性能測試就屬于軟件系統級測試，其最終目的是驗證用戶的性能需求是否達到，在這個目標下，性能測試還常常用來做：
(1)識別系統瓶頸和產生瓶頸的原因;
(2)最優化和調整平臺的配置(包括硬件和軟件)來達到最高的性能;
(3)判斷一個新的模塊是否對整個系統的性能有影響。
系統瓶頸：
瓶頸本來是指玻璃瓶中直徑較小并影響流水速度的一段，用它來比喻軟件系統中出現性能問題的節點是很形象的，比如一個典型的分布式系統架構如圖1-4所示。
圖1-4 軟件系統壓力流動圖
如果把軟件系統看做是交通系統，那么網絡就是一條條大道，客戶端、防火墻、負載均衡器、Web服務器、應用服務器(中間件)、數據庫等各個系統節點就是交通要塞，客戶的請求和數據就像在道路上行駛的車輛，如果在某處發生堵車，那么整個交通系統都會不暢。在這個時候，我們就要分析是哪里出了問題，是道路不夠寬，還是某處立交橋設計不合理而引起堵塞等。找到問題的關鍵點，那么此關鍵點就是本系統的瓶頸。軟件系統也是如此，我們做性能測試的大部分工作都是為了尋找這個瓶頸到底在何處。
需要注意的是，軟件的性能瓶頸可能不止一處。
作為軟件測試的一種，軟件測試的規則同樣適用于性能測試中：
(1)確定預期輸出是測試必不可少的一部分
如果事先無法肯定預期的測試結果，往往會把看起來似是而非的東西當作正確結果。必須提倡用事先精確對應的輸入和輸出結果來詳細檢查所有的輸出。對于性能測試來說，預期輸出就是用戶的性能需求，一份明確的性能需求是成功性能測試的先決條件。
(2)必須徹底檢查每一個測試結果
事實上，在最終發現的錯誤，有相當一部分在前面的測試中已經暴露出來了，然而由于人們未能細心檢查先前的測試結果而遺漏了。
一段程序中存在的錯誤概率與在這段程序中發現的錯誤數呈正比。
這是pareto原則應用于軟件測試，也包括性能測試，即性能測試發現的錯誤中的80%很可能集中在20%的程序模塊中。
(3)窮舉測試是不可能的
在性能測試中不可能覆蓋每一個功能部分，這也意味著有性能問題的模塊可能被忽略掉，這樣的話，我們在設計性能測試案例時，應該采取一些策略和技巧，使用盡可能少的性能測試用例，發現盡可能多的bug。這方面內容我們將在本書的第10章中介紹。
在具有軟件測試共性的同時，性能測試也有自身的一些特點。
1.性能測試不是功能測試
性能測試不要求也無法做到覆蓋軟件所有的功能，通常我們只是對系統中某些功能或模塊做性能測試。一般的，我們在選擇性能測試案例時需要遵循以下的原則：
(1)基本且常用的
比如，一個E-mail系統，基本且常用的功能有注冊、登錄、收郵件、查詢郵件，用戶使用這些功能的頻率較高，要做性能測試。而高級查詢、過濾器、郵件列表等功能被使用的次數較少，就可以不做性能測試，或者進行性能測試的優先級低一些。
(2)對響應時間要求苛刻的
這樣的要求經常出現在金融和電信等對實時性要求比較高的系統中。比如，從手機呼叫開始，經過基站、核心網，再到被叫手機響鈴，整個系統的處理時間應該在用戶能接受的范圍內。另外，一個負責和手機通信的基站在發生故障或掉電后，要能很快地恢復工作狀態。這些功能都對時間有著嚴格的要求，一定要做性能測試，當然實際運作時，電信系統上線時所做的性能測試不僅僅限于這些功能。
將這些功能細分就是性能測試中的事務(Transaction)。關于事務這個概念我們在后面的章節中將詳細闡述。
2.性能測試屬于系統級測試
從V型圖可以看到，性能測試屬于系統級測試。那么性能測試是基于單元測試、集成測試、功能測試等都已經完成的基礎上，站在用戶的角度去測試整個系統的。這包含兩個含義：
第一，性能測試是“兩頭在外”，軟件性能需求不僅直接來自用戶，最終目的也是服務于用戶。通過性能測試這個過程，從上面我們講到用戶的需求和性能測試指標的對應關系，就可以看出。
第二，性能測試開始的必要條件是軟件系統已經處于一個比較穩定的狀態，系統架構、主要代碼、中間件等都不再有大的變化，否則會給性能測試帶來很大的風險。
思考
基于以上事實，我們應該在軟件流程什么階段開始性能測試?結合自己的實際工作進行分析。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
