最近有朋友問我一些測試的問題，問題層面很廣，像是去一家新創 Startup 如何 Build Up QA Team？自動化測試該用哪一套？測試的方法論該怎麼落地？聊到後來我發現問題背後的期待有問題，期待是什麼？

測試想要一步到位

基於這個前提，後來我把觀察到的現象與問題寫下，起筆是 2018/07/03 的隨筆，在不同時間陸陸續續整理以下文章：

• 2018/07/03: 軟體品質的核心概念
• 2019/01/19: 關於軟體測試：一些觀察到的現象
• 2019/10/28: 軟體測試的現實與理想
• 2021/02/21: 軟體測試管理工具的選擇
• 文中列舉的問題，我自己親身的經歷參見： Software QA 的職能條件

這篇文章整理上述文章的想法與整合。

本文的思路，後來整理成專文： 如何意識到問題的存在
20230523 更新：本文內容部分收錄在 共同著作《軟體測試實務》 第一冊 第一章之中，歡迎大家彭場指導。

現象與問題

現象一：把 功能驗證 跟 效能量測 混在一起

最常見的問題：把 功能驗證 跟 效能量測 擺在一起執行，混為一談，用同樣前提看待他們，特別是在規劃環境時。常見的現象：

現在很多人都說測試環境要跟 Production 要一致 … 所以 Production 環境有啥，測試環境全都要

• Production 有 CDN ，測試環境也要 CDN；Production 有 S3，測試環境也要 S3 ….
• Production DB 有 HA，測試環境 DB 也要 HA；Production AP 有 HA，測試也要 HA …
• Ops 還非常熱血地用 Infra as Code 來驗證，真的可以做到！KPI 達標，Production 與測試環境一致。

問題一

對待測的架構不清楚，不知道哪一些是業務功能必要的、哪一些是選擇性的

• 舉例中 CDN 是屬於效能性質的，除非產品本身就是在做 CDN ，否則 大部分 的 Web 在做功能驗證時，是不需要的。
  • 請注意頻率副詞：是大部分，大概 87 成吧
• 機器的 HA 也是，大部分功能驗證時，不需要 HA 的資源。
• 執行策略上，如果團隊夠成熟，
  • 例如已經對於技術掌握能力夠，那麼是可以在功能驗證時，同時驗證 AP or DB 的 HA，可以讓一些問題提早浮現。
• 對於架構，沒有抽象化的認知，把具象與抽象混為一談，例如
  • 抽象架構角色：Web、Batch、DB
  • 具象架構角色：
    • Internet ALB、Web using AutoScaling
    • Internal NLB、Batch using AutoScaling
    • DB using Replicaion
    • Cloud Storage with S3

問題二

對於測試的執行沒有策略。

處理問題的基本手法：分而治之 (Divide and Conquer)，確立每個單元都是正常運作的之後，再把他們放在一起。測試也一樣，所以必須要先拆分執行的單元。這篇整理：淺談軟體測試的階段與策略 - 就是在定義測試該做的部分。其中提到最重要的觀念：

1. 功能驗證 (FVT)：假設功能還沒好，目的是確認 商業功能正確性，像是邏輯完整性、資料正確性、驗證與錯誤處理 … 等，強調功能本身的 內聚力。
2. 系統驗證 (SVT)：假設功能都好了，增加 外在環境因素 之後，把這些 功能 放到不同的環境會有什麼問題？強調外在 耦合性、真實世界 的情境。

拆分處理的最基本方法：二分法，所以這個策略會讓事情更好溝通，也讓任務可以分層處理。

問題三

問題二的延伸，把功能與系統性驗證的測試資源混在一起

這是最常見的問題，我最常看到的現象：團隊裡一堆人都需要資源，不管是開發者、測試、還是維運，但是公司基於成本考量，讓他們共用一個環境，這三個角色，整天就在哪裡搶資源，沒有人負責協調工作，混亂的局面就是天天上演。

我認為品質體現在整個團隊的運作過程，像是：

