拿去給用戶演示（幾個人），一切很完美。

但是當開始試運行時，500人，1000人，10000人用的時候，就是開始出問題了，要么響應很久后成功，要么直接失敗。

這就是忽略了對性能的要求。

性能的重要性不必細說，有些數據表明：近80%的用戶反饋應用響應時間慢、點擊沒反應等性能問題。

一般在公司里會有專門的測試人員對系統進行性能測試，而對于性能的標準，具體性能指標多少合適，測試同學是不清楚的。

這個時候就需要產品狗們提出性能要求，給測試同學作參考。

接下來我們說說性能需求咋提以及性能指標。

性能需求屬于非功能需求，一般在需求文檔內需要有單獨模塊對性能做說明。

在寫需求文檔的時候就可以把性能需求一起規定好，在需求評審時也要評審下性能需求，讓各方達成一致。

研發同學在做技術設計時考慮進來，避免在項目后期，出現重大性能問題。

測試同學在準備測試用例時，把性能也提前規劃進來，提前準備好測試方案。

另外性能測試也會占用一定的項目時間，需要在制定項目計劃時，把性能測試的時間也納入計劃中。

性能需求是指對系統性能進行規范化描述，提出明確、合理的性能指標要求。

主要分為2個方面：

1.系統整體性能需求

主要指標包括

在線用戶數數量：如支持在線用戶數200w

平穩運行時間：如7×24h

平均響應時間：如頁面打開時間低于2s。（對于一些主要頁面可以在做單獨性能要求）

CPU：CPU使用率＜75%

2.不同功能/接口性能需求

由于不同功能、不同接口的使用頻率、重要程度不同，我們可以對不同功能、不同接口單獨提出性能需求。

可以從下邊幾個標準來確定需要單獨明確的功能/接口

高頻：系統中高頻率使用的功能，高頻調用的接口，像刷動態

關鍵：系統中不能出現問題的功能，像登錄、注冊、支付

特色：系統中的亮點功能，產品的賣點，比如處方合理性審核系統、風險監控系統，還有像交友的在線匹配功能。

涉及大量數據：比如說報表查詢。

舉個“登錄”功能的例子：

并發用戶數500，響應時間2s，TPS到500/s，CPU不得超過75%。

下邊我們詳細說說性能指標以及性能指標的標準

主要有響應時間、并發數、吞吐量、CPU等，對于App需要關注FPS、啟動時間、耗電量等。

1. 響應時間——最直觀的表現

“系統應該讓用戶知道發生了什么，在適當的時間內做出適當的反饋?！蹦釥柹捎眯允瓌t——狀態可見性

在尼爾森可用性十原則中的“狀態可見性原則”提到的“適當的時間”就可以理解為響應時間。

站在用戶角度描述就是點擊一下按鈕，系統在頁面上給出反饋的時間。這個反饋時間是用戶最能直觀感受到的，也是對用戶體驗影響最大的地方。

當響應時間＞5秒后，74%的PC端用戶、50%以上的App用戶會選擇放棄操作，30%的用戶會選擇卸載應用，33%以上的用戶會轉身使用競品。

嚇人不？

我們接著看下響應時間的定義：提交請求和返回該請求的響應之間使用的時間。主要由網絡傳輸時間和業務處理、數據處理時間組成。

而對于產品來說，需要關注的是頁面響應時間，就算接口處理完成，數據傳到客戶端上了，在前端也需要解析出來，也會消耗一定時間。

響應時間多長才能滿足要求呢？

之前有個2-5-10原則，而現在隨著技術、硬件的更新換代，響應時間也有了1-3-5標準。

即1s內用戶完全可以接受，3s內用戶覺得還可以，5s用戶就會開始焦躁不安。

當然這只是個通用標準，不是個固定標準。我們在提出需求時，可以結合業務重要性、數據量大小、使用頻次來做綜合考慮。

舉個例子：導出excel報表。對于很多B端產品，這是個剛需、高頻的功能。

我們可以這樣提出性能要求：

1萬條數據，導出完成用時3s。

3萬條數據，導出完成用時5s。

10萬條數據，導出完成用時8s。

我從網上找到一些響應時間參考指標，大家可以看下：

互聯網企業：500毫秒以下，例如淘寶業務10毫秒左右。

金融企業：1秒以下為佳，部分復雜業務3秒以下。

保險企業：3秒以下為佳。

制造業：5秒以下為佳。

2. 并發用戶數——籠統也直觀的指標

