最近有初入行的朋友，向我询问公共测试用例的生成方法。其实我也才做测试没多久，关于公共测试用例这块的也不是像网友想象中那样有深刻的体会。下面就我自己的体会做点阐述，也当总结一下几个月前工作过程中的总结吧。
首先，得弄明白以下问题，为什么要生产公共测试用例呢，关于这个问题，网络上还有书籍上已经阐述得很明白了，他们说得很多，简而言之“成本，时间”。另外一个得弄明白一个词也就是“公共”，我解释为“共用的”。再者，得知道用例的一个主要作用，即“指导”作用。所以从上面可以得出一个定义，公共测试用例指，将软件共有的或共用的测试用例归纳为一个集合，本着节约用例开发时间缩减用例开发成本为原则，与其它用例相融后指导测试工作开展的用例（这个定义，个人观点哈，仅供参考）。
有了上面的定义，那么如何依据定义来创建公共测试用例呢？偶认为可以从以下几个方面去考虑，其实也就是把定义分几个步骤去实现而已（注意，本文仅从功能测试用例为出发点，性能测试用例或其它测试用例未涉及）。
1、首选得确定公共用例在整个用例架构中的地位，确定引入原则。这叫指导思想，没有整体的指导思想，后期的创建与引入会很混乱的，这可是经验哦。嘿嘿……
2、提炼软件共有的或共用的模块，将常用模块或功能抽取出来，比如登录模块。这个是基础，要判断或者说评审那些模块或功能是应该抽取出来的。
3、注意前提条件，每次在导入公共用例至某个具体项目时得注意实现项目的情况，网络上有种方法是在公共用例中给入参数化的方法，这种思想就是防止公共用例与具体项目用例冲突出生出的思想。当然，他好像是用自动化去测试的，但手工测试用例中也可引入这个思想，但得注意具体项目中执行参数的惟一性，这个参数必须是得到大家认可的。
4、注意过程描述的广泛性与具体性，公共用例描述得有广泛的适宜性，不能够说得太死也不能太活，不然用例执行人员在执行时常常会用较多时间去猜测其含义的（老手就不需要了，一看就会明白的）。
5、注意期待结果的广泛性与具体性，理由同4。
6、公共用例是得经过评审等，并且得到大家认可的，如果没人认可，白搭！
7、注意基本用例的创建思想同样适合公共用例，并且公共用例得遵循这个思想。比如用例架构问题。
最后，从辨证法的角度来说，事物是两方面的，即然这个有许多优点，那么他可能会带来那些缺点呢，在此给出某次总结中的内容，仁者见仁，智者见智吧！
公共测试用例存在以下几点缺陷。
A、公共测试用例引用标准缺乏，不同用例设计人员引有方式不同。目前存在两种引用模式：a、直接引用整个模块（此种方法在用例适应具体情况方面较差，但减少用例数量）b、模块内分级引用（此种方法会增加用例数量，但适应性有所增强）。
B、公共测试用例中某些内容描述过于模糊，难于理解。
C、公共测试用例未呈现逻辑性和层次性，架构不严谨。
D、公共测试用例的测试点不够全面，需增加。
E、公共测试用例在详细用例中多次导入与导出，无形中增加了测试人员多文档搜寻内容的工作量。
再次申明一下，以上纯属个人观点，不具有普遍性，另如要引用，请标明出处！谢谢！（以上言论仅代表作者的个人观点，不代表51Testing观点）
版权声明：本文出自wolaizhinidexin的51Testing软件测试博客：http://www.51testing.com/?287227
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
推荐阅读：
