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