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