淺談軟體測試的階段與策略

這幾年 DevOps 盛行，大家都在討論，然後都在喊要 CI 、要自動化測試 ….

我從 Software Developer, Software QA (SQA), System Operation / Administrator 三種角色 / 職務都走過，做了幾年的 System Operation / Administrator 之後，最近開始有機會回到 Developer 身份，專注 Microservice 與架構，反思測試的重要性感覺又更深刻。

Software QA 的職能條件有過去經驗的分享。

整理一下過去做 SQA Manager 時的 Test Strategies (測試執行策略) 與心得。

本文整理的資訊，大概只是 目錄、基本章法，有空再把內容展開，整理出完整的分享。
20230523 更新：本文內容部分收錄在共同著作《軟體測試實務》第一冊第一章之中，歡迎大家彭場指導。

名詞定義

先整理名詞定義：

Test Stages: 測試的階段性
- 怎樣的測試階段，每的階段的目的性、範圍、確認點都不一樣。
- 這些 Stage 有些事有相異性的，有些依照不同的產業、產品性質，則是屬於選擇性的。
- Stage 種類很多，我的定義主要來自於 IBM 的測試方法。
Test Strategies: 策略
- 依據不同產品特性，選擇不同 Stage 的組合，稱為策略 (Strategy)
- 我心裡有一個基本款的策略，也就是不管是怎樣的產品，都要走完，否則就是不及格。
- 最基本的 Test Strategy: Functional Test + Regression Test

我定義的測試全部都是黑箱，也就是不包含 Unit Test，因為那是 Developer 的責任。

Developer 要專注在 Design, Coding, and Unit Test，合稱為 DCUT，相關參見：Software Development Lifecycle

前提

下面描述的測試，必須要有這些前提：

Architecture Overview: 清楚的架構藍圖，包含以下：
- 一、具體的商業目的，使用者情境
- 二、服務定義、關係、依賴性
- 三、每個服務的角色定義、依賴性、關係
- 四、實踐的技術、流程等
Resource Provisioning：根據前述的架構，如何建置環境
Artifacts Management：根據前述的建置，用來部署應用程式

Stages Scope

底下描述 Stage 的關係以及範圍可能有點複雜，下面這張圖表達這些測試的概念，幫助讀者理解下面的描述：

整體而言，用功能與非功能化成兩大區塊，定義如下：

Source: 演講：從理想、到現實的距離，開啟品味軟體測試之路

Stages：Functional Test

Functional Stages 主要專注在商業功能的驗證，確認的是商業功能自身、彼此之間的交互。

假設的是：不考慮外在環境因素，功能還無法使用，需要經過嚴謹的確認。

Functional Verification Test (FVT)

功能測試，也就是主要的商業功能與流程。這是一般做測試最基本的工作，也是 QC 的範疇。
包含完整的 User Stories, Scenario, Use Cases
這段落的測試 完成率 必須 100%， 通過率 必須 90% 以上，才能繼續往下走。
完成率 以及 通過率 的比例與設定，因產品性質不同而有所不同。
FVT 測試環境的 Provisioning:
- 環境建置專注在功能面 / 應用層，不是系統面
- 不用考量 Performance 部分，像是 HA / Failover / Reliability 等，也不用去弄 DB HA / Replication
- 測試環境要最小化，盡量使用 Container 技術，讓每個人 (Developer / QA) 都可以快速建立自己的環境。
- 容器技術的誕生，FVT 更容易了。

Stages：Functional cross with Non-Functional

Integration Test

整體概念如下圖：

Source: 演講：從理想、到現實的距離，開啟品味軟體測試之路

三大種類：

功能對功能：
- 不同 商業功能 之間的互動性測試
  - 登入功能 跟 購物車 的關聯性，就是整合測試
  - 像是跟 時間 有關的功能整合驗證，相關案例參考：從 iOS 無限黑屏事件，淺談軟體測試階段 - 回歸測試 Regression Test
- 著重在 商務領域 的適用性，也就是走的是 User Scenario，必須包含 商業邏輯 + 場景條件
  - 商務邏輯: 打開 APP -> 點選 FB 登入 -> 確認註冊權限 -> 完成登入
  - 場景條件: iOS / Android / Web on Desktop / Web on Mobile …
- End to End 可以說是一種 Integration Test
系統對系統：
- 內部 對 外部 系統的整合：像是電商串接外部金流
- 內部 對 內部 系統的整合：像是內部的 SMS 對串
功能對系統：
- 一分鐘之內同時湧入 1000 張訂單，但是所有的訂單快照，必須在 1 分鐘之內完成。

相對應的注意事項：

環境建置：同 FVT 需求
問題：這樣排列組合會很多，要怎麼走？
- 找 Happy Path，這些可以經過自動化安排，要轉化成 UAT、Health Check
- 其他組合有足夠資源再說吧
誤區：有些產業會把 System 和 Integration 合在一起稱為 SIT，我覺得不太適合。

