本文探讨了软件测试领域中人员角色与职责的演变，强调了理想与现实之间的距离，以及在软件开发生命周期中，如何有效地整合功能与非功能测试的策略。文中详细介绍了测试金字塔理论，并阐述了不同测试阶段的重要性与实践经验，旨在帮助软件从业人员明确定位与提升专业能力。作者分享了个人经历，并提供了对行业发展的见解与建议。

1. 台灣軟體工程學會
從理想、到現實的距離
開啟品味軟體測試之路
1
Rick Hwang
2022/08/13 (Sat)

2. 2
source: https://www.hexschool.com/2022/06/23/2022-06-23-software-engineer-salary/

3. 那些人會跑去做 軟體測試：
1. 不喜歡寫 Code 的人：
a. 跑去做測試
b. 跑去做網管、維運
c. 跑去做 PM
2. 從 PM 轉換到測試，求生存
3. 喜歡探索軟體
4. 喜歡自幹一個產品
經驗談：不是很科學的刻板映像
3

4. 故事 理想
現實 探索
4

5. 1. 從一段故事開始
5

6. Rick Hwang
6
自詡為 軟體開發者 (Software Developer) ，工作角色
經歷 Software Develpoer、SQA Manager / SDET
Lead、Operation / Infrastructure Manager、Architect。
專長為系統架構、軟體開發、軟體測試、系統維運。這幾
年專注在 分散式系統、AWS、DevOps / SRE、經營管
理 等領域，著有技術部落格：Complete Think、譯著：分
散式系統設計。
工作之餘喜歡金庸武俠、科幻小說、經典文學、哲學、人
文藝術。
也是個業餘音樂愛好者，約有廿年的經驗，涉略涵蓋 吉
他、鍵盤、編曲、製作、教學，著有音樂部落格：喝咖啡
聊音樂 及 電子書 。

7. - Java EE
- Eclipse Plugins
- Unit Test
- Integration
- 8y
Software
Developer
Operation /
Infrastrcuture
Software Quality
Assurance
(SQA)
Software
Developer
Arch
- Fully Time QA
- Automation Test Framework and Architecture
- 網通產品: Datapower
- 2y
- Part Time QA
- WebUI Aumation
- Eclipse UI Automation
- 2y
7
SQA Manager
SDET Lead
HQA (Hardware)
- Fully Time QA
- Performance Test
- SDLC
- SQA Manager
- Startup BU
- IoT: IPCam / Streaming
- Webstore
- 3y

8. 8
Dev
QA
PM
Requirement
Spec
System Design
Unit Test
Coding
Test Plan Design Test Case E2E / Integration
Defect Fix
Prepare
Test Environment
Verify Defect
Ref: Software Development Lifecycle
Systems Analysis
Ops
備註：圖上的階段任務，都不是
絕對的。每個組織都有自己的跑法。

9. 9
● PM
a. Project Manager (PM)
b. Product Manager (PM)
c. Product Owner (PO)
● Dev
a. Developer
b. Engineer
c. Programmer
d. Coder
e. SED (Software Development Engineer,
Google)
四個角色、四種專業
● QA
○ Tester
○ QA (Quality Assurance)
○ SQA (Software Quality Assurance)
○ QE (Quality Engineer)
○ SDET (Software Development Engineer
in Test, Microsoft)
○ STE (Software Test Engineer, Google)
● Ops / Infra
○ OP (Operator), SysOps, SysOp
○ IT
○ MIS
○ Infra
○ SRE (Site Reliability Engieer, Google)
○ DevOps
○ SecOps / Security
軟體開發的四大角色 (Roles)

10. 10
Dev
QA
PM
Requirement
Spec
System Design
Unit Test
Coding
Test Plan Design Test Case E2E / Integration
Defect Fix
Prepare
Test Environment
Verify Defect
Ref: Software Development Lifecycle with PDCA
Systems Analysis
Ops
規劃Plan 執行Do 驗證 Check
Action: Do
Action: Plan
驗證 Check

11. 11
Ref: Software Development Lifecycle with PDCA
Dev
QA
PM
Ops
規劃Plan 執行Do 驗證 Check
Action: Do
Action: Plan
驗證 Check

