在大型项目的测试中通常都伴随着大量的测试用例。如何优化用例以提高编写的效率，如何组织用例以提高执行的效率经常困扰着我们；因此总结了一些在编写用例时的心得。
一份好的用例设计需要有一个好的用例框架的支撑，因此用例结构优化的第一步就是优化用例框架。
一般我们的用例框架是先以测试方法作为基础，第一层是测试类型，考虑系统所需要测试的测试类型。
如果用例偏重于场景法的话，那么第二层是场景考虑，此时暂不要去思考如何实现；如果用例偏重于模块测试的话，那么第二层是你划分的各个模块；如果用例设计偏重于逻辑路径的话，那么第二层是你每个路径主要实现的功能。
第三层是功能点，以场景为导向的考虑的是实现这个场景需要哪些功能模块支撑，每个模块做什么；以模块为导向的则考虑每个模块中主要实现的功能点；以路径为导向的则是考虑路径中的功能点的实现。
不管是什么组件，总有它自己使用的机制，与它实现的功能点没有任何关系。最常见的是调度机制以及最基本的配置读取的机制。这些都可以剥离出来单独测一次就够了，不需要在每个模块中测一次，重复编写用例。
在这个方法中，什么样的用例可以作为公共用例是最关键的。一般情况下可以作为公共用例的有两种类型：
第一种是测试方法在所有项目中通用，一般类似于翻页、导出、上传这些；测试方法统一，会因为设计的不同在每个项目中略有不同，但是在一个项目的各个地方的功能实现基本是一致的。此时一般会将用例设计写为一份，作为公共用例设计，但是测试用例会分散在各个模块中有多份以方便执行。
第二种是在一个项目中多个组件共同使用的方法，此时会将用例设计与用例都单独作为一份进行编写，执行时也只需要执行一遍就可以，不需要在每个组件中再单独都执行。
另外其实还会有一种比较不常见的公共用例，例如在报表系统中的ETL过程，虽然ETL过程是对数据进行抽取、转换、加载，是对不同的数据源进行处理，但实际在流程处理上是一致的，只会在需要进行数据进行有条件的转换时不一致。因此整一套流程实际就是一份公共用例。
第一种公共用例比较好分辨，第二种的话需要对逻辑设计有一定的认识，并且需要从开发那边获取信息，比如说开发把哪些部分封装成了公共调用方法；此时并不一定是一开始就规划了这部分作为公共用例，而是在写用例设计过程中发现大部分设计几乎相同，才会考虑开发是否会把此部分作为公共代码，能否作为公共代码以及与开发沟通他们准备如何实现。
如果涉及到的用例是由很多条件组合控制的话，尽量将用例设计中的各个条件细分到最小的粒度，而不是使用组合的方式展现。
当条件细分到最低粒度的时候很多的用例设计就有了共同的地方，此时就会出现很多可复用的测试用例设计，这样能够减少用例设计的工作量。
然后再在细分到最小粒度的用例设计基础上进行一定的组合优化，因为有些正向数据实际是由多个最小粒度的条件组合而成，不需要单独进行验证，所以组合后能够减少用例执行的时间。
对于状态控制很多的用例，需要进行一定的场景分析，对一些不存在的场景进行用例的删除。因为即使开发没有做对应的控制，要求开发修改的可能性也非常小，并且此类的修改没有意义。
如果测试要求粒度特别细的状态下，用例量几乎是翻倍的。这是可以从路径覆盖的角度上分析，实际会发现有很多重复检查某一部分的用例量。此时需要我们做的是测试用例粒度的把控。在最正常的路径中做详细的测试，在其他路径中做粒度略粗的测试，一定要特别注意有没有特殊场景不能做粒度的放粗。
原文：http://www.cnblogs.com/shengs/p/3790079.html