会员woodcraft：

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

　　1、缩短用例开发时间。

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

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

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

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

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

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

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

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

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

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

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

　　示例如下：

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

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

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

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

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

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

　　我们团队的评审分两种：

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

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

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

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

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

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

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

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

　　原理：

　　例2：

版权声明：本文出自51Testing软件测试论坛，感谢会员woodcraft、wangz在每周一问（09-09-02）中的精彩回答。

http://bbs.51testing.com/forum-157-1.html

原创作品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。