Photo by Jeffrey Betts on Unsplash

前言

在上禮拜的文章中，小弟粗略的介紹了一下軟體測試，內容包括了驗證與確認的重要和靜態分析與動態測試以及白箱測試與黑箱測試，如果有興趣還沒看過的大哥大姐們可以稍微看看，鼠年全馬鐵人挑戰 WEEK 02：軟體測試的種類 - 第一集。(◍•ᴗ•◍)

而這禮拜的文章內容將會延續上禮拜的文章繼續做延伸，主要會講的內容包含了軟體測試金字塔與非功能性測試。那我們就廢話不多說，趕快開始吧～

軟體測試金字塔

以前大家所看到的軟體測試金字塔應該都是只有最下面三層的居多吧～ (◜◔。◔◝)
但是隨著時代的變遷，測試也多了新花樣，也就是最頂端的 Acceptance Test。
越往金字塔的頂端爬，規模會越來越大，數量相對會越來越少，測試時間也會被拉長。
而金字塔最底層，最接近開發者，能夠在前期的時後發現錯誤，大大降低了處理成本。

底下將簡單的介紹一下金字塔內部的各個測試種類 (ง •̀_•́)ง

單元測試 - Unit Test

• 什麼是單元測試？
  單元測試中的每個單元可以是單個功能、方法、過程、模組或對象。
  簡單來說也就是程式的中最最最底層的，最最最單一的東西。
  測試目的是為了確保軟體的每個單元或是組件按照預期執行。
  單元測試基本上是由開發人員在應用程式的開發階段中完成。
  通常會使用上一篇所提到的白箱測試進行單元測試的檢驗。
  但是計畫總是趕不上變化，有些單元測試還是會由 QA 幫忙進行。

• 為什麼要有單元測試？

  • 能夠在開發週期的早期發現錯誤進行修復並節省成本。
  • 能夠幫助開發人員了解代碼，達成快速修改的目標。

• 舉個例子
  以紅綠燈來說，單元測試就像是在檢驗紅綠燈中最為基本且單一的各個元件。
  像是 LED 信號燈、蓋板、帽沿、裝飾面板與亮殼等。最底層最單一的元件。

整合測試 - Integration Test

• 什麼是整合測試？
  在元件通過單元測試之後，會開始整合單元模組，以檢查元件之間的一致性。
  目的是為了確保在整合這些軟體模組時，之間交互中不會出現任何缺陷。
  雖然每個單元模組都通過各別的單元測試，但組合後的各模組未必能順利執行。
  通常會使用上一篇所提到的黑箱測試進行整合測試的檢驗。
  像下圖一樣門閂跟拉門各自的功能都沒問題，但是這兩個組在一起問題就大了。
  

• 為什麼要有整合測試？

  • 確保多個模組進行整合測試，是可以統一工作的。
  • 確認是否完善異常處理，減少更多問題的發生。

• 舉個例子
  以紅綠燈來說，整合測試就像是在檢驗剛剛單元測試的元件組在一起是沒問題的。

系統測試 - System Test

• 什麼是系統測試？
  系統測試可以驗證完整且完全整合的軟體產品，評估端到端的系統規格。
  測試環境應與實際環境相似，並參考系統的需求、規格與效能要求來進行設計。
  通常會使用上一篇所提到的黑箱測試進行整合測試的檢驗。

• 為什麼要有系統測試？

  • 檢驗整個系統軟硬體功能及執行績效是否符合需求。

• 舉個例子
  以紅綠燈來說，系統測試就像是結合不同的計數器或是燈號的樣式進行測試。
  

驗收測試 - Acceptance Test

• 什麼是驗收測試？
  基本上是由最終用戶或客戶端執行的一種測試。
  也稱之為 User Accrptance Test (UAT)。
  目的是為了將應用程式釋出之前進行系統的 驗證/驗收。
  在完成單元、整合和系統測試之後，在測試的最後階段完成驗收測試。
  而如果以 QA 的角度來看，驗收測試又可以被分成兩種。
  by QA 的 Alpha Test 跟 by Clients or End Users 的 Beta Test。

• 為什麼要有驗收測試？

  • 確保開發人員根據需求編寫的軟體，是客戶實際上所需要的。
  • 避免項目中的需求變更無法有效地傳達給開發者而引發錯誤。

• 舉個例子
  以紅綠燈來說，驗收測試就像是將整個完成的紅綠燈實際的擺在測試道路上。
  讓一些測試人員，或是直接讓使用者或客戶群直接進行測試。

非功能性測試 (Non-Functional Test)

非功能測試被用於檢查軟體應用程式的非功能性方面，像是性能、可用性和可靠性等。
而以下就是可以做為非功能性測試的參數依據，可以根據這些參數做相對應的測試。
那實際上該注意的有哪些東西呢，就讓我們繼續看下去吧～

Security： 確保系統能夠抵擋內部或外部來源的蓄意或突如其來的攻擊。
Availability： 確保系統在長時間運作的情況下，系統能夠正常運作。
Efficiency： 確保系統能夠有效的處理流量、數據與回應時間。
Reliability： 確保系統在沒有故障的情況下，每次的操作都能有相同的回應。
Survivability： 確保系統在修復故障後，系統能夠自行恢復並繼續運作。
Usability： 確保使用者在使用系統時，能夠越簡單易懂，越好記。
Flexibility： 確保系統能夠在不同軟硬體配置下工作。像最低RAM、CPU要求一樣。
Scalability： 確保系統能夠滿足額外的需求增加與擴展的處理。
Reusability： 確保系統的部分功能能夠轉換到其他系統上使用。
Interoperability： 確保系統能夠與其他軟硬體間互相操作。
Portability： 確保系統從當前環境轉移至其他軟硬體能夠正常運作。

以上說了這麼多，但是非功能性測試的測試實在太多太廣泛了。
但是只要提到非功能性測試，很常都會把性能測試也提出來說。
因為非功能性測試也包含了性能測試，所以經常被一起提出來。
關於性能測試，之後小弟會再另外寫一篇文章簡單的介紹一下。

結尾

就這樣，以上是這篇所介紹的內容，希望內容不會太艱澀難懂。
如果有疑問或是有錯誤，還請各位大哥大姐提點。

參考文獻

• Guru99