在生活中，做任何事情之前，最好先確定一個目標。

同樣的，在我們日常做性能測試之前，最好把本次預期性能指標確定下來，沒有預期指標的衡量，將無法評估測試結果數據是否滿足預期。比如以下這樣的指標：

在實際工作中呢，最理想的情況是，開發/產品/項目經理已經提前確定好了性能指標，然後把指標明確的告訴你。

但是理想很豐滿，現實很骨感，根據我多年的性能測試經驗來看，大多數提性能需求的人，大多是不太懂性能的，所以根本不會有指標的，或者雖然有指標，但是是拍腦袋決定的，沒有任何依據。

所以作為一個測試人員，很有必要去通過一些數據分析，在測試之前就先明確一個相對科學的指標，這樣測試才會更加有價值。

一般來講，我們將壓測的項目分為兩類，一種是老項目，一種新項目。

先看看老項目，老項目是指項目已經上線了，並且已經運行了一段時間，這時候會產生一些歷史數據，可以通過以下手段對歷史數據進行分析

1、業務監控系統

在一些大廠，或者一些發展比較成熟的公司，大多都有各種各樣的業務監控系統，定期監控各業務模塊核心接口的調用量、平均耗時等等，一般是以分鐘級別做監控，如下圖

我們可以在系統裏查看過去一周（或者一個月）內，接口調用量最高的那一天，然後再找到當天中接口調用量最高的時間點（分鐘級別），比如說是在12:10調用量為10000，那麽我們再換算為每秒調用量10000/60=166，因此可以確定這個接口tps只要達到166即可滿足。

2、日誌

有的公司（大多數都是創業型公司）根本沒有上述的業務監控系統，那有沒有辦法去評估預期指標呢。

方法也是有的，那就是通過中間件的日誌，每個中間件都有訪問日誌。比如Nginx的access.log，該日誌中詳細記錄了每個HTTP請求的訪問時間、url、響應狀態碼、響應時間等，如下圖

有了這些數據就好說了，我們可以通過一些腳本（自己編寫或者找運維幫忙），統計出每個接口在哪個時間段調用最高，調用量峰值是多少。根據峰值數據，最終可以計算出每秒的調用量，然後可以將這個指標定為接口的預期TPS。

接下來我們重點說一下新項目，也是在實際工作中遇到最多的情況。

新項目是還沒有上線，在上線前希望先進行一輪壓測，評估項目性能是否能支撐當前的用戶，這個時候性能預期指標更為重要。但是由於是新項目，線上並沒有任何的歷史監控數據和日誌數據，所以之前介紹的方法就不再適用，這個時候需要使用另外一種方法來評估性能指標，那就是“二八定律”。

什麽是二八定律？先來看一下定義：

二八定律又名80/20定律、帕累托法則（Pareto‘s principle）也叫巴萊特定律、朱倫法則（Juran‘s Principle）、關鍵少數法則（Vital FeRule）、不重要多數法則（Trivial Many Rule）最省力的法則、不平衡原則等，被廣泛應用於社會學及企業管理學等。

二八定律是19世紀末20世紀初意大利經濟學家帕累托發現的。他認為，在任何一種事物中，最重要的只占其中一小部分，約20%，其余80%盡管是多數，卻是次要的。

從經濟學上看，世界上80%的財富，都集中的20%的人手裏

從心理學來說，人類80%的智慧，都集中在20%人身上

二八定律是一種社會準則，符合大多數社會現象的規律。同樣也適用於互聯網領域。

一個網站有成千上萬的用戶，但是80%的用戶請求是發生在20%的時間內，比如大家去網上購物，基本也都集中在中午休息或晚上下班後。二八定律的核心原則是關註重要部分，忽略次要部分。系統性能如果能支撐發生在20%時間內的高並發請求，必然也能支持非高峰期的訪問。

具體來說下怎麽通過二八定律來計算預期指標。

首先先預估系統的每日總請求數，這個沒有固定的方法，如果沒有任何歷史數據參考，一般是通過用戶量或者其他關聯系統來評估。

比如某網站新增了一個每日簽到送積分功能，由於還沒有上線，所以沒有簽到的數據。網站的註冊用戶1000w，日活躍用戶大概是100w左右，那麽最極端情況下，這100w人都會來簽到（實際肯定不會這麽多人來簽到，但是評估指標要盡量往高評，以免出現極端情況），那麽每天大概有100w次簽到請求，80%的請求數就是100w*0.8=80w。

其次確定系統的20%時間，大多數系統是24小時對外提供服務的（也有一些系統，比如政府類的項目，是在一天的某個時間段提供服務的）。但是大多數系統在0點-6點之間訪問量很少，從一天的總訪問量來看，可以忽略不計。所以統計時間的時候，可以把這段時間去掉，一天24小時去掉這6個小時，還剩下18個小時，那20%的時間=18小時*3600秒*0.2=12960秒。

最終計算出來的結果為80w請求/12960秒=61左右。也就是說接口TPS滿足61即可。

但是也需要考慮一個問題，因為上面的用戶請求是按照100w評估，也有可能推出這個活動後，每日會有超過100w的用戶來簽到。簽到業務每個用戶只能執行一次，如果是其他業務，可能會有多次操作。所以評估出來指標後，為了更加保險一些，最好再乘以一個冗余系數，提高預期指標，防止人為評估造成預期指標偏低的情況。

這個冗余系數一般定為2-5之間（個人經驗），上面計算出來的tps指標為61，如果再乘以一個冗余系數3，那麽最終tps指標就定為183。同時，將來項目上線後，可以通過對項目接口的峰值監控，來對比之前評估的算法結果，調整冗余系數，最終隨著不斷的數據積累，將會形成一套本項目的性能模型。

那麽將來項目上線後，接口的訪問量真的和計算的一模一樣嗎？這個肯定不會，大家一定得知道一個原則，性能測試從來都不是一門非常精確的技術。二八定律也並不是100%適用於所有業務場景。在沒有任何歷史數據參考的背景下，二八定律相對來說是一種相對來說靠譜的算法，最起碼有一定的理論依據，比拍腦袋猜的值靠譜多了。

總結一下，二八定律的算法為 80%的請求 / 20%的時間 * 冗余系數

看了上面一大堆分析，有的朋友可能又說了，別整這些有的沒的，我們公司的項目就是啥都沒有，三無產品，沒有業務監控、沒有中間件日誌，也沒有日活數據，那怎麽評估預期指標。

對於這樣的系統和公司，我的建議是，可以不要管什麽指標了，直接開始測試，測試完成後，把本次測試數據發送給相關人員，然後大家召開會議會結果進行討論，最終由領導來拍板決定系統性能是否滿足需求。

二八定律在性能測試中的應用