如何保证测试用例的广度?

     个人理解相对深度而言，广度是指覆盖率。一般在以下3个阶段来考虑保证测试用例的覆盖率。

　　阶段1：测试用例设计时一般做如下考虑：

　　1、最基本的先保证以正反两大类用例全面覆盖需求(且先不论需求中的主次)，其中包括

　　(1)细化各种数据类型，达到有效和无效数据类型的覆盖

　　(2)细化各种流程分支(考虑主流程、辅流程、异常处理、出错处理等)

　　2、考虑需求不完善之处(如与其它模块的交互、如对于性能的要求等)，进一步补充用例

　　3、考虑设计约束(如分页处理、并发处理等)，进一步补充和修改用例

　　阶段2：测试用例设计好后与需求人员、开发人员、组内其他测试人员组织评审，可以吸取大家从不同角度看到的遗漏之处，进行补充;

　　阶段3：测试执行阶段

　　测试用例执行时可能产生新的测试想法，可以补充;根据测试覆盖率工具提供的报表，可以发现没有执行到的代码，对测试用例再进行补充;进行用户验收测试或上了产品后，用户报告的问题也可以补充到测试用例中去，提高覆盖率。

 

--------------------------

补充：

最近在看一本书，书上对于用例的设计提出了新的思维思考，按照一般的需求覆盖到测试需求，是将整个大模块再划分成小模块再划分为检查点再划分测试点。。以这样的方式来进行覆盖，覆盖率基本上能有个把握。（我在以前都是那么进行划分）
其实我们可以从用户的角度来划分，比如说用户使用的核心功能，然后围绕这些功能再将与它存在业务逻辑联系的功能扩展进去这些从这个角度上，可以挖掘更多的测试点。但是它的缺点就是覆盖率不能把握。
可以将这两种方式一起结合起来进行分析。