开发的框架一般分为与业务无关的通用框架和专门针对企业业务逻辑的定制框架，在软件的开发中这两种框架都发挥着自己作用，相互辅佐。

　　通用的框架如：MVC的Struts，Webwork，ORM的Ibatis、hibernate，IoC的Spring等，这些都是大家耳熟能详的东西，就不必多说了。这些框架可以给你的项目开发提供基础的支持，但不会在你业务上的需求提供帮助，所有与你业务相关的东西你得自己一步步实现。而在一些业务较为繁琐，系统开发复杂的企业，会倾向于根据自己的业务特点定制一套自己的业务框架，这主要在一些开发周期比较长，后期复用性较多的企业系统会出现的比较多，如某海运集团会为其系统构建一套针对港口的业务特点的，封装了港口主要操作的一套开发框架，以提高后续的开发效率，并方便后面 enhancement的开发。这样的框架这对性较强，它并不奢望能在别的行业通用，甚至在别的海运公司也不能复用，它的好处在于封装大量业务细节，从而是开发更为简洁高效。

　　这样的思想在淘宝这样一个业务线繁多，且业务复杂系统，是有一定的参考价值的。暂且不说开发，就是进行接口测试，对于每个执行步骤的所有验证点的了解是一件非常痛苦的事情。如果我们能将一些主要的业务步骤，和各业务步骤的验证点封装起来，那么侧试就会简单得多，而且高效得多。这些步骤就犹如一个个模板，一套流程就是有这样的模板一个个拼装而成，这样不管接口测试还是集成测试都能从中受益。可惜Java不支持模板，但有一位C++的工程师曾这说：“Java 没有模板，也就只有通过annotation玩些花活”，或许他说的是对的，但万幸的是Java通过annotation玩出来的花活要比C++ 的模板效果好得多。

　　这样的话我们不妨将我们测试中的测试步骤annotation化，那样的话，我们在测试时，只需将这些annotation一个个拼接起来，便可以实现了一个逻辑流程的测试，如在一个购买流程中，我们讲流程中的各个步骤annotation化，那么我们的测试代码就有可能简化如下：

　　这样一来，用代码就行测试边可以与手工测试很方便的的对应结合起来，一些手工测试的主要步骤都有相应的annotation与之对应，这样在用例设计时，手工测试的用例设计便会很方便的转为测试代码，甚至可以用一些文本抽取工具进行稍加整理便能完成测试代码的产出。

　　YY中，希望能在某个系统的测试中能成为现实~~~（以上言论仅代表作者的个人观点，不代表51Testing观点）