保證用例的覆蓋度，一直是測試人員追求的目標，只有用例覆蓋了，才能確保該功能經過測試。

而沒有覆蓋到的，只有靠探索式、隨機測試等方式了。

但是這些方式并不是絕對可靠的，因此在寫測試用例時，對業(yè)務流程、高風險功能、高訪問頻率的功能保證測試用例覆蓋，是對產品質量的有效保障。

那么要如何才能保證覆蓋度呢？根據經驗大致談談。

1. 覆蓋顯性需求
需求文檔或原型圖上已經標注清楚的功能一定要全部覆蓋，通過思維導圖工具進行梳理一般都能保證。

2. 獲取隱含需求
隱含需求的獲取是一大難點，但需求就像冰山，露在水面的始終只是極少的一部分。

• 行業(yè)
  測試某個產品，要對產品所針對的業(yè)務要清楚。一般每個行業(yè)都有一定的規(guī)范、標準。同時復雜的業(yè)務，也會有專門的行業(yè)研究。比如電商、物流、ERP、CRM、財務、OA 等系統都有其自身的業(yè)務體系。
  作為測試人員，測試某個行業(yè)的業(yè)務，就要學習該行業(yè)的業(yè)務知識，才能保證測試時能夠考慮得更加全面。

• 競品分析
  競品也就是同類的產品，需求分析也講究競品分析，每個行業(yè)都有標桿性的軟件，這些軟件代表了該領域的高水平設計。那么對這些產品的分析，取長補短，同時也能獲取到很多需求中沒有描述到的內容。
  比如電商，多關注淘寶、京東、拼多多、唯品會等；比如視頻，關注優(yōu)愛騰（優(yōu)酷、愛奇藝、騰訊）；比如直播，關注斗魚、虎牙等；比如小視頻，關注抖音、快手、美拍等。根據自己的業(yè)務類型關注對應領域的產品。簡單看看應用商城分類排行榜也就一目了然了。

• 溝通記錄
  如果可能收集到產品經理在與客戶溝通的原始記錄，也能夠更好的理解客戶的本意。在獲知客戶本意的基礎上，更容易揣摩用戶的隱含需求。

• 站在用戶的角度分析
  如果可能多與一線的使用終端的用戶溝通，可以獲取第一手的用戶使用流程?？梢愿玫恼驹谟脩舻慕嵌热ニ伎?。
  你作為一個用戶，在什么場景下會使用這個產品，使用這個產品是為了達成什么目標，為了達成這個目標會怎么做？
  比如一個OA系統中的請假條，用戶可能會先有請假的計劃，那么會提前申請；也有可能用戶需要臨時緊急請假；還有生病了，要先請假后提請假申請等各種情況。

• 通用規(guī)范
  對于用戶體驗、界面樣式等都有一定的通用規(guī)范或者業(yè)界都認可的一些方案。那么這些經過檢驗的內容，也可以幫助我們提高隱含需求的覆蓋度。

3. 合理使用合適的用例設計方法

• 常規(guī)設計方法
  等價類、邊界值、流程分析法等常規(guī)的用例設計方法自不必說，這是測試人員的基本技能，通過合理的用例設計方法可以有效提高測試用例覆蓋度。

• 歷史問題分析
  我們常說錯誤猜測法，由于軟件缺陷的免疫性、集中性、反復性，錯誤猜測法是除教科書式的測試用例設計方法以外最有效的用例設計方法。
  但是錯誤猜測法有一個最大的問題，就是要基于測試經驗的積累。沒有大量的實際項目經驗是難以有效的猜測哪些地方容易出 bug 的。
  這里結合經驗給大家?guī)c建議：
  a. 典型問題：收集每次項目中的典型問題，這些典型問題極具代表性，比如查詢功能中的日期范圍問題，比如輸入為空的判斷；
  b. 出現頻率高的問題：每次項目的測試報告中對高頻率的 Bug 進行收集和分析；
  c. 線上遺漏問題：客戶遺漏問題，往往是測試過程中忽略的問題，極具參考價值，對于測試范圍、用例設計的改進有很大的意義。
  Bug 管理工具上的 Bug 是一個寶庫，好好分析總結收集，會有很多可見或不可見的好處。

4. 用例評審
用例評審是保證用例覆蓋度的一種制度性的方案。用例評審一般是需求、開發(fā)和測試三方參與。

• 測試思路
  測試人員在參與用例評審，通過講解用例體現每個人的測試思路，這時其他成員可以檢驗該測試人員有沒有測試范圍的偏差、測試思路的欠缺等。
  通過用例評審及時糾正，可以避免后期測試過程中方向性的錯誤。

• 覆蓋度
  通過用例評審可以借助開發(fā)、需求從不同的角度來提高用例的覆蓋度。
  需求人員可以從業(yè)務的角度、用戶使用的角度來檢驗用例的覆蓋度；
  開發(fā)人員可以從設計和編碼的角度，為測試人員提供代碼邏輯層面的邏輯覆蓋。

• 不同人員負責模塊交叉部分
  一般在體量較大的項目，都會有多個測試人員協調分工，每人負責一部分模塊。這些模塊與模塊之間都可能存在交互。
  如果每個測試人員閉門造車，那么可能就會忽略很多模塊之間的交互內容。
  通過用例評審，測試人員可以結合互相模塊之間交互的地方，檢查有沒有被忽略的需求點。