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

默默巫

一个系统基本上构造是由：1.增删改查   2.数据流程   这两大块组合的
在整个系统中相同的操作、相似的操作可以说比比皆是，如何构造公共的测试用例呢？大家构造过么？

问题难点：
1.公共用例尺度应该如何把握
2.带参数化的公共用例难于评审（TD,QC这类可以带参数的，其他我不是很了解）
3.测试人员的水平还有测试人员编写用例的表述及方法。


从2008年初，我就在思考这个问题，如何去权衡这些问题呢，大家来一起讨论，下面是我们公司一个测试人员编写的公共用例里面的正常新增（当然跟我理解的是不一样的）：
输入：输入所有字段，执行新增操作
输出：
能正常完成新增操作。
1.一般有给予相关提示信息,如'保存成功'。(不强制规定)
2.如果系统有提供数据回显那么回显数据与新增数据是一致的。
3.如果新增数据后有返回到列表，则一般是新增的数据排在首页首行，但也可根据具体
的排序需求而定。

换成是我来写的话，我会带上参数化：
输入：<<<users>>>登录系统，点击【<<<模块1>>>】||【<<<模块1子模块>>>】，点击新增，<<<所有字段>>>录入正确有效的数据后，点击保存
输出：1.保存成功并正确返回页面  2.录入前后数据一致。
我的方法嘛好处自然是在执行测试的时候知道谁登录，哪个模块执行了什么样的操作，但如果让开发已经公司其他成员来评审的时候，这样的可读性就很低了（毕竟TD上还得经过调用，可读性几乎为0了，评审人员只能查看公共用例模板，调用部分都无法查看清了）

大家平时写用例都主要关注什么呢？如何把握公共用例？欢迎大家讨论！

本话题由会员鹭岛提供,如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	woodcraft	当当购物卡50元	13#
二等奖	wangz	300论坛积分	5#
三等奖	jeffsui	100论坛积分	23#

找茬

我是一名初级测试员，对测试了解的并不是很透彻。所以只能说说自己的拙见：

所谓的公共用例是指不用更改任何用例参数即可止执行的用例，软件框架用例，界面一致性用例，翻页控制用例，内存占用率用例，当页帮助及登录等；

至于各子功能项的增删改查不属于公共用例，因为各个功能的配置参数及预期结果不尽相同；

shaofei19820625

我的理解，公共用例库不需要去写具体的操作步骤，而只需要将某类功能需要关注的点写出来就可以了。比如新增功能我们要关注的是：
1、新增操作是否有权限控制
2、新增功能入口
3、新增见面元素完整性
测试用户新增界面的元素的完整性。请参照下图：
界面元素不能多不能少
界面元素名称要和下图一致
界面元素类型要和下图一致：文本框、下拉列表框、按钮等等
4、新增界面默认值校验
5、新增界面必填项测试
6、新增界面各元素项测试
分别针对各截面元素项的类型、长度、格式等进行测试。标准参考以下表格：
对于各种异常测试界面的提示信息也需要关注，测试开发是否针对各种异常情况进行捕获。
对于下来列表框、弹出框等的测试（比如数据来源的测试）
7、新增功能的限制
比如什么信息可以新增什么信息不可以新增
8、新增的重复性校验
9、新增重复提交的测试
10、新增的异常情况测试
比如新增的时候系统挂了
11、新增后的影响
新增后界面什么提示；数据库怎么展示；新增后的数据对其他功能的影响等


而以上的公用用例可能又会调用其他的公共用例，比如6界面各元素项的测试，每个元素的展示框测试（比如文本框，下拉框等的测试，可以调用其他公共用例的。

[ 本帖最后由 shaofei19820625 于 2009-9-18 12:10 编辑 ]

zishuijing

做成通用的公共用例个人感觉不可能，都需要根据具体情况修改； 但公共用例对应的检查点是可以通用的，尤其像增删改查，翻页、文本框、列表框等的检查。形成公共用例库对以后的复用非常有用。

zouzoulo

看了各位的高见，我都不知道自己写的能不能叫 测试用例了。

zyq_799

公用测试用例目的为了减少重复性工作，增强用例的可用性。个人认为应该将对输入项的校验，选择框，日期框，必填项的校验，分页校验，浏览器的后退及前进校验，上传附件等作为公用的测试用例。

jeffsui

所谓公共用例，我的理解：
1.可以复用的用例。
2.操作频繁的用例。
3.在以往项目中经常使用的用例。
LZ的表述应该是结合配置管理工具执行的公共用例库的管理层面吧。
放在公共用例库中的信息，应该至少是基线化了的工作产品吧。
可以从用例的组成部分探究哪些用例适合放到公共用例库中，
a。前置条件
b。操作步骤
c。期望结果
d。关联用例
等等。
以上条件如果满足公司统一的规范，那么就可以放到公共用例里。
但是用例的维护工作不是一蹴而就的，需要进行公共用例库的定期维护。
综上所述，什么样的用例纳入到公共用例中，如何进行公共用例的构建，标准如何统一，还是一个配置管理问题。
以上仅代表我个人观点。
继续看大家的回帖。

