测试⽤例怎么优化？这⾥有测试⽼鸟分享的6个⼼得
（松勤软件测试讯）在⼤型项⽬的测试中通常都伴随着⼤量的测试⽤例。如何优化⽤例以提⾼编写的效率，如何组织⽤例以提⾼执⾏的效率经常困扰着我们；因此，松勤程⽼师在这边总结了⼀些在编写⽤例时的⼼得。世界杯规则
1⽤例框架的优化
那年夏天宁静的海 歌词⼀份好的⽤例设计需要有⼀个好的⽤例框架的⽀撑，因此⽤例结构优化的第⼀步就是优化⽤例框架。⼀般我们的⽤例框架是先以测试⽅法作为基础，第⼀层是测试类型，考虑系统所需要测试的测试类型。
打开襟翼如果⽤例偏重于场景法的话，那么第⼆层是场景考虑，此时暂不要去思考如何实现；如果⽤例偏重于模块测试的话，那么第⼆层是你划分的各个模块；如果⽤例设计偏重于逻辑路径的话，那么第⼆层是你每个路径主要实现的功能。
第三层是功能点，以场景为导向的考虑的是实现这个场景需要哪些功能模块⽀撑，每个模块做什么；以模块为导向的则考虑每个模块中主要实现的功能点；以路径为导向的则是考虑路径中的功能点的实现。
2组件机制与模块功能的分离
关于桃花最出名的诗句不管是什么组件，总有它⾃⼰使⽤的机制，与它实现的功能点没有任何关系。最常见的是调度机制以及最基本的配置读取的机制。这些都可以剥离出来单独测⼀次就够了，不需要在每个模块中测⼀次，重复编写⽤例。
3提取公共⽤例取名字男孩
在这个⽅法中，什么样的⽤例可以作为公共⽤例是最关键的。⼀般情况下可以作为公共⽤例的有两种类型：
第⼀种是测试⽅法在所有项⽬中通⽤，⼀般类似于翻页、导出、上传这些；测试⽅法统⼀，会因为设计的不同在每个项⽬中略有不同，但是在⼀个项⽬的各个地⽅的功能实现基本是⼀致的。此时⼀般会将⽤例设计写为⼀份，作为公共⽤例设计，但是测试⽤例会分散在各个模块中有多份以⽅便执⾏。
第⼆种是在⼀个项⽬中多个组件共同使⽤的⽅法，此时会将⽤例设计与⽤例都单独作为⼀份进⾏编写，执⾏时也只需要执⾏⼀遍就可以，不需要在每个组件中再单独都执⾏。
另外其实还会有⼀种⽐较不常见的公共⽤例，例如在报表系统中的ETL过程，虽然ETL过程是对数据进⾏抽取、转换、加载，是对不同的数据源进⾏处理，但实际在流程处理上是⼀致的，只会在需要进⾏数据进⾏有条件的转换时不⼀致。因此整⼀套流程实际就是⼀份公共⽤例。
微博阅读量
第⼀种公共⽤例⽐较好分辨，第⼆种的话需要对逻辑设计有⼀定的认识，并且需要从开发那边获取信息，⽐如说开发把哪些部分封装成了公共调⽤⽅法；此时并不⼀定是⼀开始就规划了这部分作为公共⽤例，⽽是在写⽤例设计过程中发现⼤部分设计⼏乎相同，才会考虑开发是否会把此部分作为公共代码，能否作为公共代码以及与开发沟通他们准备如何实现。
4条件细分，正向组合
如果涉及到的⽤例是由很多条件组合控制的话，尽量将⽤例设计中的各个条件细分到最⼩的粒度，⽽不是使⽤组合的⽅式展现。
当条件细分到最低粒度的时候很多的⽤例设计就有了共同的地⽅，此时就会出现很多可复⽤的测试⽤例设计，这样能够减少⽤例设计的⼯作量。
然后再在细分到最⼩粒度的⽤例设计基础上进⾏⼀定的组合优化，因为有些正向数据实际是由多个最⼩粒度的条件组合⽽成，不需要单独进⾏验证，所以组合后能够减少⽤例执⾏的时间。
5场景分析剔除
对于状态控制很多的⽤例，需要进⾏⼀定的场景分析，对⼀些不存在的场景进⾏⽤例的删除。因为即使开发没有做对应的控制，要求开发修改的可能性也⾮常⼩，并且此类的修改没有意义。
6⽤例设计粒度的控制
如果测试要求粒度特别细的状态下，⽤例量⼏乎是翻倍的。这是可以从路径覆盖的⾓度上分析，实际会发现有很多重复检查某⼀部分的⽤例量。此时需要我们做的是测试⽤例粒度的把控。在最正常的路径中做详细的测试，在其他路径中做粒度略粗的测试，⼀定要特别注意有没有
特殊场景不能做粒度的放粗。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论