從理想、到現實的距離，開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)
0 likes6,083 views
Date: 20220813 (六) 主辦單位: 台灣軟體工程協會 (https://www.seat.org.tw/event/2022testing) 內容摘要： 分享從無到有建立軟體測試團隊的經歷，探討軟體測試常見的現象，像是『測試金字塔的現實與理想』、『功能與非功能驗證混搭』，最後透過探索與品味軟體的想法，希望能讓社會新鮮人進入職場後，在軟體開發與測試路上，找到適合自己的路。 Blog：https://rickhw.github.io/2022/08/13/SQA/Path-to-Software-Testing/ 錄影：https://youtu.be/WAK-kMzi8wc
![[B22] PostgresPlus Advanced Server の Oracle Database 互換機能検証 by Noriyoshi Shinoda](https://cdn.slidesharecdn.com/ss_thumbnails/b22postgresplusadvancedservershinoda-131125024333-phpapp02-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to 從理想、到現實的距離，開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813) (20)
![[Agile Tour Hsinchu 2019] Our practice in the DevOps Process for Manufacture ...](https://cdn.slidesharecdn.com/ss_thumbnails/devopsmanufacture-191214052228-thumbnail.jpg?width=560&fit=bounds)
More from Rick Hwang (20)
從理想、到現實的距離，開啟品味軟體測試之路 - 台灣軟體工程協會 (20220813)
- 3. 那些人會跑去做 軟體測試： 1. 不喜歡寫 Code 的人： a. 跑去做測試 b. 跑去做網管、維運 c. 跑去做 PM 2. 從 PM 轉換到測試，求生存 3. 喜歡探索軟體 4. 喜歡自幹一個產品 經驗談：不是很科學的刻板映像 3
- 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?
- 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
- 30. 所以，比重應該怎樣才對？ 30
- 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 以內 ● 集團：幾千人
- 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
- 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
- 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