本文從技術角度制定效能測試實施過程中關鍵技術規範。這些規範可以協助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的壓測流量。