在DevOps建設中，主流的測試分層體系可以分為單元測試、接口測試和界面測試。Google曾提出一個經驗法則：70%的小型測試，20%的中型測試，10%大型測試。

當然，這個比例不是確定的，不同類型的項目，測試需求也不相同：

• 單元測試粒度最細，外部依賴少，適合開發團隊快速排查錯誤，從而保證代碼質量和異常處理；?
• 接口測試相對界面測試成本較低，可以在標準的開發環境下運行，效益較高；?
• 界面測試最為直觀，但成本高，外部依賴多，實施起來最困難，接口測試和界面測試保證了產品的質量和數據驗證。

一、單元測試

今天我們來講講單元測試。

• 對于面向過程語言，單元是一個函數；
• 對于面向對象語言，單元是一個類；
• 如果是圖形化軟件，單元可能是一個窗口或者菜單。

總而言之，單元測試指人為規定的最小被測功能模塊。?缺少單元測試的項目會帶來沒有必要的重復工作，缺乏持續反饋機制，導致問題、壓力、風險積累到后期爆發。充分的單元測試可以保證代碼的質量和良好的異常處理。

根據測試內容將測試任務分為：強制性測試和推薦性測試。

• 強制性測試包括：模塊接口、局部數據結構、出錯處理；
• 推薦性測試包括：路徑測試、第三方服務、數據訪問層、超時測試。

• 模塊接口測試，指對通過被測模塊的數據流進行測試；
• 局部數據結構，要求檢查數據類型說明、初始化、缺省值等；
• 出錯處理，指檢查錯誤處理功能是否包含錯誤；
• 路徑測試，指對基本執行路徑和循環進行測試，建議覆蓋所有的邏輯語句；
• 超時測試，指測試生產代碼在某些情況下的運行時間是否會超過可容忍程度；
• 數據訪問層測試，指驗收數據訪問框架與SQL語句的聯合正確性；
• 第三方測試，指檢查代碼是否成功調起第三方服務。

實際開發中，要求開發人員針對生產代碼必須進行強制性測試，選擇進行推薦性測試，并且測試粒度達到一定要求。

二、自動化單元測試

自動化單元測試由四個關鍵部分組成：

• 通過版本控制系統實現配置管理；
• 由構建工具來管理依賴；
• 測試框架方便測試用例編寫和批量測試；
• 通過反饋平臺可以很方便的查看測試結果。

三、農行自動化單元測試實踐

還在擔心上手難？看看我行是如何做自動化單元測試的。

例如Java開發的項目。

• 單元測試、打包、部署等都通過Maven的生命周期管理，測試用例的編寫遵循Junit規范；
• 項目的構建可以通過代碼提交，也可以通過定時按周期觸發；
• 構建結束后在TFS上能夠看到構建單元測試歷史，以及單元測試代碼覆蓋率等信息。

今天的自動化單元測試內容就先分享到這里，接下來，還有更精彩的接口和界面自動化測試的內容分享，敬請關注！

【作者簡介】葉嵐

2009年加入農行，現任軟件開發中心項目管理辦公室質量控制組高級專員，從事測試過程管理和質量控制相關工作。

總結

以上是生活随笔為你收集整理的【DevOps进行时】自动化测试之单元测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。