背景：最近正在準備雙十一的準備，所以壓測就是我們的第一要務。

一、需求調研：（我們公司需求為列簡單列出）

• 測試范圍：訂單流程、搜索等
• 系統架構： gateway  、ES 、MySQL redis
• 業務邏輯 & 數據流向：略
• 測試數據量：商品數量：1w，用戶數據：1w
• 外部依賴：調用其他rpc,如user服務，mq等
• 預期指標：
• 1> 業務監控系統，找到業務量峰值，除以機器數量，計算出單機系統每秒的業務量
• 2> 訪問日志統計接口調用量。或者數據庫表中查詢每天的寫入數據量，通過eads就能了解到
• 命令：awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -10
• 3> 只知道每天大概的業務總量，（每天的總業務量*80%） / （24 小時*3600 *20%）/ 部
• 署機器數量 / 性能冗余量（30%-50%）
• 業務比例:暫無
• ps1 :性能測試，需求分析特別重要，一定要知道真實場景，場景不對，就等于白忙活；監控+工具提前都需要準備；
• ps2:真實的壓測場景，總會遇到一些問題，產品或者技術就給你說，我有個接口你給我們壓壓，就是不說我給你壓多少；最好可能壓的場景和實際的結果有出入，如果真的出了問題，可能要背鍋（不過迄今為止沒有發生線上嚴重的問題，除了一次的優惠券）

二、業務場景：（以我們公司為例）

• 明確我們的測試范圍和目的
• 我們是社交電商+活動；促銷活動，商品搜索、物流倉儲業務，基礎消息及推送服務（mq）,訂單交易+余額支付，拼店業務+秀場業務
• 知道了這些范圍，我們就可以和產品、開發、一起來梳理這些流程：
• 首頁：就是登陸，查看活動首頁，看是否崩潰
• 商品：商品搜索（數萬級別）、查看商品詳情
• 訂單：選擇商品下單，確認訂單，利用余額支付；選擇商品+購物車，進行下單支付；最后查看訂單商品；從拼店入口+選擇商品，進行下單
• 支付：采用余額支付，三方支付暫時沒有考慮，mook掉了
• 個人中心，簽到流程，
• 活動，首頁營銷活動，領取獎品,消耗獎品和優惠券
• ps1:APP首頁會關心活動首頁和活動會有強依賴；商品和搜索、商品詳情，加入購物車，甚至下單會發送消息有強依賴；訂單、購物車、支付、搜索、用戶和交易有強依賴的業務
• ps2:壓測前，分析各業務之間強弱依賴關系，不同服務會根據業務屬性來進行高度內聚解耦，劃分不同功能的優先級和重要程度

三、鏈路場景分析：

• 場景和業務都梳理了，我們就需要對它的分析，需要從需求到測試點的覆蓋和執行；
• 任務拆解，細化，把場景轉化成操作流程；
• 任務確定時間；測試準備、數據準備、環境準備、瓶頸優化，這些時間都需要考慮進去，然后出一個時間；
• 權重劃分：哪些重要，資源偏向，還有就是場景比例的投放得當；

四、壓測執行：

• 以上工作做得差不多，還是需要拉一個會議討論下，需要各方面的支持資源都需要溝通好
•