進擊吧性能QA！

文 | 安和

網易智企資深性能測試工程師

一般在軟件產品的研發流程中，性能QA處於被動輸出的位置，研發人員提性能需求，性能QA執行，常見流程圖以下：

這種工做模式可能出現2種場景：

1. 性能QA被需求淹沒，疲於需求執行，但產品性能質量提高程度和頭禿程度徹底不成正比。
2. 需求愈來愈少，性能QA時刻面臨的一個問題：嚇！要失業了嗎？

在某些產品中，這是個尷尬的狀況：生產環境10天半個月都沒有性能問題；業務需求愈來愈穩定，性能需求減小；用戶流量增加趨勢緩慢，暫無穩定性風險。沒有性能需求，性能QA還有必要存在嗎？

若是你是性能QA，若是你出如今如上場景中，也許你須要捫心自問：

我能作的只有執行嗎？

我只能作到這種程度嗎？

個人價值應該體如今哪裏？

問題由現象而來，

但思考能夠從根源出發

換個角度，上面的三個問題能夠整合爲一個問題：我還能爲產品多作些什麼？

性能QA的本職工做毋庸置疑是保證產品的性能質量知足用戶使用需求，咱們的思考能夠從這個根源展開，試試拆解來看。

這句話有幾個關鍵詞：產品、性能質量、知足用戶。

一、 產品

產品是核心，性能QA的全部活動都要圍繞具體產品研發過程展開，對產品勢必要有必定了解，包括但不限於這是什麼產品、有什麼業務功能及特色、用戶羣體的行爲模式、產品部署的總體架構等等。

瞭解產品有什麼用？

• 產品的業務功能特色：提煉關注重點；（工做優先級）
• 產品的用戶行爲：提煉測試場景、測試類型、測試目標；（結果有效性）
• 產品的架構特色：提煉測試模式及可能瓶頸點；（結果有效性及測試充分性）
• 產品的研發流程：提煉重要的流程節點；（測試充分性）

在產品研發過程當中，性能QA應該處於什麼位置？

如開篇所示的流程中，性能QA是做爲質量保障的最後一道門檻，處於後方守衛的位置。該位置的缺點是一般被動接受研發人員提出的性能需求。

假設不一樣產品是不一樣場地，研發人員是球員，性能QA是守門員，球門線是性能質量及格線，球員要作的是用正確的姿式踢球入門，守門員要作的是把不符合條件的球擋在門外。

若是球員不瞭解規則，能不能踢進，全靠球員自由發揮；若是多個球員從不一樣的角度用不一樣的腳法同時射球，能不能擋住爛球，全靠守門員自由發揮。

那麼有2個問題急需解決：

1. 如何提升好球的進球率，即代碼質量提高，好比減小重複問題的出現；
2. 如何提升爛球的攔截率，即bug的篩查，好比增長驗證及監控手段；

當性能QA開始思考這個問題，已經邁出了突破思惟模式侷限性的一步，不只僅是性能需求的執行者，而是球場上的規則制定者。也能夠這樣說：不想當教練的守門員不是好QA。

此時或許能夠基於不一樣產品的特色總結出進球指南， 好比：

1. A產品的用戶對歷史數據的查詢分析較多（用戶行爲模式），大量的循環操做可能會帶來較大的性能開銷；
2. B產品的外部調用較多（業務特色），大量的同步請求操做可能會阻塞系統的正常請求處理；
3. C產品的調用層級較複雜（架構特色），下游異常時系統反應可能會不可預知，須要提早作故障演練；

二、性能質量

保證性能質量必須基於產品來實施。

如開篇所示的流程只能被稱爲性能測試，輸出的內容只是某個性能需求的性能質量，當咱們習慣從更多的角度瞭解產品，並擺正了本身的位置後，可以更清楚的瞭解到保證性能質量不只僅依靠性能測試執行，而應該是多視角多維度的。

嘗試把保證性能質量看做一個服務性質的產品，首先須要明確如下幾點：

一、什麼是性能質量？

經過量化指標判斷性能知足用戶使用需求的程度。在軟件質量模型中，性能屬於效率，效率不是非黑即白，那麼對性能質量的評估，除了基線外，趨勢對比一樣重要。

二、目標用戶

