測試工程師常見的任務

• 開發測試工具
• 開發針對安全或性能測試的工具
• API 或協議測試的自動化
• BUG 大掃除 ( bug bashes )
• 撰寫測試計畫
• 寫測試案例的文件
• 執行手工測試
• 核心測試範例自動化

從這裡面我可以切出 8 張票

- [ ] 1, 撰寫 scripts 自動測試
    - [ ] 1.1. 單元測試
    - [ ] 1.2. 效能測試
    - [ ] 1.3. 安全測試
- [ ] 2. API 測試自動化
- [ ] 3. 安排時間 Bug bashes (大家一起找 bug)
- [ ] 撰寫測試計畫
    - [ ] 添加到規格書中
- [ ] 寫測試案例的文件
    - [ ] 針對核心測試範例寫文件

里程碑模式

對項目的版本做規劃，每個里程碑都要有：

• 階段標準 Exit Criteria
  • 關鍵功能完畢
  • 中期測試目標達到 ( 代碼覆蓋率 + 測試完成率達標 )
  • 缺陷目標達到 ( 無 P1 Bug , 第一嚴重 BUg )
  • 非功能目標達到 ( 性能, 負荷測試完成, 無嚴重問題 )

各里程碑(M1,M2,M3,Release) 的目標

• M0
  • 準備各種定義
    • 目標文件
    • 專案管理流程
    • 發布目標
    • 功能規格書
    • 功能優先次序表
    • 里程碑進度
• M1
  • 執行：無要求
  • 覆蓋：都能測量並生成報告
  • 可靠性：無要求
  • 功能：無要求
  • 性能：完成性能測試並生成報告
• M2
  • 執行：P1 Case 都能執行
  • 覆蓋：65%
  • 可靠性：解決 M1 中 50% Issue
  • 功能：20% 擁有公開介面
  • 性能：確立性能基準線與目標性能
• M3
  • 執行：P1 Case + P2 Case 都能執行
  • 覆蓋：75%
  • 可靠性：解決 M2 中 50% Issue
  • 功能：50% 擁有公開介面
  • 性能：全面性能測試自動化完成
• Private Build:
  • 一個介在 M3 與 Release 之間的版本
• Release:
  • 所有 Case 都能執行
  • 覆蓋：80%
  • 解決 M3 中 70% Issue
  • 功能：100% 公開介面
  • 性能：全面性能目標達到
• MQ:
  • Release 之後到下個階段之前，空檔時間能還債
  • 大量 debug
  • 規劃一個 Code Review 流程
  • 衡量所有 bug 哪些 bug 可以在更早之前里程碑解決掉, 並找到衡量方法
    • 例如 for 迴圈 20 行

質量門檻

• L1 所有測試都通過
• L2 功能性 Bug 都修復, Issue 都關閉
• L3 性能要求達標
• L4 測試計畫書完成，對所有測試都有提供說明
• L5 所有程式碼都通過審查
• L6 文件完成
• L7 安全性的應對計畫已完成
• L8 代碼覆蓋率達 80%
• L9 所有功能在不同環境中都能正常運作

宏觀視野

• 開發人員的輸出粒度：
  • 程式碼 Code
  • 函數 functionality
  • 產品功能 feature
    • 戰術：怎麼工作的更有效率
  • 專案 Project
    • 戰略&戰術
  • 產品線 Product
    • 長期戰略
    • 業務需求

各階段版本

• LKG (Last Know Good) 已知最近一個符合特定質量標準的版本
  • L1 LKG, L2 LKG, L3 LKG, L4 LKG …
• Self-host 自用版 - 內部團隊可以在日常生活中使用的版本
• Visual freeze 介面凍結版本
  • 在某個時間點開始視覺效果和 API 介面被凍結, 在發行前不再改變
• debug build 除錯版 裡面支援很多除錯功能的版本
• free build 銷售版 為發行而做各種最後優化得到的版本
• Alpha 目標是得到功能和可用性的初步回饋的版本
• Beta 預定發布的版本，希望得到反饋

測試規格

• 目標與摘要
• 策略
• 功能測試
• 元件測試
• 整合測試
• 互操作性測試
• 一致性測試
• 國際化測試/全球化測試
• 性能測試
• 安全測試
• 安全或部屬測試
• 依賴關係釐清
• 各種度量方法

測試用例

• 驗證測試
• 錯誤避免測試
• 開心路徑

功能測試