12. 12
思考
1. 測試做到怎樣才是最好？怎麼確認好了？
2. 市面上有哪些好軟體？好產品？好服務？
3. 什麼是好軟體？
4. 測試結果沒有問題，就是高品質？品質是什麼？

14. 2. 現實與理想的距離
2.1 測試金字塔
2.2 功能與非功能
14

15. 情境：以電商為例
1. 去某個電商下單，完成購物流程。
2. 產生訂單快照，訂單快照必須標記下單時間、訂單編號
3. 確認訂單快照這個功能是正常的。
15

17. 2.1 The Test Pyramid
(測試金字塔)
17

18. source: https://martinfowler.com/articles/practical-test-pyramid.html
18
2.1 The Test Pyramid (測試金字塔)
執行速度快，範圍小
貼近使用者
貼近開發者
執行速度慢，範圍大
跨系統、跨功能
面積代表執行的比重
執行速度普通，範圍大

19. 19
● UI Tests / E2E (End to End)：
○ 從終端使用者 (End User) 到 終端系統 (End System)
整段的測試，最直接的測試方式就是透過 UI Tests
(User Interface Test)
○ 路徑最長，但也最貼近真實使用者的使用感受。
○ 執行時間較長
● Service Tests / Integration：
○ 整合測試，兩個異質元素的交互結果驗證。
○ 跨系統的整合，像是電商整合支付、分散式架構
○ 異質功能的整合：時間 + 電源？
○ 排列組合多、需要探索性，測試複雜度高
● Unit Test：
○ 單元測試，指的是 Code Level 的驗證，強調程式本身
的內聚保護，由 Dev 負責
○ 執行速度快，但是考驗架構能力
說明

20. Service Tests (服務測試) / Integration (整合測試)
1. 系統對系統
a. 內部對外部：Momo 串接 Google Map、SMS、支付 … etc.
b. 同一家公司內部系統：SMS、Push、認證授權 …
2. 功能對功能
a. 極端案例一：iOS 11.1 某個功能被時間影響到了
b. 極端案例二：iPad 的 Timer 跟充電 有關係
3. 功能對系統
a. 一分鐘之內同時湧入 1000 張訂單，但是所有的訂單快照，必須在 1 分鐘之內完成。
20

21. 21
source: https://martinfowler.com/articles/practical-test-pyramid.html
事前預防，符合 規格
無法 確認 是否滿足 需求
事後發現，確立符合需求
事前預防 + 事後發現
確保異質功能、異質系統交互正常
Dev
QA
Who?

22. 22
Ref: 如何有效的回報問題

23. 23
迷惘與誤區：太過重視某個，而忽略整體性
1. 太過重視某一個階段，例如強調 Unit Test 的重要性，但是 E2E 過不了 ⇒
Developers
2. 太過重視 E2E，而忽略 Unit Test 保護內聚力 ⇒ QA / Tester / STE
3. 上面兩個都忽略 Integration / Service Tests ….

24. 24
正確的測試策略：次序與循環
Service Tests
Integration
UI Tests
E2E
Unit Test
1
2
3
Ref: 飛輪效應》如何花更少力氣，推動公司更高速運轉

25. 背景：工作剛到職的狀況
1. 20+ 個 Developers 在美、中、台三地
2. 我一個 QA Manager / SDET Lead
a. 面試時候說要做 Automation Test (含 UT)、Performance
3. IoT 產品：IPCam 影像串流到手機 (iPhone / Andriod Phone / WinPhone)
4. 上班第一天被告知下個月產品要 上線
親身經歷
25

26. 親身經歷：測試策略
26
再回到那個測試金字塔，如果上述前述的前提，下個月上線，你會怎麼做？
1. 第一個禮拜，先 E2E 切入，整理 Test Cases
2. 開出數十個 Defect，請 APP / Server / Device 三個 Team 先修 Defects、聯測
，確認東西能動、能用，同時也爭取一點時間。
3. UT 先跳過，但先寫了 Core Libarary (Protocol Package Utils)，準備壓測
目標就是：下個月能上線。

28. 執行比重
28
Source: https://martinfowler.com/articles/practical-test-pyramid.html
Source: https://twitter.com/kentcdodds/status/960723172591992832
UI Tests / E2E
Integration
Unit
Test

