做了一段時間的 QA 後，雖然這些測試大致都聽過且了解，但還是有很多很模糊的界線讓我不是很清楚，查了各方文章後，寫個筆記好好整理一下效能測試、負載測試、壓力測試 等等
在進行效能測試前，應該要先大致了解一下
總之單執行緒也是可以做到效能測試的
只是效果可能不會比 多執行緒 來得優秀
所以往往聽到負載測試、壓力測試時，大部分都還是會選擇使用多執行緒的語言(e.g. C、Java、Go)進行測試。
稍微一一介紹一下
- 效能測試(Performance Testing)、負載測試(Load Testing)、壓力測試(Stress Testing)
- 浸泡測試(Soak Testing)
- 尖峰測試(Spike Testing)
- 容量測試(Volume Testing)
- 可靠性測試(Reliability Testing)
測試的中文名稱的翻譯多少會有些出入
準確的名稱可再自行查找，今天僅先了解有關效能測試的範疇
(還有很多不同的測試，以後再慢慢整理相關資訊)
效能測試(Performance Testing)
找出該系統效能上的指標，只要與伺服器效能指標相關的測試都屬於效能測試。
主要目標不是要找缺陷（bug），而是要消除系統瓶頸和替未來的回歸測試（regression tests）建立一個底線
常見的指標如下:
1. 響應時間
2. 併發使用者數
3. 伺服器處理能力
4. 吞吐量
等等效能指標所以效能測試是一個較廣泛的說法
我們常聽聽到的負載測試、壓力測試、浸泡測試、尖峰測試、容量測試、可靠性測試等等，其實都屬於效能測試的一部分
e.g.
小明是運動選手
在沒有任何負重的情況下，跑 100 公尺需要花多少時間小疑問：
請問你知道網站突然變慢甚至癱瘓掛掉的原因嗎？
想必最有感的就是，當大家一湧而入某網站時，突然網站呈現無限 loading，再糟糕一點甚至直接癱瘓，連網站都無法進入。
答案：通常最為明顯的就是 CPU、資料庫
(我說的是 通常 唷~因為會影響的因素可能性還是很多的，下方會說明到)
CPU、資料庫堪稱是整個產品系統的命脈
在大流量的情況
CPU 是有極高的機率會使資源被占用導致卡住釋放不出來 或者 來不及被釋放
資料庫 則時會反映在 寫入/讀取 過程的快慢
如果對於來說公司的錢不是問題，那無上限的擴增升級也是一種方式，也是能最直接改善效能問題啦XDDD(乾爹?會影響系統效能的因素還有可能如下：
- 硬體：CPU、記憶體、硬碟、網路卡以及其他網路裝置
- 作業系統
- 網路
- 中介軟體（也叫應用伺服器，如Jboss、websphere、weblogic等）
- 資料伺服器
- 客戶端
- 程式語言、程式實現方式、演算法
詳細可參考：
負載測試(Load Testing)
在 可預期內 的流量進行測試，透過 逐步增加 系統流量(負載)，最終確定系統所能承受的 最大負載量。
通常主要是找出 伺服器 響應時間 及 穩定性，也就是說幫伺服器做健康檢查，目的是為了找個各種毛病並給予治療。
常見的毛病如下:
1. 響應時間超長: 正常伺服器處理請求時間是 500ms，但現在變成 3s - 5s
2. 部分服務異常報錯: 無法同時正常響應多個請求
3. 伺服器當機: 系統完全掛掉，任何請求都進不來縱然效能測試和負載測試看起來很像似，但他們的預期目標、執行方式皆不同。
負載測試更多的是體現了一種方法或一種技術。
!!!注意!!!
負載測試並不是要藉由壓倒它來中斷系統，反而是要嘗試維持系統持續運作像情況良好的機器，因為高負載至使中斷系統是壓力測試的目標。
e.g.
小明是運動選手
背負 30 公斤，跑 100 公尺需要花多少時間
背負 40 公斤，跑 100 公尺需要花多少時間
背負 50 公斤，跑 100 公尺需要花多少時間
等等...但這皆是以不會操倒他為前提的負載量(所以通常做負載測試時，都會優先做壓力測試，先找出上限值，接下來就會以不觸發上限值進行多種不同測試)
壓力測試(Stress Testing)
【壓力測試也是一種負載測試中的一種】
主要是測試系統的極限在哪，在較大的效能流量壓力下，執行一個較長的時間，看看系統服務是否正常及系統資源的利用率情況。
上方負載測試中有提到 穩定性，這主要就是壓力測試要測試的目標
看完負載測試跟壓力測試，應該又會覺得兩者也很相似
因為壓力測試可以被看作是負載測試的一種，即高負載下的負載測試，或者說壓力測試採用負載測試技術。
負載測試 v.s 壓力測試
相同點：都屬於效能測試中的一種
差異性：
- 負載測試目標是 系統效能再 正常工作情況 下的達到效能指標，以便找出資料吞吐量、系統佔用的資源量等等的效能瓶頸。
- 壓力測試目標是 系統效能在什麼極限點條件之下，將會變得 不正常/不可接受/強制中斷系統，進而我們就能提早發現後並進行預先防範，以盡量避免日後系統遇到災難性的打擊。
e.g.
小明是運動選手
背負 30 公斤跑步
背負 31 公斤 ...
...
一直逐漸增加負重，並且全程是 長時間 的進行
延續上一個範例，最後跑了 12hr 且負載量增加至到 100 公斤時，小明直接累倒
檢查他的上限值為 100 公斤 12hr效能測試是動力，負載測試載重，壓力測試強度
浸泡測試 (Soak Testing)
屬於壓力測試的範疇之一
在預期的最大負荷下長時間的運行應用程式，確保應用程式能夠運作。
通常因為系统運行時間過長，一些資源無法正常釋放，導致系统回應的時間慢慢變長。
e.g.
小明是運動選手
背負 100 公斤跑步，然後不分晝夜讓他一直地跑
檢查他是不是還可以 維持喘氣、跑步動作、跑速 等等，看他哪時候開始出現異常
(注意:浸泡測試固定維持某個高負載量且長時間的，不像壓力測試是不斷增加負載且長時間運行。)尖峰測試 (Spike Testing)
屬於壓力測試的範疇之一
是為了驗證網站在 用户量 短時間 內突然急速增加的情况下能夠正常工運行。
e.g.
小明是運動選手
在 1 分鐘內，背負 10 + 20 + 30 + 40 公斤進行跑步(重量在跑步中逐漸快速增加)
檢查他是不是還可以 維持喘氣、跑步動作、跑速 等等容量測試(Volume Testing)
在一定的軟、硬體條件下，在資料庫不同資料量級資料量的情況下，對系統中讀/寫比較多的業務進行測試，從而獲得不同資料量級(高負載)下的效能指標值。
e.g.
小明是運動選手
直接背負 100 公斤，看他能在 100 公尺來回跑幾次
檢查他是不是還可以 維持喘氣、跑步動作、跑速 等等可靠性測試(Reliability Testing)
在給定的一定的負載等級壓力，持續執行一段時間，檢視系統是否穩定。
e.g.
小明是運動選手
直接背負 100 公斤，5 分鐘內，跑 100 公尺另外一個實際例子：
電商秒殺場景，幾十個商品幾十萬個人同時秒殺搶購
如何理解可靠性測試:
- 編寫效能指令碼：假設一秒內有一萬個人同時發起請求
- 有壓力嗎？有，一萬個人同時發起請求
- 但是持續時間短，不像壓力測試一樣需要持續一段時間
- 目的是為了驗證當這麼多人同時發起請求時，成功秒殺的使用者能否繼續完成後續下單付款等操作【一定業務壓力下，系統是否穩定執行】
所以其實 可靠性測試 是一個結合上方提到測試方式中的集合體
