本文從技術角度制定性能測試實施過程中關鍵的技術規范。這些規范可以幫助PTS的用戶更好地從技術上來規避系統上線后的風險、評估線上系統的真實能力、根據業務模型摸底線上能力以提前應對。
適用范圍
適用于所有需要性能測試的項目。 對性能測試實施過程中非常重要、關鍵的相關技術進行分析，主要包括：系統環境、測試指標、業務模型、數據量、測試模型、測試類型、腳本（API）、場景、監控、瓶頸分析、調優和性能測試分布式云化壓測工具。
系統環境
分析
系統環境分為生產環境、測試環境等。兩個環境的方案各有其優缺點，生產環境衡量的精準度較高，參考效果更好，但是需要清理相關的測試數據（同時要保證數據刪除的完整性，基礎數據的構造參考后續數據量部分）或者BI統計的時候過濾，或者更徹底的方案是參考阿里全鏈路壓測方式，生產環境的壓測盡量挑選在低峰期進行，避免對生產業務造成影響；單獨的測試環境風險可控，難點在環境的構建上，規模和生產一致的成本也是較高的，所以一般而言有通過等比構建（1/2，1/4，1/8等），甚至是生產環境中部分應用獨立部署測試集群，數據庫共用的方式，此外測試環境需要從生產環境中導入脫敏的基礎數據，例如至少是最近半年或者1年的，保持其整體的數據關聯性，這個對于壓測的準確度和參考性也很重要。
風險
測試環境的風險主要體現在跟生產的差異度，測試結果的參考價值會打一定程度的折扣，可以視自身情況選擇合理的方式，例如看重入口網絡的檢驗的，可以測試環境和生產環境共享入口。 對測試環境系統平臺、中間件、數據庫等不熟悉和不了解，也會導致瓶頸不易分析、不易調優。
規范
測試環境搭建
在熟知以上問題的前提下，測試環境搭建應盡量滿足如下規范：
測試環境架構與生產環境架構完全相同。
測試環境機型與生產環境機型盡量相同，云化的資源確保是同規格ECS或者容器。
測試環境軟件版本與生產環境軟件版本完全相同，版本主要包括：操作系統、中間件相關、數據庫、應用等。
測試環境參數配置與生產環境完全相同，參數主要包括：操作系統參數、中間件參數、數據庫參數、應用參數。
測試環境基礎數據量與生產環境基礎數據量需在同一個數量級上。
只能減少測試環境機器臺數，并且需要同比例縮小，而不能只減少某一層的機器臺數。
理想的測試環境配置是生產環境的1/2，1/4。
測試環境調研
測試環境調研，需要調研如下內容：
系統架構：系統如何組成的，每一層功能是做什么的，與生產環境有多大差異，主要為后面進行瓶頸分析服務和生產環境性能評估，這個很重要。
操作系統平臺：操作系統是哪種平臺，進行工具監控。
中間件：哪種中間件，進行工具監控和瓶頸定位。
數據庫：哪種數據庫，進行工具監控和瓶頸定位。
應用：啟動多少個實例，啟動參數是多少，進行問題查找和瓶頸定位。
可以配合APM工具（如ARMS）進行中間件、數據庫、應用層面的問題定位。
測試指標
分析
測試指標一般分為業務指標、資源指標、應用指標、前端指標。
業務指標：如并發用戶數、TPS（系統每秒處理事務數）、成功率、響應時間。
資源指標：如CPU資源利用率、內存利用率、I/O、內核參數（信號量、打開文件數）等。
應用指標：如空閑線程數、數據庫連接數、GC/FULL GC次數、函數耗時等。
前端指標：如頁面加載時間、網絡時間（DNS、連接時間、傳輸時間等）。
風險
不同用戶對指標類型和期望值是不一樣的，需要提前針對不同角色的人員進行指標調研、設定閾值，測試出系統在閾值下的性能，瓶頸定位及調優。若您未提前關注測試指標，可能會導致測試結果不是相關人員需要的，結果是無效的。
規范
業務指標
業務響應時間（Response Time）：這個指標所有相關人員都明白其含義，業務部門更需要此指標的具體值，一般情況下，不同系統的業務響應時間期望值是不同的，建議１秒以內。像淘寶系統業務RT基本在幾十毫秒以內。
業務處理能力（Transaction Per Second）：具體指標為TPS（Transaction Per Second，即系統每秒處理事務數），這個指標是衡量系統的處理能力的一個非常重要的指標。TPS可以參照同行業系統和結合具體業務，中小企業TPS值為50~1000筆/秒，銀行TPS值為1000~50000筆/秒，淘寶TPS值為30000~300000筆/秒。
成功率：這個指標是衡量系統處于壓力下，業務的成功率，一般業界成功率要大于99.6%。
資源指標
一般情況下，系統資源指標也不能超過瓶頸值，例如CPU資源利用率≤75%，內存無SWAP，磁盤和網絡I/O不能自動處理。理想的情況下，當系統壓力上不去的時候，資源成為瓶頸（正常情況下，非其他瓶頸情況下導致），這樣的話加資源，系統處理能力還會上升的，但是遺憾的是，很多系統性能測試資源都沒達到瓶頸的時候，壓力就上不去了。
業務模型
分析
系統有很多業務，每種業務邏輯和業務量是不一樣的，消耗系統的資源也不一樣，因此業務種類、業務占比決定了系統的處理能力，業務模型在性能測試中起著關鍵性的作用。以電商場景為例，不同的促銷形式和主推的類目決定了不同的容量整體配比，那么精準地將流量落地在PTS上進行壓測拿到系統的木桶最短板可以更好的利用機器資源達到業務目的。
風險
業務模型中業務和占比選取不對，跟生產差異非常大，直接導致測試結果沒有任何參考價值，并且容易誤導對系統處理能力的判斷。 有些業務的業務量雖然占比很低，但一旦突變，對系統也是致命的，這些業務在性能測試中也需要關注。
規范
系統中的典型業務如何選取一般情況下遵循的規則是選取業務量高的、經常使用的、有風險的、未來有增長趨勢的業務作為系統的典型業務。已經上線的系統可以通過高峰時段歷史業務量和生產問題性能來評估，對于即將上線的系統可以通過調研和單交易資源消耗的結果來評估。
已上線系統
搜集生產上不同高峰時間段的業務種類和業務量，每個時間段的業務種類和業務量是否有很大的差異，如有的話，必須有多個業務模型，差異不大的，可以只用一個業務模型。
搜集生產上高峰時間段資源消耗和資源異常的時間點，從中捕獲資源消耗高和異常的原因，可能是由于某種”不起眼”的業務導致。
搜集生產問題，進行分析，如果是由于某種業務導致而且以前性能測試的時候忽略此筆業務，那么這筆業務的風險是非常大的，需要后續性能測試將此業務加入到業務模型中。
未上線系統
通過調研，確定業務種類和業務占比。
通過調研，確定是否在業務促銷等活動中，某些業務有突變的可能。
通過測試結果，確定每筆業務的資源消耗，如果某些業務雖然占比低，但資源消耗非常大，那么需要適當的調整此業務占比。
數據量
分析
數據量主要包括基礎數據量（或者叫歷史數據量、墊底數據量、數據庫中已有的數據量）和參數化數據量，數據量在性能測試中起到非常重要的作用。 對于在數據庫中只有幾條記錄和有幾億條記錄里面查詢信息，那么結果肯定相差非常大的。隨著業務量的增長，記錄也越來越多，因此使用性能測試環境時，需要保持跟生產上相同級別的數據量。如果采用在生產環境中插入測試賬戶的方式，可以一定程度解決環境真實性和基礎數據量同量級的問題。 阿里全鏈路壓測的方式對于基礎數據量的要求和上述類似。 然后，我們在測試的時候需要考慮參數數據量的大小和數據分布的問題。
風險
如果基礎數據量跟生產環境的基礎數據量不在同一個數量級上，將會導致相關指標例如響應時間比生產上快很多，不真實，甚至導致測試結果沒有參考意義。 如果參數化數據量過少、未考慮數據分布的情況，將會導致測試結果不真實，甚至測試結果沒有參考意義。 生產環境中插入測試賬戶的方式，需要考慮數據準備的完整性問題，還有清理的邏輯需要完整。 全鏈路壓測的方式需要投入較大的改造成本，同時包括后續的持續迭代維護。
規范
基礎數據量
如果是測試環境，基礎數據量需要跟生產環境基礎數據量保持在同一個數據量級上，一般情況下需要考慮未來三年數據量增長趨勢，如果增長過快需要在測試環境造非常多的數據。
參數化數據量
參數化數據量盡可能的多，必要的情況下，可以清除緩存或者用寫代碼的方式提供參數化。
參數化數據分布，如果業務有明顯的地域等分布的特征，需要考慮數據分布的情況。
測試模型
分析
測試模型是在業務模型的基礎上演變而來的，一般情況測試模型和業務模型是相同的，但是由于某種業務無法模擬或者安全原因，需要去掉此筆業務，重新計算占比得出。
風險
參照5業務模型風險。
去掉的業務如果有風險，那么需評估此筆業務的風險，風險大的情況下，需采取其他解決方案。
規范
參照5業務模型規范。
測試類型
分析
測試類型主要分為負載測試、壓力測試，其中包括單交易基準測試、負載測試、壓力測試、混合交易負載測試（容量測試）、業務突變測試、混合交易穩定性測試、混合交易可靠性測試、批量測試、批量測試對混合交易影響測試等。 每種測試類型針對不同的目的，可以根據生產系統現實情況進行選擇。
風險
缺少某種測試類型，將會導致現實生產系統某種場景沒有測到，發生風險，例如：系統崩潰、響應時間慢等。
規范
如果時間充足，建議大部分測試類型都需要測試一下，也可以參考以下規范：
單交易基準測試：可選
單交易負載測試：可選，未上線系統建議做負載，看資源消耗
混合交易負載測試（容量測試）：必須
混合交易壓力測試：可選
業務突變測試：可選
混合交易穩定性測試：必須
混合交易可靠性測試：可選
批量測試：可選
批量測試對混合交易影響測試：可選
串聯鏈路
場景
分析
（壓測）場景是若干個基于HTTP/HTTPS的URL/API的組合，用于模擬現實生產環境中業務場景，包括施壓模式、壓力遞增方式、運行時間等。 場景模擬需要跟生產上場景相一致，特別是在一段時間內，測試出來的各業務TPS占比跟生產上高峰時候業務占比一致。
風險
場景的風險主要體現在測試出來的業務TPS占比需跟生產上業務占比一致，在業務比例偏離嚴重的情況下，將會導致測試結果不真實或者無效，不能反映生產上的業務場景。
規范
測試結果中各業務TPS占比需跟生產上業務占比（業務模型）相一致，可以使用PTS特有的RPS模式（Request Per Second，直接測試吞吐能力）來保證一致。 例如：A和B兩筆業務，占比為1:4，響應時間分別為1ms、100ms，那么只需要通過PTS給A和B兩個接口按照1:4比例設置請求數（RPS）施壓即可。如果使用傳統的并發模式，A和B的并發需要經過換算確保比例是1:400，使得最終與生產上保持一致的業務模型。
監控
分析
監控的目的主要是為進行性能測試分析服務的，完善的對系統進行監控，針對瓶頸定位起到”事半功倍”的效果。 一般來說，需要針對操作系統、中間件、數據庫、應用等進行監控，每種類型的監控盡量指標全面。
風險
沒有完善的系統監控，將會導致性能分析無從下手，定位不出系統瓶頸，根本不知道從哪進行調優。
規范
操作系統：CPU（User、Sys、Wait、Idle）利用率、內存利用率（包括Swap）、磁盤I/O、網絡I/O、內核參數等。
中間件：線程池、JDBC連接池、JVM（GC/FULL GC/堆大小）。
數據庫：效率低下SQL、鎖、緩存、會話、進程數等。
應用：方法耗時、同步與異步、緩沖、緩存。
瓶頸分析
分析
瓶頸定位的目的是對系統中存在的瓶頸點進行分析，為調優做準備，系統的性能瓶頸點主要分布在操作系統資源、中間件參數配置、數據庫問題以及應用算法上，對于有針對性的進行調優，有利于系統性能的提升。
風險
當系統的瓶頸點不能被分析出來以后，新業務上線或者核心業務就存在風險，這種風險有可能導致業務高峰的時候，系統性能體驗差，甚至“崩潰”。
規范
分析系統的瓶頸點遵循的規則如下：
操作系統資源消耗：CPU、Memory、Disk I/O、Network I/O。
中間件指標：線程池（Thread Pool）、數據庫連接池（JDBC）、JVM（GC/FULL GC/堆大小）。
數據庫指標：效率低下SQL、鎖等待/死鎖、緩存命中率、會話、進程等。
應用：方法耗時、算法、同步和異步、緩存、緩沖。
壓力機：壓力機資源消耗，一般情況下，壓力機成為瓶頸的可能性非常低。PTS壓力機有保護和調度機制不用單獨關注。
調優
分析
調優的目的是提升系統的性能，針對系統的“瓶頸點”對癥“下藥”，通過測試驗證系統的性能有多大的提升。
風險
未進行調優的系統，系統上線后，可能會出現客戶體驗差的效果，甚至導致系統“崩潰”的風險。
規范
系統調優遵循的規則如下：
中間件調優：線程池、數據庫連接池、JVM。
數據庫調優：效率低下SQL、死鎖和鎖等待、緩存命中率，進程和會話參數。
應用調優：方法耗時、算法、同步和異步、緩存、緩沖。
系統資源：一般情況下，系統資源（例如CPU等）大部分是由應用和參數設置不合理導致的，并非系統資源不夠。
性能測試分布式云化壓測工具
簡介
性能測試服務（Performance Test Service，簡稱PTS）是Web化的卓越SaaS性能測試平臺，具備強大的分布式壓測能力，可模擬海量用戶的真實業務場景。
PTS基于單鏈路或全鏈路壓測平臺。該平臺對內除了支持日常的外部流量壓測之外，同時支持了各種大促活動，如天貓雙11、雙12和年貨節等。PTS的壓力發起來源是遍布全國上百個城市和各運營商的CDN節點，相比業界產品的云主機發起更快速，來源更廣泛，脈沖能力和流量掌控能力更強。PTS在功能上強調頁面可視化編排，倡導無需編碼的復雜交互式壓測，RPS壓測模式，實時調控實時生效的調速能力均優于業界。
PTS目標是將性能壓測本身的工作持續簡化，使您可以將更多的精力回歸到關注業務和性能問題本身。通過PTS可以用較低的人力、資源成本構造最接近真實業務場景的復雜交互式流量，快速衡量系統的業務性能狀況，為性能問題定位、容量配比、全鏈路壓測的流量構造提供更好的幫助，進而提升用戶體驗，促進業務發展，最大程度實現企業的商業價值。
功能
壓測場景構建
支持有序串行和并行編排壓測的API，參數化上支持數據文件、系統函數、字符串和出參彼此之間的組合，對cookie支持非常友好，還有豐富的指令擴展場景的仿真度。調試功能可以便捷地進行復雜場景的數據流向的校驗。
相應的資源包配套有極易上手的云端錄制，非常便于移動端的請求抓取和到壓測場景中的一鍵導入。
壓測流量控制
支持并發和RPS模式，分鐘內快速啟動壓測。極低的誤差，同時支持自動和純手動模式，壓測流量的調整秒級生效，支持千萬的流量瞬時脈沖，多重機制確保壓測流量及時停止。
監控和壓測報告
陸續豐富中的監控指標，實時監控和報告中包括但不局限于各API的并發、TPS、響應時間和采樣的日志，請求和響應時間還有不同的細分數據，其他監控能力陸續集成中。
優勢
穩定可靠
基于單鏈路或全鏈路壓測平臺，技術穩定性更高。
支持行業廣泛，涉及電商、多媒體、金融保險、物流快遞、廣告營銷、社交等等。
功能強大
全SaaS化形態，無需額外安裝和部署。
覆蓋主流瀏覽器的錄制插件。
數據工廠功能，簡單編碼實現壓測的API、URL的請求參數格式化。
復雜場景的全可視化編排，支持登錄態共享、參數傳遞、業務斷言，同時可擴展的指令功能支持多形態的思考時間、流量蓄洪等。
支持RPS、并發等多種壓測模式。
流量支持動態秒級調整，百萬QPS亦可瞬時脈沖。
強大的報表功能，將壓測客戶端的實時數據做多維度細分展示和統計，同時自動生成報告供事后查閱。
壓測API、場景均可調試，壓測過程提供日志明細查詢。
流量真實
流量來源于全國上百城市覆蓋各運營商（可拓展至海外），真實模擬最終用戶的流量來源，相應的報表、數據更接近用戶真實體感。
施壓能力強，支持較高RPS的壓測流量。
配套完善
除了壓測平臺之外，可付費增值提供全鏈路壓測解決方案輸出，全方位保障站點平穩應對業務峰值。