在项目的初期，我们参与到需求评审中

　　需求文档或原型图上已经标注清楚的功能一定要全部覆盖，通过思维导图工具进行梳理一般都能保证。

　　2.获取隐含需求

　　隐含需求的获取是一大难点，但需求就像冰山，露在水面的始终只是极少的一部分。

　　3.合理使用合适的用例设计方法

　　常规设计方法：等价类、边界值、流程分析法（场景法）等常规的用例设计方法自不必说，这是测试人员的基本技能，通过合理的用例设计方法可以有效提高测试用例覆盖度。

　　正向的用例+反向用例

　　除了功能测试用例之外，还有性能测试用例、安全测试用例、UI、兼容性测试用例等、易用性测试用例等等。

　　4、历史史问题分析：把项目中典型问题、高频率问题、线上遗漏问题进行分析，进行本次测试用例的改进设计。

　　我们常说错误猜测法，由于软件缺陷的免疫性、集中性、反复性，错误猜测法是除教科书式的测试用例设计方法以外最有效的用例设计方法。

　　但是错误猜测法有一个最大的问题，就是要基于测试经验的积累。没有大量的实际项目经验是难以有效的猜测哪些地方容易出bug的。

　　这里结合经验给大家几点建议：

　　a.典型问题：收集每次项目中的典型问题，这些典型问题极具代表性，比如查询功能中的日期范围问题，比如输入为空的判断；

　　b.出现频率高的问题：每次项目的测试报告中对高频率的Bug进行收集和分析；

　　c.线上遗漏问题：客户遗漏问题，往往是测试过程中忽略的问题，极具参考价值，对于测试范围、用例设计的改进有很大的意义。

　　Bug管理工具上的Bug是一个宝库，好好分析总结收集，会有很多可见或不可见的好处。

　　5、用例评审

　　用例评审是保证用例覆盖度的一种制度性的方案。用例评审一般是需求、开发和测试三方参与。

　　测试人员在参与用例评审，通过讲解用例体现每个人的测试思路，这时其他成员可以检验该测试人员有没有测试范围的偏差、测试思路的欠缺等。通过用例评审及时纠正，可以避免后期测试过程中方向性的错误。

　　覆盖度

　　通过用例评审可以借助开发、需求从不同的角度来提高用例的覆盖度。需求人员可以从业务的角度、用户使用的角度来检验用例的覆盖度；开发人员可以从设计和编码的角度，为测试人员提供代码逻辑层面的逻辑覆盖。

　　不同人员负责模块交叉部分

　　一般在体量较大的项目，都会有多个测试人员协调分工，每人负责一部分模块。这些模块与模块之间都可能存在交互。如果每个测试人员闭门造车，那么可能就会忽略很多模块之间的交互内容。通过用例评审，测试人员可以结合互相模块之间交互的地方，检查有没有被忽略的需求点。