并發用戶數的定義是每秒同時向服務器提交請求的用戶總數量。

關于并發用戶數有2個理解：

多個用戶同一時間做不同操作，比如多個用戶有發動態的，有刷動態的。

多個用戶同一時間做同一個操作，比如多個用戶一起發動態。

對于這2個理解，在性能需求上可以分開提，比如：

系統支持并發用戶數500

發布動態：支持300人并發發布動態。

有幾種并發用戶數評估方法，大家可以看下：

1）公式1：

n：平均每天的訪問用戶數。App可以直接用日活代替。

L：一天內用戶從登錄到退出的平均時間，可以理解為平均用戶使用時長。

T：考察時間長度，一天內多長時間有用戶在使用系統。

舉個例子:

App日活是10w，用戶平均使用時長是10min，用戶每天活躍時間大約是從早上10點到晚上10點。

公式里的n=10w，L=10min，T=12h

C=（10w×10min）/12h，時間單位統一成秒

C=（10w×10×60）/（12×3600）≈1388人/秒

峰值C’=1388×3×根號1388≈1500人/秒

提需求時可以以峰值并發用戶數為準

2）公式2：

C=（用戶總量/統計時間）*影響因子

影響因子一般為3

比如App的每天晚上8點-10點用戶最活躍，且活躍用戶有8w。

8w/2h×3≈33人/秒

3）公式3：

根據80~20原則：80%的請求在20%的時間內產生。然后結合PV一起算（注意不是UV，因為一個用UV產生多個PV）

比如1天的PV有100w

先算80%的PV：100w×80%=80w

20%的時間：24h×20%=4.8，換算出秒，就是4.8×3600=17280秒

并發數就是：80w/17280=46人/秒

如果是B端私有化部署的產品，一般使用人數比較固定，我們可以從企業人員數量做評估：用戶數量×比例，比例可以視具體情況而定，一般取8%-20%。

當然這些都是評估方法，得出的具體數據量只是做個參考。

3. 吞吐量——衡量系統處理能力的重要指標。

吞吐量是指單位時間內系統能處理的請求數量，體現著系統處理請求的能力。

吞吐量的量化指標有：TPS（每秒事務數）、QPS（每秒查詢數）

TPS：是指事務數/秒。一個事務是指服務器發送請求，服務器做出反應的過程。

整體過程就是：用戶做出操作>>請求服務器>>服務器處理>>服務器處理完成返回到用戶。

每秒能完成多少個流程就是多少個TPS

簡單理解：就是登錄一次算一個事務，每秒能完成2個登錄事務，就是2個TPS。

QPS：是指每秒查詢率。指一臺服務器每秒能夠響應的查詢次數。

QPS 基本類似于 TPS，不同的是：在完成一個事務時，會存在多次查詢服務器，所以應該是TPS≤QPS。

另外TPS、QPS響應時間與并發用戶數有關系，對應的公式是：

TPS=并發用戶數/平均響應時間。

當性能測試完，測試說500TPS，我們要有個大約概念，如果響應時間按1s算，那并發數就是500。

一般的標準有：

互聯網電子商務：10000TPS~100000TPS,例如天貓5萬TPS

互聯網中型網站：100TPS~500TPS

互聯網小型網站: 50TPS~100TPS

4. CPU

CPU指標主要指的CPU利用率。

程序在運行的時候，會使用CPU做處理計算。就會占用CPU的空間，如果占用過多，系統就會出現卡頓、無響應的情況。

CPU標準：

CPU＜20％的利用率為資源空閑

在20％～60％之間表示資源使用穩定

在60％～80％之間表示資源使用飽和

當＞75%時，就需要關注了。

對于web端，一般指服務器的CPU。而對于移動端，常指手機的CPU 。

App的CPU一般在20-40%，最多不能超過75%，如果長時間cpu利用率過高，就會產生發燙、閃退。

5. 內存

內存主要是運行處理CPU發出的指令，在內存里處理完畢后，再反饋給CPU。

在網絡上或者硬盤上加載的資源，一定會通過內存交換，可以理解為：頁面加載出來的圖片、文字會暫時存到內存里的，處理完成后就刪掉。

內存和CPU類似，資源都是有限的，如果占用過多，會出現卡頓或閃退的現象。

內存常內存使用率做為指標，一般＜70%。

6. 磁盤吞吐量

磁盤吞吐量是指單位時間內通過磁盤的數據量，主要是每秒的讀、寫請求大小。

