0%
Loading ...

[軟體工程筆記] 軟體測試 (Software Testing) 是什麼?單元測試、功能測試、整合測試等介紹

目錄

前言

軟體驗證 / 測試 (Software Validation / Software Testing) 是一門很常見,但也常被忽略的學問。

我遇到很多工程師都說討厭寫文件、討厭寫測試,
雖然這兩種東西寫起來都有點麻煩,但是這兩種東西真的不重要嗎?

如果你有以下的這些困惑,那這篇文應該可以解答這些問題:

  1. 為什麼需要軟體測試?
  2. 我都寫單元測試了,為什麼需要另外叫 QA 來測試?
  3. 為什麼有些 QA 不會寫 code?
  4. 軟體測試到底有幾種?

接下來,就來看看吧!

為什麼需要軟體測試?

好的測試可以有效提升軟體的品質,
例如 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,請測試:

  1. 驗證 output 的正確性,func(1, 1) == 2
  2. 放奇怪的 input 值看會怎麼樣
    • func(1, 'a') = ??
    • 假設存數字的 data type 是 int32,那 func(2**32, 1) = ??

功能測試 (Functional Test)

目的

做 module 功能的測試

範圍

單一 module

進行的時間點

每次開發都該進行 ( 建議寫成 automated test )

範例

開發了帳號相關的 module,請測試:

  1. 註冊
    • User 帳號名重複 ?
    • User 帳號過長 ?
    • User 進行 SQL Injection ?
  2. 登入
    • User 帳號過長 ?
    • User 進行 SQL Injection ?
    • 沒有該 User 的資料 ?
  3. 登出
    • 是否完全清除登入狀態 ?

整合測試 (Integration Test)

目的

做 multi module 功能的測試,確保他們互動正確

範圍

複數個 modules

進行的時間點

每次開發都該進行 ( 建議寫成 automated test )

範例

我有註冊、登入帳號跟購物車的 module,請測試:

  1. 未登入加入購物車
    • 加入購物車時有叫 user 創建新帳號或登入嗎 ?
    • 註冊成功後的商品是否還存在購物車裡面 ?
    • 登入成功後的商品是否還存在購物車裡面 ?
  2. 有登入加入購物車
    • 登入成功後的商品是否還存在購物車裡面 ?`

系統測試 (System Test)

目的

做整個 system 的測試,確保牽涉到的 module 都正確

範圍

整個 system

進行的時間點

每次開發都該進行 ( 建議寫成 automated test )

範例

我有一個購物網站,請測試:

  1. 新註冊購物流程是否順暢,
    • 註冊 -> 瀏覽 -> 購買 -> 付錢
    • 瀏覽 -> 購買 -> 註冊 -> 付錢
  2. 舊會員購物流程是否順暢,
    • 登入 -> 瀏覽 -> 購買 -> 付錢
    • 瀏覽 -> 購買 -> 登入 -> 付錢

更淺層、高層次的測試

冒煙測試 (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 😛

數據女巫 𝔻.𝕡𝕪𝕤 🔮

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.