新年第一個工作日，繼續整理之前的技術筆記。
前面通過三篇的內容，將自動化測試相關的技術筆記做了整理彙總。
這篇內容，主要是我剛開始做性能測試時的一些記錄，對新手或者剛進入一個新項目的同學，應該有所幫助。
一般我們在剛介入一個項目時，我認爲可以從如下幾個方面來快速的上手壓測工作。
熟悉業務特性
無論是做什麼類型的測試工作，都脫離不了業務。
我們的被測對象，也是基於系統架構的用代碼實現的高度具象的業務系統。
如果是專職做性能測試，或者剛介入一個全新的系統進行壓測，想要短時間內瞭解業務細節是幾乎不可能的。
但爲了更好的快速開展工作，我個人的經驗是快速熟悉業務特性，結合自己的經驗對系統有個大致的瞭解。
什麼是業務特性呢？可以參照下面幾個例子：
- 電商下單業務：典型的先讀後寫類型，要考慮庫存、事務的一致性，還有響應時間的範圍；
- 大數據&報表業務：典型的讀場景，可能會涉及到緩存或者消息隊列，甚至是批處理；
- 金融風控信審業務：這種業務對響應時間沒有太高的要求，但業務鏈路較長，不同系統間的交互要考慮；
- 語音識別搜索業務：涉及到語音文字的識別轉換、準確率和命中率，計算密集型業務要更關注內存資源；
上述幾個例子只是參考，其實最核心的思路在於：瞭解業務有什麼特點，對響應時間、事務一致性的要求，可能的技術實現方式是什麼，用到了什麼技術組件，壓測時要關注哪些指標。
瞭解系統架構
聊完業務特性後，被測系統的系統架構是一定要了解的。
因爲我們的工作對象是具體的系統，而且壓測要關注技術指標，關注請求處理的過程以及耗時等情況。
一般來說要了解被測系統的系統架構，可以通過如下幾種方式：
- 系統架構圖&網絡拓撲圖；
- 模擬幾個請求，藉助鏈路追蹤工具來繪製請求鏈路；
- 如果都沒有，通過監控觀察請求的變化，挨個摸底；
- 看業務需求的prd，瞭解業務之間的關係，然後映射到具體的服務和接口；
上述幾種方式是我常用的幾種方式，在具體工作中要靈活變通，而且這種對系統架構摸底和請求鏈路的瞭解過程，也是個人快速學習和成長的過程。
下面是一個請求被處理的過程，也是一個較爲完整的常見微服務架構，供參考。
團隊工作方式
團隊工作方式，不僅限於性能測試團隊或者測試團隊，而是從需求到發佈整個軟件研發過程各個團隊是如何協同配合的。
剛進入一個新的團隊或者介入一個新項目時，可以從下面幾個方面去熟悉，主要包括：
- 流程：包含需求評審、提測、UAT、灰度和生產發佈等主要流程以及時間節點；
- 環境：開發環境、測試環境、UAT環境以及生產環境，主要涉及域名、權限、負責人等；
- 基礎工具：配置中心、註冊中心、需求&缺陷管理平臺、CICD流水線工具、監控分析工具等；
- 測試工具：包含壓測工具、抓包工具、造數工具、mock工具、文檔管理工具、協作辦公溝通工具等；
- 測試方法：之前怎麼做壓測？對指標有沒有標準或定義？測試方案測試報告的撰寫要求等；
- 協作人員：不同業務域或者業務系統的研發/運維/DBA是誰，跨團隊的溝通協作方式等；
以上幾點是我個人看來比較重要的一些點，快速瞭解這些之後，也會有助於工作更好的開展。
以上內容來源於我之前做性能測試工作時的筆記內容，稍加提煉和修改。
下一篇我會聊聊做性能測試前期的一些準備工作如何開展。