保证用例的覆盖度，一直是测试人员追求的目标，只有用例覆盖了，才能确保该功能经过测试。
而没有覆盖到的，只有靠探索式、随机测试等方式了。
但是这些方式并不是绝对可靠的，因此在写测试用例时，对业务流程、高风险功能、高访问频率的功能保证测试用例覆盖，是对产品质量的有效保障。
那么要如何才能保证覆盖度呢？根据经验大致谈谈。
1. 覆盖显性需求
需求文档或原型图上已经标注清楚的功能一定要全部覆盖，通过思维导图工具进行梳理一般都能保证。
2. 获取隐含需求
隐含需求的获取是一大难点，但需求就像冰山，露在水面的始终只是极少的一部分。
行业
测试某个产品，要对产品所针对的业务要清楚。一般每个行业都有一定的规范、标准。同时复杂的业务，也会有专门的行业研究。比如电商、物流、ERP、CRM、财务、OA 等系统都有其自身的业务体系。
作为测试人员，测试某个行业的业务，就要学习该行业的业务知识，才能保证测试时能够考虑得更加全面。竞品分析
竞品也就是同类的产品，需求分析也讲究竞品分析，每个行业都有标杆性的软件，这些软件代表了该领域的高水平设计。那么对这些产品的分析，取长补短，同时也能获取到很多需求中没有描述到的内容。
比如电商，多关注淘宝、京东、拼多多、唯品会等；比如视频，关注优爱腾（优酷、爱奇艺、腾讯）；比如直播，关注斗鱼、虎牙等；比如小视频，关注抖音、快手、美拍等。根据自己的业务类型关注对应领域的产品。简单看看应用商城分类排行榜也就一目了然了。沟通记录
如果可能收集到产品经理在与客户沟通的原始记录，也能够更好的理解客户的本意。在获知客户本意的基础上，更容易揣摩用户的隐含需求。站在用户的角度分析
如果可能多与一线的使用终端的用户沟通，可以获取第一手的用户使用流程。可以更好的站在用户的角度去思考。
你作为一个用户，在什么场景下会使用这个产品，使用这个产品是为了达成什么目标，为了达成这个目标会怎么做？
比如一个OA系统中的请假条，用户可能会先有请假的计划，那么会提前申请；也有可能用户需要临时紧急请假；还有生病了，要先请假后提请假申请等各种情况。通用规范
对于用户体验、界面样式等都有一定的通用规范或者业界都认可的一些方案。那么这些经过检验的内容，也可以帮助我们提高隐含需求的覆盖度。
3. 合理使用合适的用例设计方法
常规设计方法
等价类、边界值、流程分析法等常规的用例设计方法自不必说，这是测试人员的基本技能，通过合理的用例设计方法可以有效提高测试用例覆盖度。历史问题分析
我们常说错误猜测法，由于软件缺陷的免疫性、集中性、反复性，错误猜测法是除教科书式的测试用例设计方法以外最有效的用例设计方法。
但是错误猜测法有一个最大的问题，就是要基于测试经验的积累。没有大量的实际项目经验是难以有效的猜测哪些地方容易出 bug 的。
这里结合经验给大家几点建议：
a. 典型问题：收集每次项目中的典型问题，这些典型问题极具代表性，比如查询功能中的日期范围问题，比如输入为空的判断；
b. 出现频率高的问题：每次项目的测试报告中对高频率的 Bug 进行收集和分析；
c. 线上遗漏问题：客户遗漏问题，往往是测试过程中忽略的问题，极具参考价值，对于测试范围、用例设计的改进有很大的意义。
Bug 管理工具上的 Bug 是一个宝库，好好分析总结收集，会有很多可见或不可见的好处。
4. 用例评审
用例评审是保证用例覆盖度的一种制度性的方案。用例评审一般是需求、开发和测试三方参与。
测试思路
测试人员在参与用例评审，通过讲解用例体现每个人的测试思路，这时其他成员可以检验该测试人员有没有测试范围的偏差、测试思路的欠缺等。
通过用例评审及时纠正，可以避免后期测试过程中方向性的错误。覆盖度
通过用例评审可以借助开发、需求从不同的角度来提高用例的覆盖度。
需求人员可以从业务的角度、用户使用的角度来检验用例的覆盖度；
开发人员可以从设计和编码的角度，为测试人员提供代码逻辑层面的逻辑覆盖。不同人员负责模块交叉部分
一般在体量较大的项目，都会有多个测试人员协调分工，每人负责一部分模块。这些模块与模块之间都可能存在交互。
如果每个测试人员闭门造车，那么可能就会忽略很多模块之间的交互内容。
通过用例评审，测试人员可以结合互相模块之间交互的地方，检查有没有被忽略的需求点。
