測試好多都是性能小白，雖學了些性能知識，但在實際工作做開展性能測試，都很茫然，求指導，應該怎麼處理？

從小入手，從簡單的開始，然後慢慢的做更系統更複雜的性能測試。

確定需求

剛接觸性能測試的同學往往不知道性能測試是有需求的。比如

• 給我測一下系統的性能
• 線上xx伺服器掛了，能否重現一下線上問題

如果你是性能測試同學，假設時間有限，這兩個需求你只能接一個，你是接哪個？

很多同學會選第一個，因為第一個需求似乎是性能測試的需求，第二個跟性能測試似乎沒有特彆強烈的關係。

但是第一個需求太泛泛了，如果不細化的話操作起來會很難，第二個儘管看起來是亡羊補牢的行為，但現實工作中這類的需求很多，操作起來也是有套路的，不會特別發散。

總之，建議新人在需求分析的時候接一些具體的，可以操作的需求。需求是否可以細化分解，基本就註定了性能測試能否順利完成

了解業務

比如重現線上問題的需求，拿到手之後，我們就必須熟悉線上的業務。用戶是怎麼操作的，系統崩潰的時段是哪個，這個時段里有多少用戶在使用系統，他們都在做什麼？

儘可能精確的重現用戶的行為或者預測用戶的行為，這是性能腳本的是否符合實際的關鍵。而這種精確是建立在了解業務的基礎之上的。

搭建測試環境

儘可能搭建跟線上環境一致的性能測試專用環境。

關鍵字

• 一致：最好跟線上環境一樣，如果不可能的話，可以減配，但是要保證架構一致。比如線上集群100台，測試環境沒那麼多資源的情況下，可以適量減少，比如測試環境集群2台，但是一定要是集群，不然就沒意義了
• 專用：測試環境是性能測試專享的，其他測試不要在上面搞

實現腳本

比如可以用jmeter實現測試腳本，推薦測試教程網的jmeter教程

對於新人來說，實現腳本往往比較困難。

另外一些基本的性能知識也是必要的，推薦看測試教程網的性能基礎知識教程

腳本執行及監控

根據負載模型去執行相應的腳本，這裡就不展開了。

收集測試結果

對於新人來說，只需要把測試結果提交給項目組的開發人員分析就好了。

對於有一定經驗的性能測試人員，希望可以通過監控和代碼走查的方式找到系統瓶頸，並給出部署的建議方案。

持續學習

• linux知識：比如伺服器kpi指標，簡單監控命令，並發模型等
• 架構知識：最簡單的方式，自己搭建性能測試環境或者線上環境，多搞幾次就熟了
• 更多知識：總之遇到不懂的就學，比如資料庫優化，jvm優化等知識

綜上。希望對你有所幫助。

樓主茫然的同時除了學習更多的性能知識外，也可以藉助工具進行性能測試，通過工具的使用，關注關鍵的性能指標，反向思考也能學習到很多知識點。

一、三樓的同學對測試流程和基本概念都說的比較清楚了，那就性能測試工具的使用來補充說明下。

客戶端性能測試 - Cube

這款工具適用於Cocos、Unity等各類遊戲和應用，可獲取FPS、CPU、內存、流量等基礎性能數據，以及Drawcall、三角形數量等渲染數據；（樓主通過工具得出性能數據後，就可以反向思考是什麼原因導致的，從不達標的數據點入手查找問題根源）

針對Unity引擎的產品：

1. 代碼性能詳細統計，展示各幀高耗時函數，精準定位問題函數，分析函數出現場景，解決函數不合理調用；
2. 展示紋理、網格、動畫、音頻等使用情況，資源影響區域一目了然，輕鬆優化冗餘資源，資源快照對比，明確新增及保留資源；
3. 展示內存趨勢，輕鬆發現內存泄漏，統計內存分配，快速發現問題函數，詳細定位內存問題，精確至函數級別；

更多幫助文檔請戳：http://wetest.qq.com/help/documentation/10234.html

伺服器性能測試 - 壓測大師

• 一款簡單易用的伺服器測試工具，一分鐘完成用例配置，無需維護測試環境支持http協議、API介面、網站等主流壓測場景；
• 騰訊雲提供壓力源，無需額外配置壓力機，雲端壓力穩定、無上限，按需配置，隨開隨用；
• 性能測試數據圖表可視化展示，監控核心性能指標如 TPS、 響應時間、 CPU和內存、 磁碟IO、 網卡負載壓力機性能監測等；

