性能測試從零開始實施指南-場景模型篇
- 2019 年 12 月 2 日
- 筆記
今年跳槽到一家電商企業，性能測試需要從零開始。在性能測試不斷推動落地過程中，積累了一些從零開始的經驗和教訓，自己也在有計劃的寫一個系列《性能測試從零開始實施指南》。前面已經聊過了從零開始要做的一些事情，比如：《性能測試從零開始實施指南——流程篇》、《性能測試從零開始實施指南-文檔建設篇》、《性能測試從零開始實施指南-測試計劃篇》。
最近在忙著準備雙十一全鏈路壓測相關的工作，正好今晚私信收到一個同行的消息，看完感觸蠻多的，也算是督促了這篇部落格的出現吧。私信的主要內容包含下面幾點：
1、性能測試，需求分析是重中之重——分析不到位會導致場景不符合實際，做無用功；
2、工具+監控沒太多學習成本；
3、真實的性能需求，才是影響最終測試結果的關鍵因素；
這幾點問題，和我在實際工作中的感受很類似。相信很多性能測試的同學，都遇到過下面這些問題：
1、需求不明確，有時候甚至是「我們有個XXX介面，你給我壓一下」這種偽需求；
2、需求不明確導致無法對測試點&測試場景進行詳盡完善的分析，最終的測試結果與實際需要的結果差距很大，無法對瓶頸定位和線上容量規劃提供精確的參考；
3、工作結果沒有正向有效的回饋機制，出了問題甚至需要背鍋這種蛋疼的事情；
當然，實際工作中，還會遇到很多其他的問題，重要的是：我們如何分析問題背後的原因，然後想辦法解決問題！
這篇文章，聊聊在性能測試過程中，我是如何理解並且去實踐場景建模的方法。。。
關於場景建模，我個人的實踐和經驗，主要從如下三方面入手：
一、業務場景
在測試開始前的需求階段，一定要梳理調研清楚，我們測試的範圍和目的是什麼？
以我司來說，主要是社交電商+鑒定，社交必備的風控業務，電商先天自帶的物流倉儲業務，基礎的消息及推送服務，以及雙十一必備的促銷活動，在雙十一大促期間，這些都是核心的業務鏈路。
那麼，我們可以確定大體的測試範圍，包含如下幾個核心業務鏈路：
知道了測試的業務鏈路範圍，接下來就是和對應的業務&產品&開發同學梳理確認各自負責的核心業務鏈路（這裡指的是帶有業務屬性的鏈路及對應API，以及重要程度和優先順序）。
以交易業務來說，交易業務鏈路，會包含如下的一些核心業務鏈路：
其中，首頁可能會包含開屏頁、登錄首頁、促銷活動頁，個人主頁等；商品會包含商品詳情、商品列表、商品收藏等；以及訂單、購物車、支付、搜索等和交易有強依賴的業務。
根據不同業務鏈路包含的細分業務功能，以及結合系統架構類型（微服務可能會根據業務屬性來做高度內聚解耦），劃分不同功能的優先順序和重要程度。
這樣，我們在需求階段，就可以得到一個比較明確的業務場景，從而開始下一步的工作。
二、鏈路場景
完成了測試範圍的確認和業務場景的梳理劃分，接下來，就是從需求→測試點的拆分（關於這點，初始的想法是和壓測場景合併來說，但仔細想想，作為一個獨立場景更好）。
在鏈路場景構建過程中，最重要的，是考慮到如下三點：
1、任務拆解
任務拆解，和字面意思一樣，根據梳理出來的業務場景，從用戶的角度來劃分不同的操作流程，然後梳理出不同業務鏈路的任務List；
2、任務排期
根據拆分的業務鏈路，分析梳理它的前置項（環境準備、服務聯調）、跨部門合作（運營投放、渠道引流）、資源投入（開發、運維、測試）、交付產出（版本、API文檔、日誌服務、監控）。
然後按照時間節點，預估工期並進行倒排，工時預估到天/人，可以有半天左右的浮動，但一定要明確交付時間和預案（比如各team交付太晚或資源不足的備份方案）。
3、權重劃分
你看，按照上面的玩法，梳理出來的東西一定很多。但很多時候，交付產出總會晚點，資源投入總會少點，預案基本是沒有的。
針對這種問題，作為性能測試，該如何做呢？答案其實上面已經說到了，劃分權重和優先順序，在有限的時間和資源投入範圍內，優先保障核心和重要鏈路的測試覆蓋！
畢竟，兜底方案，是有很多的，比如流量限流、服務降級甚至熔斷（這些手段都是有損的，但為了保障到時候服務不掛掉，這些都是可接受的）。
PS：有些細節性的東西，限於保密和安全規則，無法詳細介紹，但抓住重點，按照上面介紹的思路去實踐，總歸會有適合自己團隊的方法。
三、壓測場景
前面我們確認了測試範圍、業務場景、業務鏈路，劃分了優先順序和權重，做了一些預案及任務排期，但最終要落地的，還是測試方案及具體的測試場景。
比如，針對不同的業務場景，我們要採用哪些測試策略，如何進行測試，什麼時候開始，預期結果以及驗收標準等等。
這裡，我建議在輸出最終的測試方案前，先畫個思維導圖，和開發、運維甚至架構童鞋快速的review一下，先達成大方向的一致，然後輸入測試方案，執行壓測。
可以參照如下的壓測思路進行具體的測試場景設計：
這裡主要分享一些我個人的思路和方法，具體實踐，還是建議根據各自team的特點，針對性執行。
