壓力測試要知道的事（三）

在壓力測試要知道的事（一）和壓力測試要知道的事（二）我們討論了進行測試的觀念、如何評估測試的目標，最後我們還需要了解要如何進行測試。

在市面上有不少測試的工具可以使用，然而每一種工具都有對應的差異。我在 TGONext 的時候跟著教練探討的時候，才了解到選擇適合的工具也是非常重要的一環。

大多數時候，我們在討論壓力測試通常會先想到 ab 這個工具，然而這個工具會一次性的發送請求，有時候不一定符合現實的使用情況，同時也會受限於運行測試機器的限制（例如：Thread 上限）因此可能會得到不太精確的結果，在測試一定請求等級的瞬間壓力是有用的。

又或者像是 wrk 這個工具，在計算上並不一定符合真實使用者的操作情況。然而替換成 wrk2 之後，採取了 Coordinated Omission 會將發出請求到收到回應等各種情況考慮進去，進而更加接近真實使用者用瀏覽器操作的狀況。

除了工具的特性之外，當我們想要發起比較大規模的壓力測試時，會受到單台機器無法模擬真實的大流量，那可能就需要借助雲端服務或者自己搭建 Cluster（叢集）的方式來解決。

舉例來說，我們可以利用 Python 的 Locus 開源專案來進行測試，除了可以透過 Python 腳本來撰寫測試之外，還能夠透過在多台機器上運行來組合成叢集，來發出比較大量的請求。

我個人比較喜歡的是 k6 這個專案，在過去是知名的壓力測試服務 LoadImpact 後來變成 k6 這個開源專案（也提供雲端服務）因為是 Golang 所撰寫具有不錯的可攜性，又能夠用 JavaScript 撰寫腳本以及和 Grafana 這類開源工具搭配，整體上來說是個相當容易入門的工具，也比較容易在大規模測試時直接導入雲端服務。

壓力測試對比稍微有規模的系統是很重要的一環，然而目前大多都是一些大公司有各自的處理方案，相比軟體開發世界還是有很多可以探索的地方。

舉例來說，我們該如何在測試環境進行測試來模擬正式環境能夠支撐預期的流量、是否能夠透過拆分服務之類的方式來進行測試，或者在測試時該如何產生用於測試的資料都會是不錯的議題，有點類似於整合測試的進階版本，還需要考慮到壓力極大時不會將其他第三方服務拖垮等等問題。

封面圖片使用 Unsplash 上 Norbert Kundrak 的作品，有想聽的主題可以透過匿名問卷告訴我，想了解專業的技術主題可以到弦而時習之找找靈感。