通過這款工具可以看出，伺服器性能測試的主要注意點有事務成功率、TPS、響應時間、CPU和內存、磁碟IO、收發包率、錯誤統計等，樓主如果做壓力測試的話這些一定要特別關注，產品上線前的壓力測試至關重要，人數的預估和高並發的承載能力需要提前衡量。

更多進階壓測使用請戳：http://wetest.qq.com/help/documentation/10245.html

希望以上對您能有幫助~

難得上回知乎，有恰巧這個相關問題推送給我。

為什麼這麼多年過去了， 測試一點長進都沒有，還在看那麼lowb的基礎知識，很多人當年寫書本來基礎就不好，只不過為了名和利憑著自己的想像亂寫一通，現在你們還拿這些狗屎當飯吃。

多看看國外的文檔吧，孩子。感覺測試人員的素養越來越低了，很少看到能跟外國性能領域前沿的分享。

1.1基本概念

　　並發用戶：用戶並發一般發生在使用比較頻繁的模塊中，而且遇到異常通常都是程序的問題。

　　用戶並發數量：在線用戶數量是計算並發用戶數量的主要依據之一。=使用系統的用戶數量(5%~20%)

　　並發主要針對WEB伺服器而言，是否並發的關鍵是看用戶的操作是否對伺服器產生了影響。

　　吞吐量：一次性能測試過程中網路上傳輸的數據量的總和。

　　吞吐率吞吐量傳輸時間，單位時間內網路上傳輸的數據量，也可以指單位時間內處理的客戶端請求數量。吞吐率用「請求數秒」或者「頁面數秒」來衡量。

　　點擊率：每秒鐘用戶向web伺服器提交的HTTP請求數。點擊率越大，對伺服器的壓力也越大。重要的是分析點擊時產生的影響。

　　點擊不是指滑鼠的一次「單擊」操作，因為在一次「單擊」操作中，客戶端可能向伺服器發出多個HTTP請求。

1.2WEB性能測試種類

　　壓力測試：確定一個系統的瓶頸或者不能接收用戶請求的性能點，來獲得系統能提供的最大服務級別的測試。

　　負載測試：在被測系統上不斷增加壓力　，直到性能指標達到極限，響應時間超過預定指標或者某種資源已經達到飽和狀態。這種測試可以找到系統的處理極限，為系統調優提供依據。

　　大數據量測試：針對某些系統存儲、傳輸、統計查詢等業務進行大數據量的測試。

　　配置測試：通過測試找到系統各資源的最優分配原則。

　　可靠性測試：可以施加cpu資源保持70%-90%使用率的壓力，連續對系統加壓運行8小時，然後根據結果分析系統是否穩定。即載入一定壓力的情況下，使系統運行一段時間。

　　並發測試： 多以發現一些演算法設計上的問題。

　　性能測試以用戶並發測試為主的測試。

　　性能測試主要是為了發現軟體問題和硬體瓶頸。

　　對於性能方面給系統留有30%左右的擴展空間即可。

　1.3Web全面性能測試模型

1.3.1預期指標的性能測試

　　主要指需求分析和設計階段提出的一些性能指標。

　　針對每個指標都要編寫一個或者多個測試用例來驗證系統是否達到要求。

　　預期指標的性能測試用例通常以單用戶為主，如果涉及並發用戶內容，則歸併到並發用戶測試用例中進行設計。

1.3.2並發性能測試

　　選擇具有代表性、關鍵的業務來設計用例，並且用戶的設計應該面向「模塊」

　　用戶並發性能測試分為：獨立核心模塊並發性能測試，組合模塊並發性能測試

　　獨立核心模塊並發：完全一樣功能的並發測試；完全一樣操作的並發測試；相同不同的子功能並發。

　　針對獨立核心模塊用戶並發性能的測試用例設計，可發現一些核心演算法或者功能方面的問題，如一些多線程、同步並發演算法在單用戶模式下測試是很難發現問題的，通過模擬多用戶的並發操作，更容易驗證其是否正確和穩定。

　　核心模塊測試一般屬於基本的性能測試，它較多地關注模擬的「功能」，一般不會對伺服器進行測試。

　　組合模塊並發：具有耦合關係的核心模塊進行組合併發測試；彼此獨立的、內部具有耦合關係的核心模塊組的並發測試；基於用戶場景的並發測試。

　　組合模塊測試一般發現介面方面的功能問題，並儘早發現綜合性能問題。

　　在實際中，各種類型的用戶都會對應一組模塊，相當於不同的業務組在並發訪問系統，要充分考慮實際場景，如話費管理系統中的每月10日左右的收費高峰等場景。