一般用磁盤繁忙率來確定性能，磁盤繁忙率要＜70%。

這個指標了解即可。

7. 網絡吞吐量

是指有每秒有多少兆流量進出，一般情況下不能超過設備最大傳輸能力的70%。

這個指標了解即可。

8. 錯誤率

錯誤率=(失敗事務數/事務總數)*100%。

在一定并發下，循環調用某個接口，會出現接口報錯的情況。錯誤率正常情況下要為0。

在高并發的情況下錯誤率一般要低于0.6%，就是成功率要高于99.4%。

這個指標了解即可。

像CPU、內存、磁盤、網絡是指服務器的資源利用率，主要是對公司內部來說。

性能測試的同學對于這些指標的標準都很清楚，對于我們產品，需要明白這些定義與具體標準即可，性能需求提不提問題都不大。

1. FPS

FPS是指每秒顯示的幀數，主要用來體現出app的流暢度。

App的FPS一般＞24幀/秒，最好是60幀/秒。

FPS的越高并不意味著越流暢，FPS低也不意味著頁面卡。

還需要關注幀率的穩定性。如果一直都是低幀率，卡頓現象感受不明顯，如果幀率忽高忽低，就會有明顯的掉幀、卡頓現象。

對于游戲類app幀率要求較高，對于非游戲類app，我認為只要能保證沒有明顯的卡頓現象就可以了。

2. 耗電量

在App中，CPU處理、藍牙、定位、傳感器、GPU（圖形處理）都會加快耗電量。

對于不同的App單位時間耗電量是不同的，耗電量的標準可以通過對比得出：

與歷史版本間進行對比。如果新版本與上一個版本單位時間內耗電量相差過多，則需要優化。

與競品對比，如果比競品多了10%以上的耗電量，也需要優化。

3. App啟動時間

在說響應時間的時候，我們提到1-3-5原則，5s的時候用戶已經開始焦慮了。

而App的啟動時間，是用戶感知到的第一個時間段，直接影響用戶對App的首要體驗，第一次留不住，讓用戶再回來就更難了。

App的響應時間標準是最大不能超過5s。

如果啟動時間過長，該優化就優化。

當然也可以對于歷史版本與競品進行對比，看看自家App的水平在哪。像支付寶，啟動時間是秒開。

性能指標一般就以上這些，大家需要理解下。

一般性能測試同學在測試完成后，會給出對應的性能測試報告，我們可以通過解讀性能報告的內容來判斷是否需要優化性能。

在我的工作經歷中，很多時候會出現性能不達標的情況，如果性能需求不滿足，我們可以按照以下方式確定：

1. 重新分析指標合不合理

一般在評估時會對性能要求過高，需要重新定義性能指標再做判斷。

2. 判斷實際性能與性能需求是否相差太多

如果相差不大，可以先發版，延期處理性能問題。

如果相差太大，不能接受，就要與研發溝通，確定是否有優化方案、優化方案內容、優化是否會導致延期。

如果會引起延期，就要和領導反饋，以及同步各方。

性能問題歸根到底是技術問題，而為了達到更好的性能指標，達到最好的用戶體驗，我們也可以從產品設計上整點花樣。

采用tab頁的方式：同一個頁面數據過多時，使用tab頁分開加載。

分頁加載：一次加載10條/20條等。

盡量不采用全屏加載的方式，使用懶加載、預加載。

懶加載：比如圖片先展示縮略圖，然后點擊查看原圖。

預加載：提前把內容加載好，用戶進入到頁面時，可以直接看。有些app的開屏廣告就是提前預加載好，用戶下次點擊進入時可以直接觀看。

連接超時后進行情感化提示：設置超時時間10s，當超時后，通過有趣的方式提示用戶。

“欺騙”用戶：在頁面顯示操作成功，但是后端還在處理。微信發朋友圈時，就算在斷網的情況下也是可以發布出來，但是就自己能看到，等聯網后才能成功發布出來。

上邊的幾種方式雖然是和技術相關的，但是這些是直接影響產品用戶體驗，還是需要我們產品提出。

另外對于緩解用戶的焦慮感，可以使用有趣、好玩的加載動畫，分散用戶的注意力。

也可以采用進度條來體現系統處理的進度。對于處理時間確實很長的，給用戶個大約用時，讓用戶有個心理預期。

性能需求是個容易忽視，卻是非常重要的地方的。需依據不同的用戶基數和運營情況制定性能指標。