大家来讨论下关于测试用例里面的公共用例（09-09-02）（获奖名单已公布）

Jackc

1、首先，偶们需要定义公共用例使用的范围，也就是偶们设计公共用例的目的。
   通常有以下几种：
    1）只在一个项目中使用
    2）在类似的项目中使用
    3）在所有项目中使用
  根据选择的使用范围不同，所需的工作量有几何的变化。偶们经常使用的公共用例都是1）、2）种，但是往往偶们定的目标是第3）种，所以经常会导致领导觉得偶们做的公共用例实用性不强。

2、针对公共用例不同的应用范围，偶们再来具体的划分工作细节。因为本人的能力有限，偶只谈第1）种应用中的功能测试内容。
   在项目需求确定后，偶们可以在整理需求时得到以下信息：
   1）不同功能模块的完全相同的操作：比如数据输入测试（可分为：编辑框、CheckList选择框、布尔选择框、数据包输入等等），根据输入数据的方式分类，再根据各个输入条件限制分类（比如编辑框可能有些要求全字符输入，有些要求只输入数字字符等），基本可以得到若干个公共测试用例。（这种公共用例设计比较简单，维护成本也较低，是用的最为广泛的）
   2）关联模块的相同操作：比如有AB两个功能模块，B在实现某个功能时，需要调度A模块的a功能，则可以把a功能的测试提取出来作为一个公共测试用例，在B模块测试时，只需在a功能的测试用例中加入一个预置条件即可。（这种公共用例设计较麻烦，维护成本也较高，在用例整理和维护上花费的时间也比较多，常常是根据项目实际情况完成一部分即可）
  3）关联功能的组合操作：在2）的基础上，将各个模块的子功能划分为极小的单元，每个单元都是一个公共用例，通过组合完成功能测试。单元就像是：输入数字、点击OK按钮等等（个人认为这种做法相当复杂，不赞成使用）

其实就像15楼说的那样：“公共用例可以节省用例的开发成本，这点毋庸置疑，但也得结合实际情况”

Jackc

1.公共用例尺度应该如何把握
尺度决定于公司/项目的预期成本,多大的投入带来多大的回报。尺度越小自然越专业，不过用句俗话：看着专业，用着麻烦。
建议尺度颗粒控制在一个独立子功能即可（有完整的独立输入和输出），比如编辑框、完成一次数据存储操作、完成一次拨号呼叫等都可以。
2.带参数化的公共用例难于评审（TD,QC这类可以带参数的，其他我不是很了解）
首先，参数化是用来做什么的？看着更专业？还是看得更清晰明白？
如果追求于后者，那么建议参数化的国度符号选用大家一眼都能看明白的东东，比如：按下《A按钮》——>进入（B界面）
3.测试人员的水平还有测试人员编写用例的表述及方法。
测试人员水平只能在实战中提升，注意总结测试经验，并时刻将实际所得与理论相比较。
测试用例编写最好全公司固定一种格式，这样也能高效的保障评审“大家都能看懂”……