Stages：Non-Functional

Non-Functional Stages 主要專注在外在環境改變之下，商業功能是否正常運作。

假設的是：商業功能已經可以使用，外在環境改變之下，功能是否影響。

System Verification Test (SVT)

假設功能已經好了，通過 FVT / Integration Test，把它放到不同的系統，可能的影響。
代表真實世界要面對的問題。
針對 系統性 的驗證，兩個異質性系統的溝通、配置、效能等問題。
外在條件的影響，例如不同的瀏覽器、作業系統、版本、 … 等
- iOS / Android 版本
- Android 的型號 (xxoo)、Android 的 Resolution
偏重在技術端、系統面的邏輯正確性與系統串接功能正確
SVT 包含 效能測試 (Performance Test)，分成很多種，後述。
這些也歸類在 SVT:
- Smoke Test / Monkey Test
- Installation Test / Deployment Test
- Pipeline Test (CI / CD)
- Configuration Test (Config 是要測試的)
- Chaos Engineering
環境的建置考量：
- 仰賴 Resource Provisioning ，也就是環境建置自動化，相關技術有 AWS CloudFormation、Terraform ..
- 要考慮完整的系統架構，包含 HA / Failover / Reliability / DB HA
- 要確認這些系統環境彼此的 config / functional 正常能正常運作
- 系統之間的設定問題，要在這階段找出來。
上線後的監控指標 (Metrics)：
- 系統上線後需要監控哪一些指標，要在這個階段找出來。更多參閱：淺談系統監控與 CloudWatch 的應用

更多參閱：輕鬆聊：系統測試 (SVT) 的三兩事

Regression Test (RT)

中文翻成 回歸測試
把舊的功能全部都測過，理想 有包含以下幾個 Stage：
- FVT
- Integration Test
- SVT
- 測試曾經出現過的 嚴重 Bug
高度仰賴自動化
環境建置可以是 FVT or SVT 的條件。

經驗上，很難真的達到這樣的標準，我實際做過的大概是這樣分配：

全部 FVT，包含所有 User Story
少量 Integration Test
少量 SVT
大部分嚴重的 Bug

這樣可以滿足大部分的條件，也達到品質金鐘罩的目的。

案例討論：從 iOS 無限黑屏事件，淺談軟體測試階段 - 回歸測試 Regression Test

回歸測試的挑戰，如何面對 已知 Bug 的問題：

已知問題如何在測試環境重現，包含測試資料、系統配置的還原
測試程式與資料如何組織與管理
測試程式如何測試
測試程式執行的管理：同樣的步驟，可否同時跑不同的版本？

這邊部分的心得，請參考 SRE CH25 - Data Processing Pipelines, P15 的經驗分享。

我過去有類似的開發設計經驗，全文整理成獨立文章，參閱 Designing Test Architecture and Framework

Migration Test

有幾種混合的情境：

通常是新舊程式 (database) 合併之後的測試。
不同 app 版本對 server side 的差異測試

Migration 是很複雜的事情，所以 Plan 很重要，特別是需要長時間的執行，沒規劃好的溝通成本會非常驚人。

更多參閱：相容性與維護性

Performance Test

本段已獨立成專文，請參閱：

User Acceptance Test (UAT)

使用者接受度測試，一句話：出貨前最後驗證，要驗證什麼？

產品最重要的功能，最常走的路徑，那些功能就是 UAT

Field Test

前述的 Stage 都不是在 Production 測試，只有 Field Test 是正式環境，根 UAT 唯一的差異就是 環境，UAT 是在內部的環境， Field Test 則是在 Production。

也可以稱為 Sandbox.

Deployment Test

部署測試。

現在講求自動化部署，我常常會反思：請問你的部署程式可以測試嗎？可以在 Local Workstation 搭配 Container 模擬部署流程？

現在有所謂 GitOps，強調概念就是 deployment pipeline 可以程式化，強調 Ops 的觀念，那 Ops 是什麼？

其實，我想要強調的是：

只要是 Code，就要能測
自動化程式 也是程式
部署 本身也是一個功能，只是它是服務軟體開發，他是軟體工程必要的一環。
CI / CD 產生的 Code 都要可以被測試，本身要有自己的測試，確保正確運作。

其他 xVT

除了前述提到的，以前在 IBM 還有 GVT (Globalization)、IVT (Installation)、TVT (Translation) … 等測試。

除了這種 xVT，還有最近流行的 CI / CD / Deployment 其實也都是要測試的。

其他領域

硬體生產領域也有類似的階段，主要的 DVT, EVT, PVT 三個階段。請參閱 Introduction to Embedded Systems 的介紹。

Strategies 策略

依據產品性質、專案執行的資源、時程、市場需求，會有不同的策略。策略由不同 Stage 組成，理想的條件，全部都要有，不過那是理想。最基本的組合，也是很常見的組合，就是沒有測試就出貨了，嗯，沒有 QA 團隊的公司都是這個等級。