1. 測試執行策略的規劃，參閱 淺談軟體測試的階段與策略
2. 團隊協作的紀律與溝通效率，參閱 協同合作系統建制與導入
3. 團隊資訊交付與傳遞，參閱 Issue Tracking 在企業裡的價值 - KM、閱讀能力的重要性、文件的持續交付
4. 問題探索與分析能力，參閱 輕鬆聊：系統測試 (SVT) 的三兩事、從 iOS 無限黑屏事件，談軟體測試階段 - 回歸測試 Regression Test
5. 問題回報的品質，參閱 如何有效的回報問題
6. 系統架構的工程能力，參閱 Designing Test Architecture and Framework、軟體自動化測試常見的問題、Resource Provisioning and DevOps、如何量測系統的容量？

現象二：因為要測試左移，所以同時做功能驗證與效能量測

測試左移 不是什麼新觀念，我們以前稱 Early Stage，基本概念就是 早期發現、早期治療，沒啥學問，所以這概念不是這幾年才有的。回到問題：兩個一起同步測？測試效能的執行，在產品發展的大範圍時間線上，有幾個階段：

• 新創期
• 發展期
• 成熟期

新創期

也就是產品 prototype 剛出來的時期。依照產品特性，底下是我建議的執行策略：

• 功能驗證能夠通過一定比例，滿足市場業務需求。
• 核心功能的效能必須達到一定水準，例如 Live Streaming 的 Latency < 5s

這段時間，通常都還在 MVP，確認產品的方向性。所以效能其實不是最重要的，反而是產品功能可以滿足業務市場的需求，打到客戶的甜蜜點。當然，如果產品功能就具備 Latency Sensitive 的特性，那麼該功能的效能就會非常重要。

發展期

大概抓到業務方向，快速增強產品功能。

以電商為例，例如本來交易能夠放到購物車、扣庫存、訂單成立基本的。但是，隨著業務的策略與發展，確立成立訂單需要一定的乘載量，所以需要了解 TPS (Transition Per Second) 可以到達多少，這時候的 TPS 量測就非常有價值。

這時候的測試執行策略，就可以把功能驗證、效能量測分頭進行，建立效能量測的基本執行策略、方法與技術框架，然後未來新功能增加時，一起調整框架與方法，讓效能量測可以類似於 TDD 的概念，反過定義要多少 TPS ，然後依此為目標去執行。

TPS 屬於系統容量的量測，詳細參閱： 如何量測系統的容量？

成熟期

如果業務發展順利，會開始進入成熟期，這時候企業會開始獲利。如果在發展期有建立框架與方法，那麼效能量測這件事情，可以變成標準程序，也就是每次的開發都可以精準的量測。

實務執行面，依照產品特性的區別，定期量測，或者讓專屬團隊做深度效能工作。例如著名的記憶體檢查工具 Purify。

現象三：容量量測右移，它是 Ops / SRE 的工作

承上題，這題很多人會跟我有不同的看法，我認為容量量測是 QA 要做的工作。想想你拿到一個 3C 產品，例如：iPhone，你是拿到 iPhone 前就知道規格，還是拿到手上自己要量測規格，包含 CPU / Memory / Storage / 硬體規格 (工作溫度、防水程度、外觀機構能乘載的工作環境 …) ，答案絕對是拿到之前。

而一個即將要部署的 Web System，如果部署前都不知道單位資源能夠乘載的量，請問 SRE / Ops 是要如何做容量計畫 (Capacity Plan)？開怎樣的機器等級？依據什麼做規劃？要做 可靠性工程規劃 (Reliability Engineering) 要怎麼做？

更多概念參閱 如何量測系統的容量？

現象四：QA 不需要知道如何部署應用程式，不需要懂 CI/CD

這也是一個我無法理解的問題，QA 不知道如何部署應用程式、從來沒看過 Backend 的 Config、也沒看過 DB Schema、更別提知道 CI/CD … 恩，對我來說，有點不可思議。詳細參閱 DevOps 8 字環的誤區：左環問題、聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)