研發團隊/產品負責人：直接用戶；

軟件產品的使用羣體：最終用戶；

三、 目標用戶的需求

• 產品負責人：可以支撐多少用戶順滑且穩定的使用；是否存在潛在風險以及如何規避等。
• 研發人員開發：架構設計是否合理；代碼是否存在不合理的資源佔用/資源競爭等。
• 軟件產品的使用羣體：軟件是否操做順滑且狀態穩定，一直順滑一直爽；

四、提供什麼樣的服務

基於如上的目標用戶及用戶需求，性能QA提供的服務應該具有如下幾個特色：

1） 基線和對比

2） 兼顧局部性能、系統性能、業務場景性能及服務穩定性；

3） 可以規避風險、預知風險、評估風險；

4） 及時跟蹤用戶體驗；

即從多視角出發，推進性能活動介入到產品整個生命週期中，提供全方位的支撐，能夠稱爲性能質量保障或非功能質量保障。性能質量保障並不等同於性能測試，性能測試是指一類測試行爲，而性能質量保障是一系列行爲活動的集合，其中包括性能測試執行。

三、 知足用戶

是否知足，對不一樣產品可能會有不一樣判斷標準，一般在用戶正常使用過程當中，50ms和500ms的差異很難有明顯感覺，可是「不知足」都有類似表現，好比說頁面加載失敗、用戶操做無響應等（非功能上的異常）。

性能QA須要作的除了驗證「知足」，更要保證「不知足」的狀況可以不發生或者可以及時補救，保證產品可以保持穩定的性能表現。若是功能是指「作的對」，性能是指「作的快」，穩定就是指「作的好」。

但研發過程是不斷產生「不知足」風險的過程，性能QA怎麼規避風險呢？

首先來分析一下研發過程當中，哪些階段可能會產生風險以及產生的緣由，以一個簡單的流程圖爲例：

性能QA能夠作什麼：

1） 人爲因素：減小人爲因素的干擾；在研發階段卡點評估風險。

2） 客觀因素：預案管理、提早演練

思路有了，

還怕不知道作什麼嗎？

彙總上述章節的思路，當性能QA思考「我能夠爲產品多作些什麼」的時候，能夠從這幾個方向入手：

1）從熟知產品出發，轉換視角

2）嘗試多總結多輸出，轉換角色

3）擴展關注產品性能表現的角度和深度

4）從多方位規避風險

5）及時跟進用戶體驗

嘗試列出腦圖：

從這些思考中能夠大體整理出工做規劃的幾個方向：

1） 版本迭代性能需求

由研發或業務QA提出的性能測試需求，主要用於發現新功能的性能問題、處理瓶頸以及性能影響範圍。

2） 版本回歸

線下全鏈路壓測，用於對比歷史版本的性能表現，關注是否存在性能降低、資源佔有異常等性能風險。

3） 線上全鏈路壓測

線上容量評估，爲服務擴容和線上容量規劃提供參考數據。

4） 核心模塊摸底

對核心模塊的核心接口進行性能摸底，關注該模塊核心接口的性能表現及性能瓶頸。

5） 故障演練&服務治理

單模塊或全鏈路的故障演練，根據故障用例和故障恢復預案，模擬真實故障狀況的演習。目的是服務治理、預案驗證，即驗證系統的故障恢復能力，是有效預防系統失控的手段。

6） 非功能質量線上巡檢

關注線上性能表現及資源使用狀況。

7） 賦能

旨在加強研發團隊對於產品性能的意識及主觀能動性，提升研發效能。

當咱們清楚能夠作什麼後，接下來是如何作、如何作的更好、如何評估、如何持續作，本文不作展開。

總結

在軟件產品開發這個行業裏，性能質量的範圍很是龐大，從前端到後端、從網絡到操做系統、從虛擬機到數據存儲，而性能質量保障的方法手段一樣層出不窮，展開來分分鐘懷疑人生。那麼如何規劃和規範這些手段，使之井井有理、高質高效的爲產品服務，稱之爲性能質量保障體系的建設。這是個逐漸演變、逐漸完善的過程，是咱們須要進一步思考和實踐的方向。

「道可道也，非恆道也；名可名也，非恆名也」，請性能QA獨立行走！共勉！