29. 執行比重
29
Source: https://martinfowler.com/articles/practical-test-pyramid.html
Source: https://twitter.com/kentcdodds/status/960723172591992832
E2E
Integration
Unit Test

30. 所以，比重應該怎樣才對？
30

31. 這是 是非題？
還是 選擇題？
31

32. 32
0% 5%
10% 15%
10%
20%
15%
25%
企業發展階段
草創期
(招生意)
起步期
(做生意)
成長中
(管公司)
90% 80% 70% 60%
Service Tests
Integration
Unit Test
UI Test
E2E
人力配置比例：以電商為例
20%
30%
50%
發展中
(保客戶)
成熟期
(管產品)
Ref: 不同階段的企業

33. 33
決定比例『應該』如何如何
依照產品 / 產業性質
● 電商 / 網通：整合性很高的產品，Integration 比例一定會很高
依照企業發展階段
● 新創：20 人
● 成長中：200 以內
● 成熟期：500 以內
● 集團：幾千人

34. 34
了解就業目標的『局』
找到適合自己的定位 (位置)

36. 2.2 功能與非功能測試
36

37. 37
定義功能與非功能測試
● 功能需求 (Functional)：又稱 業務需求、領域需求、商業需求
○ 給客戶直接的價值，客戶會直接使用的功能
○ 把客戶帶進來，開啟新的業績
● 非功能需求 (Non-Functional)：非業務需求、系統需求
○ 客戶間接影響的功能，像是系統效能、資訊安全、系統可靠度、擴展性、使用體驗
○ 把客戶留下來，把讓客戶推銷產品的關鍵因素，把產品散出去

38. ● 功能需求：客戶能夠查閱訂單快照
● 非功能需求：
○ 無論同時成立幾張訂單，都能夠在『一分
鐘』之內查閱訂單快照

39. 1. 效能測試
2. 可靠度測試
3. 資訊安全
4. 使用者體驗
5. 建置與部署測試
6. 容量量測
7. 高可用性測試
8. …
非功能性測試：電商產業
39

40. 1. 客戶：請問你們的系統能夠處理多大的流量？
2. 業務：這季目標會有 200k 的使用者上限，我們系統撐得住？
3. 開發團隊：我們能不能知道系統每台運算單元的上限使用者數量？
40

41. 41
案例：業務目標
1. IPCam + Sensor: 100,000 同時上線
2. Mobile 使用者: 300,000 同時上線 ref: 如何量測系統的容量？

42. 42
10% 20% 30% 40%
企業發展階段
90% 80% 70% 60%
功能測試
非功能測試
人力配置比例：以電商為例
50%
50%
Ref: 不同階段的企業
草創期
(招生意)
起步期
(做生意)
成長中
(管公司)
發展中
(保客戶)
成熟期
(管產品)

43. 普遍的問題 / 刻板映像：
QA 只能負責 功能性測試？
43

45. 3. 探索自己職涯的路
45

46. 46
source: https://www.hexschool.com/2022/06/23/2022-06-23-software-engineer-salary/

47. 47
業務功能
(Biz / Functional)
非業務功能
(System / Non-Functional)
白箱
White
Box
Unit Test
Unit Test
Code Scan
黑箱
Black
Box
Integration
E2E
UAT (Happy Path)
Integration
Performance
Capacity
Reliability
Deployment
QA 在這裡
Web、電商、SaaS 網通、設備、IoT
Dev 在這裡
SDET / Sr. QA
SRE / Architect
Security
Sr. QA
Google, MSFT

48. 48
source: https://martinfowler.com/articles/practical-test-pyramid.html
事前預防，符合 規格
無法 確認 是否滿足 需求
事後發現，確立符合需求
事前預防 + 事後發現
確保異質功能、異質系統交互正常
Dev
QA
Sr QA / SDET
SRE / Architect

49. 49
Rick 對於 軟體品質 的看法
1. 品質不只有測試，而是整個 (開發) 過程。
a. 除了太空梭不能測，地球上沒有不能測的。
b. 品質從需求開始，測試只是種手段
c. 整個過程：SDLC (Software Development Lifecycle)
2. 用品質建立數量，由數量產生速度。
3. 優秀的 軟體測試 ，必須具備產品意識、 開發軟體 經驗、軟體架構設計、維運
經驗 能力才具備資格
ref: 學習法則

