| 名稱 | 分母 | 分子 | 示例 |
| 手工測試覆寫率 | 所有測試用例 | 手工測試執行的用例 | A系統目前3個測試工程師參與了4個月，寫了近300條測試用例，那目前的300條就作為整個測試覆寫率的分母 |
| 接口覆寫率 | 接口總數 | 測試涉及的接口總數 | 系統有10個接口，對其中8個做了接口自動化測試，那麼覆寫率就是80% |
| 自動化測試覆寫率 | 測試用例總數 | 自動化測試涉及的測試用例總數 | 系統有100條測試用例，其中有60條用例已經被自動化腳本化測試，那麼覆寫率是60% |
| 測試用例覆寫率 | 測試功能點總數 | 自動化測試涉及的測試功能點 | 系統有100條測試用例，400個測試功能點（checkpoint），其中200個Checkpoint已經被自動化測試腳本測試，那麼覆寫率是50% |
| 需求覆寫率 | 所有使用者故事或任務 | 已被測試的使用者故事或任務 | 目的：測試的行為覆寫了每一個需求 |
| 缺陷覆寫率 | 已被發現并修複的缺陷數量 | 對缺陷進行自動化測試的數量 | A系統上線前共發現了70個缺陷，測試工程師将這70個“已經被修複”的缺陷寫成了自動化測試用例 |
| 代碼行覆寫率 | 代碼總行數 | 被執行過的代碼行數 | 一個Java應用有10W行代碼，執行了一次手工回歸測試，同時也觸發了自動化測試腳本，然後利用Jacoco元件檢視看測試覆寫率，發現10W行代碼中，有3W行代碼已經被覆寫了，那麼代碼行覆寫率就是30% |
| 代碼分支覆寫率 | 代碼總分支數 | 被執行過的代碼分支數 | 本質上與代碼行覆寫率一樣，隻是統計的次元不一樣 |
自動化測試覆寫率的案例分享
思路：剔除無意義的套路代碼，結合不同的覆寫率名額，綜合得出一個相對有價值的覆寫率資料。
做法：
1，搭建測試覆寫率環境
Java使用的是Jacoco元件，其他程式設計語言可以使用其他覆寫率統計元件
2，執行自動化測試腳本
觸發自動化測試腳本執行，等待執行完畢。
上圖說明：
- 綠色區域：代碼行覆寫率充分，100%覆寫了該代碼。
- 黃色區域：代碼行覆寫不充分。
- 紅色區域：代碼行未經過覆寫。
- 綠色鑽石：代碼分支覆寫率充分，100%覆寫了該代碼分支。
- 黃色鑽石：代碼分支覆寫率不充分。
- 紅色鑽石：代碼分支未經過覆寫。
請注意，此時請勿打開測試環境的系統頁面、接口調用等操作，保證資料的真實性。
3，篩選掉無意義的套路代碼
以SpringBoot架構為例，如bean、model、entity、util、mapper、dao、constant、config等目錄，大部分都是套路的代碼統統過濾掉。
留下有業務意義的代碼目錄：controller、service目錄和自己封裝的業務函數類，服務端代碼的業務邏輯運算、接口的代碼邏輯都在這裡，這才是代碼的核心部分。
自動化腳本執行完成後，Jacoco測試覆寫率從0%變成了多少，那麼目前的自動化測試腳本覆寫率就是多少。
重點：
代碼覆寫率本身具有局限性，因為100%的代碼覆寫率并不能說明系統品質沒有問題。是以除了關注已被測試行為覆寫的代碼，更重要的是觀察未被覆寫的代碼，因為這部分是沒有測試用例覆寫到的，讓測試工程師自己發現思維的不足、遺漏的用例，這才更有價值。