淺談效能測試

本文整理重新摘分在 Stages in Software Testing 整理的效能測試部分。

Performance Test

分成幾種: Stability, Reliability, Stress/Load Test, Capacity

作 Performance Test 的前提：FVT、SVT 要過。

我做 SQA Manager 的時候，本來是要去做 Performance Test，但是發現功能根本就不能用，所以就整個砍掉重來，先把 FVT 守住，直到通過率到一定程度之後，才開始 Performance Test。這段故事在 [協同合作系統建制與導入 - 以 Redmine 為例][4] 有提到一點。

環境建置考量：必須跟 Production 一致，可以利用 Cloud (ex. AWS, GCP) 快速建立完整的 Scale，測完就刪掉。

效能測試的準備工作

如果是測試 Web System ，那就要花時間把整個系統建置起來，準備好測試資料，餵到 DB … 等。

實際上不只是待測要花時間準備，測試的 Client 的準備也是要花不少時間的，例如：

• 模擬商業邏輯的資料，像是 Database Schema or 模擬使用者資料的 資料 … (啥鬼XD)
• 測試程式的設計，模擬功能的行為。以 Live Stream 就是模擬 IPCam 的資料丟到 Server 然後傳給 App。
• 測試程式執行環境的準備，要確認網路 Throughput 是否足夠
  • 測試環境能否自動化建置，最好利用像是 AWS CloudFormation 這樣的東西
  • 平常就要做好 [Resource Provisioning][6] 的工作。
  • 用 AWS 的話，確認機器等級的 Network 狀況，透過 VPC Flow Log 蒐集狀況
• 測試流程 (HTTP Request) 模擬與建制，可以從既有的 Log 分析
• 測試過程要蒐集的資料與 Log, 如何觀測 (Observailitiy)？參閱 Monitoring vs Observability
• 預期會產生的資料如何分析？

這段 AWS NLB 的介紹中： Deep Dive: New Network Load Balancer 提到效能測試，Client 開了 c4.xlarge * 100

Stability (穩定性)

一定的資源之下：長時間，且大量的 Request 之下，系統維持在穩定狀況，不會有 CPU / Memory 凸波、或者是 Memory Leak、Disk I/O 瞬間的狀況。

如果應用程式本身具備 GC 機制，當記憶體使用量到一定程度時，則會自動恢復。

現象：不倒翁

Reliability (可靠性)

Chaos Engineering

Capacity (容量測試)

目的在 量測 (Measure) 系統可以乘載的數據，單位可以是線上使用者、單位時間內的交易量、單位時間內的流量 … 等，像是 QPS (Query Per Second)、RPS (Request Per Second) …

量測的對象就是整個系統，系統要考量以下：

• 一定的硬體資源，包含 Networking, Computing, Memory, Storage .. 等條件，應用程式能夠滿足多少的處理單位。
• 放在 AWS 上的網站來說，使用 c4.large 的機器，最大能夠乘載多少的 HTTP Request，這個值稱為 Benchmark .
• 有了 Benchmark 可以根據需求推論出系統需要的成本。例如已經知道 c4.xlarge 可以同時乘載 5k/second request,，那麼就可以推論如果有 100k/s request 需要準備多少台 c4.xlarge
• Rate Limit: 服務提供固定的 SLA，像是可以乘載的數量上限，超過時候，告訴 Client 已經滿了。這種設計應用在 搶購 (flash sales) 是必要的。

Performance 測試除了上述面向，另一個面向就是帶測體是屬於整個 stack ，還是 layer or tier 。

例如傳統的 web 有三層： Web -> Application -> DB ，每個 layer 都有自己效能的問題，最終的目標是了解整個 stack 的 benchmark，但實際在執行上應該要先 bottom up，也就是先找到每一個 layer 自身的效能，最後才能測出 stack 的效能。

另一個例子是 realtime stream，像是影音串流的效能，先不考慮使用 p2p 技術，考慮使用 server relay 技術，一班實作就是： data source -> server relay -> client (app or web)

這三個端點都各自有傳輸的延遲時間 latency ，每個節點都有運算時間，所以效能就包含兩個議題：

• Latency: 資料傳輸時間，相依於網路，WAN -> Gateway / LAN / NAT / Wi-Fi … 等節點
• Computing: 每個節點 encode / decode 的運算、protocol (RTSP)、mjpg / h264 … 等

從 Stack 的效能測試屬於 Top-Down View，大部分都會直接用這種方式開始，特別是沒有很多資源的狀況之下。一開始入門效能測試也都會從這個角度著手的比較多。

從 Layer 則屬於 Bottom-Up 方法，先找到每個 Layer 的 Capacity，然後再用數學方法模擬出整個系統的樣子，最後用 Infra as Code 的方式建立整套的系統，模擬測試。

這些根系統架構會有直接關係，現代的常見的 Pattern 就是API Gateway、 Service Mesh