测试用例优化

1、用例框架的优化

一份好的用例设计需要有一个好的用例框架的支撑，因此用例结构优化的第一步就是优化用例框架。

一般我们的用例框架是先以测试方法作为基础:

第一层是测试类型，考虑系统所需要测试的测试类型。

第二层是关注用例的偏重点

• 用例偏重于场景法的话，那么第二层是场景考虑，此时暂不要去思考如何实现
• 用例偏重于模块测试的话，那么第二层是你划分的各个模块
• 用例设计偏重于逻辑路径的话，那么第二层是你每个路径主要实现的功能。

第三层是功能点

• 以场景为导向的考虑的是实现这个场景需要哪些功能模块支撑，每个模块做什么；
• 以模块为导向的则考虑每个模块中主要实现的功能点；
• 以路径为导向的则是考虑路径中的功能点的实现。

 

2.组件机制与模块功能的分离

不管是什么组件，总有它自己使用的机制，与它实现的功能点没有任何关系。最常见的是调度机制以及最基本的配置读取的机制。这些都可以剥离出来单独测一次就够了，不需要在每个模块中测一次，重复编写用例。

3.提取公共用例

一般情况下可以作为公共用例的有两种类型：

第一种是测试方法在所有项目中通用，一般类似于翻页、导出、上传这些；

第二种是在一个项目中多个组件共同使用的方法，此时会将用例设计与用例都单独作为一份进行编写，执行时也只需要执行一遍就可以，不需要在每个组件中再单独都执行。

4.条件细分，正向组合

如果涉及到的用例是由很多条件组合控制的话，尽量将用例设计中的各个条件细分到最小的粒度，而不是使用组合的方式展现。

当条件细分到最低粒度的时候很多的用例设计就有了共同的地方，此时就会出现很多可复用的测试用例设计，这样能够减少用例设计的工作量。

然后再在细分到最小粒度的用例设计基础上进行一定的组合优化，因为有些正向数据实际是由多个最小粒度的条件组合而成，不需要单独进行验证，所以组合后能够减少用例执行的时间。

5.场景分析剔除

对于状态控制很多的用例，需要进行一定的场景分析，对一些不存在的场景进行用例的删除。因为即使开发没有做对应的控制，要求开发修改的可能性也非常小，并且此类的修改没有意义。

6.用例设计粒度的控制

如果测试要求粒度特别细的状态下，用例量几乎是翻倍的。这是可以从路径覆盖的角度上分析，实际会发现有很多重复检查某一部分的用例量。此时需要我们做的是测试用例粒度的把控。在最正常的路径中做详细的测试，在其他路径中做粒度略粗的测试，一定要特别注意有没有特殊场景不能做粒度的放粗。