接上篇，簡單說說性能測試關注的性能指標，高手請飄過。。。
一，響應時間
可大致划分為呈現時間和服務端響應時間，真正用戶感受到的響應時間是這兩者之和，呈現時間：前端構成頁面所需的時間（前端響應時間），服務端響應時間：前端從請求發出開始到客戶端收到響應所消耗的時間（服務器端響應時間）。
二，並發用戶
從業務角度來看：指的是同一時間段內訪問系統的用戶數量，從服務端承受的壓力出發：指得是同時向客服端發出請求的客戶，體現的的是服務端承受的最大並發訪問數。
三，吞吐率
吞吐率直接體現軟件系統的性能承載能力，指：單位時間內系統處理的客戶請求的數量，一般來說，吞吐率用請求數/秒或頁面數/秒來衡量，許多性能測試工具生成的報告都會有。
注：吞吐量是指在一次性能測試過程中網絡上傳輸的數據量的總和，吞吐率=吞吐量/總時間（秒）
四，事務成功率/錯誤率
事務成功率和錯誤率，也存在於部分性能測試工具中，這個很好理解，指成功的事務或錯誤的事務與總事務的比，事務就是用戶進行的一個業務操作，取決於業務場景，可以自定義，一個事務中可能包含一個或多個請求。
五，思考時間
也稱為休眠時間，從業務的角度來說，該時間指：用戶在進行業務操作時，每個操作的間隔時間，也可以說每個請求之間的間隔時間，一般在測試腳本中體現。
六，系統資源
也許叫性能計數器更為合適，指：描述服務器或操作系統性能的一些數據指標。為了方便比較，引出了資源利用率：資源的實際使用/總的資源可用量，如在某某情況下，服務器的CPU占用率68%，內存占用率為55%等等，其中68%和55%就是資源利用率的數值。
理解上面這些，就可以深入理解用戶的實際需求了。
開始踩坑------------------------------------
當時我們最先接到的需求是元旦跨年的那天晚上，准備搞推廣活動，到時人數可能幾十萬的訪問量，運營要我們這邊測試下，要求程序不能崩潰（原始需求）。
可能處於需求不穩定期，老大也沒在意，先叫我們准備哈，因為這個小程序項目之前是外包的，平時流量不會很高，后端只有1個負責，測試也就我有點經驗，於是我們兩個就擼起袖子開搞了（也可以說兩個半灌水，照葫蘆畫瓢）
測試分析
1，因為是掃碼登錄，所以首當其沖的是登錄接口，所以登錄接口的並發量最大，而下單的轉化率低，下單的接口的並發量較低，但業務比較重要。
2，暫定對這兩個業務進行壓測
3，由於訪問並發量不好估算，所以先對服務器目前的性能做個評估
4，業務模型分析，據了解推廣活動99%用戶都是新用戶，線上用戶行為分析：100個用戶使用，下單率約25%
5，以可忍受的時間為3秒之內，來尋找最大並發用戶數
測試計划
1，編寫計划文檔，並估計排期（包括需求調研、測試方案、環境部署、腳本設計與執行、調優及報告等）
2，搭建測試環境，這里是提前申請的阿里雲ecs（深刻體會到一分一秒就是錢）
3，整理接口文檔（之前是外包的接口文檔，現在是僅供參考，尷尬）
4，測試工具的選擇（Jmeter和Nmon監控，阿里雲服務器其實自帶監控）
測試設計
1， 腳本接口設計
主要進行接口設計，如果接口文檔可用，就不用抓包錄制這些了，Jmeter的錄制真心不好用，如果接口不多，還是直接填快一些，這里目的是把登錄和下單接口調通。（如果接口存在簽名驗證，防篡改機制這些，可能需要花費點時間，為了應付我們接口的延簽規則，還花了很多時間寫了個生成簽名的jar包，Jmeter擴展使用，如果時間不夠，可以讓后端把這些驗證代碼關了）
2，腳本數據設計
接口調通后，需要對接口參數進行參數化分析，盡量模擬真實場景，比如登錄的用戶名密碼之類的，而微信小程序比較特殊，你要獲取部分用戶信息，需要有openid和unionid唯一標識，登錄流程如下（同一個用戶，在你的多個應用中，openid可能都不相同；但是，unionid一定會相同的，參考來自 https://www.jianshu.com/p/865f0679ba52）
真實場景：用戶微信登錄時，服務器會獲取登錄憑證（code）然后去請求微信，再把得到的openid返回給小程序，小程序使用該openid獲取用戶信息，並發送給服務保存，即完成了用戶的登錄注冊，而后面用戶下單也需要該openid。
模擬場景：首先我們不可能模擬微信登錄的，所以我們這樣設計，先給服務器一個假的登錄憑證（code）（可以寫死或者參數化都可以），然后服務器使用該code去微信申請openid，這里肯定會失敗，需要開發配合改下代碼，失敗也返回openid（這里最好隨機生成），然后小程序使用該openid再加上用戶信息（用戶信息最好參數化）發送給服務器保存，即模擬了用戶的登錄注冊，Jmeter工具需要關聯該openid，以便后面用戶下單使用到。
注：模擬場景的原則是與真實場景一致，不能達到一致時，也盡量別修改原來的代碼邏輯。這里也考慮過不請求微信接口，代碼直接隨機休眠多少時間，但由於請求微信接口的響應時間很快，而代碼隨機生成openid也快，就采用此簡單方案，當然更嚴格的也可以自己寫個類似微信接口返回openid等等，大家如果有更好的設計方案歡迎交流！
3，測試場景設計
上兩步基本完成了腳本設計，即多個用戶依次登錄下單是沒有問題的（Jmeter理解為單線程），可能包含參數化，斷言，關聯，自定義函數等技術（是不是和LoadRunner很像），其他等待時間，集合點，吞吐量控制器跟測試場景有關，可根據具體情況自行選擇。主要分三個場景：
基准測試場景：該場景的主要目的是獲取單個交易在無壓力的情況下的基准響應時間及環境資源使用情況，作為其他場景的參考依據。
例子：一般使用一個用戶或一個線程，延時設置為0，對一個交易持續運行10分鍾以上，類似下圖
單交易測試場景：單交易負載的場景是為了找到單個交易的最優TPS，檢測單交易在並發情況下是否存在性能瓶頸。
例子：分階段依次提高並發用戶或線程數，對一個交易持續運行5分鍾以上，這里退出方式沒有標明，一般與加載方式一致，類似下圖
混合交易測試場景：多交易混合負載的目的為了找到應用的最優TPS，一般指應用CPU資源消耗在70%左右時的TPS（此時需確保數據庫等其他被調用資源不成為瓶頸），此場景比較復雜，一般依據日常的業務流程占比與業務操作占比（基於線上日志和產品運營分析）。
例子：由於推廣活動主要為老用戶，且業務單一，業務流程這里主要分老用戶與新用戶流程（區別是新用戶會新增地址流程），業務操作占比：登錄55%，下單25%，那么場景類似如下
注：這三個場景主要體現的負載測試，其他容量測試（也叫壓力測試），穩定性測試等可在此場景基礎上延伸，部分參考：https://blog.csdn.net/chenqiuge1984/article/details/80129298。
測試執行與分析
1，執行前准備
確認測試數據已經准備好，已執行過測試后記得還原數據，這里使用的業務數據量跟線上保持一致；
確認腳本已經通過了調試，最好使參數化的數據都走過一遍，避免出現一些數據錯誤；
確認測試工具配置正確，禁用一些不必要的元件，比如Jmeter的聚合報告等等（Jmeter官方鼓勵非GUI方式運行）；
確認web等服務器已經“熱身"（可能服務器需要初始化一些東西）；
確認性能監控工具可用，可能需要提前上傳服務器，並設置好采集時間，阿里雲的ecs自帶資源監控。
2，執行場景
按照設計的場景分階段依次執行，如果存在多個負載機分布式加壓，需要關注各負載機節點的執行情況
執行工具時，最好負載機和服務器都不要運行其他軟件，避免干擾，還要關注下負載機的資源使用情況
注：Jmeter沒有loadrunner的IP欺騙功能，即同一台負載機發送的請求，IP地址是一樣的，如果服務器做了防刷機制，記得屏蔽掉
3，結果收集與分析
每次執行完畢后保存相應的執行結果與監控數據，並及時分析測試結果，以指導下一次場景設計。
如何分析測試結果？
其實Jmeter的聚合報告已經很明確告訴了吞吐量，響應時間等等，類似下圖
其中Samples指的是發出的取樣器請求數，Average是平均響應時間，Error是失敗的請求數占比，Throughput（這里指的是吞吐率）是指的每秒服務器處理的請求數，即一個用戶（等同Jmeter的一個線程）進行登錄業務，如果僅發送一個請求，那么該Throughput就是服務器能支持的每秒並發用戶數，如果該業務是發送兩個請求，那並發用戶數減半。
且最大並發用戶數 = 每秒並發用戶數 x 用戶可忍受時間 /單次業務的請求個數，按照上圖吞吐率66.9的QPS，最大並發用戶數= 66.9 x 3 /1 = 200.7個用戶,參考：https://www.cnblogs.com/jackei/archive/2006/11/20/565527.html。
如何找到最大的並發用戶數？我分了以下幾步（后面才發現Jmeter有個階梯型壓測插件，可以更快的找到系統的吞吐率）。
第一，聚合報告中Error數據得為0，即不能存在失敗請求。
例：可能設計的並發用戶增量數據不合適，比如100的線程數，服務器響應正常，然后500的線程數，服務器就開始報錯了。
解決：我們不能接受報錯，就需要根據實際情況，一要么減少線程數；二要么調整服務器配置，使請求都能成功
第二，服務器報錯的類型有很多，具體場景具體分析，這里的目標是配合開發使服務器配置或代碼調整為最優。
例：一般常見的是請求連接超時，基本都是請求太多，服務器處理不過來了。
解決：查看服務器資源使用情況，如果CPU、內存占用不高，那么需要配合開發調整配置或代碼，最終使同一測試場景下，報錯數最低。
第三，上兩步走下來，基本達到了最優配置，如果沒有Error數，可以逐步增大線程數，如果存在Error數，就逐步減少線程數
例：如果出現沒有Error數，但隨着線程數增加，Throughput只是緩慢增加，甚至反而減少的情況
解決：那么恭喜你，基本上最大的吞吐率就在這附近了，在最大Throughput和Throughput開始減少的線程數區間內逐步細分，找一個最好看的數字就是了，而最大並發用戶數 = Throughput / 用戶單個業務的請求數
注：你是不是有多問號！比如吞吐率跟線程數呈什么線性關系？網上說的吞吐量是啥？不設置集合點么？不用定義事務？多個業務怎么設計比例？等等問題，我們后面討論。
測試總結
雖然使用了這個笨辦法找到了最大並發用戶數（耗時耗力，又樂於其中），也算有個結論了，貼上測試過程與測試數據，做個測試報告就可以交差了，看起來做了很多工作，其實只是性能測試的冰山一角而已。。。而我自己摸索踩坑的日子也到此結束了
---------------------------------------------------------------------------------------未完待續-------------------------------------------------------------------------------
下篇說說如何與空降的外包性能測試團隊相處