设计用于自动化的Regression Testcase
一种更高效率的方式是，在功能验证testcase里挑选一些。比如把一些主要的testcase标记为regression，而把细枝末节的，和一些异常情况testcase排除在外。在我经历过的一个测试组织中，他们使用了一种类似的方法，那就是在功能验证测试之外，重新定义一个regression testcase库，这些testcase的组织方式是按照产品的功能逐渐细化，每一个testcase代表了一个足够细化的功能点，整个testcase库看上去像产品功能树。
但是，这还不是最高效率的regression testcase设计，至少对于大多数的企业应用程序来说是如此。企业应用程序一般属于自动化数据处理系统(Automatic Data Processing System)，ERP系统是比较典型的自动化数据处理系统。这种程序的特点是，1）系统具有很高的可配置型，可以按照企业的不同需求配置。2）系统具有多个接口，和其它系统交换数据。
在我看来，regression testcase应该和产品所支持的业务模型联系起来。这是什么意思呢？
1） 在设计regression
testcase的时候，面对系统不是一个“光秃秃“系统，而是已经有一些静态资源配置在里面，而且这些静态资源的配置最好来源于真实的用户。
2） 同时，这个系统也不是一个静态的系统，它的输入输出接口，还有相关的第三方系统是活动的。也就是说，在测试的时候，系统的各个接口已经在实时的处理数据。数据的类型和数量还是来源于真实的用户。
Regression testcase的特点和功能验证的testcase也很不一样。简单来说regression
testcase更注重描述一个过程，这个过程涉及到多个功能，而不是一个功能点。一般来说这样的过程来源于use story，但我觉得也不一定要拘泥于如此，毕竟测试系统和真实用户使用系统还是不一样的，特别是仅仅使用use story，覆盖率会不够。 所以如果需要，用一个“假的use
story“把一些功能点串在一起也是可以的。
从testcase的执行效率来说，这样的regression testcase有更高的效率。因为
1. 很多静态资源不需要在testcase里准备，而是在系统运行起来的时候已经准备好了
2. 因为系统已经在自动化的处理各种数据，也就是很多重要的功能已经在运行了，所以很多checkpoint可以直接开始执行，而不需要额外的准备步骤。
3. 面向过程的testcase比面向功能点的testcase天然具有更高的执行效率。
从覆盖率来说。主要功能和真实用户对这些功能的使用方式已经能cover。
Regression
Testcase设计挑战
设计专门的regression testcase的最大挑战是，如何设计出“足够好的testcase“。对于testcase的设计者来说，其面对的复杂性比设计功能验证testcase要高很多。
1. 首先，从知识储备来说，设计者需要更了解产品在客户环境的使用情况。
2. 在设计之初就要考虑到，基础资源，输入输出接口的数据，第三方接口的数据交换，这些整体构成一个基础的用户业务模型。
3. 在设计testcase架构时，要有足够的全局观。这体现在如何对testcase分类和如何组织testcase。不像功能验证的testcase，天然的可以按照功能分类，regression testcase涉及到多个功能，其如何分类需要深入的了解产品的功能后才能做好。
4. 在设计testcase架构和具体设计testcase过程中，都要对全局资源进行明确的定义和管理。需要协调好只读的资源和可以修改的资源。
5. 在设计具体的一个testcase的时候，需要灵活运用已有的资源和创建新的资源，需要在use story和testcoverage中保持平衡。
设计Regression testcase库就像设计一个复杂的软件产品，只是产品恰好是一个testcase库。