monicahyq

个人感觉公共用例写的尽量简洁易懂，具体方式可大家讨论后来定，没个固定模式了

kukumaru

学习啦~

风雪夜归人

首先：我觉得漏掉了一个最重要的部分，公共用例的设计就是为了抽象一些经常用到的，有共同点的操作，但是，前提肯定是很常用的，这样才能保证成本的最小化，如果仅仅用一次的用例，就算再简单，也不需要写为公共用例的。
其次：公共用例一般能完成某一单一的功能，这要看具体情况，如果有几种情况相差比较小，ok，可以把他们总结起来，写成一个公共的用例，可以通过设置某些参数的形式使其完成预期的功能，但是，有个原则：肯定有一种情况把所有的参数都用上（师傅告诉我的，我思考了很久，觉得非常正确）
再次：没有了~~哈哈

Jackc

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

Jackc

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

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

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

atomtiger

形成公共用例难啊，我们单位讨论这个问题很久了。还没有结论。。。有个设备经常测，每次用例都要变动

ruanjianceshi51

感觉楼主有点牛的

hootoue

公共用例可以节省用例的开发成本，这点毋庸置疑，但也得结合实际情况

白素

还没接触到，进来学习下先

woodcraft

目前的测试团队，一般而言，不同的项目都存在许多的共通之处，通过构建公共用例库的好处我认为有以下两方面：
1、缩短用例开发时间。
2、继承团队的项目经验。

公共用例的定义与使用，我是这么理解的：
首先，公共用例并不在在某些项目上拿来就可用的（具体项目具体而言），如果是抱着这样的思路去构建，那么公共用例的编写与维护需要投入大量的资源（因为要考虑兼容多个项目）。
其次，在公共用例库建立后，对于每个项目，需要将公共用例提取建立基线后与此项目的私有用例合并，单独维护。否则，项目有独立的私有用例与公共用例，对于测试者来说反而容易混乱。在用例的维护中，如果发现公共用例有需要更新的地方，再对公共用例更新补充，建立新的基线。

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

一是基于相同的开发实现平台的公共用例库。
基于相同的开发实现平台，一般而言，在界面风格、公共模块的实现上基本都是一样的，因此建立公共用例库应该从界面或者菜单方面着手，以缩短多个项目的用例开发时间。
此类公共用例库，个人建议一定要将用例与需求挂钩，这样，通过对需求的变化，我们将需求不变的部分筛选出来，可用的公共用例也就筛选出来了，测试者可将更多的精力放在需求变化的部分构建新用例。

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

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

示例如下：

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

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

1、公共用例尺度应该如何把握？
这个尺度，我有些不太明白，是指用例的颗粒度，还是指其他的？
对于用例的颗粒度，这个我觉得应该根据团队成员的共识与项目情况决定。

2、带参数化的公共用例难于评审（TD,QC这类可以带参数的，其他我不是很了解）
我们团队的评审分两种：
一是有项目组参与的评审，个人认为在这种评审中，项目组主要关注流程方面。
二是测试团队的内部评审，相比较上一种评审，这种评审可能更关注参数的选择。

3、测试人员的水平还有测试人员编写用例的表述及方法。
测试人员水平，没什么好说的，只有通过工作学习提升。
现在我编制一份测试相关文档，都需要写三份，以便于测试者实行统一的规范：
一是空白格式，这没什么好说的。
二是填写规范或作业指导书，估计楼主也会写，至少口头有在宣导。
三是实际案例。完成了空白格式与规范后，由于个人理解不一，有时候写出来千差万别，这时候你就得写一些实际的案例，通过案例结合规范，使得团队达到同一表述。

[ 本帖最后由 woodcraft 于 2009-9-8 16:39 编辑 ]

sunlight426

其实通用测试用例对于一个测试新手来说是个非常好的学习材料，我们公司也有整理，主要是针对具体的某个控件来设计的用例，或者是某些通用的场景，通过通用测试用例的学习和编写，可以整理测试思路，测试方法，我认为这样的整理还是有必要的

abedd

公共用例是在抽取一些共同点，操作所具有的共性。增删改查这些是免不了的，针对每种操作进行公共的编写，而私有属性则是对他们不同的地方进行特别的说明。但是这样能不能很有效的提高效率，还是个值得思考和验证的问题。-----------个人观点，若有异议，还望指正！

rocky_chen0423

个人认为，其实公共测试用例应该是一种通用的规范之类的，即类似的功能测试，有哪些地方时需要注意的，有哪些条件是必须用到的。
例：一个输入项的测试，其实这个输入项就包含很多东西了，只要是需要输入的地方都可以用到这个测试用例，用例可以如下
1、无输入内容
2、输入内容长度超过边界
3、只输入空格符
4、输入特殊字符
这样的话，只要有输入项的地方，都可以考虑这些因素，然后再加上需求本身的内容，就可以构成当前测试系统的测试用例了。
通用测试用例主要就是方便测试人员进行测试用例编写，省的对一些行业规范及业务规范有所遗漏。