本來想分成7篇來寫，但是又考慮看到情深處，還得翻頁，所以，索性合成一篇來寫。
在寫正文之前，先分享一個小故事：
人物：
小屌絲：測試經理
大佬：產品經理
小屌絲最近在做一個xx項目，項目馬上結項，大佬突然要求小屌絲做性能測試。
俗話說做項目，要有規範流程，也要有項目計劃。
小屌絲一臉懵逼，3秒後，小屌絲髮出4問~ ~
小屌絲：大佬，首先我們在項目初期評估，這個項目是不是不需要做性能測試，二來，客戶有沒有要性能報告，三來，合同有沒有提供軟硬件設備信息，性能期望值等信息，四來，我們是不是需要到客戶現場進行部署？
大佬：嗯…
小屌絲：那我們做性能測試，是爲了體現報告的完整性，還是爲了體現我們團隊牛叉？
大佬：我就是想要性能測試報告！
小屌絲：…
哎！ 長嘆一聲吧~ ~
言歸正傳，既然作爲一名專業性能測試工程師，一定要給出項目負責人/客戶最合理，最優的解決方案，千萬不要因爲她們的不瞭解，而嘲笑她們。
畢竟隔行如隔山~ ~ ~
接下來，跟着小魚，詳細的學習，如何搞性能！
小魚兒會讓你，從入門到放棄，就是一瞬間~ ~
一、測試流程
引用魯迅的話：無規矩不成方圓。
------魯迅表示沒說過這句話！
當然，我們性能測試，也需要有流程規範，而且符合項目管理流程，你說帥不帥~~
我們來瞅瞅這個流程規範
有了上面的流程圖，接下來，我們就來詳細介紹一下各個環節：
①業務學習：通過查看文檔，或通過實際操作來了解系統的功能。
②需求分析：分析系統非功能需求，劃定性能測試的範圍，瞭解系統性能指標。
③工作評估：工作量分解，評估工作量，計劃資源投入(人、日)。
④設計測試模型：劃定性能測試範圍後，把業務模型映射成測試模型。
聽到這句話，是不是一頭霧水？什麼是測試模型？
通俗的說，就是 ：性能測試用例設計+性能測試方案
用例只關注業務，模型還需關注如何實現，是否具有可操作性，可驗證性等，最後還得根據不同的測試目的，組合成測試場景。
⑤計劃編寫：計劃測試工作，在文檔中明確列出測試範圍、人力投入、持續時間、工作內容、風險評估、風險應對策略等。
⑥腳本開發：錄製或編寫性能腳本，開發測試擋板程序，開發測試程序。甚至如果沒有第三方工具，還需要開發測試第三方工具後程序。
>擋板程序：自己開發程序來替代第三方的支持
>>如：需要與航空系統進行交互，奈何航空公司不提供技術支持，我們就要自己開發程序替代。
⑦測試環境準備：性能測試環境包括服務器和負載機兩部分。
服務器：被測系統的運行平臺(軟件、硬件)
負載機：我們用來產生負載的機器，用來安裝負載工具，運行腳本的。
⑧測試數據準備：根據數據模型來準備被測系統的主數據和業務數據。
⑨測試執行：這一步是成敗的關鍵，因爲不同的人，設計場景以及測試執行上，所以結果可能還會有較大差異。
⑩缺陷管理：性能測試過程中發現的缺陷
⑪性能分析：性能測試結果可能暴露的問題進行分析，找出原因。
>>如何進行性能分析，請看小魚的這篇《性能分析流程》
⑫性能調優：這就需要協作，性能測試大佬與開發大佬一起來解決性能問題
>>如何進行性能調優，請看小魚的這篇《性能調優怎麼做》
⑬測試報告：對測試結果的總結。
>>常見性能指標包含：TPS、RT、CPU Using 等等
⑭報告評審：針對性能報告中的內容進行評審，確認問題，評估上線/交付風險。
二、成敗要素
小魚記得，在性能分析這篇文章說過：如果把項目的各個環節比作各個學科，那麼性能測試就是理綜，集成了需求、開發、測試、運維、協調溝通。
我們從以下幾點來說一下性能測試的幾大難點：
①需求分析
②場景設計
③性能診斷調優
④環境搭建和模擬
很多性能測試大佬由於在需求分析階段沒分析到位，不準確的預估用戶行爲，不能在場景上很好的模擬用戶操作，無法真實的模擬系統的負載情況，
最後的結果就是：在測試或者UAT環境運行的非常好，在上線後，就問題頻頻發生，結果可想而知。
就好比 ：
2008年的奧運會，
2012年11.11 某寶，
2012年11.11 某東，
2014年1月9日的12306，
2014年11月6日亞馬遜網站。
針對外行人，或者有些性能測試大佬，都以爲性能測試就是使用一個工具或者寫一個腳本，弄幾臺服務器，隨便"跑跑"，然後出一個報告，就ok了。
通常關注併發多少、響應時間多少、能不能跑通等等。
性能測試如果真的那麼簡單，還對得起從入門到放棄這幾個字嗎~~~
接下來我們來看一下，性能測試重要關注點有哪些：
1.評估系統，需求分析
在客戶沒有明確要求哪些值，
我們需要引導運維大佬和需求大佬給出具體的需求數據，並對數據進行二次分析，得出我們需要的信息。
針對初次上線的系統：我們需要用同行的數據，進行用戶行爲分析和商業數據結構的估算爲前提，來進行推算，來得到我們想要的性能需求。
針對已上線的系統：我們可以通過運維人員獲取TPS和時間的比例分佈圖、用戶數和時間的分佈圖、數據庫ER關係圖、容量數據等，直接精確的得出目前系統的用戶行爲和業務數據關係，進而得到我們想要的性能需求。
2.場景設計，用例設計
我們要儘可能的真是模擬線上系統的負載。
我們要決定哪些功能需要參與性能執行，參與方式怎樣？這就是用例設計。
如何有效的組織測試用例就是場景需做的事情，如，按業務分佈，業務量，業務時段，業務角色來綜合分配用戶數、執行時間、執行比例等。
這個場景設計、用例設計，花費的時間可不短。
3.測試執行，是否pass
模擬不同負載執行測試場景來識別系統弱點，做好各種監控，篩查各種問題，驗證系統穩定性等。
4.性能診斷優化
性能測試的大佬，需要具備良好的、敏銳的性能意識，能夠把問題細化(即分步分類)，協助各開發團隊完成問題定位，分析調優。
三、大佬看性能
由於性能是一門綜合學科，所以，我們就從不同的角度，來看看這些大佬對系統的要求有哪些：
1.黑盒測試大佬角度：
關心應用程序的單步響應時間，性能的好壞，就看應用的時間多少，即數據流經過服務器/服務器集羣經過網絡傳輸後往返時間總和。
2.開發大佬角度
①架構合理性
②數據庫設計合理性
③代碼
④系統裏內存使用方式
⑤系統裏線程使用方式
⑥系統資源是否有惡性，不合理競爭
3.運維大佬角度
①硬件資源利用率
②JVM
③DB
④系統是否支持7x24的服務
⑤擴展性，兼容性，最大容量，可能的瓶頸
4.性能測試大佬角度
①服務器硬件性能
②根據需求或歷史數據制定性能目標
③建立性能通過模型
④對開發代碼框架和硬件框架進行性能分析
⑤針對開發發佈版本進行基準測試
⑥執行軟件性能驗收及穩定性測試
⑦生產環境的配比和優化
⑧執行性能測試用例、場景設計
⑨協調部分之間的配合
⑩特定的性能分析
四、相關術語
1.負載：
模擬業務操作對服務器造成壓力的過程，比如2000個用戶進行下單操作。
2.性能測試(Performance Testing)：
模擬用戶負載來測試系統在負載情況下，系統的響應時間，吞吐量等指標是否滿足性能要求。
3.負載測試(Load Testing)
在一定軟硬件環境下，通過不斷價大負載(不同虛擬用戶數)來確定在滿足性能指標情況下能夠承受的最大用戶數。
>>這裏性能指標包含：TPS(每秒事務數)，RT(事務平均響應時間)，CPU Using(CPU使用率)，Mem Using(內存使用情況)等軟硬件指標。
4.配置測試(Configuration Testing)
爲了合理的調配資源，提高系統運行效率，通過測試手段來獲取，驗證，調整配置信息的過程。
5.壓力/強度測試(Stress Testing)
在一定軟硬件環境下，通過高負載的手段來使服務器的資源(強調的是服務器資源，硬件資源)處於一個極限狀態，測試系統在極限狀態下長時間運行是否穩定。
>>確定穩定的指標，包含：TPS(每秒事務數)，RT(事務平均響應時間)，CPU Using(CPU使用率)，Mem Using(內存使用情況)等。
6.穩定測試(Endurance Testing)
在一定軟硬件環境下，長時間運行一定負載，確定系統在滿足性能指標的前提下是否運行穩定。這裏強調一下，穩定性測試並不是在極限狀態下來運行的，這與上面第五條的壓力/強度測試 是不一樣的。
一般我們會在滿足性能要求的負載情況下加大到1.5 ~ 2倍的負載量進行測試。
7.TPS
每秒完成的事務數，通常指每秒成功的事務數，性能測試中重要的綜合性能指標。一個事務是一個業務度量單位。
舉個例子：
比如支付操作，在後臺系統可能會經歷會員系統，財務系統，支付系統，會計系統，銀行網關等，但是針對用戶來說，我就行知道我從下單到付款成功共花費多長時間。
8.RT/ART(Response Time/average Response Time)
響應時間/平均響應時間，指一個事務花費多長時間完成。我們更多的時候，是統計很多次響應時間，然後去平均值，這樣保證了時間的準確性，同時也更具代表性。
>>通常，我們寫RT，來代替ART。
9.PV(Page View)
每秒用戶訪問頁面的次數。
>>此參數是用來分析平均每秒有多少用戶來訪問頁面
10.Vuser(Virtual user)
虛擬用戶數。即模擬真實業務邏輯步驟的虛擬用戶，虛擬用戶模擬的操作步驟都被記錄在虛擬用戶腳本里。Vuser腳本用戶描述Vuser在場景中執行的操作。
11.併發：
併發最主要要有兩點：點層面上和線層面上。
①點層面上的：
例如：週一早上7:30半，小學生要統一到操場升國旗。
>>即：同一時間做某件事
②線層面上的：
例如：中午11:30-13:00，小學生有的跳皮筋，有的踢足球，但同時對服務器產生壓力。
>>即：一個時間段做不同的事
這裏不做過多介紹，詳細可以看小魚寫的這篇《常見併發問題》，裏面有對併發的詳細解讀。
12.場景(Scenario)
性能測試過程中爲了模擬真實用戶的業務處理過程，在LR中構建的基於事務、腳本、虛擬用戶、運行設置、運行計劃、監控、分析等一系類動作的集合，稱之爲性能測試場景。
>>場景中包含：待執行的腳本、腳本組、併發數、負載生成器、測試目標、測試執行時的配置條件等。
13.思考時間(Think Time)
模擬真實用戶在實際操作過程中停頓的時間間隔。
>>從業務角度來講：思考時間是用戶在操作時，每個請求之間的時間間隔；
>>從測試腳本來講：是兩個請求語句之間的時間間隔。
14.標準差(Std. Deviation)
根據數據統計的概念得來，標準差越小，說明波動越小，系統越穩定，反之，則說明系統不穩定。
>>包含：響應時間標準差，TPS標準差，Running Vuser標準差，Load標準差，CPU Using標準差等等。
五、性能工具
市面上的性能測試工具，還蠻多的，但是我們熟知，且使用最多的 JMeter 和Loadrunner這兩款，那麼，我們要怎麼選性能測試工具、市面上又有哪些性能測試工具呢？
彆着急，我們慢慢介紹。
1.如何選擇性能測試工具
我們在選擇工具的時候，無非從以下幾個方面來考慮：
①專業，穩定，高效。
②簡單易上手，在測試腳本上不需要花費太多時間。
③有技術支持，文檔健全。
④投入與產出比。
2.常見性能工具有哪些
①HP公司的 Loadrunner
②Apache JMeter
③Grinder
④CompuWare 公司的QALoad
⑤Microsoft 公司的WAS
⑥RadView公司的WebLoad
⑦IBM公司的RPT
⑧OPENSTA等
在這裏，小魚強調一下，性能測試的核心不是選擇什麼工具，而是性能分析，重要的是思想，實現方式，這與選擇什麼工具，並無太大關係，
所以一定要分析主次。
六、通過標準
判斷性能測試是否通過，不僅是看TPS，RT，而是要從服務端性能，前端性能，和用戶體驗性能來分析。
常見的測試通過標準如下：
七、小結
以上跟大家分享了，性能測試的基本情況，相信大家都能很好的理解並消化掉這些姿勢，不， 是知識。
性能測試，要求的很多，不僅僅要求專業技能，還需要的是溝通能力。
爲了能更好的學習掌握性能測試，還想需要各位大佬多從分析的角度來提升自己，畢竟，其的核心點就是性能分析。