　　在編寫組合模塊用戶並發性能測試用例時，不但要考慮用戶使用場景，還要注意並發點的運用，並發點是指一定數量的用戶開始執行同一功能或者操作的時間點，一組測試場景通常包含多個並發點，從而實現了核心模塊同一功能或者操作的真正並發。

　1.3.3獨立業務性能測試

　　獨立業務實際是指一些核心業務模塊對應的業務。這些模塊通常具有功能比較複雜，使用比較頻繁，屬於核心業務等特點。主要測試這類模塊和性能相關的一些演算法、還要測試這類模塊對並發用戶的響應情況。

　　用戶並發測試是核心業務模塊的重點測試內容。

　　1.3.4組合業務性能測試

　　是最接近用戶實際使用情況的測試，也是性能測試的核心內容。

　　組合併發的突出特點是根據用戶使用系統的情況分成不同的用戶組進行並發，每組的用戶比例要根據實際情況來進行匹配。

　　用戶並發測試是組合業務性能測試的核心內容。「組合」並發的突出特點是根據用戶使用系統的情況分成不同的用戶組進行並發，每組的用戶比例要根據實際情況來進行匹配。

　　1.3.5網路性能測試

　　為準確展未帶寬、延遲、負載和埠的變化是如何影響用戶的響應時間的。主要是測試應用系統的用戶數目與網路帶寬的關係。

　　調整性能最好的辦法就是軟硬相結合。

1.3.6大數據量測試

　　主要是針對對資料庫有特殊要求的系統進行的測試，主要分為三種：

　　1．實時大數據量：模擬用戶工作時的實時大數據量，主要目的是測試用戶較多或者某些業務產生較大數據量時，系統能否穩定地運行。

　　2．極限狀態下的測試：主要是測試系統使用一段時間即系統累積一定量的數據時，能否正常地運行業務

　　3．前面兩種的結合：測試系統已經累積較大數據量時，一些實時產生較大數據量的模塊能否穩定地工作。

　　大數據量測試用例的設計1,歷史數據引起的大數據量測試和2運行時大數據量測試

　　首先確定系統數據的最長遷移周期和選擇一些前面的核心模塊或者組合模塊的並發用戶測試用例作為其主要內容即可.

　1.3.7伺服器性能測試

　　性能測試的主要目的是在軟體功能良好的前提下，發現系統瓶頸並解決，而軟體和伺服器是產生瓶頸的兩大來源，因此在進行用戶並發性能測試，疲勞強度與大數據量性能測試時，完成對伺服器性能的監控，並對伺服器性能進行評估。

　　伺服器性能測試用例設計就是確定要採集的性能計數器，並將其與前面的測試關聯起來。

1.3.8設計性能測試用例注意的原則：

　　可以滿足預期性能指標測試用例要求的，就沒有必要設計更多的內容，因為用例越多，執行的成本也越高。

　　一定要服從整體性能測試策略，千萬不能僅從技術角度來考慮設計「全面」的測試用例，「全面」應該以是否滿足自己的測試要求作為標準。

　　適當裁剪原則

　　只有根據實際項目的特點制定合理的性能測試策略、編寫適當的性能測試用例，並在測試實施中靈活地變通才可以做好性能測試工作。

　　測試計劃：主要包含測試範圍、測試環境、測試方案簡介、風險分析等，測試計劃要進行評審後方可生效。

　　測試報告：主要包含測試過程記錄、測試分析結果、系統調整建議等。

　　測試經驗總結：不斷總結工作經驗是建立學習型團隊的基礎，實踐－總結－再實踐

　2.1人員之間的配合關係

　　客戶代表：可了解一些項目的背景知識，例如客戶在軟體性能方面的需求，是否關注性能測試等，這些都是制定性能測試策略的依據。

　　需求分析員：確定哪些業務是核心業務，為後面編寫核心業務模塊相關的測試用例打下良好的基礎，並且他們對用戶群體構成以及系統的擴展目標較清楚，這些都是設計性能測試的數據來源。

　　架構師：了解系統的結構，使設計出的性能測試用例在「恰當」的地方施壓。

　　2.2性能測試的範圍確定

　　對測試項或測試需求進行打分，根據綜合評分確定性能測試工作包含的測試內容，評分要素主要包含客戶關注度、性能風險、測試的成本等，性能風險主要指如果不進行該項性能測試需求，投產系統可能潛在的風險。

　　客戶關注程度或者性能風險較高的均應劃分到測試範圍內

性能測試有具體步驟的，去找找性能測試學習路線圖。