Stages in Software Testing


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

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

How to be an SQA? 有過去經驗的分享。

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

  • 本文整理的資訊,大概只是 目錄基本章法,有空再把內容展開,整理出完整的分享。
  • Updated 2019/02/22: 本文重構中 … 不知何年何月得償所望 XDD


名詞定義

先整理名詞定義:

  • 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 的關係以及範圍可能有點複雜,下面這張圖表達這些測試的概念,幫助讀者理解下面的描述:


摘要 Stages:Functional

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 更容易了。

Integration Test

  • 不同 商業功能 之間的互動性測試
  • 著重在 商務領域 的適用性,也就是走的是 User Scenario,必須包含 商業邏輯 + 場景條件
    • 商務邏輯: 打開 APP -> 點選 FB 登入 -> 確認註冊權限 -> 完成登入
    • 場景條件: iOS / Android / Web on Desktop / Web on Mobile …
  • End to End 可以說是一種 Integration Test
  • 有些產業會把 System 和 Integration 合在一起稱為 SIT,我覺得不太適合。
  • 環境建置考量:同 FVT 需求
  • 問題:這樣排列組合會很多,要怎麼走?
    • Happy Path,這些可以經過自動化安排,要轉化成 UATHealth Check
    • 其他組合有足夠資源再說吧

摘要 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):

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


Regression Test (RT)

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

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

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

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

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

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

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

這邊部分的心得,請參考 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

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

相關概念參閱:

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) 的三兩事 一文最後用車子的測試當案例,舉例外在因素的影響層面。分類的哲學 最後提到 的概念,表達的是沒有不斷的透過自我反饋、重新組織整理,最後抑制熵,讓系統更穩定。而測試的目的正式要抑制軟體系統熵值的增加。


延伸閱讀 (站內)

測試

流程 & 管理

Operations

參考資料 (站外)


Comments