從 iOS 無限黑屏事件,談軟體測試階段 - 回歸測試 Regression Test


12/02 Apple iOS 11.1.2 爆炸了,無限黑屏轉圈圈,暫解法是把時間改到 11/30 即可。Apple 隨即也 Relase 11.2 緊急 Fix 這個問題。

來源: Iphone 6 plus突然黑屏轉圈圈

很多人會疑惑:

  • 為什麼蘋果會犯這種不可原諒的錯誤?
  • 難道 Apple 沒有 QA 了?
  • 有跑 Regression Test (回歸測試, 以下簡稱 RT) 應該可以發現吧?
  • 有人覺得很容易重現,為什麼沒發現?

但我想的是:

  • 為什麼這會很容易被發現?為什麼大家會這樣覺得?
  • 為什麼跑 RT 就一定能 Release?
  • 實際上很多人不知道 RT 是什麼,還有其重要性,很多公司根本就沒這關卡,能動就上。

從這件事情,簡單分析,同時討論軟體的測試階段:Regression Test (回歸測試)

為什麼會發生這樣的問題?

從現象來看,是 某個功能特定時間 有關係,使用者只要調整到 12 月之前就可以緩解。

朋友覺得:為什麼這麼容易重現的問題沒 cover 到

我是從反面思考:我覺得這問題,在 Release 前是不容易被發現的。

如果能夠完整跑完 RT 就有機會避免,我的概念上,RT 包含以下四個階段:

  • FVT: Functional Verification Test
  • Integration Test: A + B + C =?
  • SVT: System Verification Test
  • 重大 Bug 測試

詳細軟體測試階段的定義,請參閱 Stages in Software Testing 的介紹。

以 RT 必須 Cover 這麼多 Stage 來看,除非很明確知道 特定功能時間 有關係。但實務上的 RT,經常需要遷就於資源、環境、維護 … 等因素,大部分能跑的是 Functional Test 的範圍,也就是各個獨立功能的測試。而功能跟功能 (ex: Apple Pay + Datetime) 不見得會有完整排列組合的 Integration Test。

想像在 iOS 點到 Settings 裡面之後,相關的、或無關的功能樹,要做 n * n 的排列組合,全部跑過測試。如果這段有做,應該有機會發現,但實務上能做到的不容易,同時誰也不知道會不會改了 FuncA 居然會影響 FuncB,更別提 FuncA 還有 SubFuncN、AttributeX Z X …。

不過以蘋果這種規模的公司,他的資源要做到我說的應該是必要的,只是,感覺越來越不重視罷了。

有了 UT 就不需要其他測試?

這個問題需要看面對什麼樣的測試對象 (Objective),例如:

  • 是 API 的 UT? 我認為是 Partial 可以,但是如果有 API Aggregation 就很難說了。
  • 是針對 API Ingration (Aggregation)? 我認為有 UT 是完全不夠的,但 UT 可以守住七八成。
  • 是針對 GUI (Web, Desktop, Mobile): 答案絕對是 NO,這是兩回事。API 通過 UT != Frontend 就沒事了。
  • UT != FVT != Integration Test != RT
  • 系統性測試 (System Test) 跟 UT 是兩碼子事。

老樣子,詳細軟體測試階段的定義,請參閱 Stages in Software Testing 的介紹。

回歸測試是不容易的 (Regression Test is Tough)

實際上 RT 案例的增減、管理、維護是非常重要的,它包含前述提到的四大部分,加上任何增減的功能、還有系統性的維度 (像是: 版本, 平台, 甚至是語系),都要調整 RT Test case 的數量,而每一次的執行都要有紀錄,稱為 Execution Record (ER),從 ER 可以分析問題的穩定性。

用數學方法簡單計算 RT 要跑的數量與維度:

  • F: Functional Test Case 的數量
  • A: Functional 本身的參數 (Attributes)
  • S: 系統性維度: Version, Platform, 手機型號
  • B: 重大 Bug 數量 (另一種 FVT)

整理公式:

  • Integration Test QTY = ( (F x A)^2 ) x S
  • RT Test Case QTY = F + (Integration Test QTY) + B

舉例,有個產品的狀況如下,

  • 100 個功能 (Functions)
  • 每個功能平均有 3-10 個參數,為了方便解釋,參數取中位數: 6
  • 測試的對象是手機有 3 個版本
  • 2 種 Platform
  • 已知曾經發生過的重大 Bug 有 5 個。

所以簡單計算各個階段 (Stage) 要測試的數目 (QTY):

  • FVT: 100 x 6
  • Integration Test = (100 x 6)^2 = 360,000
  • SVT: ( (100 x 6)^2 ) x (3+2) = 1,800,000
  • RT Test Case = 100 x 6 + (1,800,000) + 5 = 1,800,605

實際上,是很恐怖的數量。很多人會覺得我可能算錯了,或者應該用 User Story 來測比較合理。用 User Story 就是測不到這種很詭異的問題。User Story 滿足的是商務需求的情境,但不會走過這種很 tricky 情境。

所以我想說的是:Coverage 這件事情在 RT 階段,不是一般人想的那麼簡單,也不是用說的。UT 的 Coverage 相對簡單,因為大部分有清楚的對象,也有清楚的範圍,而 RT 很多對象是不清楚,而且看不到範圍的邊界的。

另外,要把 Bug Automation 起來,實際上沒那麼容易,光是如何把問題自動化重現就是個考驗技術能力的事情。

  • 所以 Testcase 的管理是另一門專業與學問,也有專門的工具,像是 Testrail,他就是專門面對這樣的問題。Testrail 很貴不是沒道理的。
  • 關於 Bug Automation & Testrail 有空另外整理文章分享經驗

結論

測試說很簡單,做不容易,特別是自動化。

很多人 (特別是 Developer / PM / Boss) 會覺得有自動化、有 UT 軟體就安全了,實際上這只是第一步而已。

回歸測試是 工程問題統計問題、也是 政治問題,跟有沒有導入 Agile / Scrum / Kanban 沒關係。

當要管理、維護上千個 Testcase,同時要維護他們的 測試環境、報告時,很多事情已經不是那麼單純了,特別是產品已經上線一段時間了。特別是如果要快速跑完這些 Case (像是跑整個晚上 Overnight),分散式的批次作業就是加速的方式,這也是雲端流行之後,可以更快速自動化測試的方法之一。

而這些事情,導入 Agile / Scrum / Kanban 是不會知道的,但是他卻會直接影響 Release 的結果與品質,這就是 Regression Test (回歸測試) 的重要性。

用程式碼當作 Test case 不見得會比較好管理,因為如果那個 Code 的品質很糟糕,或者 Test tools 本身很不穩,那會是另一個大麻煩。參見怨念文:軟體自動化測試常見的問題自動化帶來的問題自動化 XXX 的陷阱

最近除了 iOS 爆炸了,還有 OS X 也是,如果你是 QA Manager,那你會怎麼做?

微軟一陣子會把整個 OS 砍掉重新架構,其實是有道理的。

延伸閱讀 (站內)


Comments