現象五：QA = Test

這是個普遍認知與名詞誤用的問題，QA 的全名是：Quality Assurance，目標是為品質提供可靠的方法、制度與流程，而 測試 (Test) 是達到品質的手段與工具，測試更精準一點的詞是 Quality Control (品質控制)。軟體的 QA 稱為 SQA：Software Quality Assurance。下面這張圖比較了 SQA 與 Tester 的職能差異：

底下這幾篇文章，在探討用人、策略、流程、制度，然後達到軟體品質：

• 三種 QA
• 淺談軟體測試的階段與策略
• Software QA 的職能條件
• 輕鬆聊：系統測試 (SVT) 的三兩事
• 從 iOS 無限黑屏事件，談軟體測試階段 - 回歸測試 Regression Test

底下這幾篇，談的是工程方法（不包含實踐技術）：

• 軟體自動化測試常見的問題
• 自動化 XXX 的陷阱
• Designing Test Architecture and Framework
• 如何量測系統的容量？
• 聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)

這幾年，新實踐技術演進很快，新的平台、方法推陳出新，變化速度非常的快，但是工程方法、品質概念，基本上不太會變。引用我自己 領悟 的話來說：

品質不只有測試，而是整個 (開發) 過程。
品質從需求開始，測試只是種手段

底下截圖是我在社群回答類似問題的截圖，完整參閱：關於 DevOps 的討論與想法

品質與測試的差異，原始討論：

QA 的工程能力：

名詞亂用的現象

對於品質與測試不分的後果是什麼？有點難說，但部分的人對這東西沒啥感覺，但我感覺很強烈，幾年下來也懶得說了。

香蕉是一種水果，但是水果不只有香蕉一種。

測試可以讓產品有品質，但是品質不是只有測試一種方法，像是：

1. 改善整個開發流程也可以改善品質
2. 改善溝通協作方法也可以改善品質
3. 改善團隊運作模式也可以提升品質
4. 改善需求管理也可以提升品質
5. 提供良好的成長環境，讓團隊獨立自主，也可以提升品質
6. ….

所以：

1. 測試環境 != QA 環境
2. 測試工程師 != 品保人員
3. Tester != QA

QA 的職稱部分，我在 軟體自動化測試常見的問題 裡有提到以下幾種層次的定義：

1. Tester: 依據 Test Spec 寫 Testcase
2. QA: 寫 Test Sepc、Automation、
3. SDET: 架構、平台、Sample Code
4. QA Manager: 規劃、策略

四種層次也可以對應到一般 Developer 的層次：

1. Jr. Developer
2. Sr. Developer
3. Tech Leader / Architect
4. Tech Manager

有些公司讓 QA 負責商業邏輯驗證、QE (Quality Engineer) 則負責自動化，但其實這兩個還都只是 QC 的層次而已。所以 ….

到底有沒有等於？

我的答案就是這樣：

QA != Test
QA 包含 Test
測試只是達到品質的一種手段

這問題就跟 DevOps != SRE 一樣。

不過現代工作都希望 Developer / Engineer 也能做 Test 的工作，技能上是不能，但是能否有 QA 的能力，那又是另一回事了。

最後還是 Repeat 我的話：

品質不只有測試，而是整個 (開發) 過程。

現象六：測試管理不重要，寫程式最重要。

標題是常見的 二擇一現象，這段回答是我在 Test Corner 針對 測試管理 工具選擇的回答。

先講結論：

工具選擇的核心概念：品質從需求就開始

每次迭代時都要 管理需求、重構需求、會發現 問題就在需求，回去跟團隊討論，這過程帶來的就是品質，這就我常講的 務虛，也是 QA 本職。工具的目的在於持續維持需求的品質。

BTW, 測試管理 如同 專案管理 一樣重要，對應到開發就像是 gitlab 或者維運平台一樣。 … 以前 提過有空要整理心得，但一直沒空整理心得 XDD

正文開始：

很多年前也用過這幾種, 簡略當時選擇思路:

