目錄
前言
軟體驗證 / 測試 (Software Validation / Software Testing) 是一門很常見,但也常被忽略的學問。
我遇到很多工程師都說討厭寫文件、討厭寫測試,
雖然這兩種東西寫起來都有點麻煩,但是這兩種東西真的不重要嗎?
如果你有以下的這些困惑,那這篇文應該可以解答這些問題:
- 為什麼需要軟體測試?
- 我都寫單元測試了,為什麼需要另外叫 QA 來測試?
- 為什麼有些 QA 不會寫 code?
- 軟體測試到底有幾種?
接下來,就來看看吧!
為什麼需要軟體測試?
好的測試可以有效提升軟體的品質,
例如 RD 快樂寫完新功能時,QA 就可以給他們當頭棒喝 (x),
啊不是,是愛的提醒,提醒是不是忘了些東西要注意等等的。
咦?
你說你們公司的開發的風氣就很良好,
自己就先寫完單元測試 (Unit Test) 了,還要 QA 幹嘛?
為什麼有些 QA 不會寫 code?
事實上,測試的實作方式分作兩種流派,而且不會取代彼此。
自動化測試 (Automated Testing)
假設我們是 Google 的測試工程師,
我們應該不會想要每小時、或甚至每秒都手動驗證 Google 的搜尋框有沒有壞掉…
這種時候我們就會用自動化的測試框架來驗證,
如果有玩過按鍵精靈的話就會懂 XD
適用時機
用 code 來做重複性高,很 routine 的測試工作 🤖
工具
驗證網頁的測試框架,常見的有 Playwright、Cypress 等,
python 的爬蟲工具 Selenium 也有點像,但他不算測試框架所以 out。
手動測試 (Manually Testing)
沒錯正如其名,手動測試是手動的,所以確實不用寫 code。
適用時機
沒有辦法自動化或是自動化成本太高的時候。
…
聽起來很像廢話,
但是在工作中,你會發現很多場景其實都是手動先發現問題。
例如 探索性測試 (Exploratory Test) ,
就是由 QA 們先按照票上面的理想流程進行手動測試,
單元測試 pass 了不代表這新功能就沒問題,
欄位規格、跑版跟使用者體驗也是這種測試很注重的部分。
有些問題可能在工程師眼裡不算是 bug 只是介面比較醜,
但累積起來也是會極大的降低 user 的信心的。
尤其服務正式上線後,
理想上,你覺得 user 應該會按照 A -> B -> C
的流程操作成功✔️,
結果他不知道從哪搞來了 C 的成功轉導網址,DB 把操作成功的狀態收進去,
然後他再說,奇怪我怎麼沒辦法用這個新功能 (❓
User 的問題千奇百怪,這些都是自動化測試沒有辦法涵蓋到的。
所以先讓會乖乖按照指令的 QA 們進行手動測試,
如果連他們都發現了問題,那一上線爆掉肯定是板上釘釘的事啦 ~
工具
手手 👋
軟體測試有哪些種類?
事實上,單元測試 (Unit Test) 只是軟體測試裡面的一小部分,
就好像 Leetcode 的 test cases 全 pass 也不代表高流量的服務一定過。
以測試範圍來分 (小 -> 大)
單元測試 (Unit Test)
目的
做最基本的測試
範圍
單一 function / component
進行的時間點
開發時就該寫,不寫不給推上去
範例
有一個做兩數字相加的 func,請測試:
- 驗證 output 的正確性,
func(1, 1) == 2
- 放奇怪的 input 值看會怎麼樣
func(1, 'a') = ??
- 假設存數字的 data type 是 int32,那
func(2**32, 1) = ??
功能測試 (Functional Test)
目的
做 module 功能的測試
範圍
單一 module
進行的時間點
每次開發都該進行 ( 建議寫成 automated test )
範例
開發了帳號相關的 module,請測試:
- 註冊
- User 帳號名重複 ?
- User 帳號過長 ?
- User 進行 SQL Injection ?
- 登入
- User 帳號過長 ?
- User 進行 SQL Injection ?
- 沒有該 User 的資料 ?
- 登出
- 是否完全清除登入狀態 ?
整合測試 (Integration Test)
目的
做 multi module 功能的測試,確保他們互動正確
範圍
複數個 modules
進行的時間點
每次開發都該進行 ( 建議寫成 automated test )
範例
我有註冊、登入帳號跟購物車的 module,請測試:
- 未登入加入購物車
- 加入購物車時有叫 user 創建新帳號或登入嗎 ?
- 註冊成功後的商品是否還存在購物車裡面 ?
- 登入成功後的商品是否還存在購物車裡面 ?
- 有登入加入購物車
- 登入成功後的商品是否還存在購物車裡面 ?`
系統測試 (System Test)
目的
做整個 system 的測試,確保牽涉到的 module 都正確
範圍
整個 system
進行的時間點
每次開發都該進行 ( 建議寫成 automated test )
範例
我有一個購物網站,請測試:
- 新註冊購物流程是否順暢,
註冊 -> 瀏覽 -> 購買 -> 付錢
瀏覽 -> 購買 -> 註冊 -> 付錢
- 舊會員購物流程是否順暢,
登入 -> 瀏覽 -> 購買 -> 付錢
瀏覽 -> 購買 -> 登入 -> 付錢
更淺層、高層次的測試
冒煙測試 (Smoke Test)
目的
快速看系統是否運作正常的測試
範圍
淺,整個 system 最核心的功能
進行的時間點
新版本發佈前後進行
範例
這版我增加了 Gmail 的超炫酷暗黑關燈模式。
推版後,Gmail 的核心功能是否還能使用 ?
收信
發信
C.C.
/B.C.C.
💡 核心功能 = 不能使用就死定了的功能 ☠️☠️☠️
迴歸測試 (Regression Test)
目的
確保新功能加入後,也不會影響到舊系統
範圍
淺 ~ 中,整個 system
進行的時間點
新版本發佈前進行
範例
這版我增加了 Gmail 的超炫酷暗黑關燈模式。
推版後,Gmail 的所有 or 重要功能是否不受影響 ?
收信
發信
C.C.
/B.C.C.
簽名檔
頭像顯示
- …
健全性測試 (Sanity Check)
目的
快速做新功能是否運作正常的測試
範圍
淺,整個 system
進行的時間點
小小變動新版本的時候
範例
上一版的推薦商品功能壞掉了,趕緊推了一個 fix 的 patch 上去。
讓我們 Sanity check 一下,搜尋 "iphone" 出來的推薦商品:
推薦商品有出現嗎 ?
是否是與 "iphone" 相關的商品 ?
「速度好慢,問題出在哪?」的效能測試
Code 能跑,但不多…
效能測試 (Performance Test)
目的
評估整體系統的穩定性、效能跟反應
範圍
跑起來的整個 system
進行的時間點
想 tune 效能的時候 ( 請跟 PM 好好溝通跑這種測試的時間 )
範例
賣演唱票的網站平常每天只有 10 人次,
接下來要獨家販售五月天的票了,瑟瑟發抖…
機器規格是 4CPU, 16G RAM, ...
,請測試我們主機的效能 :
平均延遲 (Average latency)
最長 ~ 的處理時間 (Peak Response Time)
資料傳輸速率 (Data Transfer Rate)
網路頻寬 (Bandwidth)
吞吐量 (Thoughput)
等,統稱 Performance Metrics。
效能測試還可以拆出很多的測試,列舉如下。
負載測試 (Loading Test)
目的
評估整體系統在一定的穩定性、效能跟反應速度下的可接受 loading
範圍
跑起來的整個 system
進行的時間點
想知道最大 loading 時候 ( 請跟 PM 好好溝通跑這種測試的時間 )
範例
賣演唱票的網站平常每天只有 10 人次,
接下來要獨家販售五月天的票了,瑟瑟發抖…
機器規格是 4CPU, 16G RAM, ...
,請測試我們主機的效能 :
在平均反應速度 < 5ms 的情況下,可以接受的最大同時在線數
在平均反應速度 < 10ms 的情況下,可以接受的最大同時在線數
在最長的處理時間 < 1min 的情況下,可以接受的最大同時在線數
尖峰測試 (Spike Test)
目的
評估在 loading 突然增高 時,整體系統的穩定性、效能跟反應
範圍
跑起來的整個 system
進行的時間點
想 tune 效能的時候 ( 請跟 PM 好好溝通跑這種測試的時間 )
範例
賣演唱票的網站平常每天只有 10 人次,
接下來要獨家販售五月天的票了,瑟瑟發抖…
機器規格是 4CPU, 16G RAM, ...
,請測試我們主機的效能 :
10 秒內湧入 100 人次,系統會變怎樣?
10 秒內湧入 1000 人次,系統會變怎樣?
10 秒內湧入 10000 人次,系統會變怎樣?
壓力測試 (Stress Test)
目的
評估在 極端壓力 時,整體系統的穩定性、效能跟反應
範圍
跑起來的整個 system
進行的時間點
想看效能上下限的時候 ( 請跟 PM 好好溝通跑這種測試的時間 )
範例
賣演唱票的網站平常每天只有 10 人次,
接下來要獨家販售五月天的票了,瑟瑟發抖…
機器規格是 4CPU, 16G RAM, ...
,請測試我們主機的效能 :
30 秒內湧入 100 人次,系統會變怎樣?
30 秒內湧入 1000 人次,系統會變怎樣?
30 秒內湧入 10000 人次,系統會變怎樣?
耐久測試 (Endurance Test)
目的
評估在 高 loading 且長時間 時,整體系統的穩定性、效能跟反應
範圍
跑起來的整個 system
進行的時間點
想 tune 效能的時候 ( 請跟 PM 好好溝通跑這種測試的時間 )
範例
賣演唱票的網站平常每天只有 10 人次,
接下來要獨家販售五月天的票了,瑟瑟發抖…
機器規格是 4CPU, 16G RAM, ...
,請測試我們主機的效能 :
24 小時內線上長駐 100 人次,系統會變怎樣?
24 小時內線上長駐 1000 人次,系統會變怎樣?
24 小時內線上長駐 10000 人次,系統會變怎樣?
e.g. 系統是否還能在 平均反應速度 < 5ms
的情況下持續運行?
注意
效能測試的目的是 測試上下限,好讓服務隨時在線且運作得當,
把自家的系統打爆的話不叫測試,應該叫做 DDoS 😛
- [推薦工具] 讓程式碼截圖變的美美的吧!VScode CodeSnap 與 3 種同功能線上工具介紹 - 2025-01-05
- [AI 繪圖初級教學] 用 X/Y/Z Plot 比較 Stable Diffusion 的 prompt 與 LoRA 效果 - 2024-12-27
- [AI 繪圖中級篇教學] Stable Diffusion WebUI WD14 Tagger 介紹 - 2024-12-26