保證用例的覆蓋度澎埠，一直是測試人員追求的目標(biāo)虽缕，只有用例覆蓋了，才能確保該功能經(jīng)過測試蒲稳。

而沒有覆蓋到的氮趋，只有靠探索式、隨機(jī)測試等方式了江耀。

但是這些方式并不是絕對可靠的剩胁，因此在寫測試用例時，對業(yè)務(wù)流程祥国、高風(fēng)險功能昵观、高訪問頻率的功能保證測試用例覆蓋，是對產(chǎn)品質(zhì)量的有效保障舌稀。

那么要如何才能保證覆蓋度呢啊犬？根據(jù)經(jīng)驗(yàn)大致談?wù)劇?/p>

1. 覆蓋顯性需求
需求文檔或原型圖上已經(jīng)標(biāo)注清楚的功能一定要全部覆蓋，通過思維導(dǎo)圖工具進(jìn)行梳理一般都能保證壁查。

2. 獲取隱含需求
隱含需求的獲取是一大難點(diǎn)觉至，但需求就像冰山，露在水面的始終只是極少的一部分潮罪。

• 行業(yè)
  測試某個產(chǎn)品康谆，要對產(chǎn)品所針對的業(yè)務(wù)要清楚领斥。一般每個行業(yè)都有一定的規(guī)范嫉到、標(biāo)準(zhǔn)。同時復(fù)雜的業(yè)務(wù)月洛，也會有專門的行業(yè)研究何恶。比如電商、物流嚼黔、ERP细层、CRM、財(cái)務(wù)唬涧、OA 等系統(tǒng)都有其自身的業(yè)務(wù)體系疫赎。
  作為測試人員，測試某個行業(yè)的業(yè)務(wù)碎节，就要學(xué)習(xí)該行業(yè)的業(yè)務(wù)知識捧搞，才能保證測試時能夠考慮得更加全面。

• 競品分析
  競品也就是同類的產(chǎn)品，需求分析也講究競品分析胎撇，每個行業(yè)都有標(biāo)桿性的軟件介粘，這些軟件代表了該領(lǐng)域的高水平設(shè)計(jì)。那么對這些產(chǎn)品的分析晚树，取長補(bǔ)短姻采，同時也能獲取到很多需求中沒有描述到的內(nèi)容。
  比如電商爵憎，多關(guān)注淘寶慨亲、京東、拼多多宝鼓、唯品會等巡雨；比如視頻，關(guān)注優(yōu)愛騰（優(yōu)酷席函、愛奇藝铐望、騰訊）；比如直播茂附，關(guān)注斗魚正蛙、虎牙等；比如小視頻营曼，關(guān)注抖音乒验、快手、美拍等蒂阱。根據(jù)自己的業(yè)務(wù)類型關(guān)注對應(yīng)領(lǐng)域的產(chǎn)品锻全。簡單看看應(yīng)用商城分類排行榜也就一目了然了。

• 溝通記錄
  如果可能收集到產(chǎn)品經(jīng)理在與客戶溝通的原始記錄录煤，也能夠更好的理解客戶的本意鳄厌。在獲知客戶本意的基礎(chǔ)上，更容易揣摩用戶的隱含需求妈踊。

• 站在用戶的角度分析
  如果可能多與一線的使用終端的用戶溝通了嚎，可以獲取第一手的用戶使用流程±扔可以更好的站在用戶的角度去思考歪泳。
  你作為一個用戶，在什么場景下會使用這個產(chǎn)品露筒，使用這個產(chǎn)品是為了達(dá)成什么目標(biāo)呐伞，為了達(dá)成這個目標(biāo)會怎么做？
  比如一個OA系統(tǒng)中的請假條慎式，用戶可能會先有請假的計(jì)劃伶氢，那么會提前申請假哎；也有可能用戶需要臨時緊急請假；還有生病了鞍历，要先請假后提請假申請等各種情況舵抹。

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

3. 合理使用合適的用例設(shè)計(jì)方法

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

• 歷史問題分析
  我們常說錯誤猜測法，由于軟件缺陷的免疫性掠兄、集中性像云、反復(fù)性，錯誤猜測法是除教科書式的測試用例設(shè)計(jì)方法以外最有效的用例設(shè)計(jì)方法蚂夕。
  但是錯誤猜測法有一個最大的問題迅诬，就是要基于測試經(jīng)驗(yàn)的積累。沒有大量的實(shí)際項(xiàng)目經(jīng)驗(yàn)是難以有效的猜測哪些地方容易出 bug 的婿牍。
  這里結(jié)合經(jīng)驗(yàn)給大家?guī)c(diǎn)建議：
  a. 典型問題：收集每次項(xiàng)目中的典型問題侈贷，這些典型問題極具代表性，比如查詢功能中的日期范圍問題等脂，比如輸入為空的判斷俏蛮；
  b. 出現(xiàn)頻率高的問題：每次項(xiàng)目的測試報(bào)告中對高頻率的 Bug 進(jìn)行收集和分析；
  c. 線上遺漏問題：客戶遺漏問題上遥，往往是測試過程中忽略的問題搏屑，極具參考價值，對于測試范圍露该、用例設(shè)計(jì)的改進(jìn)有很大的意義睬棚。
  Bug 管理工具上的 Bug 是一個寶庫，好好分析總結(jié)收集解幼，會有很多可見或不可見的好處。

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

• 測試思路
  測試人員在參與用例評審害晦，通過講解用例體現(xiàn)每個人的測試思路特铝，這時其他成員可以檢驗(yàn)該測試人員有沒有測試范圍的偏差暑中、測試思路的欠缺等。
  通過用例評審及時糾正鲫剿，可以避免后期測試過程中方向性的錯誤鳄逾。

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

• 不同人員負(fù)責(zé)模塊交叉部分
  一般在體量較大的項(xiàng)目，都會有多個測試人員協(xié)調(diào)分工搞动，每人負(fù)責(zé)一部分模塊午笛。這些模塊與模塊之間都可能存在交互。
  如果每個測試人員閉門造車苦锨，那么可能就會忽略很多模塊之間的交互內(nèi)容逼泣。
  通過用例評審，測試人員可以結(jié)合互相模塊之間交互的地方舟舒，檢查有沒有被忽略的需求點(diǎn)圾旨。