一、 新創團隊 初期用 google docs:

主要考慮 1) 成本, 2) 協作快速.

約一年後，就開始會發生 excel 資料過多, 以及 testcase 與 execution records (ER) 難以整理. testcase vs ER 是一堆多的結構, 通常就是 一個 tc 要跑在多個 device (iOS / andiod / desktop), 所以一個 testcase 會對應到至少 3 個 ERs.

另一個問題就是產品在變, feature 與 testcase 的關係也要梳理, 用 excel 難以管理關係, 難以看出與現在 feature 列表的關係, 容易造成執行計畫與 feature 現況有落差.

其實跟團隊 run 了半年，我就想換掉了，每次整理 testcases 與 ERs 很痛苦.

當時的團隊約六人.

二、嘗試用系統管理

後來我就開始用 testlink 管理. 基本結構還是:

1
2
3
4
5
6
7

`- requirement
   `+- feature A
    | `+- tcs A
    |  +- tcs B
    |     `+- ERs A
    |      +- ERs B
    +- feature B

testlink 可以滿足這個結構的需求，但是那個 UI 當時 (2013) 的我不能接受 … 所以用了兩個月, 我就開始找下一個了, 後來經過一些評估決定買 testrail.

註一：過程 IT 團隊有提供一份中國開發的管理工具清單給我，希望我選擇裡面的 …. 後來我還是選擇 testrail.
註二：上述的結構，就是測試管理的 領域知識 (Domain Knowhow)，是我判定一個 QA 是否夠專業的依據之一。

三、定期 重構 Testcases

如前面提及，我會定期 re-org testcases, 分析 產品現況功能結構, 也就是 requirement - feature - tcs 之間的關係，淘汰不必要的 tcs, 調整 testcase priority，微調每次 UAT 的 testcases, 篩選每次 Regression 的 tcs, 這個工作是每個 iteration 都要修正的.

這時候發現 testrail 的 org 能力很強，UI 操作很方便, 而且整理 ERs 能排列組合功能很強大, 另外是人員工作分配的機制也很完善. 當時同時也 survey 過其他類似的產品, 最後還是以 testrail 為主.

重點：

如果你很在意組織管理 testcase 與 feature 之間的關係, 如何有效的產生 ERs, 如合作好人力配置, Testrail 很推薦.

這個過程，就是 品質。

測試管理 一直是想寫的題目，之前工作曾經花不少時間分析與應用，在 三種 QA 一文也提到這樣的想法。對於如何選擇剛好藉由社群朋友的提問，整理出沈澱已久的脈絡。

待整理

還有一些現象待整理，先把條列出來：

• 現象：期待整合測試覆蓋率 100%，覆蓋率 100% 就沒問題
• 現象：覺得需要完整的架構才能做功能驗證
• 現象：有自動化就不會有 Bug
• 現象：普遍的 QA 不需建置環境、懂系統架構
• 現象：先自動化再說，或者一開始就想自動化 XXX，參閱： 自動化 XXX 的陷阱
• 現象：有自動化，就不需要手動

結論

對於品質，我的核心概念是這樣：

兩個不穩定的東西，結合成一個東西，那一個東西一定是更加不穩定。

所以一堆不穩定的軟體個體 (可能是 service、module、package、lib … whatever)，放在一起，做出來的軟體，基本上是沒有穩定性可言的。舉個反例：

Unix / Linux 的哲學，小而美，一堆小而美的東西放在一起的結果，形成一個相對穩定的狀態

所以 待測軟體 如果有相依性 (直接相依)，一定要先找到穩定的基礎，移除不可靠的依賴，在穩定基礎之下的測試才會有意義、問題才會收斂。之後的整合測試，也才夠有效收斂。如果兩個以上的不穩定待測軟體放在一起測，結果就是：

找死，問題只會無限發散，無法收斂。

這也是為什麼，我在 淺談軟體測試的階段與策略 會描述有那麼多種，而第一個 FVT 是最重要的。

現實跟理想

