從 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 測試

詳細軟體測試階段的定義，請參閱淺談軟體測試的階段與策略的介紹。

以 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 是兩碼子事。

老樣子，詳細軟體測試階段的定義，請參閱淺談軟體測試的階段與策略的介紹。

回歸測試是不容易的 (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 砍掉重新架構，其實是有道理的。

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

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

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

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

結論

延伸閱讀 (站內)

相關資料

Comments

About

著作

演講

Facebook

AWS Certifications