大爱

用例结构优化心得

2013-04-24

在大型项目的测试中通常都伴随着大量的测试用例。如何优化用例以提高编写的效率,如何组织用例以提高执行的效率经常困扰着我们;因此总结了一些在编写用例时的心得。

1. 用例框架的优化

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

一般我们的用例框架是先以测试方法作为基础,第一层是测试类型,考虑系统所需要测试的测试类型。

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

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

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

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

3. 提取公共用例

在这个方法中,什么样的用例可以作为公共用例是最关键的。一般情况下可以作为公共用例的有两种类型:

第一种是测试方法在所有项目中通用,一般类似于翻页、导出、上传这些;测试方法统一,会因为设计的不同在每个项目中略有不同,但是在一个项目的各个地方的功能实现基本是一致的。此时一般会将用例设计写为一份,作为公共用例设计,但是测试用例会分散在各个模块中有多份以方便执行。

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

另外其实还会有一种比较不常见的公共用例,例如在报表系统中的ETL过程,虽然ETL过程是对数据进行抽取、转换、加载,是对不同的数据源进行处理,但实际在流程处理上是一致的,只会在需要进行数据进行有条件的转换时不一致。因此整一套流程实际就是一份公共用例。

第一种公共用例比较好分辨,第二种的话需要对逻辑设计有一定的认识,并且需要从开发那边获取信息,比如说开发把哪些部分封装成了公共调用方法;此时并不一定是一开始就规划了这部分作为公共用例,而是在写用例设计过程中发现大部分设计几乎相同,才会考虑开发是否会把此部分作为公共代码,能否作为公共代码以及与开发沟通他们准备如何实现。

4. 条件细分,正向组合

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

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

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

5. 场景分析剔除

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

6. 用例设计粒度的控制

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

使用支付宝打赏
使用微信打赏

若你觉得我的文章对你有帮助,欢迎点击上方按钮对我打赏

扫描二维码,分享此文章