有一次在公司內部讀書會，提到 測試金字塔 (如下圖) ：

大概就是 UT、API / Integration、UI (E2E)， 很多人都會說 UT 最重要，不做會怎樣、如何如何 … 。有同事問：

你覺得哪一個比較重要？

每次聊到這個，直覺就想到我上個工作剛到職的狀況：

1. 20+ 個 Developer 在美中台三地
2. 我一個 QA
3. 我面試進來的時候說要做 Automation Test (含 UT)、Performance
4. 然後下一個月產品要 上線。

我 On Board 的第一天就看到 Email 裡有十幾個 Workitems …. 有趣的是，UT 居然要叫 QA 寫，工作這麼久，寫 Code 這麼久，還是第一次遇到。

這段經驗談詳細參見：聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)

On Board 第一天 Backend Lead 就找我幫忙壓測，跟我說這堆 java package 底下的 UT 就是我的。老闆跟我說就等我來，搞定這壓測，產品下個月就要上線了。但是，當下我想的是整個測試的 短期執行策略、以及中長期的策略：

1. 短期策略：如何為自己爭取一點時間、並累積信用
2. 短期策略成功之後，如何規劃中長期計畫，取得資源

所以再回到那個測試金字塔，如果是我前述的前提，下個月上線，你會怎麼做？我記得第一個禮拜我開出數十個 Defect，請 APP / Server / Device 三個 Team 先修、聯測，確認東西能動，同時也爭取一點時間，然後跟 Backend Lead 一起壓測（還是有做，只是我出張嘴），UT 先跳過，但我先寫了 Core Libarary (Protocol Package Utils) … 總之，目的就是：下個月能上線。

所以，書上寫的三角形我也都認同，理想我也知道，但是功能出去根本就不能用的產品 (E2E)，其實是不用談效能的。後來出貨了 (包含硬體)，產品功能還可以，有流量了，效能才也找人慢慢補上測試，然後才展開中長期執行策略。

以前帶 SQA Team 我會問 Team Member 這個問題：

User Story 跟 User Scenario 的差別是什麼？

我的回答沒有像一些書本那麼複雜，答案很簡單：

前者不談前提，後者包含前提。

所以帶 SQA Team 的 UAT 通常執行的都是 User Scenario，也就是具備實際背景條件的 User Story，而過程中我們也都習慣性地在探索產品的各種可能，因為使用背景條件改變了。

如果說測試金字塔是一種關於測試的 User Story，那麼我上個工作第一個月的實際案例，就是 User Scenario。而現在的工作面對的是什麼？全部都是 User Scenario，每一件事情，我都要考慮前提與背景，否則對我來說都是虎與蘭花的對話。

延伸閱讀

• 如何意識到問題的存在

軟體測試系列文

• 淺談軟體測試的階段與策略
• 軟體自動化測試常見的問題
• Software QA 的職能條件
• 三種 QA
• 自動化 XXX 的陷阱
• 輕鬆聊：系統測試 (SVT) 的三兩事
• Designing Test Architecture and Framework
• 如何量測系統的容量？
• 從 iOS 無限黑屏事件，談軟體測試階段 - 回歸測試 Regression Test
• 如何有效的回報問題 (How to Report Problems Effectively)
• 新書上市 - 共同著作《軟體測試實務 I、II》

DevOps 相關

• DevOps 8 字環的誤區：左環問題
• 聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)
• 協同合作系統建制與導入 - 以 Redmine 為例
• Issue Tracking 在企業裡的價值 - KM
• Resource Provisioning and DevOps
• 閱讀能力的重要性
• 文件的持續交付

Facebook 隨筆

• 2018/07/03: 軟體品質的核心概念
• 2019/01/19: 關於軟體測試：一些觀察到的現象
• 2019/10/28: 軟體測試的現實與理想
• 2021/02/21: 軟體測試管理工具的選擇

更新紀錄

• 2021/04/30: 新增段落 軟體測試管理工具的選擇
• 2020/01/01: 增加現象五