性能測試
性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。
中國軟件評測中心將性能測試概括為三個方面：應用在客戶端上性能的測試、應用在網絡上性能的測試和應用在服務器端上性能的測試。通常情況下，三方面有效、合理的結合，可以達到對系統性能全面的分析和瓶頸的預測。
定義
狹義的性能測試主要用於描述常規的性能測試，是指通過模擬生產運行的業務壓力或用戶使用場景來測試系統的性能是否滿足生產性能的要求。
廣義的性能測試則是壓力測試、負載測試、強度測試、並發（用戶）測試、大數據量測試、配置測試、可靠性測試等和性能相關的測試統稱。
基本策略
測試的基本策略是自動負載測試，通過在一台或幾台PC機上模擬成百或上千的虛擬用戶同時執行業務的情景，對應用程序進行測試，同時記錄下每一事務處理的時間、中間件服務器峰值數據、數據庫狀態等。通過可重復的、真實的測試能夠徹底地度量應用的可擴展性和性能，確定問題所在以及優化系統性能。預先知道了系統的承受力，就為最終用戶規划整個運行環境的配置提供了有力的依據。
目的
目的是驗證軟件系統是否能夠達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，以優化軟件，最后起到優化系統的目的。
包括以下幾個方面：
1．評估系統的能力，測試中得到的負荷和響應時間數據可以被用於驗證所計划的模型的能力，並幫助作出決策。
2．識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，並突破它，從而修復體系的瓶頸或薄弱的地方。
3．系統調優：重復運行測試，驗證調整系統的活動得到了預期的結果，從而改進性能。
4. 檢測軟件中的問題：長時間的測試執行可導致程序發生由於內存泄露引起的失敗，揭示程序中的隱含的問題或沖突。
5．驗證穩定性（resilience）、可靠性（reliability）：在一個生產負荷下執行測試一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法。
類型
性能測試類型包括：負載測試、壓力測試、並發測試、配置測試、基准測試、驗收測試、可靠性測試、失效恢復測試、容量測試，穩定性測試等。
一般企業會按照這個步驟去執行測試：先負載測試（逐步增加並發用戶數來增加壓力，只能找出性能指標的瓶頸范圍，而不是具體的性能指標值），再性能測試（驗證我們的性能指標的具體的值，即精確），最后壓力測試。
平時我們說的基准測試其實是在性能測試里的找出。
壓力測試：在一定的壓力下，運行比較長的時間。目的是看服務器的穩定性。
企業口語說的“壓測”表達的是：要做負載測試和性能測試。
負載測試（Load Testing）
定義
負載測試是一種主要為了測試軟件系統是否達到需求文檔設計的目標，譬如軟件在一定時期內，最大支持多少並發用戶數，軟件請求出錯率等，測試的主要是軟件系統的性能。
負載測試是不斷增加系統的負載，直到負載達到閾值——評估系統在預期工作負載下的性能的測試。這里增加負載的意思是在測試中增加並發用戶數量、用戶交互等，通常是在可控的環境下進行。典型的負載測試包括在負載測試過程中確定響應時間，吞吐量，誤碼率等。該方法可以找到系統的性能極限，可以為性能調優提供相關數據。該類方法通常要基於或模擬系統真實運行環境，且選取的業務場景也要盡可能地與實際情況相符。
狹義的定義：是指對系統不斷地增加壓力或增加一定壓力下的持續時間，直到系統的某項或多項性能指標達到安全臨界值，例如某種資源已經達到飽和狀態等。運用場景：此類型的測試目前運用得比較少。一般情況下，是以服務器資源安全臨界值為界限的測試。如果要模擬某個應用在指定服務器上最大且安全的負載量，則屬於負載測試。
目標
確定並確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征。例如，響應時間、事務處理速率和其他與時間相關的方面。
負載測試的目標是測試在一定負載情況下系統性能（不關注穩定性，也就是說不關注長時間運行，只是得到不同負載下相關性能指標即可）；實際中我們常從比較小的負載開始，逐漸增加模擬用戶的數量（增加負載）， 觀察不同負載下應用程序響應時間、所耗資源，直到超時或關鍵資源耗盡，這就是所說的負載測試，它是測試系統的不同負載情況下的性能指標。
目的
負載測試是為了發現系統的性能問題，負載測試需要通過系統性能特性或行為來發現問題，從而為性能改進提供幫助，從這個意義看，負載測試可以看作性能測試的一部分。但它們兩者的目的是不一樣的，負載測試是為了發現缺陷，而性能測試是為了獲取性能指標。因為性能測試過程中，也可以不調整負載，而是在同樣負載情況下改變系統的結構、改變算法、改變硬件配置等等來得到性能指標數據，從這個意義看，負載測試可以看作是性能測試所用的一種技術，即性能測試使用負載測試的技術、使用負載測試的工具。性能測試要獲得在不同的負載情況下的性能指標數據。
通過負載測試和壓力測試都可以獲得系統正常工作時的極限負載或最大容量。容量測試，自然也是采用負載測試技術來實現，而在破壞性的壓力測試中，容量的確可以看作是一種副產品——間接結果。
負載測試的必要准備
1.什么是你真正需要了解的？
2.確定用戶數量
3.研究你的分析
4.組建你的團隊
5.准備你的瀏覽器
6.准備測試你的應用
7.預留時間分析結果
8.預留時間修改
9.計划一個敏捷測試方法
壓力測試（Stress Testing）
定義
壓力測試是在強負載（大數據量、大量並發用戶等）下的測試，查看應用系統在峰值使用情況下操作行為，從而有效地發現系統的某項功能隱患、系統是否具有良好的容錯能力和可恢復能力。壓力測試分為高負載下的長時間（如24小時以上）的穩定性壓力測試和極限負載情況下導致系統崩潰的破壞性壓力測試。
壓力測試可以被看作是負載測試的一種，即高負載下的負載測試，或者說壓力測試采用負載測試技術。通過壓力測試，可以更快地發現內存泄漏問題，還可以更快地發現影響系統穩定性的問題。例如，在正常負載情況下，某些功能不能正常使用或系統出錯的概率比較低，可能一個月只出現一次，但在高負載（壓力測試）下，可能一天就出現，從而發現有缺陷的功能或其它系統問題。通過負載測試，可以證明這一點，某個電子商務網站的訂單提交功能，在10個並發用戶時錯誤率是零，在50個並發用戶時錯誤率是1%，而在200個並發用戶時錯誤率是20%。
狹義的定義：壓力測試是指超過安全負載的情況下，對系統不斷施加壓力，是通過確定一個系統的瓶頸或不能接收用戶請求的性能點，來獲得系統能提供的最大服務級別的測試。運用場景：此類型的測試目前運用得比較少。但對於大型的共享中心或者核心的應用也會用到。
目標
壓力測試的目標是測試在一定的負載下系統長時間運行的穩定性，尤其關注大業務量情況下長時間運行系統性能的變化（例如是否反應變慢、是否會內存泄漏導致系統逐漸崩潰、是否能恢復）；壓力測試是測試系統的限制和故障恢復能力，它包括兩種情況：
穩定性壓力測試：在選定的壓力值下，長時間持續運行。通過這類壓力測試，可以考察各項性能指標是否在指定范圍內，有無內存泄漏、有無功能性故障等；
破壞性壓力測試：在穩定性壓力測試中可能會出現一些問題，如系統性能明顯降低，但很難暴露出其真實的原因。通過破壞性不斷加壓的手段，往往能快速造成系統的崩潰或讓問題明顯的暴露出來。
目的
壓力測試主要是為了發現在一（任意）定條件下軟件系統的性能的變化情況，通過改變應用程序的輸入以對應用程序施加越來越大的負載（並發，循環操作，多用戶） 並測量在這些不同的輸入時性能的改變，也就是通常說的概念：壓力測試考察當前軟硬件環境下系統所能承受的最大負荷並幫助找出系統瓶頸所在。其實這種測試也 可以稱為負載測試，但是負載測試通常描述一種特定類型的壓力測試——增加用戶數量以對應用程序進行壓力測試。比如實際中我們說從比較小的負載開始，逐漸增加模擬用戶的數量， 直到應用程序響應時間超時，就是說的負載測試。
壓力測試主要是為了測試硬件系統是否達到需求文檔設計的性能目標，譬如在一定時期內，系統的cpu利用率，內存使用率，磁盤I/O吞吐率，網絡吞吐量等，壓力測試和負載測試最大的差別在於測試目的不同。壓力測試是指當硬件資源如cpu、內存、磁盤空間等不充足時對軟件穩定性的檢查。壓力測試屬於負面測試（Negative testing），使大量並發用戶/進程加載軟件以使系統硬件資源不能應付，這個測試也被稱為是疲勞測試（Fatigue testing），通過超出其能力的測試來捕獲應用程序的穩定性。壓力測試的主要思想是確定系統故障，關注系統如何優雅地恢復正常，這種質量被稱為是可恢復性。
負面測試(Negative testing)是相對於正面測試(Positive testing)而言的。正面測試就是測試系統是否完成了它應該完成的功能；而負面測試就是測試系統是否不執行它不應該完成的操作。
配置測試
同功能測試一樣，如果需求規格說明中有明確的性能需求，例如完成復雜運算處理的解算時間要求，解算精度要求，網絡傳輸吞吐量，數據庫的最大容量，服務器能允許的同時在線訪問數量等等，都要反映在配置項測試里。如果沒有明確指出性能要求，測試人員可根據軟件產品所處行業，自行產生測試需求。——這很考驗測試人員的素質和水平的哦。例如前面所提到的，服務器能允許的最大同時在線訪問量，就是互聯網行業的一個性能需求。當然，還有常規的空間性能（存儲和占用計算機硬件資源）和時間性能（軟件處理一個任務所用時間），如今的計算機資源，基本都滿足要求，除非你是航空發射，武器控制等特殊行業，才需要非常關注
配置測試主要指通過測試找到系統各項資源的最優分配原則。配置測試是系統調優的重要依據。例如，可以通過不停地調整 Oracle 的內存參數來進行測試，使之達到一個較好的性能。可以看出，配置測試本質上是前面提到的某些種類的性能測試組合在一起而進行的測試。
並發測試
定義
所謂並發，它的特點是“並行”和“同時”。在loadrunner中就得使用集合點的功能來實現。
測試多個用戶同時訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其他性能問題，幾乎所有的性能測試都會涉及一些並發測試。通常的測試方法是設置集合點。
目的
測試目的並非為了獲得性能指標，而是為了發現並發引起的問題。
並發概念的淺談
想確定用戶並發數；必須知道系統所承載的在線用戶數；
對於並發，我過去接觸了幾種理解，在接觸的第一種理解中，“並發”是由loadrunner中獲取，即腳本中所有或部分vuser執行至集合點函數時進行停留，等待觸發條件發生以后，同時執行集合點函數后的請求操作的這一個過程，為“並發”（這一個請求操作一般存在多個http請求），可惜這種“並發”是無法直接用於衡量系統性能的。
LoadRuner的並發很好理解，就是虛擬用戶數。因為LR有個集合點，可以在所有虛擬用戶初始化且到達集合點后，再一起執行后續操作，從而達到同時且並行的效果。
而在接觸的第二種理解中，“並發”的理解是相對於服務器某一個時間區間內接收的請求數，也就是每秒的點擊率（loadrunner考慮到這點，也就是analysis里面的hits/s），為“並發”，這種“並發”是可以用於對系統性能狀況進行量化的，但是這種測試思想只是比較片面的從性能指標的角度去衡量系統性能，不能體現出系統性能帶給用戶何種性能體驗（這也是不少開源性能測試工具的問題）。
前一種“並發”的理解普遍獲得了loadrunner初級用戶的認可，后一種“並發”的理解普遍獲得系統運維、開發人員的認可，在溝通中為了方便區別開來，在兩種角色里面，當大家意識到並發的理解存在差異時，大家把前一種被稱為“狹義上的並發”，而后一種被稱為“廣義上的並發”。后來，又從淘寶團隊里面了解了一種定義，貌似淘寶QA把“並發”定義為一個完整的事務請求數量過程（loadrunner也考慮到這點，也就是analysis里面的Transactions per Second）。一直以來，還有一種技術范圍以外對“並發”的粗略的理解被第三方測試拿來用了，那就是用戶在線數中的某個百分比即並發數。
如果一個團隊里面對“並發”的理解有這么多種，那么當我們在討論性能需求的“支持並發數”時，我們究竟在討論什么呢？
個人認為，有一部分的原因是由於loadrunner是惠普saas（軟件即服務的解決方案）的一部分，所以並不是一個純粹技術人員使用的測試工具，它同時也是一個業務人員可以相對輕易掌握的性能測試工具，因此loadrunner內很多名詞解釋也不能單純從技術人員的角度從字面意義上理解。
通常來說，面對同樣100筆業務交易量，普遍會認為100vuser對服務器產生的負載會比50vuser要高，但是在性能腳本能夠在較快的響應時間中完成時，由於50vuser執行過程中每一個vuser都需要發生兩次迭代，導致了性能場景中vuser在腳本action部分停留的時間更長，因此反而能夠得到比100vuser的更高的vuser在線數，更高在線數帶來的也就是更大的負載，也就是說：
同等業務量的情況下，50線程所產生的負載完全有可能比100線程所產生的負載要高。
為了避免發生這種問題，“並發（集合點）”的真正作用就體現出來了，通過集合點函數控制了vuser的行為相對一致，降低了初始化過程和事務前后文請求產生的時間差影響。測試工具中並發存在的真正意義也就在這里，對集合點所理解的“並發”，和現場實際用戶里面同時觸發的請求關系不是太大。
分析“並發”需求時的一些典型：
a) 某個業務系統里面有10000用戶，但是能夠訪問這個系統的終端數只有1000個、或者所需測試的業務每個月上限是1000筆，那么最高在線用戶數就不可能超過1000、業務量也不可能超過1000。所以，有些時候在分析性能需求的時候，去統計一個業務系統的用戶數還不如去統計能夠訪問這個系統的終端數、甚至業務量靠譜。
b) 某個業務系統里面，各個業務模塊都不一樣，那么就是說完成一筆業務交易，所產生的請求數也是不一樣的，例如表單新增，有的需要填寫20個字段，有的只需要填寫5個字段，各個表單都不一樣，那么為了更接近的去模擬用戶現場負載，請求數都不一樣的各種業務混在一起，並發數又應該是多少呢？
為了解決這些問題，需要首先考慮“並發”的粒度，以真實的業務場景為例：
a) 把粒度控制在用戶上來看，假定所有用戶訪問一次系統平均耗時500秒，一個業務峰值會有800用戶在線，則800/500=1.6。理論上，系統的性能需求是每秒要成功處理1.6個用戶的請求；
b) 把粒度控制在事務上來看，假定所有用戶執行一次完整的、成功的業務操作平均需要500秒，一個業務峰值有2000筆所關注的業務需要去執行，則2000/500=4。理論上，系統的性能需求是每秒要成功處理4筆業務交易；
c) 把粒度控制在請求上來看，假定所有用戶執行一次完整的、不管成功或者失敗的HTTP請求操作平均需要0.08秒，一個業務峰值有28000個請求需要去完成，則28000/0.08=350000。理論上，系統的性能需求是每秒要成功處理350000個請求。
分類
1、獨立業務性能測試：核心業務模塊的某一業務並發性能測試；
2、組合業務性能測試：一個或多個模塊的多個業務同時進行並發測試。
獨立業務性能測試
1、完全一樣功能的並發測試：檢查程序對同一時刻並發操作的處理，例如模擬多個用戶在同一時刻向數據庫寫入相同數據，或者多個用戶在同一時刻發出請求測試系統能否正確響應。
2、完全一樣操作的並發測試：在同一時刻完成完全一樣的操作，即從宏觀上看操作對系統的影響是一致的，例如同時單擊保存按鈕。這類測試目的在於驗證大量用戶使用同一功能時系統能否正常工作。
3、相同/不同的子功能並發測試：同一模塊大多數功能相互耦合，針對一些子功能較多的模塊做組合測試。組合的依據就是用戶使用的場景，每個不同的子功能都模擬一定的用戶數量進行並發測試。
組合業務性能測試
1、不同核心業務模塊的用戶進行並發，模塊之間具有一定耦合：這種測試比較接近用戶使用情況，測試的對象是多個模塊組，每個組相關的模塊之間具有一定耦合關系。組與組之間的關系相對獨立。例如實際中各類型的用戶都會對應一組模塊，相當於不同的業務組並發的訪問系統。
2、具有耦合關系的核心模塊組進行並發，每組模塊內部存在耦合關系：主要測試多用戶並發條件下一些存在耦合或者數據接口的模塊是否正常運行，可以參考集成測試用例和概要設計文檔，分析出一些核心模塊的接口。
3、基於用戶場景的並發測試：選擇用戶的一些經典場景做測試，測試對象可以是核心模塊，也可以是非核心模塊。這種測試更接近用戶使用的實際情況，測試需要充分考慮實際場景。設計組合模塊用戶並發性測試用例一般用不同“子功能”或者“子事務”為單位，來進行各種模塊的不同核心功能組合。
並發用戶數量設計方法
容量測試（Volume Testing）
定義
所謂容量，即系統處於最大負載狀態或某項指標達到所能接受的最大閾值下對請求的最大處理能力。
容量測試是一種非功能的測試，它通過向應用程序中添加大量的數據來實現檢查被測系統處理大數據量的能力。
可以通過向數據庫插入大量的數據或讓應用程序處理一個大型文件來進行測試應用程序。通過容量測試，可以識別應用程序中具有大數據時的瓶頸，檢查應用程序的效率，進而得到不同數據量級下應用程序的性能。確定系統最大承受量，譬如系統最大用戶數，最大存儲量，最多處理的數據流量等。
舉例：
在一個新開發的網絡游戲應用程序中，在進行容量測試時，可以通過向數據庫中插入數百萬行的數據，然后在這些數據的基礎上進行性能的測試。
注意，這里所說的數據一定是符合其功能場景的，不是毫無關系的數據。
目的
容量測試的目的是通過測試預先分析出反映軟件系統應用特征的某項指標的極限值（如最大並發用戶數、數據庫記錄數等），系統在其極限狀態下沒有出現任何軟件故障或還能保持主要功能正常運行。容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。軟件容量的測試能讓軟件開發商或用戶了解該軟件系統的承載能力或提供服務的能力，如某個電子商務網站所能承受的、同時進行交易或結算的在線用戶數。知道了系統的實際容量，如是不能滿足設計要求，就應該尋求新的技術解決方案，以提高系統的容量。有了對軟件負載的准確預測，不僅能對軟件系統在實際使用中的性能狀況充滿信心，同時也可以幫助用戶經濟地規划應用系統，優化系統的部署。
如何統計容量指標？
統計維度
一般來說，可以從如下兩個維度來定量系統的容量：
統計方法
一般來說，常用的采集數據的方法，有以下幾種方式：
①、埋點采集：即在系統的各個節點，根據需要添加埋點，針對性的進行數據采集；
②、日志/數據庫：通過日志服務（比如ELK）或者運維監控（現在很流行的Devops），采集分析數據；
③、Agent/探針：在需要采集的節點添加Agent/探針，實時采集，數據存入時序數據庫（比如influxdb），實時展示；
注意事項
①、采集對比的數據一定要采集線上的真實數據，這樣才能反映真實客觀的系統壓力。
②、容量測試環境的配置，一定要和線上保持一致（服務器數量可以不同，但配置盡可能保持一致）。
測試思路
①、根據具體的業務情況和系統架構，通過配置測試的手段，測量得到單個服務節點在對應的業務場景下最大的性能表現；
②、根據系統架構（集群、分布式、微服務）特點，通過啟用≥2的服務節點，來得到服務節點的增加和系統性能的提升比例；
③、通過線上采集的系統數據，分析出過去某段時間（或某個業務）的高峰流量，然后通過計算，得到容量擴容，需要投入的實際服務數量；
約束/停止條件
在測試過程中，只要限定的某項指標達到最大可接受閾值或某項資源達到最大使用狀態，即刻停止測試。
選擇合適的容量指標
考慮到業務需求和系統架構的不同，在選取容量指標時一般遵循如下原則：
①、數據密集型：即並發請求量較大的類型，一般TPS和RT是比較關注的指標；
②、數據存儲型：即需要存儲讀寫的數據量較大的類型，一般吞吐量和IO是比較關注的指標；
容量規划
為什么需要容量規划？
對於業務越來越復雜的商業形態，每個業務都由一系列不同的系統來提供服務，每個業務系統都部署在不同的機器上。容量規划的目的在於讓每一個業務系統能夠清晰地知道：
①、什么時候應該增加服務節點，什么時候應該減少服務節點（比如服務端接受到的流量達到什么量級）？（比如雙十一，大促，秒殺）
②、為了雙 11 、促銷、秒殺、渠道拓展引流等業務需求，需要擴充到什么數量級的服務，才能即保證系統的可用性、穩定性，又能節約成本？
容量規划四步走
①、業務流量預估階段：通過分析歷史數據以及實時的線上監控，預估未來某個時間點或者某個業務可能會有多少多少的流量沖擊；
②、系統容量評估階段：根據具體的業務場景，分析每個業務場景的流量配比，然后計算每個業務大概需要多少服務節點來提供可靠穩定的性能支撐；
③、系統容量測試階段：通過全鏈路壓測或者PAT/UAT環境的壓測，來模擬真實的業務場景，確定每個服務節點的具體性能表現，進行針對性的調整；
④、流量分配調整階段：根據壓測的結果，設定限流、服務降級等系統保護措施，來預防當實際流量超過系統所能承受的最大流量時，系統無法提供服務；
擴容手段
①、垂直擴容
升級服務的硬件配置，讓單個服務節點的容量更大，來提供更高的系統服務能力。比如：
加大服務機器的CPU數量和內存，更換性能更好的高速緩存服務器，數據存儲用NAS盤替換等。
②、水平擴展
即增加服務節點的數量，讓可提供服務的服務變得更多，來提升系統總體的服務能力。常見的方式有：
服務集群：服務器的數量由1→N（但需要重點關注負載均衡）；
分布式：提供服務的節點由統一集中管理部署，分散到不同的地點；
容器：提供更靈活的彈性擴容機制，根據具體的訪問流量大小來彈性擴容或者縮容；
容量測試的優點
以下是任何軟件應用程序的容量或洪水測試的優點。
- 它提供了運行軟件應用程序所需的硬件類型的清晰圖像，包括CPU、內存等。
- 可以很早地確定可擴展性計划。
- 它有助於節省可能用於應急計划的大量資金。
- 它有助於盡早發現應用程序操作中的瓶頸。
- 它確保了經過容量測試的應用程序已准備好投入實際使用。
- 它有助於讓應用程序上線或不上線。
容量測試的缺點
此類測試增加了項目的額外成本，因為它是由不同的性能測試團隊在功能測試的基礎上完成的。
為什么經常推薦容量測試？
由於以下原因，通常建議進行容量測試。
- 當到數據庫中的數據量增加時，它有助於檢查系統性能。
- 使用大量數據研究軟件應用程序行為。
- 評估應用程序穩定性開始降低的點。
- 它可以識別正常，低，中，高容量下的應用能力。
容量測試檢查
在容量或洪水測試期間評估和檢查以下參數。
- 容量測試旨在檢查是否有任何數據丟失。
- 進行容量測試以記錄不同容量條件下的響應時間並評估平均響應時間。
- 它旨在評估數據庫中的數據是否正確保存。
- 它旨在驗證數據是否被任何通知覆蓋。
- 它旨在檢查警告和錯誤消息，以及它們在不同容量級別的關聯。
- 它旨在檢查高數據量是否會以任何方式影響被測系統中處理請求的速度。
容量測試最佳實踐
以下是最佳容量測試結果廣泛遵循的最佳實踐。
- 在檢查所有日志 (即服務器和應用程序的日志) 時, 不要忘記停止所有服務器。
- 在開始容量測試之前，確保正面（正常）場景正常工作。
- 為了從容量測試中獲得最佳結果，始終建議錯開用戶數量。
- 平衡你的容量試時間以克服許可限制。
- 引入的任何新版本都應該非常謹慎地處理。
- 建立基線后，應分析用例以提高性能。
- 在出現性能瓶頸的情況下，應該反復重復進行容量測試，以深入研究性能問題。
可靠性測試
定義
軟件可靠性測試是指為了保證和驗證軟件的可靠性要求而對軟件進行的測試。其采用的是按照軟件運行剖面(對軟件實際使用情況的統計規律的描述)對軟件進行隨機測試的測試方法。
軟件可靠性是軟件系統在規定的時間內以及規定的環境條件下，完成規定功能的能力。一般情況下，只能通過對軟件系統進行測試來度量其可靠性。
對軟件可靠性進行定量的評估或驗證，為了達到和驗證軟件的可靠性定量要求而對軟件進行的測試。
軟件可靠性測試通常是在系統測試、驗收、交付階段進行，它主要是在實驗室內仿真環境下進行，也可以根據需要和可能在用戶現場進行。
在給系統加載一定業務壓力的情況下，使系統運行一段時間，以此檢測系統是否穩定。例如，可以施加讓 CPU 資源保持 70%～90%使用率的壓力，連續對系統加壓 8 個小時，然后根據結果分析系統是否穩定。這么多類型的性能測試看起來很嚇人，實際上它們大多是密切相關的。例如，運行 8 個小時來測試系統是否可靠，而這個測試極有可能包含了可靠性測試、強度測試、並發（用戶）測試、負載測試，等等。
特點
測試的目的
(1)通過在有使用代表性的環境中執行軟件，以證實軟件需求是否正確實現。
(2)為進行軟件可靠性估計采集准確的數據，預測軟件在實際運行中的可靠性。
估計軟件可靠性一般可分為四個步驟，即數據采集、模型選擇、模型擬合以及軟件可靠性評估。可以認為，數據采集是整個軟件可靠性估計工作的基礎，數據的准確與否關系到軟件可靠性評估的准確度。
(3)通過軟件可靠性測試找出所有對軟件可靠性影響較大的錯誤。
(4)通過測試可以提高整個軟件系統的防錯、容錯和糾錯的能力。
通過軟件可靠性測試可以達到以下目的：
(1) 有效地發現程序中影響軟件可靠性的缺陷，從而實現可靠性增長：軟件可靠性是指“在規定的時間內，規定的條件下，軟件不引起系統失效的能力，其概率度量稱為軟件可靠度。”
軟件的“規定的條件”主要包括相對不變的條件和相對變化的條件，相對不變的條件如計算機及其操作系統;相對變化的條件是指輸入的分布，用軟件的運行剖面來描述。認為按照軟件的運行剖面對軟件進行測試一般先暴露在使用中發生概率高的缺陷，然后是發生概率低的缺陷。而高發生概率的缺陷是影響產品可靠性的主要缺陷，通過排除這些缺陷可以有效地實現軟件可靠性的增長。
(2) 驗證軟件可靠性滿足一定的要求：通過對軟件可靠性測試中觀測到的失效情況進行分析，可以驗證軟件可靠性的定量要求是否得到滿足。
(3) 估計、預計軟件可靠性水平
通過對軟件可靠性測試中觀測到的失效數據進行分析，可以評估當前軟件可靠性的水平，預測未來可能達到的水平，從而為開發管理提供決策依據。軟件可靠性測試中暴露的缺陷既可以是影響功能需求的缺陷也可以是影響性能需求的缺陷。軟件可靠性測試方法從概念上講是一種黑盒測試方法，因為它是面向需求、面向使用的測試，它不需要了解程序的結構以及如何實現等問題。
分析方法
目前主要的軟件可靠性分析方法有失效模式影響分析法、嚴酷性分析法、故障樹分析法、事件樹分析法、潛在線路分析法。
測試過程
包括五個步驟：確定可靠性目標，定義軟件運行剖面，設計測試用例，實施可靠性測試，分析測試結果。
失敗恢復性測試
對於有冗余備份和負載均衡的系統，通過這樣的測試來檢驗如果系統局部發生故障用戶是否能夠繼續使用系統，用戶收到多大的影響。
強度測試
強度測試是一種性能測試，它在系統資源特別低的情況下軟件系統運行情況，目的是找到系統在哪里失效以及如何失效的地方。
強度測試主要是為了檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。例如：
當正常的用戶點擊率為“1000 次/秒”時，運行點擊率為“2000 次/秒”的測試用例；
運行需要最大存儲空間（或其他資源）的測試用例；
運行可能導致操作系統崩潰或磁盤數據劇烈抖動的測試用例，等等。
強度測試是一種特別重要的測試，對測試系統的穩定性，以及系統未來的擴展空間均具有重要的意義。在這種異常條件下進行的測試，更容易發現系統是否穩定以及性能方面是否
容易擴展。
疲勞測試
疲勞測試是采用系統穩定運行情況下能夠支持的最大並發用戶數，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定系統處理最大工作量強度性能的過程。是一類特殊的強度測試，主要測試系統長時間運行后的性能表現，例如 7× 24 小時的壓力測試。
尖峰測試（Spike testing）
尖峰測試（Spike testing）其實可以算作是壓力測試（Stress Testing）的子集。
尖峰測試是在目標系統經受短時間內反復增加工作負載，以至超出預期生產操作的負載量時，分析系統的行為，驗證其性能特征。它還包括檢查應用程序是否可以從突然增加的超預期負荷中恢復出來的測試。
舉例：在電商應用程序中經常有“整點秒殺”的活動，所以在整點時間前后的兩三分鍾時間里，會有巨大數量的用戶進入到該活動中秒殺商品。尖峰測試就是為了分析這類場景。
持久測試（Endurance testing）
持久測試（Endurance testing），也被稱為是浸泡測試（Soak Testing），它也是一種非功能的測試。
持久測試是指在相當長的時間內使用預期的負載量對系統進行測試，以檢查系統的各種行為，如內存泄露、系統錯誤、隨機行為等。
這里的提到的相當長的時間是相對而言的，舉例來說，如果一個系統設計為運行3個小時的時間，那可以使用6個小時的時間來進行持久測試；如果設計為5個小時的時間，不妨用10個小時的時間來進行持久測試。對於現在的許多網絡類應用程序，通常情況下會持續運行好多天，那么進行持久測試時可以選擇更長的時間段。
穩定性測試
狹義的定義：穩定性測試是指被測試系統在特定硬件、軟件、網絡環境條件下，給系統加載一定業務壓力，使系統運行一段較長時間，以此檢測系統是否穩定，一般穩定性測試時間為 n*12 小時。
運用場景：此類型的測試目前也最常見，針對需要長時間穩定運行的性能點，需要執行穩定性測試。往往在一個項目的性能測試過程中，會划分出優先級較高的性能點，做穩定性測試。例如：寶貝詳情頁面等等。
如何實施
識別並確認軟件主要業務（是否需要穩定性測試）
將穩定性測試的重心放在軟件最有Value的地方，比如說一個搶票系統，它最有value的地方是當有一定數量的用戶同時進行買票操作是系統的響應時間，資源利用率等是否能夠正常且穩定，而不是用戶如何添加新的聯系人，修改個人信息等。
羅列主要用戶場景及響應負載量
用戶場景可以根據軟件主要業務進行設定
對主要場景負載量需要有一個清晰的定義（或者通過負載測試驗證了用戶場景的負載量，這將作為一個標准的負載在穩定性測試中使用）
制定穩定性指標模型（Modeling）
根據用戶場景建模，創建合適合理的穩定性指標模型（之后會有一個例子）
測試環境准備（對軟硬件環境的配置：配置的來源可以是客戶環境模擬、需求文檔規定的配置或者配置測試得出的最佳配置）
識別穩定性的主要性能指標（KPI）
用來描述穩定性測試關注的系統指標，比如響應時間、CPU、內存使用率等等，需要根據具體業務進行定義測試的執行和數據收集，
按照相應穩定性指標模型（Modeling)分析測試結果，將測試結果應用在穩定性測試模型中，觀察是否滿足穩定性要求
持續改進（如有必要）
大數據量測試
主要針對數據庫有特殊要求的系統進行的測試，如電信業務系統的手機短信業務；可以分為實時大數據量，主要目的是測試用戶較多或者某些業務產生較大數據量時，系統能否穩定運行；極限狀態下的測試，測試系統使用一段時間即系統累計一點量的數據時能否正常的運行業務；前面兩種的結合，測試系統已經累計了較大數據量時，一些實時產生較大數據量的模塊能否穩定工作；
如下大數量測試用例：
功能：數據庫中的短信息表可以保存所有不能及時發送的短信息，用戶上線后又能及時發送已經保存的信息；
大數據量測試可以分為兩種類型：針對某些系統存儲、傳輸、統計、查詢等業務進行大數據量的獨立數據量測試；與壓力性能測試、負載性能測試、疲勞性能測試相結合的綜合數據量測試方案。大數據量測試的關鍵是測試數據的准備，可以依靠工具准備測試數據。
速度測試
速度測試主要是針對關鍵有速度要求的業務進行手工測速度，可以在多次測試的基礎上求平均值，可以和工具測得的響應時間等指標做對比分析。
不同類型測試之間的區別
性能測試是為了獲得系統在某種特定的條件下（包括特定的負載條件下）的性能指標數據，而負載測試、壓力測試是為了發現軟件系統中所存在的問題，包括性能瓶頸、內存泄漏等。通過負載測試，也是為了獲得系統正常工作時所能承受的最大負載，這時負載測試就成為容量測試。通過壓力測試，可以知道在什么極限情況下系統會崩潰、系統是否具有自我恢復性等，但更多的是為了確定系統的穩定性。
壓力測試是測試系統什么情況下失效或者崩潰；負載測試是測試系統什么情況下超出需求指標；強度測試是測試系統在瞬時高負載、長時間負載情況下系統反應；容量測試是測試系統在大數據量交互的反應！
性能指標
性能測試最基本要考慮以下幾點
1、時間特性，主要指的是軟件產品的事務響應時間（用戶發出請求到收到應答的這段時間）
2、資源利用率，包括：cpu、內存、網絡、硬盤、虛擬內存（如Java虛擬機）
3、服務器可靠性，指服務器能在相對高負載情況下持續的運行
4、可配置優化性，指服務器配置優化、業務邏輯優化、代碼優化等
檢查系統是否滿足需求規格說明書中規定的性能，通常表現在以下幾個方面：
1、對資源利用（包括：cpu、內存、網絡、硬盤、虛擬內存（如Java虛擬機）等）進行的精確度量；
2、對執行間隔；
3、日志事件（如中斷，報錯）
4、響應時間
5、吞吐量（TPS）
6、輔助存儲區（例如緩沖區、工作區的大小等）
7、處理精度等進行的監測
TPS:服務器綜合能力指標值，服務器最主要的指標值。吞吐量有個單位是：平均事務數/秒
loadrunner和jmeter的TPS是有區別的，jmeter有兩種每秒事務數。jmeter除了每個業務的請求到響應完成的統計外，還有事務邏輯控制器對多個單個業務請求打包成一個全鏈路業務流的業務的請求到響應完成的統計等。
性能測試不是去找功能上的bug，是找出服務器的瓶頸。
在實際工作中我們經常會對兩種類型軟件進行測試：bs和cs，這兩方面的性能指標一般需要哪些內容呢？
bs結構程序一般會關注的通用指標如下（簡）：
Web服務器性能指標：
* Avg Rps: 平均每秒鍾響應次數=總請求時間 / 秒數；
* Avg time to last byte per terstion （mstes）：平均每秒業務腳本的迭代次數，有人會把這兩者混淆；
* Successful Rounds：成功的請求；
* Failed Rounds ：失敗的請求；
* Successful Hits ：成功的點擊次數；
* Failed Hits ：失敗的點擊次數；
* Hits Per Second ：每秒點擊次數；
* Successful Hits Per Second ：每秒成功的點擊次數；
* Failed Hits Per Second ：每秒失敗的點擊次數；
* Attempted Connections ：嘗試鏈接數；
CS結構程序，由於一般軟件后台通常為數據庫，所以我們更注重數據庫的測試指標：
* User 0 Connections ：用戶連接數，也就是數據庫的連接數量；
* Number of deadlocks：數據庫死鎖；
* Buffer Cache hit ：數據庫Cache的命中情況
當然，在實際中我們還會察看多用戶測試情況下的內存，CPU，系統資源調用情況。這些指標其實是引申出來性能測試中的一種：競爭測試。什么是競爭測試，軟件競爭使用各種資源（數據紀錄，內存等），看他與其他相關系統對資源的爭奪能力。
我們知道軟件架構在實際測試中制約着測試策略和工具的選擇。如何選擇性能測試策略是我們在實際工作中需要了解的。一般軟件可以按照系統架構分成幾種類型：
c/s
client/Server 客戶端/服務器架構
基於客戶端/服務器的三層架構
基於客戶端/服務器的分布式架構
b/s
基於瀏覽器/Web服務器的三層架構
基於中間件應用服務器的三層架構l
基於Web服務器和中間件的多層架構l
性能指標的兩個方面
外部指標|系統指標（與用戶場景和需求相關指標）
從外部看，性能測試主要關注如下四個指標
- 吞吐量：每秒鍾系統能夠處理客戶的請求數、任務數，其直接體現系統的承載的能力。
- 並發用戶數：同一時刻與服務器進行數據交互的所有用戶數量；
- 響應時間：服務處理一個請求或一個任務的耗時。
- 錯誤率：一批請求中結果出錯的請求所占比例。
響應時間
從單個請求來看就是服務響應一次請求的花費的時間。但是在性能測試中，單個請求的響應時間並沒有什么參考價值，通常考慮的是完成所有請求的平均響應時間及中位數時間。
平均響應時間很好理解，就是完成請求花費的總時間/完成的請求總數。但是平均響應時間有一點不靠譜，因為系統的運行並不是平穩平滑的，如果某幾個請求的時間超短或者超長就會導致平均數偏離很多。因此有時候我們會用中位數響應時間。
所謂中位數的意思就是把將一組數據按大小順序排列，處在最中間位置的一個數叫做這組數據的中位數 ，這意味着至少有50%的數據低於或高於這個中位數。當然，最為正確的統計做法是用百分比分布統計。也就是英文中的TP – Top Percentile ，TP50的意思在，50%的請求都小於某個值，TP90表示90%的請求小於某個時間。
響應時間的指標取決於具體的服務。如智能提示一類的服務，返回的數據有效周期短（用戶多輸入一個字母就需要重新請求），對實時性要求比較高，響應時間的上限一般在100ms以內。而導航一類的服務，由於返回結果的使用周期比較長（整個導航過程中），響應時間的上限一般在2-5s。
決定系統響應時間要素
我們做項目要排計划，可以多人同時並發做多項任務，也可以一個人或者多個人串行工作，始終會有一條關鍵路徑，這條路徑就是項目的工期。
系統一次調用的響應時間跟項目計划一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統響應時間；
關鍵路徑是由CPU運算、IO、外部系統響應等等組成。
計算公式
1、響應時間：對一個請求做出響應所需要的時間
網絡傳輸時間：N1+N2+N3+N4
應用服務器處理時間：A1+A3
數據庫服務器處理時間：A2
響應時間=網絡響應時間+應用程序響應時間=（N1+N2+N3+N4）+(A1+A2+A3)
注：絕對不允許用生產環境，公司如果有准生產環境最好。從生產的集群里抽取一個單機拿出來專門做性能測試的獨立服務器。但是其數據庫數據和服務都徹底從集群中移出來，這樣不影響生產環境正常業務發展。
獨立網絡：就是必須使用網線有線連接，千萬不要使用wifi，VPN，堡壘機（把兩個網絡連接起來的橋梁），最好是測試負載機和控制機在同一個網絡而且都是獨立的局域網里直接路由跳出去訪問外網的服務器。否則網速會嚴重影響數據的傳輸和加載，會出現數據包丟失嚴重的現象。最主要的是嚴重影響響應時間的指標值，偏差太大，沒有參考價值。
2、平均響應時間：所有請求花費的平均時間
系統處理事務的響應時間的平均值。事務的響應時間是從客戶端提交訪問請求到客戶端接收到服務器響應所消耗的時間。對於系統快速響應類頁面，一般響應時間為3秒左右。
如：如果有100個請求，其中 98 個耗時為 1ms，其他兩個為 100ms
平均響應時間： (98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms並不能反映服務器的整體效率，因為98個請求耗時才1ms，引申出百分位數
百分位數：以響應時間為例，指的是 99% 的請求響應時間，都處在這個值以下，更能體現整體效率。
注：（一般響應時間在3s內，用戶會感覺比較滿意。在3s~8s之間用戶勉強能接受，大於8s用戶就可能無法接受，從而刷新頁面或者離開，僅供參考）
響應時間與負載對應關系
圖中拐點說明：
（1）響應時間突然增加
（2）意味着系統的一種或多種資源利用達到的極限
（3）通常可以利用拐點來進行性能測試分析與定位
並發用戶數
一、首先涉及到並發用戶數可以從以下幾個方面去做數據判斷。
1.系統用戶數
2.在線用戶數
3.並發用戶數
二、三者之間的關系
1.在線用戶數的預估可以采取20%的系統用戶數。例如某個系統在系統用戶數有1000，則同時在線用戶數據有可能達到200，或者預估200做參考。
2.在線用戶數和並發用戶數又存在着關系。即：平均並發用戶數為:c=NL/T L為在線時長，T為考核時長。例如:考核時長為1天，即8小時，但是用戶平均在線時長為2小時，則c=n*2/8 n為登錄系統的用戶數，L為登錄的時常。例如:一個系統有400個用戶登錄，然后每個用戶登錄大概停留2小時，則以一天8小時考核，算平均並發用戶則為:c=400*2/8
並發主要是針對服務器而言，在同一時刻與服務器進行交互（指向服務器發出請求）的在線用戶數。
（1）並發用戶數：某一物理時刻同時向系統提交請求的用戶數，提交的請求可能是同一個場景或功能，也可以是不同場景或功能。
（2）在線用戶數：某段時間內訪問系統的用戶數，這些用戶並不一定同時向系統提交請求。如多個用戶在瀏覽網頁，但沒有對同時對服務器進行數據請求，需要與並發用戶數區分開。
（3）系統用戶數：系統注冊的總用戶數據
三者之間的關系：系統用戶數 >= 在線用戶數 >= 並發用戶數
同時在線用戶數：在一定的時間范圍內，最大的同時在線用戶數量。
同時在線用戶數=每秒請求數RPS（吞吐量）+並發連接數+平均用戶思考時間
平均並發用戶數的計算：C=nL / T
其中C是平均的並發用戶數，n是平均每天訪問用戶數（login session），L是一天內用戶從登錄到退出的平均時間（login session的平均時間），T是考察時間長度（一天內多長時間有用戶使用系統）
並發用戶數峰值計算：C^約等於C + 3*根號C 也是峰值C1,即最大並發數，計算公式C1=C+³√C
其中C^是並發用戶峰值，C是平均並發用戶數，該公式遵循泊松分布理論。
注：理解最佳並發用戶數和最大並發用戶數
看了《LoadRunner沒有告訴你的》之理發店模式，對最佳並發用戶數和最大的並發用戶數的理解小小整理了一下。
所謂的理發店模式，簡單地闡述一下，一個理發店有3個理發師，當同時來理發店的客戶有3個的時候，那么理發師的資源能夠有效地利用，這時3個用戶數即為最佳的並發用戶數；當理發店來了9個客戶的時候，3個客戶理發，而6個用戶在等待，3個客戶的等待時間為1個小時，另外的3個客戶的等待時間為2小時，客戶的最大忍受時間為3小時包括理發的1個小時，所以6個客戶的等待時間都在客戶的可以承受范圍內，故9個客戶是該理發店的最大並發用戶數。
吞吐量
我把吞吐量定義為“單位時間內系統處理的客戶請求的數量”（ 吞吐量表示單位時間內能夠完成的事務數量，因此也被稱為每秒事務數（Transaction Per Second），計算方式是完成的事務數除以時間。），直接體現軟件系統的性能承載能力，對於交互式應用系統來說、吞吐量反映的是服務器承受的壓力、在容量規划的測試中、吞吐量是一個重要指標、它不但反映在中間件、數據庫上、更加體現在硬件上。
吞吐量的指標受到響應時間、服務器軟硬件配置、網絡狀態等多方面因素影響。
- 吞吐量越大，響應時間越長。
- 服務器硬件配置越高，吞吐量越大。
- 網絡越差，吞吐量越小。
在低吞吐量下的響應時間的均值、分布比較穩定，不會產生太大的波動。在高吞吐量下，響應時間會隨着吞吐量的增長而增長，增長的趨勢可能是線性的，也可能接近指數的。當吞吐量接近系統的峰值時，響應時間會出現激增。
系統吞度量要素
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS(每秒請求數)（TPS （Transaction Per Second）每秒事務數）：每秒鍾系統處理的request/事務 數量，它是衡量系統處理能力的重要指標；
並發數：系統同時處理的request/事務數
響應時間：一般取平均響應時間
理解了上面三個要素的意義之后，就能推算出它們之間的關系：QPS（TPS）= 並發數/平均響應時間
一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
系統吞吐量評估
我們在做系統設計的時候就需要考慮CPU運算、IO、外部系統響應因素造成的影響以及對系統性能的初步預估。而通常境況下，我們面對需求，我們評估出來的QPS、並發數之外，還有另外一個維度：日頁面流量PV。
PV：訪問一個URL，產生一個PV（Page View，頁面訪問量），每日每個網站的總PV量是形容一個 網站規模的重要指標。
通過觀察系統的訪問日志發現，在用戶量很大的情況下，各個時間周期內的同一時間段的訪問流量幾乎一樣。只要能拿到日流量圖和QPS我們就可以推算日流量。
通常的技術方法：
1. 找出系統的最高TPS和日PV，這兩個要素有相對比較穩定的關系（除了放假、季節性因素影響之外）
2. 通過壓力測試或者經驗預估，得出最高TPS，然后跟進1的關系，計算出系統最高的日吞吐量。
無論有無思考時間（T_think），測試所得的TPS值和並發虛擬用戶數(U_concurrent)、Loadrunner讀取的交易響應時間（T_response）之間有以下關系（穩定運行情況下）：TPS=U_concurrent / (T_response+T_think)。
並發數、QPS、平均響應時間三者之間關系
X軸代表並發用戶數，Y軸代表資源利用率、吞吐量、響應時間。
X軸與Y軸區域從左往右分別是輕壓力區、重壓力區、拐點區。
隨着並發用戶數的增加，在輕壓力區的響應時間變化不大，比較平緩，進入重壓力區后呈現增長的趨勢，最后進入拐點區后傾斜率增大，響應時間急劇增加。接着看吞吐量，隨着並發用戶數的增加，吞吐量增加，進入重壓力區后逐步平穩，到達拐點區后急劇下降，說明系統已經達到了處理極限，有點要扛不住的感覺。
同理，隨着並發用戶數的增加，資源利用率逐步上升，最后達到飽和狀態。
最后，把所有指標融合到一起來分析，隨着並發用戶數的增加，吞吐量與資源利用率增加，說明系統在積極處理，所以響應時間增加得並不明顯，處於比較好的狀態。但隨着並發用戶數的持續增加，壓力也在持續加大，吞吐量與資源利用率都達到了飽和，隨后吞吐量急劇下降，造成響應時間急劇增長。輕壓力區與重壓力區的交界點是系統的最佳並發用戶數，因為各種資源都利用充分，響應也很快；而重壓力區與拐點區的交界點就是系統的最大並發 用戶數，因為超過這個點，系統性能將會急劇下降甚至崩潰。
Light Load（較輕壓力）-----最佳用戶數（資源利用最高）---（較重壓力，系統可以持續工作，但用戶等待時間較長，滿意度會下降）-----Heavy Load-------最大並發用戶數--------Buckle Zone（用戶無法忍受而放棄請求）
最佳並發用戶數：當系統的負載等於最佳並發用戶數時，系統的整體效率最高，沒有資源被浪費，用戶也不需要等待
最大並發用戶數：系統的負載一直持續，有些用戶在處理而有的用戶在自己最大的等待時間內等待的時候
我們需要保證的是：
（1）最佳並發用戶數需大於系統的平均負載
（2）系統的最大並發用戶數要大於系統需要承受的峰值負載
怎么理解這兩句話呢？
（1）系統的平均負載：在特定的時間內，系統正在處理的用戶數和等待處理的用戶數的總和
如果系統的平均負載大於最佳並發用戶數，則用戶的滿意度會下降，所以我們需要保證系統的平均負載小於或者等於最佳並發用戶數
（2）峰值：指的是系統的最大能承受的用戶數的極值
只有最大並發用戶數大於系統所能承受的峰值負載，才不會造成等待空間資源的浪費，導致系統的效率低下
計算公式
指單位時間內系統處理用戶的請求數
從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量
從網絡角度看，吞吐量可以用：字節/秒來衡量
對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，他能夠說明系統的負載能力
以不同方式表達的吞吐量可以說明不同層次的問題，例如，以字節數/秒方式可以表示數要受網絡基礎設施、服務器架構、應用服務器制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用服務器和應用代碼的制約體現出的瓶頸。
當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數之間存在一定的聯系，可以采用以下公式計算：F=VU * R /T
其中F為吞吐量，VU表示虛擬用戶個數，R表示每個虛擬用戶發出的請求數，T表示性能測試所用的時間
吞吐量與負載對應關系
圖中拐點說明：
（1）吞吐量逐漸達到飽和
（2）意味着系統的一種或多種資源利用達到的極限
（3）通常可以利用拐點來進行性能測試分析與定位
錯誤率
超時錯誤率：主要指事務由於超時或系統內部其它錯誤導致失敗占總事務的比率。
錯誤率和服務的具體實現有關。通常情況下，由於網絡超時等外部原因造成的錯誤比例不應超過5%%，由於服務本身導致的錯誤率不應超過1% 。
內部指標|資源指標（與硬件資源消耗相關指標）
資源利用率：資源利用率指的是對不同系統資源的使用程度，一般使用“資源實際使用/總的資源可用量”形成資源利用率。例如服務器的 CPU 利用率、磁盤利用率等。資源利用率是分析系統性能指標進而改善性能的主要依據，因此，它是 Web 性能測試工作的重點。資源利用率主要針對 Web 服務器、操作系統、數據庫服務器、網絡等，是測試和分析瓶頸的主要參數。在性能測試中，要根據需要采集具體的資源利用率參數來進行分析。
從服務器的角度看，性能測試主要關注CPU、內存、服務器負載、網絡、磁盤IO等
1.硬件性能指標：CPU，內存Memory，磁盤I/O（Disk I/O），網絡I/O（Network I/O）
CPU：主要解釋計算機指令以及處理計算機軟件中的數據
Linux系統中top命令查看CPU的使用率
CPU的利用率（<=75%）有：user（用戶使用）,sys（系統調用<=30%）,wait（等待<=5%），idle（空閑）
當user消耗高時，通過top命令查看哪個用戶進程占用cpu的使用
user消耗過高的原因可能有:
（1）代碼問題。如代碼中耗時循環中不加sleep，即例如while的死循環中，沒有加sleep時間，導致沒有空余的時間將cpu的控制權給其他的進程，一直陷入該死循環中，cpu得不到休息，所以usr的消耗過高，則cpu的消耗高
（2）gc頻繁。gc則為垃圾回收，由於垃圾回收也是需要大量的計算，也消耗cpu，所以當gc頻繁時也導致usr用戶空間的消耗也過高，cpu消耗過高
當sys消耗高時，通過top命令查看系統調用資源的情況
sys消耗過高的原因可能有：
（1）上下文切換頻繁。上下文切換發生的情況有：中斷處理，多任務處理，用戶狀態改變。
中斷處理，當cpu停止處理當前的進程轉而處理中斷請求的進程時發生上下文切換。多任務處理則為有多個進程請求cpu的處理，進程的數量多於cpu的核數，則分配進程時間片，根據時間片處理進程，意味着會強制停止一個進程而去處理另一個進程，形成頻繁的上下文切換。用戶狀態改變則為user狀態與sys狀態的改變。
wait較高時，即等待的進程占比高則可以考慮是否磁盤讀寫，磁盤瓶頸問題， 等待的進程較多時，cpu無論如何切換都是切換到等待的進程，導致cpu一直在頻繁切換等待的線程而利用率較低
內存：與cpu溝通的橋梁，計算機中所有程序的運行都在內存中進行，內存分為物理內存、頁面交換（Paging），SWAP內存（虛擬內存）
頁面交換：當物理內存即實際的內存滿了的時候，將物理內存中不常用的進程調出存儲到虛擬內存中，以緩解物理內存空間的壓力，所以當物理內存與虛擬內存的數據交換頻繁的時候，這時候就要關注下內存的性能情況。
SWAP內存：為進程分配虛擬的內存空間，即調用硬盤的空間作為內存使用。
內存的性能分析是又可用內存與頁面交換來分析的，可用內存使用占70%-80%為上限，當超出這個數值，內存性能情況就比較危險，而且即使可用內存使用不超過80%的數值時，頁面交換比較頻繁時，也是要關注下內存情
一般物理內存即使是滿內存也不能代表內存出現問題，主要是看虛擬內存swap，虛擬內存應該<=70%，大於則可以考慮是否內存問題或者內存泄漏
磁盤吞吐量，指單位時間內通過磁盤的數據量。主要關注磁盤的繁忙率，如果高於70%，則磁盤瓶頸
網絡吞吐量，指單位時間內通過網絡的數據量，當吞吐量大於網路設備或鏈路最大傳輸能力，即帶寬時，則應該考慮升級網絡設備或者增加帶寬，Linux命令netstate
網絡IO也有可能出現終止連接失敗。例如當服務端出現大量的TIME_WAIT，見以下TCP終止連接的第4個步驟，在主動發起關閉連接方接收到結束符FIN時狀態變為TIME_WAIT,這時在服務端發現大量的TIME_WAIT,意味着關閉連接是由服務端發起的。
常用的三個狀態是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。
問？什么情況是由服務端發起關閉連接？答：在用戶端的應用程序忘記關閉連接
另外如果在服務端發現大量狀態CLOSE_WAIT,則說明第二次關閉回不去，也就是TCP關閉連接的第三個步驟沒有執行，停留在CLOSE_WAIT的狀態，瀏覽器如果這時發起請求則會返回超時連接，因為服務端這邊一直無法進行第二次關閉，將結束符返回去給用戶端。
注：普及TCP連接的三次握手，終止連接的四次握手
TCP三次握手連接：
(1)用戶端發送SYN給服務器，用戶端的狀態為SYN_SEND
(2)服務端接收到后發送ACK給用戶端，服務端的狀態為SYN_RECV
(3)用戶端接收到服務端發送過來的后發送了ACK給服務端，用戶端的狀態變為Estabilished
TCP終止連接：
(1)用戶端的應用主動發起關閉連接，即應用調用close發送FIN給服務端
(2)服務端接收到FIN后發送ACK給用戶端，服務端的狀態變為CLOSE_WAIT
(3)服務端發送ACK給用戶端的同時也將FIN作為一個文件結束符傳遞給接收端應用程序
(4)用戶端的應用程序接收到FIN后將調用close關閉它的套接字，確認FIN，這時用戶端的狀態變為TIME_WAIT
(5)用戶端發送ACK回執給服務端，連接終止
2.中間件：常用的中間件例如web服務器Tomcat,Weblogic web服務器，JVM（java虛擬機），ThreadPool線程池，JDBC數據驅動
注：http服務器和web服務器與應用服務器的差別是一個存儲靜態網頁的服務器，一個是存儲css，js等動態加載網頁的服務器，而tomcat則屬於應用服務器
注：對中間件例如對服務器的性能測試，需要將監控的jmeter-server的文件下載在服務端上，然后開啟即可監控被測服務器的性能，或者將監控的軟件下載在被測服務器上，遠程啟動監控軟件等
3.數據庫指標
應關注SQL，吞吐量，緩存命中率，連接數等，則是關注sql語句執行時間，以微妙為單位，吞吐量TPS，緩存命中率應>=95%
注：對數據庫的性能測試通過jemter利用批量的sql語句對數據庫進行操作，從而測試數據庫的性能，前提是需要將jdbc的驅動加載在測試計划添加的驅動文件中，然后添加jdbc的前置處理器和jdbc的請求sample。
4.JVM，java虛擬機，為使java的代碼可以編譯運行在不同的平台上順暢，仿真模擬各種計算機來實現
GC：自動內存管理程序，被引用的對象保存在內存中，當對象不被引用時則釋放。關注的參數有Full GC完全java虛擬機垃圾部分回收頻率
5.前端指標
前端應該關注頁面展示，即首次顯示時間，頁面數量，頁面大小，網絡startRender，firstRender等
注：關注前端的性能與后端的性能的不同點在於，前端是每個用戶的直觀的感受，以及前端頁面的加載元素耗費時間給予用戶的感受，而后端的性能關注點在於多用戶使用系統時，服務器是否能夠承受或者服務器的處理能力如何，能否以較好的響應時間響應。
6.Load：系統平均負載，特定時間間隔內運行進程數，Load與cpu核數一致
CPU
CPU使用率：指用戶進程與系統進程消耗的CPU時間百分比，長時間情況下，一般可接受上限不超過85%。
后台服務的所有指令和數據處理都是由CPU負責，服務對CPU的利用率對服務的性能起着決定性的作用。
Linux系統的CPU主要有如下幾個維度的統計數據：
us：用戶態使用的cpu時間百分比
sy：系統態使用的cpu時間百分比
ni：用做nice加權的進程分配的用戶態cpu時間百分比
id：空閑的cpu時間百分比
wa：cpu等待IO完成時間百分比
hi：硬中斷消耗時間百分比
si：軟中斷消耗時間百分比
下圖是線上開放平台轉發服務某台服務器上top命令的輸出，下面以這個服務為例對CPU各項指標進行說明
us & sy：大部分后台服務使用的CPU時間片中us和sy的占用比例是最高的。同時這兩個指標又是互相影響的，us的比例高了，sy的比例就低，反之亦然。通常sy比例過高意味着被測服務在用戶態和系統態之間切換比較頻繁，此時系統整體性能會有一定下降。另外，在使用多核CPU的服務器上，CPU 0負責CPU各核間的調度，CPU 0上的使用率過高會導致其他CPU核心之間的調度效率變低。因此測試過程中CPU 0需要重點關注。
ni：每個Linux進程都有個優先級，優先級高的進程有優先執行的權利，這個叫做pri。進程除了優先級外，還有個優先級的修正值。這個修正值就叫做進程的nice值。一般來說，被測服務和服務器整體的ni值不會很高。如果測試過程中ni的值比較高，需要從服務器Linux系統配置、被測服務運行參數查找原因
id：線上服務運行過程中，需要保留一定的id冗余來應對突發的流量激增。在性能測試過程中，如果id一直很低，吞吐量上不去，需要檢查被測服務線程/進程配置、服務器系統配置等。
wa：磁盤、網絡等IO操作會導致CPU的wa指標提高。通常情況下，網絡IO占用的wa資源不會很高，而頻繁的磁盤讀寫會導致wa激增。如果被測服務不是IO密集型的服務，那需要檢查被測服務的日志量、數據載入頻率等。
hi & si：硬中斷是外設對CPU的中斷，即外圍硬件發給CPU或者內存的異步信號就是硬中斷信號；軟中斷由軟件本身發給操作系統內核的中斷信號。通常是由硬中斷處理程序或進程調度程序對操作系統內核的中斷，也就是我們常說的系統調用(System Call)。在性能測試過程中，hi會有一定的CPU占用率，但不會太高。對於IO密集型的服務，si的CPU占用率會高一些。
內存
內存利用率：內存利用率=（1-空閑內存/總內存大小）*100%，一般至少有10%可用內存，內存使用率可接受上限為85%。
性能測試過程中對內存監控的主要目的是檢查被測服務所占用內存的波動情況。
在Linux系統中有多個命令可以獲取指定進程的內存使用情況，最常用的是top命令，如下圖所示
其中
VIRT：進程所使用的虛擬內存的總數。它包括所有的代碼，數據和共享庫，加上已換出的頁面，所有已申請的總內存空間
RES：進程正在使用的沒有交換的物理內存（棧、堆），申請內存后該內存段已被重新賦值
SHR：進程使用共享內存的總數。該數值只是反映可能與其它進程共享的內存，不代表這段內存當前正被其他進程使用
SWAP：進程使用的虛擬內存中被換出的大小，交換的是已經申請，但沒有使用的空間，包括（棧、堆、共享內存）
DATA：進程除可執行代碼以外的物理內存總量，即進程棧、堆申請的總空間
從上面的解釋可以看出，測試過程中主要監控RES和VIRT，對於使用了共享內存的多進程架構服務，還需要監控SHR。
LOAD（服務器負載）
Linux的系統負載指運行隊列的平均長度，也就是等待CPU的平均進程數
從服務器負載的定義可以看出，服務器運行最理想的狀態是所有CPU核心的運行隊列都為1，即所有活動進程都在運行，沒有等待。這種狀態下服務器運行在負載閾值下。
通常情況下，按照經驗值，服務器的負載應位於閾值的70%~80%，這樣既能利用服務器大部分性能，又留有一定的性能冗余應對流量增長。
Linux提供了很多查看系統負載的命令，最常用的是top和uptime
top和uptime針對負載的輸出內容相同，都是系統最近1分鍾、5分鍾、15分鍾的負載均值
Uptime命令結果的每一列的含義如下：
“當前時間 系統運行時長 登錄的用戶數最 近1分鍾、5分鍾、15分鍾的平均負載”
查看系統負載閾值的命令如下，下方是查看CPU每個核心的使用情況：
在性能測試過程中，系統負載是評價整個系統運行狀況最重要的指標之一。通常情況下，壓力測試時系統負載應接近但不能超過閾值，並發測試時的系統負載最高不能超過閾值的80%，穩定性測試時，系統負載應在閾值的50%左右。
網絡
網絡帶寬：一般使用計數器Bytes Total/sec來度量，Bytes Total/sec表示為發送和接收字節的速率，包括幀字符在內。判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬比較。
性能測試中網絡監控主要包括網絡流量、網絡連接狀態的監控。
網絡流量監控
可以使用nethogs命令。該命令與top類似，是一個實時交互的命令，運行界面如下
在后台服務性能測試中，對於返回文本結果的服務，並不需要太多關注在流量方面。
網絡連接狀態監控
性能測試中對網絡的監控主要是監控網絡連接狀態的變化和異常。對於使用TCP協議的服務，需要監控服務已建立連接的變化情況（即ESTABLISHED狀態的TCP連接）。對於HTTP協議的服務，需要監控被測服務對應進程的網絡緩沖區的狀態、TIME_WAIT狀態的連接數等。Linux自帶的很多命令如netstat、ss都支持如上功能。下圖是netstat對指定pid進程的監控結果
磁盤IO
磁盤主要用於存取數據，因此當說到IO操作的時候，就會存在兩種相對應的操作，存數據的時候對應的是寫IO操作，取數據的時候對應的是讀IO操作，一般使用% Disk Time（磁盤用於讀寫操作所占用的時間百分比）度量磁盤讀寫性能。
性能測試過程中，如果被測服務對磁盤讀寫過於頻繁，會導致大量請求處於IO等待的狀態，系統負載升高，響應時間變長，吞吐量下降。
Linux下可以用iostat命令來監控磁盤狀態，如下圖
tps：該設備每秒的傳輸次數。“一次傳輸”意思是“一次I/O請求”。多個邏輯請求可能會被合並為“一次I/O請求”。“一次傳輸”請求的大小是未知的
kB_read/s：每秒從設備（driveexpressed）讀取的數據量，單位為Kilobytes
kB_wrtn/s：每秒向設備（driveexpressed）寫入的數據量，單位為Kilobytes
kB_read：讀取的總數據量，單位為Kilobytes
kB_wrtn：寫入的總數量數據量，單位為Kilobytes
從iostat的輸出中，能夠獲得系統運行最基本的統計數據。但對於性能測試來說，這些數據不能提供更多的信息。需要加上-x參數
rrqm/s：每秒這個設備相關的讀取請求有多少被合並了（當系統調用需要讀取數據的時候，VFS將請求發到各個FS，如果FS發現不同的讀取請求讀取的是相同Block的數據，FS會將這個請求合並Merge）
wrqm/s：每秒這個設備相關的寫入請求有多少被Merge了
await：每一個IO請求的處理的平均時間（單位是毫秒）
%util：在統計時間內所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該設備有0.8秒在處理IO，而0.2秒閑置，那么該設備的%util = 0.8/1 = 80%，該參數暗示了設備的繁忙程度。
資源利用與負載對應關系
圖中拐點說明：
（1）服務器某一資源使用逐漸達到飽和
（2）通常可以利用拐點來進行性能測試分析與定位
性能計數器（counters）
是描述服務器或操作系統性能的一些數據指標，如使用內存數、進程時間，在性能測試中發揮着“監控和分析”的作用，尤其是在分析系統可擴展性、進行新能瓶頸定位時有着非常關鍵的作用。
常見性能瓶頸
吞吐量到上限時系統負載未到閾值：一般是被測服務分配的系統資源過少導致的。測試過程中如果發現此類情況，可以從ulimit、系統開啟的線程數、分配的內存等維度定位問題原因
CPU的us和sy不高，但wa很高：如果被測服務是磁盤IO密集型型服務，wa高屬於正常現象。但如果不是此類服務，最可能導致wa高的原因有兩個，一是服務對磁盤讀寫的業務邏輯有問題，讀寫頻率過高，寫入數據量過大，如不合理的數據載入策略、log過多等，都有可能導致這種問題。二是服務器內存不足，服務在swap分區不停的換入換出。
同一請求的響應時間忽大忽小：在正常吞吐量下發生此問題，可能的原因有兩方面，一是服務對資源的加鎖邏輯有問題，導致處理某些請求過程中花了大量的時間等待資源解鎖；二是Linux本身分配給服務的資源有限，某些請求需要等待其他請求釋放資源后才能繼續執行。
內存持續上漲：在吞吐量固定的前提下，如果內存持續上漲，那么很有可能是被測服務存在明顯的內存泄漏，需要使用valgrind等內存檢查工具進行定位。
性能瓶頸定位之拐點分析法
“拐點分析”方法是一種利用性能計數器曲線圖上的拐點進行性能分析的方法。它的基本思想就是性能產生瓶頸的主要原因就是因為某個資源的使用達到了極限，此時表現為隨着壓力的增大，系統性能卻出現急劇下降，這樣就產生了“拐點”現象。當得到“拐點”附近的資源使用情況時，就能定位出系統的性能瓶頸。
軟件性能的其它術語
思考時間的計算公式
Think Time，從業務角度來看，這個時間指用戶進行操作時每個請求之間的時間間隔，而在做新能測試時，為了模擬這樣的時間間隔，引入了思考時間這個概念，來更加真實的模擬用戶的操作。
在吞吐量這個公式中F=VU * R / T說明吞吐量F是VU數量、每個用戶發出的請求數R和時間T的函數，而其中的R又可以用時間T和用戶思考時間TS來計算：R = T / TS
下面給出一個計算思考時間的一般步驟：
1、首先計算出系統的並發用戶數
C=nL / T F=R×C
2、統計出系統平均的吞吐量
F=VU * R / T R×C = VU * R / T
3、統計出平均每個用戶發出的請求數量
R=u*C*T/VU
4、根據公式計算出思考時間
TS=T/R
軟件性能的影響因素
（1）硬件設施（部署結構、機器配置）
（2）網絡環境（客戶端帶寬、服務器端帶寬）
（3）操作系統（類型、版本、參數配置）
（4）中間件（類型、版本、參數配置）
（5）應用程序（性能）
（6）並發用戶數（系統當前訪問狀態）
（7）客戶端
（8）數據服務器
（9）編程語言、程序實現方式、算法
軟件性能的關注點
首先，開發軟件的目的是為了讓用戶使用，我們先站在用戶的角度分析一下，用戶需要關注哪些性能。
對於用戶來說，當點擊一個按鈕、鏈接或發出一條指令開始，到系統把結果已用戶感知的形式展現出來為止，這個過程所消耗的時間是用戶對這個軟件性能的直觀印象。也就是我們所說的響應時間，當相應時間較小時，用戶體驗是很好的，當然用戶體驗的響應時間包括個人主觀因素和客觀響應時間，在設計軟件時，我們就需要考慮到如何更好地結合這兩部分達到用戶最佳的體驗。如：用戶在大數據量查詢時，我們可以將先提取出來的數據展示給用戶，在用戶看的過程中繼續進行數據檢索，這時用戶並不知道我們后台在做什么。
用戶關注的是用戶操作的響應時間。
其次，我們站在管理員的角度考慮需要關注的性能點。
1、 響應時間
2、 服務器資源使用情況是否合理
3、 應用服務器和數據庫資源使用是否合理
4、 系統能否實現擴展
5、 系統最多支持多少用戶訪問、系統最大業務處理量是多少
6、 系統性能可能存在的瓶頸在哪里
7、 更換那些設備可以提高性能
8、 系統能否支持7×24小時的業務訪問
再次，站在開發（設計）人員角度去考慮。
1、 架構設計是否合理
2、 數據庫設計是否合理
3、 代碼是否存在性能方面的問題
4、 系統中是否有不合理的內存使用方式
5、 系統中是否存在不合理的線程同步方式
6、 系統中是否存在不合理的資源競爭
那么站在性能測試工程師的角度，我們要關注什么呢？ 一句話，我們要關注以上所有的性能點。
性能測試的核心原理
性能測試的核心原理，開發測試工具也是基於前兩點：
1、基於協議（前端后端通信機制），基於界面（決定和前端交互），基於代碼（后端）。
基於網絡的分布式架構：基於網絡協議去模擬用戶發送請求；
2、多線程：模擬多線程操作，多人同時操作，模擬大負載量（功能測試在於用以測試功能）；
3、模擬真實場景：真實的網絡環境，用戶操作時間不確定性，操作不確定，得出的數據是准確的，場景不對，數據也不一定可用。
性能問題分析原則
性能測試原則
1）情況許可時，應使用幾種測試工具或手段分別獨立進行測試，並將結果相互印證，避免單一工具或測試手段自身缺陷影響結果的准確性；
2）對於不同的系統，性能關注點是有所區別的，應該具體問題具體分析；
3）查找瓶頸的過程應由易到難逐步排查：
服務器硬件瓶頸及網絡瓶頸（局域網環境下可以不考慮網絡因素）
應用服務器及中間件操作系統瓶頸（數據庫、WEB服務器等參數配置）
應用業務瓶頸（SQL語句、數據庫設計、業務邏輯、算法、數據等）
4）性能調優過程中不宜對系統的各種參數進行隨意的改動，應該以用戶配置手冊中相關參數設置為基礎，逐步根據實際現場環境進行優化，一次只對某個領域進行性能調優（例如對CPU的使用情況進行分析），並且每次只改動一個設置，避免相關因素互相干擾；
5）調優過程中應仔細進行記錄，保留每一步的操作內容及結果，以便比較分析；
6）性能調優是一個經驗性的工作，需要多思考、分析、交流和積累；
7）了解“有限的資源，無限的需求”；
8）盡可能在開始前明確調優工作的終止標准。
性能測試的注意要點
性能調優應該注意的要點
性能測試流程
一般企業會按照這個步驟去執行測試：先負載測試（逐步增加並發用戶數來增加壓力，只能找出性能指標的瓶頸范圍，而不是具體的性能指標值），再性能測試（驗證我們的性能指標的具體的值，即精確），最后壓力測試。
平時我們說的基准測試其實是在性能測試里的找出。
壓力測試：在一定的壓力下，運行比較長的時間。目的是看服務器的穩定性。
企業口語說的“壓測”表達的是：要做負載測試和性能測試。
注：絕對不允許用生產環境，公司如果有准生產環境最好。從生產的集群里抽取一個單機拿出來專門做性能測試的獨立服務器。但是其數據庫數據和服務都徹底從集群中移出來，這樣不影響生產環境正常業務發展。
獨立網絡：就是必須使用網線有線連接，千萬不要使用wifi，VPN，堡壘機（把兩個網絡連接起來的橋梁），最好是測試負載機和控制機在同一個網絡而且都是獨立的局域網里直接路由跳出去訪問外網的服務器。否則網速會嚴重影響數據的傳輸和加載，會出現數據包丟失嚴重的現象。最主要的是嚴重影響響應時間的指標值，偏差太大，沒有參考價值。
TPS:服務器綜合能力指標值，服務器最主要的指標值。吞吐量有個單位是：平均事務數/秒
loadrunner和jmeter的TPS是有區別的，jmeter有兩種每秒事務數。jmeter除了每個業務的請求到響應完成的統計外，還有事務邏輯控制器對多個單個業務請求打包成一個全鏈路業務流的業務的請求到響應完成的統計等。
性能測試不是去找功能上的bug，是找出服務器的瓶頸。
采用自動化負載測試工具執行的並發性能測試，基本遵循的測試過程有：測試需求與測試內容，測試案例制定，測試環境准備，測試腳本錄制、編寫與調試，腳本分配、回放配置與加載策略，測試執行跟蹤，結果分析與定位問題所在，測試報告與測試評估。
一、性能測試需求分析
性能需求分析是整個性能測試工作開展的基礎，如果連性能的需求都沒弄清楚，后面的性能測試執行其實是沒有任何意義的，而且性能需求分析做的好不好直接影響到性能測試的結果。
一些性能測試人員常犯的錯誤就是測試一開始就直接用工具對系統進行加壓，沒有弄清楚性能測試的目的，稀里糊塗做完了以后也不知道結果是否滿足性能需求。市面上的書籍也大都是直接講性能測試工具如LR，jmeter如何使用，導致很多新手一提到性能測試就直接拿工具來進行錄制回放，使得很多人認為會使用性能測試工具就等於會性能測試了，殊不知工具其實只是性能測試過程中很小的一部分。
在需求分析階段，測試人員需要與項目相關的人員進行溝通，收集各種項目資料，對系統進行分析，建立性能測試數據模型，並將其轉化為可衡量的具體性能指標，確認測試的目標。所以性能測試需求分析過程是繁雜的，需要測試人員有深厚的性能理論知識，除此之外還需要懂一些數學建模的知識來幫助我們建立性能測試模型。
首先，讓我們來看看通過性能需求分析我們需要得出哪些結論或目標：
- 明確倒底要不要做性能測試？性能測試的目的是什么？
- 明確被測系統是什么？被測試系統的相關技術信息如：架構、平台、協議等
- 明確被測系統的基本業務、關鍵業務，用戶行為
- 明確性能測試點是什么？哪些需要測，為什么？哪些不需要測，又是為什么？
- 明確被測系統未來的業務拓展規划以及性能需求？
- 明確性能測試策略，即應該怎么測試？
- 明確性能測試的指標，知道測試出來的結果怎么算通過？
其次，需求分析階段我們可以從以下幾個方面入手：
1、系統信息調研：
指對被測試系統進行分析，需要對其有全面的了解和認識，這是我們做好性能測試的前提，而且在后續進行性能分析和調優時將會大有用處，試想如果連系統的架構、協議都不了解，我們如何進行准確的性能測試？如果進行性能分析與調優？
需要分析的系統信息如下（包括但不僅限於如下這些）：
2、業務信息調研：
指對被測試的業務進行分析，通過對業務的分析和了解，方便我們后續進行性能測試場景的確定以及性能測試指標的確定。
需要分析的業務信息如下（包括但不僅限於如下這些）：
3、性能需求評估：
在實施性能測試之前，我們需要對被測系統做相應的評估，主要目的是明確是否需要做性能測試。如果確定需要做性能測試，需要進一步確立性能測試點和指標，明確該測什么、性能指標是多少，測試通過or不通過的標准？性能指標也會根據情況評估，要求被測系統能滿足將來一定時間段的業務壓力。
判斷是否進行性能測試主要從下面兩個方面進行思考：
- 業務角度:
系統是公司內部 or 對外？系統使用的人數的多少？如果一個系統上線后基本沒幾個人使用，無論系統多大，設計多么復雜，並發性的性能測試都是沒必要的，前期可以否決。當然，除非在功能測試階段發現非常明顯的性能問題，使得用戶體驗較差的，此時可進行性能測試來排查問題。
- 系統角度：系統又可以從以下3個方面進行分析
a）系統架構：
如果一個系統采用的框架是老的系統框架（通常大公司都有自己的統一框架），只是在此框架上增加一些應用，其實是沒有必要做性能測試，因為老框架的使用肯定是經過了驗證的。如果一個系統采用的是一種新的框架，可以考慮做性能測試。
b）數據庫要求：
很多情況下，性能測試是大數據量的並發訪問、修改數據庫，而瓶頸在於連接數據庫池的數量，而非數據庫本身的負載、吞吐能力。這時，可以結合DBA的建議，來決定是否來做性能測試。
c）系統特殊要求：
從實時性角度來分析，某些系統對響應時間要求比較，比如證券系統，系統的快慢直接影響客戶的收益，這種情況就有作並發測試的必要，在大並發量的場景下，查看這個功能的響應時間。
從大數據量上傳下載角度分析，某些系統經常需要進行較大數據量的上傳和下載操作，雖然此種操作使用的人數不會太多，但是也有必要進行性能測試，確定系統能處理的最大容量，如果超過這個容量時系統需要進行相關控制，避免由於不人工誤操作導致系統內存溢出或崩潰。
4、確定性能測試點：
在上面第3點中，我們簡單分析了如何確定一個系統是否需要做性能測試。下面簡單總結下如果一個系統確定要做性能測試，我們如何確定被測系統的性能測試點？
我們可以從下面幾個方面進行分析：
- 關鍵業務：
確定被測項目是否屬於關鍵業務，有哪些主要的業務邏輯點，特別是跟交易相關的功能點。例如轉賬，扣款等接口。如果項目（或功能點）不屬於關鍵業務（或關鍵業務點），則可轉入下面。
- 日請求量：
確定被測項目各功能點的日請求量（可以統計不同時間粒度下的請求量如：小時，日，周，月）。如果日請求量很高，系統壓力很大，而且又是關鍵業務，該項目需要做性能測試，而且關鍵業務點，可以被確定為性能點。
- 邏輯復雜度：
判定被測項目各功能點的邏輯復雜度。如果一個主要業務的日請求量不高，但是邏輯很復雜，則也需要通過性能測試。原因是，在分布式方式的調用中，當某一個環節響應較慢，就會影響到其它環節，造成雪崩效應。
- 運營推廣活動：
根據運營的推廣計划來判定待測系統未來的壓力。未雨綢繆、防患於未然、降低運營風險是性能測試的主要目標。被測系統的性能不僅能滿足當前壓力，更需要滿足未來一定時間段內的壓力。因此，事先了解運營推廣計划，對性能點的制定有很大的作用。例如，運營計划做活動，要求系統每天能支撐多少 PV、多少 UV，或者一個季度后，需要能支撐多大的訪問量等等數據。當新項目（或功能點）屬於運營重點推廣計划范疇之內，則該項目（或功能點）也需要做性能測試。
以上 4 點，是相輔相成、環環相扣的。在實際工作中應該具體問題具體分析。例如，當一個功能點不滿足以上 4 點，但又屬於資源高消耗（內存、CPU），也可列入性能測試點行列。
注：
PV：訪問一個URL，產生一個PV（Page View，頁面訪問量），每日每個網站的總PV量是形容一個 網站規模的重要指標。
UV：作為一個獨立的用戶，訪問站點的所有頁面均算作一個UV（Unique Visitor，用戶訪問）
5、確定性能指標：
性能需求分析一個很重要的目標就是需要確定后期性能分析用的性能指標，性能指標有很多，可以根據具體項目選取和設定，而具體的指標值則需要根據業務特點進行設定，本文不詳細進行闡述，后續可考慮就此單獨寫一篇。
二、性能測試准備
1、測試環境准備：（見：四：測試腳本設計與開發）
a）系統運行環境：這個通常就是我們的測試環境，有些時候需求比較多，做性能測試擔心把環境搞跨了影響其它的功能測試，可能需要重新搭建一套專門用來做性能測試的環境。
b）執行機環境：這個就是用來生成負載的執行機，通常需要在物理機上運行，而物理機又是稀缺資源，所以我們每次做性能測試都需要提前准備好執行機環境。
2、測試場景設計：（見：四：測試腳本設計與開發）
根據性能需求分析來設計符合用戶使用習慣的場景，場景設計的好不好直接影響到性能測試的效果。
3、性能工具准備：
a）負載工具：根據需求分析和系統特點選擇合適的負載工具，比如LR、Jmeter或galting等
b）監控工具：准備性能測試時的服務器資源、JVM、數據庫監控工具，以便進行后續的性能測試分析與調優。
4、測試腳本准備：如果性能測試工具不能滿足被測系統的要求或只能滿足部分要求時，需要我們自己開發腳本配合工具進行性能測試。
5、測試數據准備：
a）負載測試數據：並發測試時需要多少數據？比如登錄場景？
b）DB數據量大小：為了盡量符合生產場景，需要模擬線上大量數據情況，那么要往數據庫里提前插入一定的數據量。這可能需要花費一些時間，特點是關聯系統較多，邏輯復雜的業務可能同時涉及多張表。
6、性能測試團隊組建：如果需要其它關聯系統或專業人士如DBA配合的，也需要提前進行溝通。
三、性能測試計划
測試計划階段最重要的是分析用戶場景，確定系統性能目標。
1、性能測試領域分析
根據對項目背景，業務的了解，確定本次性能測試要解決的問題點；是測試系統能否滿足實際運行時的需要，還是目前的系統在哪些方面制約系統性能的表現，或者，哪些系統因素導致系統無法跟上業務發展？確定測試領域，然后具體問題具體分析。
2、用戶場景剖析和業務建模
根據對系統業務、用戶活躍時間、訪問頻率、場景交互等各方面的分析，整理一個業務場景表，當然其中最好對用戶操作場景、步驟進行詳細的描述，為測試腳本開發提供依據。
3、確定性能目標
前面已經確定了本次性能測試的應用領域，接下來就是針對具體的領域關注點，確定性能目標（指標）；其中需要和其他業務部門進行溝通協商，以及結合當前系統的響應時間等數據，確定最終我們需要達到的響應時間和系統資源使用率等目標；比如：
①登錄請求到登錄成功的頁面響應時間不能超過2秒；
②報表審核提交的頁面響應時間不能超過5秒；
③文件的上傳、下載頁面響應時間不超過8秒；
④服務器的CPU平均使用率小於70%，內存使用率小於75%；
⑤ 各個業務系統的響應時間和服務器資源使用情況在不同測試環境下，各指標隨負載變化的情況等；
web性能測試之響應時間
4、制定測試計划的實施時間
預設本次性能測試各子模塊的起止時間，產出，參與人員等等。
（1）明確測試范圍
（2）制訂時間（進度）計划
（3）制訂成本計划
（4）制訂環境計划
（5）測試工具規划
（6）測試風險分析
四、測試腳本設計與開發
性能測試中，測試腳本設計與開發占據了很大的時間比測試重。
1、測試環境設計
本次性能測試的目標是需要驗證系統在實際運行環境中的性能外，還需要考慮到不同的硬件配置是否會是制約系統性能的重要因素！因此在測試環境中，需要部署多個不同的測試環境，
在不同的硬件配置上檢查應用系統的性能，並對不同配置下系統的測試結果進行分析，得出最優結果（最適合當前系統的配置）。
這里所說的配置大概是如下幾類：
①數據庫服務器
②應用服務器
③負載模擬器
④軟件運行環境，平台測試環境測試數據，可以根據系統的運行預期來確定，比如需要測試的業務場景，數據多久執行一次備份轉移，該業務場景涉及哪些表，每次操作數據怎樣寫入，寫入幾條，需要多少的測試數據來使得測試環境的數據保持一致性等等。
可以在首次測試數據生成時，將其導出到本地保存，在每次測試開始前導入數據，保持一致性。
2、測試場景設計
通過和業務部門溝通以及以往用戶操作習慣，確定用戶操作習慣模式，以及不同的場景用戶數量，操作次數，確定測試指標，以及性能監控等。
3、測試用例設計
確認測試場景后，在系統已有的操作描述上，進一步完善為可映射為腳本的測試用例描述，用例大概內容如下：
用例編號：查詢表單_xxx_x1（命名以業務操作場景為主，簡潔易懂即可）
用例條件：用戶已登錄、具有對應權限等。。。
操作步驟：
①進入對應頁面。。。。。。
②查詢相關數據。。。。。。
③勾選導出數據。。。。。。
④修改上傳數據。。。。。。
PS：這里的操作步驟只是個例子，具體以系統業務場景描述；
4、腳本和輔助工具的開發及使用
按照用例描述，可利用工具進行錄制，然后在錄制的腳本中進行修改；比如參數化、關聯、檢查點等等，最后的結果使得測試腳本可用，能達到測試要求即可；
PS：個人而言，建議盡量自己寫腳本來實現業務操作場景，這樣對個人技能提升較大；一句話：能寫就絕不錄制！！！
五、性能測試執行
在這個階段，只需要按照之前已經設計好的業務場景、環境和測試用例腳本，部署環境，執行測試並記錄結果即可。
1、人工邊執行邊分析
通常我們做性能測試都是人工執行並隨時觀察系統運行的情況、資源的使用率等指標。性能測試的吸引力之一就在於它的不可預知性。當我們在做性能測試的時候，遇到跟預期不符的情況很正常，這個時候需要冷靜的分析。但這個過程可能會很漫長，需要不斷的調整系統配置或程序代碼來定位問題，耗時耗人力。特別是在當前敏捷開發模式比較流行的大環境下，版本發布非常頻繁且版本周期短（通常1~2周一個版本），沒有那么長的時間來做性能測試。
2、無人值守執行性能測試
無人值守是最理想化的目標，目前我們也朝着這個方向努力。無人值守不是說沒有人力介入，而是把人為的分析和執行過程分離，執行過程只是機器服從指令的運行而已。通常測試環境在白天比較繁忙，出現性能問題及定位難度較大且會影響功能測試。所以一般性能測試最好在晚上或周末進行，在相對較安靜的條件有利於測試結果的穩定性。這種方法也相對比較適合敏捷的模式，不需要人工一直守着。只需要在拿到結果后進行分析就好了。同時，這種方式對測試人員能力的要求比較高，需要我們能進行自動化的收集各種監控數據、生成報表便於后續分析。
六、結果分析與調優
1、測試環境的系統性能分析
根據我們之前記錄得到的測試結果（圖表、曲線等），經過計算，與預定的性能指標進行對比，確定是否達到了我們需要的結果；如未達到，查看具體的瓶頸點，然后根據瓶頸點的具體數據進行具體情況具體分析（影響性能的因素很多，這一點，可以根據經驗和數據表現來判斷分析）。
2、硬件設備對系統性能表現的影響分析
由於之前設計了幾個不同的測試環境，故可以根據不同測試環境的硬件資源使用狀況圖進行分析，確定瓶頸是再數據庫服務器、應用服務器抑或其他方面，然后針對性的進行優化等操作。
3、其他影響因素分析
影響系統性能的因素很多，可以從用戶能感受到的場景分析，哪里比較慢，哪里速度尚可，這里可以根據2\5\8原則對其進行分析；
至於其他諸如網絡帶寬、操作動作、存儲池、線程實現、服務器處理機制等一系列的影響因素，具體問題具體分析，這里就不一一表述了。
4、測試中發現的問題
在性能測試執行過程中，可能會發現某些功能上的不足或存在的缺陷，以及需要優化的地方，這也是執行多次測試的優點。
1.性能分析方法分類：
（1）指標達成法：用於驗證性能指標
（2）最優化分析法：用於能力驗證型測試
2.常用性能分析方法：
（1）快速瓶頸識別：
①硬件上的性能瓶頸 ②應用軟件上的性能瓶頸 ③應用程序上的性能瓶頸
④操作系統上的性能瓶頸 ⑤網絡設備上的性能瓶頸
（2）性能下降曲線：單用戶區域、性能平坦區、壓力區域、性能拐點
（3）內存分析方法 （4）處理器分析方法 （5）磁盤IO分析方法 （6）進程分析方法 （7）網絡分析方法
七、測試報告與總結
性能測試報告是性能測試的里程碑，通過報告能展示出性能測試的最終成果，展示系統性能是否符合需求，是否有性能隱患。性能測試報告中需要闡明性能測試目標、性能測試環境、性能測試數據構造規則、性能測試策略、性能測試結果、性能測試調優說明、性能測試過程中遇到的問題和解決辦法等。
性能測試工程師完成該次性能測試后，需要將測試結果進行備案，並作為下次性能測試的基線標准，具體包括性能測試結果數據、性能測試瓶頸和調優方案等。同時需要將測試過程中遇到的問題，包括代碼瓶頸、配置項問題、數據問題和溝通問題，以及解決辦法或解決方案，進行知識沉淀
性能測試的實施過程
客戶端性能測試
應用在客戶端性能測試的目的是考察客戶端應用的性能，測試的入口是客戶端。它主要包括並發性能測試、疲勞強度測試、大數據量測試和速度測試等，其中並發性能測試是重點。
並發性能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到系統的瓶頸或者不能接收的性能點，通過綜合分析交易執行指標和資源監控指標來確定系統並發性能的過程。負載測試（Load Testing）是確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統組成部分的相應輸出項，例如通過量、響應時間、CPU負載、內存使用等來決定系統的性能。負載測試是一個分析軟件應用程序和支撐架構、模擬真實環境的使用，從而來確定能夠接收的性能過程。壓力測試（Stress Testing）是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。
並發性能測試的目的主要體現在三個方面：以真實的業務為依據，選擇有代表性的、關鍵的業務操作設計測試案例，以評價系統的當前性能；當擴展應用程序的功能或者新的應用程序將要被部署時，負載測試會幫助確定系統是否還能夠處理期望的用戶負載，以預測系統的未來性能；通過模擬成百上千個用戶，重復執行和運行測試，可以確認性能瓶頸並優化和調整應用，目的在於尋找到瓶頸問題。
網絡端性能測試
應用在網絡上性能的測試重點是利用成熟先進的自動化技術進行網絡應用性能監控、網絡應用性能分析和網絡預測。
網絡應用性能分析的目的是准確展示網絡帶寬、延遲、負載和TCP端口的變化是如何影響用戶的響應時間的。
網絡應用性能監控
在系統試運行之后，需要及時准確地了解網絡上正在發生什么事情；什么應用在運行，如何運行；多少PC正在訪問LAN或WAN；哪些應用程序導致系統瓶頸或資源競爭，這時網絡應用性能監控以及網絡資源管理對系統的正常穩定運行是非常關鍵的。利用網絡應用性能監控工具，可以達到事半功倍的效果，在這方面我們可以提供的工具是Network Vantage。通俗地講，它主要用來分析關鍵應用程序的性能，定位問題的根源是在客戶端、服務器、應用程序還是網絡。在大多數情況下用戶較關心的問題還有哪些應用程序占用大量帶寬，哪些用戶產生了最大的網絡流量，這個工具同樣能滿足要求。
網絡預測
考慮到系統未來發展的擴展性，預測網絡流量的變化、網絡結構的變化對用戶系統的影響非常重要。根據規划數據進行預測並及時提供網絡性能預測數據。我們利用網絡預測分析容量規划工具PREDICTOR可以作到：設置服務水平、完成日網絡容量規划、離線測試網絡、網絡失效和容量極限分析、完成日常故障診斷、預測網絡設備遷移和網絡設備升級對整個網絡的影響。
從網絡管理軟件獲取網絡拓撲結構、從現有的流量監控軟件獲取流量信息（若沒有這類軟件可人工生成流量數據），這樣可以得到現有網絡的基本結構。在基本結構的基礎上，可根據網絡結構的變化、網絡流量的變化生成報告和圖表，說明這些變化是如何影響網絡性能的。PREDICTOR提供如下信息：根據預測的結果幫助用戶及時升級網絡，避免因關鍵設備超過利用閥值導致系統性能下降；哪個網絡設備需要升級，這樣可減少網絡延遲、避免網絡瓶頸；根據預測的結果避免不必要的網絡升級。
服務器端性能測試
對於應用在服務器上性能的測試，可以采用工具監控，也可以使用系統本身的監控命令，例如Tuxedo中可以使用Top命令監控資源使用情況。實施測試的目的是實現服務器設備、服務器操作系統、數據庫系統、應用在服務器上性能的全面監控，測試原理如下圖。
UNIX資源監控指標和描述
監控指標 描述
平均負載 系統正常狀態下，最后60秒同步進程的平均個數
沖突率 在以太網上監測到的每秒沖突數
進程/線程交換率 進程和線程之間每秒交換次數
CPU利用率 CPU占用率（%）
磁盤交換率 磁盤交換速率
接收包錯誤率 接收以太網數據包時每秒錯誤數
包輸入率 每秒輸入的以太網數據包數目
中斷速率 CPU每秒處理的中斷數
輸出包錯誤率 發送以太網數據包時每秒錯誤數
包輸入率 每秒輸出的以太網數據包數目
讀入內存頁速率 物理內存中每秒讀入內存頁的數目
寫出內存頁速率 每秒從物理內存中寫到頁文件中的內存頁數
目或者從物理內存中刪掉的內存頁數目
內存頁交換速率 每秒寫入內存頁和從物理內存中讀出頁的個數
進程入交換率 交換區輸入的進程數目
進程出交換率 交換區輸出的進程數目
系統CPU利用率 系統的CPU占用率（%）
用戶CPU利用率 用戶模式下的CPU占用率（%）
磁盤阻塞 磁盤每秒阻塞的字節數
分析優化性能思路流程
性能測試總結
1、硬件上的性能瓶頸：
一般指的是CPU、內存、磁盤讀寫等的瓶頸，為服務器硬件瓶頸。
2、應用軟件上的性能瓶頸：
一般指的是服務器操作系統瓶頸（參數配置）、數據庫瓶頸（參數配置）、web服務器瓶頸（參數配置）、中間件瓶頸（參數配置）等
3、應用程序上的性能瓶頸：
一般指的是開發人員，開發出來的應用程序（如sql語句、數據庫設計、業務邏輯、算法等）。
4、操作系統上的性能瓶頸：
一般指的是Windows、linux等操作系統，如出現物理內存不足時，或虛擬內存設置不合理（虛擬內存設置不合理，會導致虛擬內存的交換率大大降低，從而導致行為的響應時間大大增加，可以認為在操作系統上出現了性能瓶頸）。
5、網絡設備上的性能瓶頸：
一般指的是防火牆、動態負載均衡器、交換機等設備。
安全測試
安全測試是一個相對獨立的領域，需要更多的專業知識。如：WEB的安全測試、需要熟悉各種網絡協議、防火牆、CDN、熟悉各種操作系統的漏洞、熟悉路由器等。
采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ）
安全測試主要是根據對應的項目來進行的安全測試用例設計及編寫后執行安全測試。比如主要是對用戶登錄的校驗、密碼是否加密、權限；設計充值、提現等必須是否綁定手機號的短信驗證碼校驗等；需要實名認證的，甚至人臉識別技術等；做壓力測試的時候，比如需要考慮同一個IP地址的請求過多或頻繁，需要有對應的判斷是否為惡意攻擊及判斷后的相應解決措施等。
兼容性測試
兼容性測試主要是指，軟件之間能否很好的運作，會不會有影響、軟件和硬件之間能否發揮很好的效率工作，會不會影響導致系統的崩潰。
平台測試
瀏覽器測試
軟件本身能否向前或向后兼容
測試軟件能否與其它相關軟件兼容
數據兼容性測試
最常見的兼容性測試就是瀏覽器的兼容性測試，不同瀏覽器在css，js解析上的不同會導致頁面顯示不同。
常見的IE8的兼容性。
文檔測試
國家有關計算機軟件產品開發文件編制指南中共有14種文件，可分為3大類。
開發文件：可行性研究報告、軟件需求說明書、數據要求說明書、概要設計說明書、詳細設計說明書、數據庫設計說明書、模塊開發卷宗。
用戶文件：用戶手冊、操作手冊，用戶文檔的作用：改善易安裝性；改善軟件的易學性與易用性；改善軟件可靠性；降低技術支持成本。
管理文件：項目開發計划、測試計划、測試分析報告、開發進度月報、項目開發總結報告。
在實際的測試中，最常見的就是用戶文件的測試，例如：手冊說明書等。
文檔測試關注的點：
文檔的術語
文檔的正確性
文檔的完整性
文檔的一致性
文檔的易用性
易用性測試（用戶體驗測試）
易用性（Useability）是交互的適應性、功能性和有效性的集中體現。又叫用戶體驗測試。
業務測試
業務測試是指：測試人員將系統的整個模塊串接起來運行、模擬真實用戶實際的工作流程。滿足用戶需求定義的功能來進行測試的過程。
界面測試
界面測試（簡稱UI測試)，測試用戶界面的功能模塊的布局是否合理、整體風格是否一致、各個控件的放置位置是否符合客戶使用習慣，此外還要測試界面操作便捷性、導航簡單易懂性，頁面元素的可用性，界面中文字是否正確，命名是否統一，頁面是否美觀，文字、圖片組合是否完美等。
安裝與卸載測試
安裝測試是指：測試程序的安裝、卸載。最典型的就是APP的安裝、卸載。
內存泄漏測試
內存泄漏的檢測：
1、對於不同的程序可以使用不同的方法來進行內存泄露的檢查，還可以使用一些專門的工具來進行內存問題的檢查，例如MemProof. AQTime、Purify、BundsChecker等。 有些開發工具本身就帶有內存問題檢查機制．要確保程序員在編寫程序和編譯程序的時候打開這些功能。
2、通過代碼掃描分析工具來檢查