50. 1. 探索自己熟悉的、喜歡的領域
a. 可以廢寢忘食的，如果還沒有，那要多嘗試，年輕有失敗的本錢
b. 了解產品、了解使用者，做自主判斷
c. 電商、網通、NFT、Web3、毛小孩 … etc
2. 不知道自己喜歡什麼，找個持續成長的方式：
a. 喜歡是透過熟悉與成就感疊出來的
b. 充實軟體開發知識、 CS 基本技能，把 CS 知識用在生活中
c. 寫 Blog 是最好的投資，幾年後，你會感謝你自己。參 閱 學習法則
d. 精通一個軟體開發流程，掌握 品質的關鍵
e. 建立自己學習的循環
f. 給自己適度的獎勵
3. (給在職) 看清楚公司階段，看清自己的位置，找到自己的方向
50
給社會新鮮人 / 在職朋友的建議

51. 深耕 CS 基礎
1. Operating Systems (作業系統)
2. Computer Architecture (計算機系統結構)
3. Computer Organization (計算機組織)
4. Computer Network (計算機網路)
5. Data Structure (資料結構)
6. Algorithm (演算法)
工程實踐
7. Linux / Unix
8. Cloud: AWS / GCP
9. Kubernetes / Microservices
10. 軟體工程
11. DevOps / SRE
研讀經典
1. Google 的軟體測試之道
2. Agile Test
3. 人月神話
4. Peopleware
5. Refectoring / Design Pattern
6. 持續交付 / SRE
獨立思考、判斷
● 逆向思考
● 思考本質、實踐、抽象、想像力
51
給社會新鮮人 / 在職朋友的建議
給社會新鮮人 / 在職朋友的建議

52. 52
比重都要考慮以下
1. 產業：電商、網通、IoT、銀行
2. 企業發展階段
a. 決定功能與非功能的比重
b. 決定測試三角的比重
c. 開發流程角色的定義與比重
ref: 學習法則

54. 重點摘要
54

55. 55
測試策略：次序與循環
Service Tests
Integration
UI Tests
E2E
Unit Test
1
2
3
Ref: 飛輪效應》如何花更少力氣，推動公司更高速運轉

56. 56
0% 5%
10% 15%
10%
20%
15%
25%
企業發展階段
草創期
(招生意)
起步期
(做生意)
成長中
(管公司)
90% 80% 70% 60%
Service Tests
Integration
Unit Test
UI Test
E2E
找到自己的舞台
20%
30%
50%
發展中
(保客戶)
成熟期
(管產品)
Ref: 不同階段的企業

57. 57
業務功能
(Biz / Functional)
非業務功能
(System / Non-Functional)
白箱
White
Box
Unit Test
Unit Test
Code Scan
黑箱
Black
Box
Integration
E2E
UAT (Happy Path)
Integration
Performance
Capacity
Reliability
Deployment
QA 在這裡
Dev 在這裡
SDET / Sr. QA
SRE / Architect
Security
Sr. QA

58. 今天分享構思的原由
2019/10/30: 關於軟體測試，一些觀察到的現象
58

59. Reference
1. 2018/02/26: The Practical Test Pyramid - martinfowler.com
2. 2019/05/16: 什麼是測試左移（Shift-Left testing）？
3. 2019/07/04: 飛輪效應》如何花更少力氣，推動公司更高速運轉 - 商周
4. 2022/06/23: 軟體工程師薪水 - 六角學院
59

60. Complete Think
1. 2014/05/09: 軟體自動化測試常見的問題
2. 2017/07/14: Software Development Lifecycle
3. 2017/09/03: 不同階段的企業
4. 2017/09/20: 學習法則
5. 2017/11/26: 思考本質、實踐、抽象、想像力
6. 2017/12/03: 從 iOS 無限黑屏事件，談軟體測試階段 - 回歸測試 Regression Test
7. 2018/03/18: 如何有效的回報問題
8. 2018/03/18: 輕鬆聊：系統測試 (SVT) 的三兩事
9. 2019/10/30: 關於軟體測試，一些觀察到的現象
60

61. 感謝聆聽
61
Rick Hwang
2022/08/13 (Sat)