昨天初步知道了K6的背後小故事
跟它能提供給開發團隊做HTTP API等相關網路服務的測試.
今天先來了解一下, 網路服務的測試有哪些類型?
晚點來幾個Demo!!

Test Type

K6網站上列舉出適合用來測試的類型

這五種測試類型, 其實也能都跑同一個test script.
只要我們透過昨天簡單介紹到的VU和Duration就好.
Load Testing

Smoke Test

驗證你的服務是否可以處理最低或最小的負載,
換句話說確認系統與程式基本功能正常, 不出故障

就很像我們用Postman/Curl 自己打一兩次這樣, 做點確認結果是否成功且如預期.

Soak/Endurance Test

字面上看, 浸泡/耐力(?)
就是長時間的測試具有預測負載量的系統,
驗證系統在很常一段時間內的可靠性以及性能表現.

Load Test

就...很多測試都能是Load Test的一種.
所以上圖, 紫色框框是Load test, 下面也有框框是Load test
但有註明(For Performance)就是了

通常這裡講的是, 驗證被測試的系統是否可以處理預期的負載流量,
像是用戶數量, 或每秒的請求數量.
來幫助我們評估系統的預期性能表現.

Spike Test

大大的釘子測試(x)

看上圖長長的那根...是不是很像釘子?

目的是測試, 負載流量突然在極短時間內暴增或瞬間斷崖式下降,
此時系統的行為表現測試

Stress Testing

通過逐步地增加負載, 對系統施加壓力直到超出設計期望的負載時, 可以發現哪個組件或功能首先因為超載而失敗.
透過提昇該失敗組件或功能的性能, 讓我們的系統更加健壯, 性能也因此更棒!

環境準備

能參考這
今天我們透過K6來執行, 並且將結果輸出到InfluxDB上,
Grafana新增InfluxDB的DataSources, 即時呈現在儀表板上.

git clone 'https://github.com/grafana/k6'
cd k6
docker-compose up -d \
    influxdb \
    grafana

我自己會把等等的測試腳本,
都新增到剛剛clone下來的k6專案內sample/demo/下.

k6/
  samples/
    demo/
      xxxx.js
      yyyy.js

Smoke Test

程式碼參考
該程式內遇設了VU只有1 viruatal user
並且持續運行該script 1分鐘
也設置了thresholds, 希望duration p(99) 不會慢超過1.5s.

export const options = {
  vus: 1, // 1 user looping for 1 minute
  duration: '1m',

  thresholds: {
    http_req_duration: ['p(99)<1500'], // 99% of requests must complete below 1.5s
  },
};

雖然有設定了Option, 但也能在docker run時, 從外面給options.
像下面例子

docker-compose run -v \
$PWD/samples/:/script \
k6 run /scripts/demo/sample-smoke-test.js --vus 1 --duration 5s

