面我自己的体会做点阐述，也当总结一下几个月前工作过程中的总结吧。

　　首先，得弄明白以下问题，为什么要生产公共测试用例呢，关于这个问题，网络上还有书籍上已经阐述得很明白了，他们说得很多，简而言之“成本，时间”。另外一个得弄明白一个词也是“公共”，我解释为“共用的”。再者，得知道用例的一个主要作用，即“指导”作用。所以从上面可以得出一个定义，公共测试用例指，将软件共有的或共用的测试用例归纳为一个集合，本着节约用例开发时间缩减用例开发成本为原则，与其它用例相融后指导测试工作开展的用例(这个定义，个人观点哈，仅供参考)。

　　有了上面的定义，那么如何依据定义来创建公共测试用例呢?偶认为可以从以下几个方面去考虑，其实也是把定义分几个步骤去实现而已(注意，本文仅从功能测试用例为出发点，性能测试用例或其它测试用例未涉及)。

　　1、得确定公共用例在整个用例架构中的地位，确定引入原则。这叫指导思想，没有整体的指导思想，后期的创建与引入会很混乱的，这可是经验哦。嘿嘿……

　　2、提炼软件共有的或共用的模块，将常用模块或功能抽取出来，比如登录模块。这个是基础，要判断或者说评审那些模块或功能是应该抽取出来的。

　　3、注意前提条件，每次在导入公共用例至某个具体项目时得注意实现项目的情况，网络上有种方法是在公共用例中给入参数化的方法，这种思想是防止公共用例与具体项目用例冲突出生出的思想。当然，他好像是用自动化去测试的，但手工测试用例中也可引入这个思想，但得注意具体项目中执行参数的惟一性，这个参数必须是得到大家认可的。

　　4、注意过程描述的广泛性与具体性，公共用例描述得有广泛的适宜性，不能够说得太死也不能太活，不然用例执行人员在执行时常常会用较多时间去猜测其含义的(老手不需要了，一看会明白的)。

　　5、注意期待结果的广泛性与具体性，理由同4。

　　6、公共用例是得经过评审等，并且得到大家认可的，如果没人认可，白搭!

　　7、注意基本用例的创建思想同样适合公共用例，并且公共用例得遵循这个思想。比如用例架构问题。

　　后，从辨证法的角度来说，事物是两方面的，即然这个有许多优点，那么他可能会带来那些缺点呢，在此给出某次总结中的内容，仁者见仁，智者见智吧!

　　公共测试用例存在以下几点缺陷。

　　A、公共测试用例引用标准缺乏，不同用例设计人员引有方式不同。目前存在两种引用模式：a、直接引用整个模块(此种方法在用例适应具体情况方面较差，但减少用例数量)b、模块内分级引用(此种方法会增加用例数量，但适应性有所增强)。

　　B、公共测试用例中某些内容描述过于模糊，难于理解。

　　C、公共测试用例未呈现逻辑性和层次性，架构不严谨。

　　D、公共测试用例的测试点不够全面，需增加。

　　E、公共测试用例在详细用例中多次导入与导出，无形中增加了测试人员多文档搜寻内容的工作量。