---
# System prepended metadata

title: Software testing
tags: [Software testing, grafana k6]

---

# Software testing
Why testing? 在完成軟體後，如果此時立即把軟體上線容易遇到一些意外的因素導致軟體crash掉，因此在軟體上線前先將軟體進行測試並修正，可以大幅降低維護成本。
因此此時需要定義出軟體要如何被使用者所使用，並請設計出相對應的測試場景，以下將介紹常見的software testing方法。

## System function test (測試系統功能)
旨在進行系統功能測試，在software完成後先對於code進行測試，常見有Top-down和Bottoms-up兩種測試方式，Top-down意即 Functional test -> Intergration test -> Unit test，Bottoms-up 則相反 Unit test -> Intergration test -> Functional test。

### Unit Test
Unit test旨在完成軟體後對於寫完的function函數，以開發者的角度去逐一寫測試確保函數出來的結果符合預期，以利於軟體在後續改動或是出bug時查找問題，當各個function都沒有問題後，在進行更大項目的測試。
### Integration test
Integration test旨在測試各unit之間的互動有沒有符合預期，當各個Unit之間的互動沒有問題後會進入下一步的functional test。
### functional test
Functional test 旨在測試使用者與軟體應用之間的互動，以使用者的角度去測試軟體使用是否符合預期，因此在進行functional test時關注於api輸入後輸出是否符合預期。

## System Load test (測試系統流量負載)
旨在對於系統進行負載測試，測試在各種用戶情境下，系統表現是否符合預期。
### Smoke Test
旨在確保系統最基本的功能是否正常，即為平常在開發時常常使用curl去戳系統獲取response，確保回應正常。
### Soak/Endurance Test
旨在驗證系統的可靠性，將系統進行長時間的浸泡測試，在系統預先define好可承受的低流量下長時間去驗證系統。
### Load Test
旨在驗證系統是否可以承受大流量的用戶，在大流量的用戶使用後系統是否符合預期，會設計SLO(service level objective)去驗證系統響應是否符合預期。
### Stress Testing
旨在驗證系統最高負荷承受上限，在測試時不停地增加用用直到系統爆炸。
### Spike Test
旨在驗證系統在瞬間的高流量下，是否可以符合預期表現。

## Testing tool
Grafana k6 可以測試 performance test 以下將簡易介紹 Grafana k6
### Grafana k6
[Grafana k6](https://k6.io/docs/) 由 Grafana所maintain，其底層以go語法去運行，上層以js包裝。在測試前須先define系統需要測試的項目，並設計測試目標，以下先介紹k6 運行指標。

|METRIC NAME|TYPE|DESCRIPTION|
|--|--|--|
|vus|Gauge|當前活躍虛擬用戶數|
|vus_max|Gauge|最大可能的虛擬用戶數（VU資源是預先分配的，以避免擴大負載時影響性能）|
|iterations|Counter|VU執行JS腳本的總次數|
|iteration_duration|Trend|完成一次iteration所花費的時間，包含setup和teardown|
|dropped_iterations|Counter|由於缺少VU或缺少時間而未啟動的迭代次數|
|data_received|Counter|接收到的數據量|
|data_sent|Counter|發送的數據量|
|checks|Rate|檢查成功率|
|http_reqs|Counter|k6 總共生成了多少個 HTTP 請求|
|http_req_blocked|Trend|在發起請求之前阻塞（等待空閒 TCP 連接槽）所花費的時間|
|http_req_connecting|Trend|與遠程主機建立 TCP 連接所花費的時間|
|http_req_tls_handshaking|Trend|與遠程主機握手 TLS 會話所花費的時間|
|http_req_sending|Trend|向遠程主機發送數據所花費的時間|
|http_req_waiting|Trend|等待遠程主機響應所花費的時間|
|http_req_receiving|Trend|從遠程主機接收響應數據所花費的時間|
|http_req_duration|Trend|請求的總時間。等於http_req_sending + http_req_waiting + http_req_receiving|
|http_req_failed|Rate|根據setResponseCallback的失敗請求率|

以下簡單列出範例，更多測試直接參考 [Grafana k6 load test type](https://k6.io/docs/test-types/load-test-types/)，其中文檔很詳細描述各測試如何進行。

#### Soak Test
大多數系統必須保持開啟狀態並在無人干預的情況下持續工作數天、數周和數月。該測試驗證系統在長時間使用後的穩定性和可靠性。此測試類型檢查僅在長期使用後才會出現的常見性能缺陷。這些問題包括響應時間降低、內存或其他資源洩漏、數據飽和和存儲耗盡。
```
import http from 'k6/http';
import {sleep} from 'k6';

export const options = {
  // Key configurations for Soak test in this section
  stages: [
    { duration: '5m', target: 100 }, // traffic ramp-up from 1 to 100 users over 5 minutes.
    { duration: '8h', target: 100 }, // stay at 100 users for 8 hours!!!
    { duration: '5m', target: 0 }, // ramp-down to 0 users
  ],
};

export default () => {
  const urlRes = http.req('https://test-api.k6.io');
  sleep(1);
  // MORE STEPS
  // Here you can have more steps or complex script
  // Step1
  // Step2
  // etc.
};
```


## 參考
* https://ithelp.ithome.com.tw/articles/10305586
* https://evan361425.github.io/feedback/distributed-systems-with-node.js/sla-and-load-testing/
* https://blog.51cto.com/u_15060533/4389309
* https://blog.darkthread.net/blog/k6-load-testing/
* https://www.tpisoftware.com/tpu/articleDetails/2920
* https://k6.io/docs/using-k6/metrics/reference/

## Thank you! :dash: 

You can find me on

- GitHub: https://github.com/shaung08
- Email: a2369875@gmail.com
