《全棧性能測試修煉寶典 JMeter實戰》—第2章 2.3節性能測試成功與失敗要素

本節書摘來自異步社群《全棧性能測試修煉寶典 jmeter實戰》一書中的第2章，第2.3節性能測試成功與失敗要素，作者road_testing軟體測試組 組稿 , 陳志勇 , 馬利偉 , 萬龍，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

2.3　性能測試成功與失敗要素

性能測試上手難度比較高，是一門融合測試、開發、運維、需求調研、架構、協調管理等綜合技能的學科，掌握一門性能測試工具對于性能測試來說隻是萬裡長征的第一步，沒有一定的需求、開發和運維專業能力，往往會吃一些苦頭。

性能測試有幾大難點：

（1）需求分析；

（2）場景設計；

（3）性能診斷調優。

（4）環境搭建和模拟

往往很多性能測試從業者在需求分析方面沒有做到位，不能準确地預估使用者行為；在場景上不能複現使用者操作，無法把需求展現在腳本和場景設計上，無法模拟真實的系統負載；這種狀态下做出的性能測試往往結果良好，上線出問題，導緻整個項目團隊狼狽不堪，整個公司手忙腳亂。

性能診斷調優是一門有效利用和協調硬體軟體的“藝術”，從oracle exadata誕生之初在軟體層面的優化就可以有200倍至10000倍之多。

但是性能診斷和調優是有時間和經濟成本的，也是需要全面的it知識體系的專家或者團隊才能比較全面地挖掘出系統的性能問題并給出調優方案。

很多性能測試初學者總覺得性能測試就是寫個腳本，弄幾台機器應付，出個報告就行了。通常關注并發多少，響應時間多少，能跑通嗎等問題認為并發越大，響應時間越快，那性能一定就越好，實際上我們需要對系統進行一系列複雜精密的工作才能開始性能測試執行，經過n次回歸，找到瓶頸的具體原因，優化再驗證。

下面講解性能測試重要關注點。

1．評估系統，需求分析

對性能測試進行需求分析，通常情況下我們很多功能測試人員會直接依賴需求人員或者項目經理的口述或者有缺陷的文檔。實際上，大多數情況下我們需要自己來引導相關的運維人員和需求人員給出具體的需求資料，并對這些資料進行二次分析，得出我們真實的性能需求。

對于初次上線的系統，我們需要用同行的系統資料，進行使用者行為分析和商業資料結構的估算為前提，利用性能估算法推算。得到的負荷和響應時間資料可以被用于驗證所計劃的模型的能力，并幫助作出決策。

對于已經上線的系統，我們可以通過運維人員擷取tps和時間的比例分布圖、使用者數和時間的分布圖、資料庫er關系圖、容量資料等，直接精确得出目前的系統的使用者行為和業務資料關系，進而得出我們需要的性能需求。

2．場景設計、用例設計

充足的需求調研與分析之後，我們要在測試場景中盡可能真實地複原系統負載。

通過需要我們要決定哪些功能要參與性能執行，如何參與？這就是用例設計。

如何有效地組織測試用例就是場景要做的事，按業務分布、業務量、業務時段、業務角色來綜合配置設定使用者數、執行時間、執行比例等。看似簡單，實際操作起來還是比較麻煩的。

3．測試執行、是否通過

模拟不同負載執行測試場景來識别系統弱點：做好各種監控，甄别各種問題；驗證系統的穩定性。下面是我們在執行時常見的需要關注的名額，如圖2-4所示。

4．性能診斷優化

性能診斷知識面要求甚廣，系統日益複雜，單打獨鬥的日子已經遠去，依靠團隊力量才能夠高效完成診斷任務。性能測試從業者要具備良好、敏感的性能意識，能夠把遇到的問題初步分類，協助各開發團隊完成問題定位、分析調優。是以首先要是一個好的協調者，還是一個技術面廣的技術人員，具備跨領域知識，如開發、運維、資料庫、緩存等。