我認為，不能跟老闆妥協的，最基本的有兩個：FVT + RT，這是要守住的基本底線。依照專案資源、時間狀況，過去我會搭配，有時候會搭 (FVT + SVT) + Migration + RT

FVT 我會直接跟 SVT 混著一起跑，Test case 直接設計成 E2E 就可以做到類似的，節省資源與時間。但前提是測試人員除了瞭解商業邏輯，同時也要懂系統架構，甚至是 Provisioning。

這些 Stages 大部分的公司都不會有，要使用也要看公司的規模，或者發展階段。剛開始燒錢的時候，只要有 FVT 就好，甚至是 Developer 自己來。但是到跨國組識，這些每個 Stage 可能都是一個 Team 的等級。

不同階段的企業

CI: Continuous Integration

CI 有幾件事一定要有才算：

Build, Artifacts
Artifact Meta
Unit Test (Automatic)
Code Quality and Analysis

實際上要做到完整的不容易，有很多基礎建設要做。

相關概念參閱：

Artifacts Management

聊聊軟體交付的濫觴談產出物管理 (Artifacts Management)

Study Notes - CodeDeploy Preparation 第一段說明。

Resource Provisioning and Test

前述很多 Stages，不管哪一個都需要在正確的測試環境執行，換言之，錯誤的環境，會造成嚴重的資源浪費與狀況誤判。

Resource Provisioning 是測試的第一件重要事情，也是 DevOps 的第一件要事。實踐方法很多，可以使用 Container 技術，也可以用 Infra as Code 的方法。

建立測試環境還有一個很重要的目的，經常 review 現在整個系統的 Interface。系統之間的 Component 透過什麼方式串接？有多少 Endpoint？使用了哪一些第三方的 API Endpoint？Key？SSO？如果要建立一套新的系統需要先準備哪一些東西？那些東西好準備嗎？有 test 模式？像是信用卡測試帳號。

如果有經常做系統安裝以及 Review，基本上這些應該不是問題。Manager / PM 應該要清楚掌握這些東西，然後主動對外要資源。避免測試過程因為這些資訊不正確，造成測試結果不正確。

我在擔任 SQA Manager 基本上很少出現這問題，因為開測之前就會全部 ready。

詳細參閱：Resource Provisioning and DevOps

我把『環境建置速度與完整性』當成是軟體開發流程成熟度的指標。

環境建置完整性 = 具備可測性 = 品質的 Baseline = 清楚的架構
環境建置的速度 = 快速交付與驗證 = 自動化測試的基礎

在一個沒有清楚 Baseline 測出來的結果，我都是打問號的。

結論

測試應該是整個開發週期最長的時間，因為他需要把所有路徑都走過，把所有狀況都模擬過。

我的腦海裡常常有這樣的畫面：一個戰場上的戰士，還沒上戰場之前，有過嚴格的訓練，上戰場前就已經是傷痕累累，已經是經百戰。測試，就是上戰場前的準備。寧可多測，也不要隨意 Release。軟體的問題通常會是非線性的關係，覆水將難收，已經上戰場了，才來磨槍，只會死得更慘。

我從不相信『臨陣磨槍，不亮也光』這種屁話。

用吉他來說，測試就是一種練習，把每個音階、和弦、技巧練熟悉，一首歌練一百次算很少、一千次算可以上台表演。軟體也是，Release 之前能夠經過千錘百鍊，才會有品質。

有朋友問，為什麼要分這麼多 Stage？測試有那麼複雜？實際上就是那麼複雜。這篇文章，對我來講應該只是目錄，每個 Stage 有時間我再獨立說明其中的原委以及我自身經歷的故事。

XXX is Dead 這幾年很常出現這種話，像是 Test is Dead, Ops is Dead … 這些幹話，我覺得看看就好，認真就輸了。因為通常會說出這種話的，實際上都沒做過那件事事情，了不起只是沾醬油而已。

品質從需求開始，測試只是種手段

品質不是測試，而是整個開發過程。

Updated: 2019/05/29

最近在公司內部分享這篇，提到了兩個概念：

假設一：不考慮外在環境因素，功能還無法使用，需要經過嚴謹的確認。
假設二：商業功能已經可以使用，外在環境改變之下，功能是否影響。

核心想法就是 內聚力、以及 外在因素，外在因素就是部署後的測試，包含測試環境、正式環境等。我有另一篇文章簡單、複雜用了三個領域：音樂、軟體開發、武俠來談內在因子與外在因素的影響。輕鬆聊：系統測試 (SVT) 的三兩事一文最後用車子的測試當案例，舉例外在因素的影響層面。分類的哲學最後提到 熵 的概念，表達的是沒有不斷的透過自我反饋、重新組織整理，最後抑制熵，讓系統更穩定。而測試的目的正式要抑制軟體系統熵值的增加。