性能測試-如何開展

背景：最近正在準備雙十一的準備，因此壓測就是咱們的第一要務。

1、需求調研：（咱們公司需求爲列簡單列出）

• 測試範圍：訂單流程、搜索等
• 系統架構： 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:真實的壓測場景，總會遇到一些問題，產品或者技術就給你說，我有個接口你給咱們壓壓，就是不說我給你壓多少；最好可能壓的場景和實際的結果有出入，若是真的出了問題，可能要背鍋（不過迄今爲止沒有發生線上嚴重的問題，除了一次的優惠券）

2、業務場景：（以咱們公司爲例）

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

3、鏈路場景分析：

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

4、壓測執行：

• 以上工做作得差很少，仍是須要拉一個會議討論下，須要各方面的支持資源都須要溝通好

•  

   

原文出處：https://www.cnblogs.com/Slowfish/p/11729280.html