iT邦幫忙

2022 iThome 鐵人賽

DAY 14
1
自我挑戰組

開始系統測試系列 第 14

Day 14 | 軟體測試階段(一) - 單元測試與整合測試

  • 分享至 

  • xImage
  •  

一、測試階段的分類

  • 測試階段也稱為測試級別
  • 分類
    • 單元測試
    • 整合測試
    • 系統測試
    • 驗收測試

二、單元測試

  1. 什麼是單元?
    • 單元是軟體內最小的、可以單獨執行程式碼的單位。
    • 對於控制語言(如C、Visual Basic等),通常由一個或多個最接近的函式(function)或過程(procedure)所組成
    • 對於物件導向設計(如Java、C++等),可以是一個類或類的實例,或者由方法(method)來實現功能
    • 對於網頁或是視窗介面,單元可以是一個文字輸入框或一個按鈕等。
  2. 什麼是單元測試(Component Testing)?
    1. 針對一個軟體單元的測試
    2. 這個階段的測試通常由開發人員執行,發現缺陷後立刻進行修改,也沒有任何形式的紀錄
  3. 單元測試的重點、所需知識和前置條件
    • 測試重點
      • 功能性測試
      • 健壯性 - 逆向測試:無效值
      • 性能
    • 所需知識/know-how
      • 開發知識和技能
      • 基本的測試技術
    • 前置條件
      • 完成編譯的測試對象
      • 測試環境
      • 開發工具
      • 測試對象的規範說明
  4. 單元測試使用的技術和能發現的缺陷
    • 典型的技術
      • 白箱測試技術(語句、分支覆蓋等) - 觀察程式的每一個過程是否符合需求
      • 黑箱測試技術(等價類劃分、邊境值分析等) - 只看輸出結果是否正確
      • 一般情況下是先黑後白,但白箱測試用的更多,白箱和黑箱是一起寫案例的。
    • 能發現的缺陷
      • 單元內的功能性缺陷
      • 運行時的缺陷
      • (本機)效能問題
      • 健壯性問題
    • 可能遺留的缺陷
      • API問題
      • 「大環境」的問題
      • 許多非功能性的缺陷
  5. 單元測試需要撰寫程式碼
    • 驅動程式(Driver) - 通過API與測試對象通訊的輔助工具,用於調用被測式的單元或系統替代性程式。
    • 模擬函數(Stub) - 替代或模擬還沒完成的單元(模組),用於模擬輸入和輸出(針對尚未完整的功能)
    • 模擬軟體(Simulation) - 用一個系統來描述另一個要測試的抽象系統行為驗證

https://ithelp.ithome.com.tw/upload/images/20220929/201408784vPdHzlFLs.jpg

三、整合測試

  1. 什麼是整合?
    • 把單元/系統合併為更大部件的過程
  2. 什麼是整合測試(Integration Testing)?
    • 目標在暴露API以及整合組件/系統間交互時存在的缺陷測試。
    • 有多種整合類型,如:
      • 單元整合測試(compoment integration testing) - 測試目的在於發現API和整合後單元間協同工作的缺陷。
        • 參數的輸入與輸出為API,而傳遞過程為交互
        • API側重於靜態,交互則側重於動態
        • 一般常說的整合測試就是單元整合測試
      • 系統整合測試(system integration testing)
        • 測試系統和其他軟體包的整合:如商務標準軟體(Commercial Off-The-Shelf software,COTS)的整合
        • 測試與外部系統的API和交互:如電子數據的交換、網路
    • 單元測試通常是單人執行,而整合測試通常是多人或第三方執行。
  3. 整合測試的重點、所需知識和前置條件
    • 測試重點
      • API
      • 系統內不同部分的交互作用
    • 所需知識/know-how
      • 最好具備開發知識和技能(有可能需要測試Driver和Stub)
      • 測試技術
      • 具備有關單元間的交互知識 - 單元間傳遞什麼參數、這些參數需要做什麼處理
    • 前置條件
      • 完成整合的被測系統
      • 測試平台(test bed) - 在單元測試階段使用的一些工具可能在整合測試階段中被反覆使用
      • 有關單元間交互的文件
  4. 整合測試使用的技術和能發現的缺陷
    • 典型的技術
      • 白箱測試技術(內部API)
      • 黑箱測試技術(等價類劃分、邊境值分析等)
      • 一般情況下仍是先黑後白,但白箱測試用的更多,白箱和黑箱是一起寫案例的。
    • 能發現的缺陷
      • API的缺陷
      • 單元間的協調錯誤
    • 可能遺留的缺陷
      • 相關單元外的問題
      • 整個系統需求的不滿足
      • 與外部系統的API常常被忽略
  5. 整合測試的策略
    • 向下整合(top-down integration)
    • 向上整合(bottom-down integration)

https://ithelp.ithome.com.tw/upload/images/20220929/201408783NNhQJfIMc.jpg


上一篇
Day 13 | 錯誤推測
下一篇
Day 15 | 軟體測試階段(二) - 系統測試與驗收測試
系列文
開始系統測試30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言