在 “淺談軟體測試的階段與策略“ 整理了各種測試的 “階段”，其中 #整合測試 (Integration Test) 是常見的階段之一，針對 “整合” 我的脈絡有以下：

1. 功能對功能 的整合
2. 系統對系統 的整合
3. 功能對系統 的整合

引用我 上次分享 整理的文字描述，如下圖：

Source: 演講：從理想、到現實的距離，開啟品味軟體測試之路

20230523 更新: 本文部分收錄在 共同著作《軟體測試實務》 第一冊 第五章之中，歡迎大家彭場指導。

整合功能的案例

整合功能其實生活中很多，大家平常在用的產品都很常出現。

案例：功能對系統的整合

上次分享 中我用 PCHome 的訂單快照 + 訂單快照的 SLA 來當整合的例子，這是個 功能對系統 整合測試的案例。

案例：功能對系統的整合

另外一篇 “有效回報問題“ 則舉例很久以前我自己遇過的例子：時間跟充電 兩個整合造成的問題。這也算是 功能對系統 的整合問題。當時的錄影如下：

文中針對問題現象做以下紀錄：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

## Environment

- iOS 11.4.1
- iPad Air 128Gb.

## How to reproduce?

1. connect the power adapter to iPad
2. open Click app, tap Timer, set a countdown in 5s
3. start the countdown
4-1: stop the sound by tab Home button,
4-2: stop the sound by swiping up notification

## Expected Result

Sound should be stopped.

## Acturl Result

Sound keeps playbacking, unstoppable.

## Notes
- Remove power adapter to fix the issue.
- No issue on iPhone6

案例：功能對功能的整合

最近 iPhone 14 上市了，新的功能 動態島 (Dynamic Island) 成為大家讚不絕的設計。這樣的功能改善了視覺上的體驗。但很快的鄉民就發現這個功能和 既有的功能 (橫向螢幕) 一整合問題就出來了，這也典型的 功能對功能 整合的案例。

整合測試的 理論範圍

整合 的基本定義：

1. 平面二維，也就是(A + B) 的概念，兩個功能的整合
2. 三維或以上：A + B + C 或者 A + B + C + D … 三個或以上的功能混合。

在軟體設計時，如果沒有針對功能與功能之間作討論與規劃，整合功能會出現 Defect or 新功能，是無法預測的。

舉例來說，iOS 的設定列表上假設有 5 個功能 (A, B, C, D, E)，這 5 功能彼此之間有沒有關係？先不管有沒關係，先假設都有關係，而且是一對一的組合，那麼這五個功能之間有多少排列組合？用二維的概念來列舉排列組合如下：

1. A: A + B, A + C, A + D, A + E = 4
2. B: B + C, B + D, B + E = 3
3. C: C + D, C + E = 2
4. D: D + E = 1
5. E: 0

以上共有 4 + 3 + 2 + 1 = 10 個組合，簡單列個公式：

n (n-1) / 2

有 10 個功能，組合有 45 個、20 功能組合有 190 個。這是二維的整合，如果是三維的整合功能，那複雜度就更高了。

這段描述不管是二維、還是三維以上的前提是：功能彼此之間是攤平的，不是巢狀結構，沒有上下依存關係。功能的關係是立體的，數量的公式就不是這麼單純的了。

排列組合的好處是可以看到理論的最大範圍，也就是如果出問題，應該都在排列組合之內。缺點則是排列組合會包含很多不合使用邏輯、不會真實存在的情境。

宇宙可觀測範圍 是天文學家推論的理論值範圍，實務上人類可能到地球毀滅都還是走不出銀河系。

整合測試的 可執行策略

在軟體測試的過程，首先會依照上述的理論範圍規劃測試計畫？實務上不會，所以執行測試也就不會這樣做，因為勞民傷財。

實務上的 執行策略 都是根據核心情境，和 核心功能 (Happy Path) 展開，以此列出有關的排列組合，列出來的就是要放入測試計畫中執行的，這樣大概就可以扣除排列組合 70% 以上的範圍。這時候所謂的自動化進場才有實務上的價值。

以這次 iPhone 14 動態島來看，理論上測試計畫必須依照這個新的關鍵功能展開，列舉可能有關的功能組合。只要是跟畫面位置、動畫有關係的功能，應該都要列入測試範圍。所以以結果論來看，我會覺得蘋果的測試管理應該要加強。 XDD

那剩下的 70% 的組合怎麼辦？這時候所謂的 探索性測試 (Exploratory Testing) 或 田野/現場測試 (Field Testing) 就是扮演著重要的階段。實務上這兩種差異前者是 Release 前 (In-House)，後者是 Run on Production。我比較常用的是後者 Field Test，也就是 As a End User 的角度，直接像是鄉民那樣，試各種極端值，各種不合邏輯的排列組合。以前測 IoT 產品就是團隊全都人都發一套帶回家用，有問題直接回報。同時在辦公室也把了全部的產品，實際上在辦公室也在用。

現在很多公司其實是直接把探索性測試外包給 Youtuber / KOL 處理，在產品 Release 前就先收回饋，避免到田野之後鄉民的反饋更大。因為 Youtuber / KOL 可以幫忙擋 XDD

這概念跟 Unit Test 的邊界測試是一樣的。

說說測試管理

軟體測試 的 Lead 有個很重要的任務：

測試管理

測試管理的工作範圍很大，其中之一是要定義：

1. 測試理論範圍
2. 可執行的範圍
3. 探索與現場測試策略

定義這些範圍，才會有效地往下展開測試計畫、資源調度、有效執行、有效建議。
因為只有這樣，才能回答那句：

為什麼這個沒有測到？

延伸閱讀 (站內)

• 淺談軟體測試的階段與策略
• 演講：從理想、到現實的距離，開啟品味軟體測試之路
• 如何有效的回報問題
• 新書上市 - 共同著作《軟體測試實務 I、II》