• 等價類劃分 Equivalence class partitioning ECP
  • 如何對等價類劃分為合法和非法子集? 變數分解
    • 過量分解會造成 false negatives / false positives
    • 總是避免冗餘測試
    • 四種啟發式方法
      • 範圍
      • 分組
      • 唯一值
      • 特殊值
    • 子集分類以 v 開頭 ex: v1, v2, v3, v4
    • 建立 "測試設計矩陣"
    • ECP 目的主要是暴露 "單點故障"
      • 單點故障假設 : 通常系統很少是 2 或多個故障共同作用的結果
• 邊界值分析 BVA
  • 邊界值的測試數量可以用 4n+1 來計算, n = 獨立參數個數
  • 建立 BVA 測試矩陣
  • 隱性邊界
    • 不是所有邊界都能透過數字輸入輸出確定
    • 例如視窗高低, 循環指令的邊界
  • the deja-vu heuristic 定義最小邊界值和忽上忽下於邊界值的數值
    • 循環指令的邊界以內, 不准進入錯誤處理分支
    • 循環指令的邊界上和外，必須初始化錯誤處理分支
• 組合分析
  • 對於半耦合 (semicouple) 的參數的測試方法
    • 分支測試 EC
      • 對每個變數都測試至少一次
    • 基準測試 BC
      • 指定一組變數作為基準來測試
      • 通常是快樂路徑常用的變量狀態組合
    • 正交陳列 OA
    • 組合測試 t=n
      • 可以隨機化生成這些矩陣, 方便提高廣度
      • 矩陣中的配對, 可以盡可能找到合適的覆蓋率
      • 以及可以接受的未覆蓋函數量
    • 窮舉測試 AC
• 標準覆蓋率
  • 這個階段主要依賴腳本化測試
• 實際可達覆蓋率
  • 這個階段透過探索性測試
  • 並再依定情況開始採用結構測試

結構測試

• 塊狀測試 Block Test
  • 針對程式碼中的一個個 Block 做測試
  • 另一個重要性是在異常處理 Exception Handling
• 決策測試 Decision Testing
  • 主要對 if/else 來測試
  • 不能有效評估複合條件判斷流程
• 條件測試 Condition Testing
  • 多個條件語句 AND/OR 組合而成
  • 劃出控制流程圖
  • 在寫出函數中各個條件的 true/false 的測試矩陣以及期待值
• 基礎路徑測試 Basic Path Testing
  • 對整個控制流程進行測試
  • 圈複雜度 cyclomatic complexity
  • 基礎路徑技術 baseline path technique
  • 簡化基礎路徑技術 simplified baseline path technique
  • 實用基礎路徑技術 practical baseline path technique

程式碼複雜度

• LOC 程式碼行數
• 圈複雜度 cyclomatic complexity
  • 1-10 低風險
  • 11-20 中等複雜度
  • 21-50 高度複雜度
  • 50+ 非常高風險/不可測試
  • 圈複雜度高不代表缺陷就多
    • 煙霧警告度量：煙多不保證火災
• Halstead 測量
  • 主要用於衡量可維護姓
• 對物件的測量
  • 類權重方法 WMC 類中的方法數
  • 繼承樹深度 DIT 一個類繼承的類總數
  • 物件間耦合度 CBO 一個類引用其他類的總數
  • 扇入扇出 fan-in/fan-out 衡量一個類有調用到其他類多少次
    • 如果一個類方法被調用 5 次而這 5 次會造成他調用其他 10 個類
    • 那扇入就是 5 而扇出就是 10

基於模型的測試

• MBT Model-based testing
• 基於模型的刺是不是為了 end-to-end scenario
• 而是為了中間的過程變化
• smart monkey test 聰明猴子測試, 隨機行走
  • 在整個模型流程中隨機執行跳轉各步驟

Bug 處理流程

• 運行測試 -> 建立 bug 報告 -> 三方會審 triage
• 重現 Reproduction
  • How Found: 怎麼重現錯誤
  • Issue Type: 程式碼問題, 設計問題, 文件問題
  • Bug Type: 安全, 性能, 功能 …
  • Source: 測試來源
• 缺陷沒有被批准就不修正
  • 重複的 bug (duplicate)
  • 推遲 Postpone
  • 外部錯誤 External
  • 設計錯誤 By Design
• 批准了就要開始調查 inverstigation approved 看是什麼問題
  • 必須修正 Must Fix
  • 應修正 Should Fix
  • 有時間就修正 Fix if time
• 提出如何修正

缺陷的衡量 Metric

• 修復的缺陷/所有解決的缺陷相對其他 Issue 的比例
  • 用這個來衡量開發處於早期還是晚期
• 各種程式語言/平台的缺陷比例
  • 衡量環境問題和開發的是否有特定領域瓶頸
• 缺陷發現率
  • 太高或太低都要擔心, 對峰值進行解釋
• 錯誤修正率
  • 當標準提高後, 修正比例應該下降
