公共用例的个人见解

目前的测试团队，一般而言，不同的项目都存在许多的共通之处，通过构建公共用例库的好处我认为有以下两方面：

1、缩短用例开发时间。

2、继承团队的项目经验。

公共用例的定义与使用，我是这么理解的：

首先，公共用例并不在在某些项目上拿来就可用的（具体项目具体而言），如果是抱着这样的思路去构建，那么公共用例的编写与维护需要投入大量的资源（因为要考虑兼容多个项目）。

其次，在公共用例库建立后，对于每个项目，需要将公共用例提取建立基线后与此项目的私有用例合并，单独维护。否则，项目有独立的私有用例与公共用例，对于测试者来说反而容易混乱。在用例的维护中，如果发现公共用例有需要更新的地方，再对公共用例更新补充，建立新的基线。

在具体的实施过程中，我认为公共用例库应该从以下两个侧重点出发进行构建：

一是基于相同的开发实现平台的公共用例库。

基于相同的开发实现平台，一般而言，在界面风格、公共模块的实现上基本都是一样的，因此建立公共用例库应该从界面或者菜单方面着手，以缩短多个项目的用例开发时间。

此类公共用例库，个人建议一定要将用例与需求挂钩，这样，通过对需求的变化，我们将需求不变的部分筛选出来，可用的公共用例也就筛选出来了，测试者可将更多的精力放在需求变化的部分构建新用例。

二是基于类似应用业务需求的公共用例库。

基于相同或类似的业务应用需求，就和楼主说的一样，系统都是一样的，在构建公共用例库时，应该从功能点出发，将流程与参数分离，以达到用例复用的目的。

基于类似应用业务需求的公共用例库，在编辑时建议采用二维图表构建，原理如图1。

示例如图2。

与楼主举的2个例子比较，这种格式应该更直观，在参数的选择上，可采用等价类分法选择。

接下来回答楼主的3个问题：

1、公共用例尺度应该如何把握？

这个尺度，我有些不太明白，是指用例的颗粒度，还是指其他的？

对于用例的颗粒度，这个我觉得应该根据团队成员的共识与项目情况决定。

2、带参数化的公共用例难于评审（TD,QC这类可以带参数的，其他我不是很了解）

我们团队的评审分两种：

一是有项目组参与的评审，个人认为在这种评审中，项目组主要关注流程方面。

二是测试团队的内部评审，相比较上一种评审，这种评审可能更关注参数的选择。

3、测试人员的水平还有测试人员编写用例的表述及方法。

测试人员水平，没什么好说的，只有通过工作学习提升。

现在我编制一份测试相关文档，都需要写三份，以便于测试者实行统一的规范：

一是空白格式，这没什么好说的。

二是填写规范或作业指导书，估计楼主也会写，至少口头有在宣导。

三是实际案例。完成了空白格式与规范后，由于个人理解不一，有时候写出来千差万别，这时候你就得写一些实际的案例，通过案例结合规范，使得团队达到同一表述。

=========================================================

最近事情比较多，博客N久没更新了.......