看結果真的就是只跑1 VUs , 5s
這畫面上的資料叫做``Summary```

也能不帶參數, 就跑script內的option

裡面的指標, 我晚點說明!
晚點也來說明, 為什麼test script內有個sleep(1)
繼續往下一個Test Type!!

Soak/Endurance Test

程式碼連結

還記得耐力測試的定義吧?
這裡就是先慢慢的增加到400VUs
再來以400VUs, 跑個3小時56分鐘...
再來最後兩分鐘內, 逐漸地降到0VU

export const options = {
  stages: [
    { duration: '2m', target: 400 }, // ramp up to 400 users
    { duration: '3h56m', target: 400 }, // stay at 400 for ~4 hours
    { duration: '2m', target: 0 }, // scale down. (optional)
  ],
};

但請允許我, 小改一下程式碼第二個stage...
只跑7分鐘...

docker-compose run -v \
$PWD/samples/:/script \
k6 run /scripts/demo/sample-soak-test.js

下圖真的是能說明2分鐘內, 逐漸地增加到400VUs後
就近到下一個stage, 以400VUs跑長時間的馬拉松:)

到了第三個stage, VU開始下降
能http req duration也開始下降了XD

Load Test (for Performance)

程式碼連結
可以看到一樣用stages, 時間長度, 不如沈浸測試來的長
但會比較要求thresholds這SLO

一樣duration我都有改短了(不然一天都耗在這上面等待了)

export const options = {
  stages: [
    { duration: '1m', target: 100 }, // simulate ramp-up of traffic from 1 to 100 users over 5 minutes.
    { duration: '5m', target: 100 }, // stay at 100 users for 10 minutes
    { duration: '1m', target: 0 }, // ramp-down to 0 users
  ],
  thresholds: {
    'http_req_duration': ['p(99)<1500'], // 99% of requests must complete below 1.5s
  },
};

docker-compose run -v \
$PWD/samples/:/script \
k6 run /scripts/demo/sample-load-test.js

哭, 2次timeout, 最終是Fail的
(看性能的thresholds不過, 該改程式了)

K6會把錯誤的訊息以及原因給輸出在console上

Stress Test

程式碼連結

逐漸地增加負載, 直到超出負荷!

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // below normal load
    { duration: '5m', target: 100 },
    { duration: '2m', target: 200 }, // normal load
    { duration: '5m', target: 200 },
    { duration: '2m', target: 300 }, // around the breaking point
    { duration: '5m', target: 300 },
    { duration: '2m', target: 400 }, // beyond the breaking point
    { duration: '5m', target: 400 },
    { duration: '10m', target: 0 }, // scale down. Recovery stage.
  ],
};

docker-compose run -v \
$PWD/samples/:/script \
k6 run /scripts/demo/sample-stress-test.js

逐步地增加負載, 但每個階段都還是要維持一段時間

Spike Test

程式碼連結
可以看到10s, 從100 -> 1400VUs
10s, 又從1400 -> 100VUs
跟坐雲霄飛車似的:)

export const options = {
  stages: [
    { duration: '10s', target: 100 }, // below normal load
    { duration: '1m', target: 100 },
    { duration: '10s', target: 1400 }, // spike to 1400 users
    { duration: '3m', target: 1400 }, // stay at 1400 for 3 minutes
    { duration: '10s', target: 100 }, // scale down. Recovery stage.
    { duration: '3m', target: 100 },
    { duration: '10s', target: 0 },
  ],
};

分析看看指標

首先看看checks, 當然完美是100%都通過斷言!
再來看看data_recevied和data_sent, 這能協助我們評估網路頻寬需要多少; 系統容量與網路頻寬的評估設計, 也是非常重要的一環.
http_req_duration協助我們評估請求多久能回覆, 我自己是會看avg與mid會不會差很大, 若是差很大, 表示有人脫後腿(不那麼穩).

iteration_duration則是一個VU跑完一整個test script需要的時間, 若我們有sleep(1), 那就是也會反應在這裡.

Sleep(1) ???

為什麼會需要Sleep(1)?
就是讓那個VU, 休息一下下, 在跑下一次迭代.
模擬User可能的實際場景, 再怎樣狂按F5, 也會有一點點手速間隔吧!!
模擬User訪問頁面後, 會停留在這瀏覽頁面約1秒.

Stress test其實就沒必要sleep了

https://github.com/grafana/k6-learn/blob/main/Modules/II-k6-Foundations/05-Adding-think-time-using-sleep.md

今日小心得

K6能用很簡單的方式, 對著同一個script
使用VU, Duration和Stages的組合
就能測試那五種負載測試場景

能協助在本機開發時, 就簡單跑一下smoke test確認正常與性能如預期.
協助我們在UAT壓測(stress test, spike test)時, 有沒有可能哪裡出現問題?
協助我們拍板定案, 正式環境用的監控thresholds該怎麼定義.

參考資料

K6 Test Types

K6 Built-in Metrics

參考影片

Getting started with API Load Testing (Stress, Spike, Load, Soak)