• 根據不同領域來看缺陷數
  • 可能那個領域需要更多測試或協助
• 不同嚴重性的缺陷數
  • 隨著發展嚴重性S1,S2 應該要像降, 而S3,S4會上升 Severity
  • 一般期待在早期發現更多嚴重的缺陷
• 缺陷重新復發比率
  • 這是一個衡量程序修正質量很好的標準
  • 當專案快要結束時, 這個會開始變多和達到最大
• 平均反映缺陷時間
  • 跟蹤開發團隊對缺陷的反應速度
• 平均關閉缺陷時間
  • 反映大家對問題的解決速度
• 缺陷門檻 (缺陷 bars)
  • 指一個開發人員在一定時間內所能接受的缺陷數量
  • 當超過這個數量介會被停止開發功能, 必須立即修補缺陷
  • 但也可能被濫用, 大家分工缺陷量

測試用例模板

• 測試用例編號
• 功能區
• 功能分區
• 優先級 (1,2,3,4)
• 類別 (功能性?性能?負載?)
• 頻率 (每次構建?)
  • 版本驗證測試 BVT
  • 每夜測試
  • 里程碑測試
  • 內部迭代至少一次
• 測試時間
• 運行方式
  • 手動/半自動化(需要一定程度手動)/自動化
• 描述
  • 測試目的
    • 到底要驗證什麼
  • 初始條件和背景
    • 確定那些條件是重要的先決條件
  • 步驟(測試點 Test Point) 1.

    2.

    3.
-   預期結果
    -   通過 Pass
    -   受一個具體的檢查點 checkpoint 規範
-   備註

自動化測試

• 設置 Setup
  • 將環境設定好
• 執行 Execution
  • 執行測試的特定步驟,充分錯誤處理,其他相關工作
• 分析 Analysis
  • 分析為什麼失敗
• 報告 Reporting
  • 報告包含日誌/資料庫/其他分析結果文件
• 清理 Cleanup
  • 清理當前環境狀態已讓下次繼續進行
• 幫助 Help
  • 在其測試生命週期如何保持可維護性
• 測試日誌應該包含的元素
  • 測試ID Test ID
  • 測試名稱 Test Name
  • 環境訊息 Environment Information
  • 被測程式訊息 Application Under Test Information AUT Info
  • 測試結果 Test Result
• 測試結果的分類
  • 通過 Pass
  • 失敗 Fail
  • 跳過 SKip 跳過環境不支援的特定測試
  • 放棄 Abort 測試失效時就直接放棄
  • 阻斷 Block 被阻止不會讓測試失敗率更加增高
  • 警告 Warn 雖然通過了旦指出需要更細緻檢查某些地方

其他工具

• churn 改動: 在一段時間內, 文件和模塊被修改的次數
  • 也就是被改動的次數
    • 修改次數
    • 增加行數
    • 刪除行數
    • 修改行數
• Total churn 可以顯示出在哪個地方可能有最多潛在 bug
• 驗收測試 BATs Build acceptance tests/ BVTs Build verification tests
• 應該每天或更頻繁的 Build
  • rolling builds 滾動構建
  • 自動同步到最新的 code
• BATs 比 BVT 範圍小一點
• BVT 屬性
  • Automate Everything (在每次 Build 前運行)
  • Test a little (驗證基本功能的簡單測試, 確保構建可被用於測試)
  • Test Fast (要求快速幾分鐘測試, 快速給予反饋)
  • Fail Perfectly 如果 BVT 失敗要立即修復失敗的地方
  • Test Broadly not Deeply 盡可能多涵蓋關鍵功能
  • Debuggable and Maintainable (BVT 會自動到 code 裡面找哪個change造成)
  • Trustworthy 可信 (要能信任 BVT 通過)
  • Critical 關鍵 (BVT 應該由最值得信賴的人建立)
• 程式碼分析成本 Code Analysis Overload
  • 全新項目早期分析的缺陷幾乎注意不到
  • 成熟階段使用帶來額外工作量

後記

花一個晚上看完，覺得收穫良多，裡面還有推薦很多參考書籍，未來可以看看

Buzz Word

• TTM ( Time to market ) 產品從構思到銷售的總時間
• assign 指派修正
• postpone 推辭處理 -> 技術負債
• 不要聽河馬的
  • 河馬 HiPPO ( Highest Paid Person's Opinion ) 指最高薪資的人
• BDUF - Big Design Up Front 指各種費時的預先設計和撰寫文件的動作
• look and feel 外再體驗

Tags: reading testing

« 在 Emacs 中使用 counsel-gtags Emacs 中透過 (which-function) 取得當前函數名稱 »