源寶導讀：ERP是“業務密集”的大型復雜軟件，而且對于業務邏輯與數據的精確度要求幾乎是零容忍，其質量保障的挑戰很大。本文將介紹ERP平臺通過自動化測試保障質量的技術實踐。

一、自動化測試概念介紹

測試金字塔原理

1.1、測試的成本

? ? UI自動化依賴于用戶界面，用戶界面發生變化，可能需要調整大量用例，用例維護成本較高；在用戶界面的測試中發現缺陷，修復缺陷的成本也是遠遠高于通過單元測試的成本。單元測試不依賴于用戶界面，維護成本較低；單元測試發現的缺陷可以盡早暴露缺陷，修復成本相對較低。

1.2、測試的效率

? ? UI自動化測試需要準備數據，需要可以看到系統界面，還需要預先執行一些諸如登陸賬戶之類的操作，才能對測試用例進行驗證，所以花費時間比較長，得到的執行結果也比較慢，反饋周期長。而單元測試能很快地驗證很小的功能或者方法是否運行正確。而且單元測試運行時間短，反饋也及時。

1.3、缺陷定位的難易

? ? 單元測試如果失敗了，測試人員很容易知道被測試的特定功能或者方法不正確。而如果是用戶界面的缺陷，測試人員就需要花費更多的時間來進行排查，確定出現問題的功能模塊，最后開發分析再進一步地發現需要修復的功能和方法。

總述：

• 越往上，越接近QA、業務/最終用戶，越往下，越接近開發；

• 越往上，測試執行越慢，越往下，測試執行越快；

• 越往上，測試成本越高（越耗時，失敗時的信息越模糊，越難跟蹤），越往下，測試成本越低。

二、自動化測試如何做

? ? 按照測試金字塔模型，我們得知越向下回報率越高，所以應該使用大量的單元測試和全面的接口測試來覆蓋產品提供的基本邏輯和功能，使用少量的集成（UI）測試來進行前端界面的功能驗證。

? ? 業內最佳實踐如Google，Google的自動化分層投入占比是：單元測試（Unit）：占比70%；接口測試（Service）：占比20%；集成測試（UI）：占比10%。

概述：

• 單元測試：盡可能編寫單元測試覆蓋產品的功能邏輯，盡可能增加單元測試用例覆蓋率；

• 接口測試：首先保證所有公開接口正常場景、異常場景均覆蓋，再逐步覆蓋產品私有的核心接口用例；

• UI自動化測試：減少重復操作，將固化的回歸業務場景梳理，轉化為UI自動化用例。

三、單元測試用例設計

3.1、基于方法說明編寫單元測試用例

方法示例場景：參數省略

參數不省略：

參數取值場景：

參數類型不匹配場景：

3.2、基于測試業務角度

方法實現功能場景：

測試業務輸入等價類劃分：輸入與之前相同值

測試業務輸入等價類劃分：空值

測試業務輸入等價類劃分：空格

測試業務輸入等價類劃分：首尾空格

測試業務輸入等價類劃分：較長內容（設置了最大長度）

還有其他場景劃分的方法：

• 測試業務輸入等價類劃分：較長內容（未設置最大長度）；

• 測試業務輸入等價類劃分：特殊符號測試；

• 測試業務輸入邊界值分析：輸入內容剛好等于最大長度；

• (測試業務輸入邊界值分析：輸入內容比最大長度小1；

• 測試業務輸入邊界值分析：輸入內容比最大長度大1；

• 測試業務分析：只讀模式賦值。

3.3、基于開發代碼編寫單元測試用例

? ? 單元測試關注的是代碼的實現與邏輯。單元測試是最基本的測試，也是測試中的最小單元，它的對象是函數對象，也可以包含輸入輸出，針對的是函數功能或者函數內部的代碼邏輯。

單元測試的覆蓋種類：

• 語句覆蓋：語句覆蓋就是設計若干個測試用例，運行被測試程序，使得每一條可執行語句至少執行一次；

• 判定覆蓋（也叫分支覆蓋）：設計若干個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次；

• 條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次；

• 判定——條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次，并且每個可能的判斷結果也至少執行一次；

• 條件組合測試：設計足夠的測試用例，運行所測程序，使程序中每個判斷的所有條件取值組合至少執行一次；

• 路徑測試：設計足夠的測試用例，運行所測程序，要覆蓋程序中所有可能的路徑。

代碼示例：

null值測試：

undefined值測試：

tooltip測試：

四、UI自動化測試實踐

4.1、測試數據準備

測試數據庫準備；

數據腳本準備（如用戶登錄初始化腳本 ）；

自動化環境初始化配置。

基本信息配置：

數據庫信息配置：

登錄用戶配置 ：

4.2、測試用例頁面規劃

規劃要做UI自動化的頁面：

梳理固化的回歸業務場景；

規劃納入UI自動化的用例頁面（對于平臺 ，沉淀平臺組件、控件、平臺特性的用例頁面）；

根據選擇頁面錄制自動化腳本。

4.3、編寫測試用例

1、規劃設置公共片段；

2、基于業務場景操作組合片斷設計測試用例：

4.4、測試計劃配置及執行

1、選擇用例添加標簽；

2、配置定時執行計劃；

3、配置執行標簽、不執行標簽；

4、設置通知郵箱：

4.5、UI自動化與研發協同平臺打通

• jenkins與云測平臺關聯：

• • jenkins配置HashCode、應用、項目名稱、分支名稱參數；

• 云測平臺與Rdc關聯：

• • 云測平臺設置與Rdc項目、應用、分支名稱一致（必須保證：云測平臺、jenkins接口、RDC上三者一致） ?；

• Rdc觸發自動化閾值控制：

• • 分支流水線測試通過時自動收集自動化結果，并判斷自動化質量閾值。

五、關于TDD的學習與思考

5.1、什么是TDD

? ? 測試驅動開發(TDD)是敏捷中的一項核心實踐和技術，也是一種設計方法論。TDD的原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什么產品代碼。
? ? TDD的基本思路就是通過測試來推動整個開發的進行，但測試驅動開發并不只是單純的測試工作，而是把需求分析，設計，質量控制量化的過程。

5.2、TDD的目的

? ? TDD的目的不僅僅是測試軟件產品，保證代碼質量僅僅是其中一部分，而且是在開發過程中幫助客戶和程序員去除模棱兩可的需求。TDD首先考慮使用需求（對象、功能、過程、接口等），主要是編寫測試用例框架對功能的過程和接口進行設計，而測試框架可以持續進行驗證。

5.3、哪些可以做TDD

? ? 單元測試、接口測試可以使用TDD。

5.4、實施TDD需要什么

接口、事件、方法文檔輸出（包括方法使用說明、方法參數、方法調用示例、方法返回結果）；

TDD流程規范；

測試人員具備編碼能力，可以分析功能邏輯編寫測試代碼；

足夠的時間。

5.5、TDD可用于目前項目么

每次需求新增接口不多，接口文檔輸出較容易；

接口測試相較于單元測試，對測試人員編碼能力要求較低；

設計接口測試用例時間上不會額外占據太多時間。

5.6、結論

? ? 綜合考慮成本、人員能力等因素，接口測試TDD可優先考慮在迭代中執行。

------ END ------

作者簡介

邱同學：?測試工程師，目前負責ERP建模平臺的測試工作。

也許您還想看

接口測試用例設計思路

使用MiddleMan進行接口自動化實踐

研發協同平臺持續集成實踐

鏈路追蹤在ERP系統中的應用實踐

總結

以上是生活随笔為你收集整理的ERP平台的自动化测试技术实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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