這是pareto原則應用于軟件測試，也包括性能測試，即性能測試發現的錯誤中的80%很可能集中在20%的程序模塊中。
(3)窮舉測試是不可能的
在性能測試中不可能覆蓋每一個功能部分，這也意味著有性能問題的模塊可能被忽略掉，這樣的話，我們在設計性能測試案例時，應該采取一些策略和技巧，使用盡可能少的性能測試用例，發現盡可能多的bug。這方面內容我們將在本書的第10章中介紹。
在具有軟件測試共性的同時，性能測試也有自身的一些特點。
1.性能測試不是功能測試
性能測試不要求也無法做到覆蓋軟件所有的功能，通常我們只是對系統中某些功能或模塊做性能測試。一般的，我們在選擇性能測試案例時需要遵循以下的原則：
(1)基本且常用的
比如，一個E-mail系統，基本且常用的功能有注冊、登錄、收郵件、查詢郵件，用戶使用這些功能的頻率較高，要做性能測試。而高級查詢、過濾器、郵件列表等功能被使用的次數較少，就可以不做性能測試，或者進行性能測試的優先級低一些。
(2)對響應時間要求苛刻的
這樣的要求經常出現在金融和電信等對實時性要求比較高的系統中。比如，從手機呼叫開始，經過基站、核心網，再到被叫手機響鈴，整個系統的處理時間應該在用戶能接受的范圍內。另外，一個負責和手機通信的基站在發生故障或掉電后，要能很快地恢復工作狀態。這些功能都對時間有著嚴格的要求，一定要做性能測試，當然實際運作時，電信系統上線時所做的性能測試不僅僅限于這些功能。
將這些功能細分就是性能測試中的事務(Transaction)。關于事務這個概念我們在后面的章節中將詳細闡述。
2.性能測試屬于系統級測試
從V型圖可以看到，性能測試屬于系統級測試。那么性能測試是基于單元測試、集成測試、功能測試等都已經完成的基礎上，站在用戶的角度去測試整個系統的。這包含兩個含義：
第一，性能測試是“兩頭在外”，軟件性能需求不僅直接來自用戶，最終目的也是服務于用戶。通過性能測試這個過程，從上面我們講到用戶的需求和性能測試指標的對應關系，就可以看出。
第二，性能測試開始的必要條件是軟件系統已經處于一個比較穩定的狀態，系統架構、主要代碼、中間件等都不再有大的變化，否則會給性能測試帶來很大的風險。
思考
基于以上事實，我們應該在軟件流程什么階段開始性能測試?結合自己的實際工作進行分析。
1.2.2 性能測試策略揭秘
文章來源于領測軟件測試網 http://www.k11sc111.com/
