關於軟體測試,一些觀察到的現象


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

測試想要一步到位

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

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


現象與問題

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

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

現在很多人都說測試環境要跟 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):假設功能都好了,增加 外在環境因素 之後,把這些 功能 放到不同的環境會有什麼問題?強調外在 耦合性、真實世界 的情境。

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

問題三

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

這是最常見的問題,我最常看到的現象:團隊裡一堆人都需要資源,不管是開發者、測試、還是維運,但是公司基於成本考量,讓他們共用一個環境,這三個角色,整天就在哪裡搶資源。


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

測試左移 不是什麼新觀念,我們以前稱 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)


待整理

還有一些現象待整理,先把條列出來:

  • 現象:期待整合測試覆蓋率 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,每一件事情,我都要考慮前提與背景,否則對我來說都是虎與蘭花的對話。


延伸閱讀

軟體測試系列

DevOps 相關

Facebook 隨筆


Comments