明確的產品需求或者功能需求：比如運營活動，申購贖回滿足正常流量/搶購流量
運維部署的效能測試需求：系統的部署方案，模組的引數調整，系統設計漏洞和**邏輯導致的效能bug，比如新模組一定要做模組級壓測
產品質量標準：這個依賴於日常的資料統計，比如各個介面的流量，響應時間，模組級別的歷史壓測資料，已知的效能風險，線上服務機器資源分布；qa根據資料的積累來做風險的評估
流量分析和環境分析非常重要，否則很可能導致在大量的無用功之後，得出乙個不準確的結論；
壓測流量要和線上流量或者線上預期承載的流量盡可能貼近，且在壓測時無其他流量，這些也往往和**策略有關；而這個重點也不熟算算術，而且去分析需要收集哪些條件，去哪收集；
比如：***的搶購系統峰值5000qps
常見比如新老使用者，白名單/非白名單使用者
首頁->產品詳情->申購->申購結果頁->持倉詳情
搶購、正常申購
這個階段往往手工分析和工具分析相結合，常用的工具：trace
比如使用者初次訪問往往會擊穿快取
比如800qps的寫，資料庫的寫入速率是多少，快取的容量變化等
對於效能測試而言，解決了環境就解決了工作的一半，推薦線下機器資源配置盡量貼近線上
物理機vs虛擬機器，以及cpu 記憶體 磁碟 等配置
網路情況
跨機房vs 同機房
執行緒數，日誌級別，連線池大小
公共元件版本，比如資料庫，redis
線上環境的壓測結果最貼近真實，但是風險也最高
以下幾點經過對流量和環境做過資料分析，基本有了以下幾點：
起多大壓力？怎麼起壓力？壓多長時間？
壓測物件是什麼，模組？系統？
壓測介面有哪些？
壓測請求怎麼構造？
線上環境？線下環境？
壓測環境怎麼保證真實？
效能測試理論
mock 替身 server 服務 測試替身的服務 1 前端 前端已寫好頁面，但是後端的介面沒寫好，那麼前端程式設計師正確的姿勢是模擬後端 在控制台內啟動，進入放置之前填寫請求資訊的資料夾內 啟動的命令是 j a jar moco runner 1.3.0 standalone.jar http p...
效能測試基礎理論
一 什麼是軟體效能 定義 軟體的效能是軟體的一種非功能特性，它關注的不是軟體是否能夠完成特定的功能，而是在完成該功能時展示出來的及時性。由定義可知效能關注的是軟體的非功能特性，所以一般來說效能測試介入的時機是在功能測試完成之後。另外，由定義中的及時性可知效能也是一種指標，可以用時間或其它指標來衡量，...
測試理論小結
典型的測試步驟 1 計畫 確定目標，確定測試策略，測試方法 2 執行 建立測試環境，按測試計畫執行 3 檢查 一步步驗證，是否執行完畢 4 迴圈 如果沒有改正，繼續執行 測試職責 1 驗證在整個軟體開發周期中，各個階段的軟體質量是否合格 2 驗證最終交付給客戶的軟體系統是否是客戶想要的，滿足需求的 ...