目前的测试团队,一般而言,不同的项目都存在许多的共通之处,通过构建公共用例库的好处我认为有以下两方面:
1、缩短用例开发时间。
2、继承团队的项目经验。
公共用例的定义与使用,我是这么理解的:
首先,公共用例并不在在某些项目上拿来就可用的(具体项目具体而言),如果是抱着这样的思路去构建,那么公共用例的编写与维护需要投入大量的资源(因为要考虑兼容多个项目)。
其次,在公共用例库建立后,对于每个项目,需要将公共用例提取建立基线后与此项目的私有用例合并,单独维护。否则,项目有独立的私有用例与公共用例,对于测试者来说反而容易混乱。在用例的维护中,如果发现公共用例有需要更新的地方,再对公共用例更新补充,建立新的基线。
在具体的实施过程中,我认为公共用例库应该从以下两个侧重点出发进行构建:
一是基于相同的开发实现平台的公共用例库。
基于相同的开发实现平台,一般而言,在界面风格、公共模块的实现上基本都是一样的,因此建立公共用例库应该从界面或者菜单方面着手,以缩短多个项目的用例开发时间。
此类公共用例库,个人建议一定要将用例与需求挂钩,这样,通过对需求的变化,我们将需求不变的部分筛选出来,可用的公共用例也就筛选出来了,测试者可将更多的精力放在需求变化的部分构建新用例。
二是基于类似应用业务需求的公共用例库。
基于相同或类似的业务应用需求,就和楼主说的一样,系统都是一样的,在构建公共用例库时,应该从功能点出发,将流程与参数分离,以达到用例复用的目的。
基于类似应用业务需求的公共用例库,在编辑时建议采用二维图表构建,原理如图1。
示例如图2。
与楼主举的2个例子比较,这种格式应该更直观,在参数的选择上,可采用等价类分法选择。
接下来回答楼主的3个问题:
1、公共用例尺度应该如何把握?
这个尺度,我有些不太明白,是指用例的颗粒度,还是指其他的?
对于用例的颗粒度,这个我觉得应该根据团队成员的共识与项目情况决定。
2、带参数化的公共用例难于评审(TD,QC这类可以带参数的,其他我不是很了解)
我们团队的评审分两种:
一是有项目组参与的评审,个人认为在这种评审中,项目组主要关注流程方面。
二是测试团队的内部评审,相比较上一种评审,这种评审可能更关注参数的选择。
3、测试人员的水平还有测试人员编写用例的表述及方法。
测试人员水平,没什么好说的,只有通过工作学习提升。
现在我编制一份测试相关文档,都需要写三份,以便于测试者实行统一的规范:
一是空白格式,这没什么好说的。
二是填写规范或作业指导书,估计楼主也会写,至少口头有在宣导。
三是实际案例。完成了空白格式与规范后,由于个人理解不一,有时候写出来千差万别,这时候你就得写一些实际的案例,通过案例结合规范,使得团队达到同一表述。
=========================================================
最近事情比较多,博客N久没更新了.......