上篇博客介紹了基準測試的一些思路和方法策略，這篇博客，聊聊基準測試的MVP（最小可行性方案）。。。

思維導圖

一、測試策略

PS：今天和朋友聊起這個話題，朋友說還應該有一個高可用測試，不過仔細想了下，高可用個人認為應該更側重容災和失效恢復測試領域。。。

二、系統配置

nCnG：性能測試可能涉及多個系統，每個系統的服務器配置存在不同，因此要明確不同系統的硬件配置，這樣也方便針對性的設定測試策略以及分析性能指標。

內存分配：這裏主要指的是堆內存分配，需要根據具體的服務器配置進行分配，當然，最好針對性的進行配置測試來確定內存的合理分配。

應用版本：以JDK為例，每個版本都有不同的改進和優化，且被測系統環境應與實際生產環境保持一致的版本。

線程池：線程池數量，也是一個需要重視的問題（我本人就遇到過由於線程耗盡最終導致的OOM）。

最大連接數：容器、DB的最大連接數，消息隊列的消費者數量，也是一個需要考慮的因素。

緩存策略：為了提高系統應對大流量沖擊以及提高可用性，緩存是離不開的一種方法，這裏需要關註的是緩存命中以及緩存穿透的問題。

三、環境選型

SIT：一般來說很少在SIT環境進行基準測試，原因很多，比如：交叉影響、穩定性、配置不一致甚至多個項目部署在同一個SIT環境等。

UAT：大多數時候，性能測試都是在UAT環境下進行，因為UAT相比SIT穩定性更好，已經通過了系統測試階段，且進行性能測試的成本相比生產環境更低。

PAT

四、執行方式

穩定施壓：上面提到的並發、容量、雙節點、穩定性測試一般都是基於一個固定的並發數來模擬負載進行測試，具體的並發數值需要根據實際的用戶數、使用頻次、業務場景考慮。

浪湧測試：在實際生產環境中，有時候存在這種情況：短時間內有很高的流量沖擊，比如限時秒殺等場景。

階梯式加壓：階梯式加壓是尋找系統拐點的最有效的方式。

五、風險預估

在進行基準測試前，要考慮到以當前的環境、業務模型、系統配置可能存在哪些影響測試的因素，以及影響程度、應對策略，比如：網絡延時、網絡波動、交叉影響等。

六、業務模型

基準測試的業務模型選擇，無論是從實施難易程度或者成本考慮，一般都以以下三種類型出發：

核心業務：一般來說核心業務的重要性和使用頻次都是優先級最高的，比如支付、訂單。

高頻次業務：查詢、更新等高頻操作場景，也是需要重點關註的場景。

日常輪詢業務：基準測試的實施前提就是可重復執行和長時間進行測試，這樣才可以進行對比和統計，來分析長期的系統性能基線變化。

七、工具選型

性能測試過程中，需要借助的工具很多，使用占比最高的為以下幾種：

負載生成工具：比如Jmeter、Loadrunner、Locust、Gatling、Artillery。

應用監控工具：主要用來監控服務端的各項指標，比如Nmon、Skywalking。

代碼分析工具：比如SonarQube、Codacy，一般結合持續集成工具來進行。

日誌分析工具：比如現在最常用的ELK。

DB監控工具：比如Zabbix、DBMonitor。

八、異常處理

在性能測試過程中，經常會遇到一些異常情況，比如超時、失敗、接口依賴、敏感數據等情況，針對這些情況，設計合理可行的解決方案。

九、統計維度

測試的結果一定要方便從各個層次、維度進行統計，這樣可以為後續的分析提供更可靠的數據來源，以響應時間來說，一般從以下幾個維度統計：

十、查詢展示

上篇博客介紹過，基準測試的結果一定要便於統計展示，可以明了直觀的展示給相關人員，一般來說，可以從不同維度，粒度從大到小的形式進行查詢展示，比如：

可以通過web頁面、儀表盤、折線圖、樹狀圖等形式，進行不同角度的系統基準表現展示，具體如何設計，可以進行需求調研，然後針對性的設計。

聊聊基準測試的MVP方案