大家来讨论下关于测试用例里面的公共用例（09-09-02）（获奖名单已公布）
一个系统基本上构造是由：1.增删改查 2.数据流程 这两大块组合的在整个系统中相同的操作、相似的操作可以说比比皆是，如何构造公共的测试用例呢？大家构造过么？
问题难点：
1.公共用例尺度应该如何把握
2.带参数化的公共用例难于评审（TD,QC这类可以带参数的，其他我不是很了解）
3.测试人员的水平还有测试人员编写用例的表述及方法。
从2008年初，我就在思考这个问题，如何去权衡这些问题呢，大家来一起讨论，下面是我们公司一个测试人员编写的公共用例里面的正常新增（当然跟我理解的是不一样的）：
输入：输入所有字段，执行新增操作
输出：
能正常完成新增操作。
1.一般有给予相关提示信息,如'保存成功'。(不强制规定)
2.如果系统有提供数据回显那么回显数据与新增数据是一致的。
3.如果新增数据后有返回到列表，则一般是新增的数据排在首页首行，但也可根据具体
的排序需求而定。
换成是我来写的话，我会带上参数化：
输入：<<<users>>>登录系统，点击【<<<模块1>>>】||【<<<模块1子模块>>>】，点击新增，<<<所有字段>>>录入正确有效的数据后，点击保存
输出：1.保存成功并正确返回页面2.录入前后数据一致。
我的方法嘛好处自然是在执行测试的时候知道谁登录，哪个模块执行了什么样的操作，但如果让开发已经公司其他成员来评审的时候，这样的可读性就很低了（毕竟TD上还得经过调用，可读性几乎为0了，评审人员只能查看公共用例模板，调用部分都无法查看清了）
大家平时写用例都主要关注什么呢？如何把握公共用例？欢迎大家讨论！
本话题由会员鹭岛提供,如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
获奖名单奖项获奖名单奖励答案链接一等奖woodcraft当当购物卡50元13#二等奖wangz300论坛积分5#三等奖jeffsui100论坛积分23# 你所谓的参数化那只是把用例表达的更具体了一些
没明白你所说的公共测试用例应该是什么样子的
是指可以重复利用的用例吗？ 可以重复利用的用例可以专门建立用例库来维护它，需要它时拿来稍稍改动下就行了。
楼主所说的是不是指用一软件下不同模块的相同功能点如何构造公共的测试用例这个吗？相同功能点的测试用例其实也差不多，也只需要稍稍改动路径等参数就可以拿来用了。。。 楼主所说的公共测试用例就是楼主在刚开始给的一个公共测试用例了，我觉得还不错了，编写起来简单。只要设计的测试用例合理，还是比较实用的，可以减轻测试人员编写测试用例的繁琐。 个人感觉什么都应该从最原始的需求出发考虑，偶们是做测试的啊..些公共用力到底是想减少那部分工作，要不然弄得复杂了还不好。太多的形象工作不但没有效率，反而会让人很急躁。
公共用例的想法很好，我们也在执行着，但是和楼主的不同，我们建立的公共用例库是仅仅为了节约写用例的成本，使用过程中维护，用例的内容是很具体，如下拉框的测试，复选框的测试，，，等等，还有就是总结了多个属性关联页面的正交测试方法.个人感觉公共用例不能太设计功能业务上的东西，否则依赖性就太强了很不好...只是从最简单最基础的出发总结出来一些总是重复出现的东西，写成公共的
我们还有个库是用于回归大版本用的测试测试用例，类似很多公司的【checklist】，如果从另外一个角度说也算是公共用例的一种。
类似你们写的
------------------
输入所有字段，执行新增操作，可完成能正常完成新增操作。1.一般有给予相关提示信息,如'保存成功'。(不强制规定)2.如果系统有提供数据回显那么回显数据与新增数据是一致的。3.如果新增数据后有返回到列表，则一般是新增的数据排在首页首行，但也可根据具体的排序需求而定。
------------------
我们不太一样的就是各个功能的主要流程去写，所以就每条详细些，复用起来可能不太好，但也仁者见仁了...哈哈个人感觉
评价：
我感觉你们考虑的太基于功能考虑多些，最开始我们也想这么做来的但是不但没有得到很好发复，还导致部分人就产生依赖，效率没有提高，但是要做checklist去考虑好像有太模糊了
只可惜我们用例就是excel管理，不存在你说的什么参数问题
回复
不知道，功能的测试用例是单独维护好呢，还是写一些测试时的注意点，或测试方法方便呢。比如，一些单选按钮，或下拉框，输入框等 谢谢版主，这个是我一直很想问的！从我目前的思考角度出发，我觉公共用例主要可以涉及：1.字符类型变化是否合法（如日期、数字、浮点数、整型数等等）
2.非关系业务逻辑方面的（如翻页是否正常、操作成功是否正常返回等等）
这类型的使用公共用例还可以，如果是关系到逻辑方面的功能，感觉不太适应公共用例，如果按照TD上的使用参数化来编写，可读性又会降低。 公共用例在我理解，更偏重于公共操作的含义，我认为这样性质的公共操作可以分为3类：
1. 前置条件
比如某项目有这样一个需求：同一种对象可以具有层次关系。那么“建立层次关系”这个测试用例的前置条件就是至少存在2个这样的对象。如果用例要求很完整，就需要有“创建对象”的前置操作，这时可以构建公共用例“创建对象”，引用到该用例中。
但这里要说明的是，“创建对象”这个公共用例仅实现操作的作用，默认是成功的。而在功能测试用例中，会有”创建对象”详细的用例，包括操作步骤，检查点和预期结果。
2.后置检查
比如通过erp二次开发的系统，通常是客户化erp的某些模块，因此在本系统的功能测试操作完成后，还需要到erp中相关模块检查数据是否正确，这样的情况可以构建公共用例“验证XXX数据”，引用到该功能用例的最后一步。
3.通用检查
上述2点都是针对特定项目的，我认为，通用检查是经过多个项目积累，形成的通用的检查点。比如楼上朋友提到的下拉列表、翻页、排序规则等。这类检查通常不会每个项目维护一份，而是每类项目维护一份，像测试准则一样，为所有测试人员接受和执行。
关于用例中的参数，的确有时候很难取舍，我在测试中也走了些弯路，和大家分享下。
我的测试工作都是在QC中进行的，刚开始发现参数这个功能很兴奋，因为它有2大好处：
1.填入参数执行时，遇到bug，直接在运行测试界面提交，会自动提取参数，减少了bug描述中写测试数据的时间。
2.可以对同一个用例用不同的数据执行多遍，每一遍都能被记录，追踪起来非常方便。
于是在一个项目中，全面用参数的形式描述步骤，但问题出来了。当时大量用到了用例引用，导致执行某个用例时，
引用到的其他用例的参数全部堆积到一起，经常忘了某个参数到底要什么数据，再回到那个被引用的用例查看，过程非常的烦琐，效率也下来了。
所以，参数这个功能是好的，用于具体的功能测试有很多的帮助，但如果一个用例经常需要被引用，那最好不要用或少用参数，参数堆积实在是件不愉快的事情。 我们公司就那几个产品，功能几乎都一样，只是以前遗留下的bug太多，现在测试还没有需求说明书，只能自己罗列需求点测试，所以用例的话基本不变，只是需要添加，以保全面测试。
参数化，可能是在输入筐、日期、等边界值输入这种测试中用得比较多吧. 个人认为，其实公共测试用例应该是一种通用的规范之类的，即类似的功能测试，有哪些地方时需要注意的，有哪些条件是必须用到的。
例：一个输入项的测试，其实这个输入项就包含很多东西了，只要是需要输入的地方都可以用到这个测试用例，用例可以如下
1、无输入内容
2、输入内容长度超过边界
3、只输入空格符
4、输入特殊字符
这样的话，只要有输入项的地方，都可以考虑这些因素，然后再加上需求本身的内容，就可以构成当前测试系统的测试用例了。
通用测试用例主要就是方便测试人员进行测试用例编写，省的对一些行业规范及业务规范有所遗漏。 公共用例是在抽取一些共同点，操作所具有的共性。增删改查这些是免不了的，针对每种操作进行公共的编写，而私有属性则是对他们不同的地方进行特别的说明。但是这样能不能很有效的提高效率，还是个值得思考和验证的问题。-----------个人观点，若有异议，还望指正！ 其实通用测试用例对于一个测试新手来说是个非常好的学习材料，我们公司也有整理，主要是针对具体的某个控件来设计的用例，或者是某些通用的场景，通过通用测试用例的学习和编写，可以整理测试思路，测试方法，我认为这样的整理还是有必要的 目前的测试团队，一般而言，不同的项目都存在许多的共通之处，通过构建公共用例库的好处我认为有以下两方面：
1、缩短用例开发时间。
2、继承团队的项目经验。
公共用例的定义与使用，我是这么理解的：
首先，公共用例并不在在某些项目上拿来就可用的（具体项目具体而言），如果是抱着这样的思路去构建，那么公共用例的编写与维护需要投入大量的资源（因为要考虑兼容多个项目）。
其次，在公共用例库建立后，对于每个项目，需要将公共用例提取建立基线后与此项目的私有用例合并，单独维护。否则，项目有独立的私有用例与公共用例，对于测试者来说反而容易混乱。在用例的维护中，如果发现公共用例有需要更新的地方，再对公共用例更新补充，建立新的基线。
在具体的实施过程中，我认为公共用例库应该从以下两个侧重点出发进行构建：
一是基于相同的开发实现平台的公共用例库。
基于相同的开发实现平台，一般而言，在界面风格、公共模块的实现上基本都是一样的，因此建立公共用例库应该从界面或者菜单方面着手，以缩短多个项目的用例开发时间。
此类公共用例库，个人建议一定要将用例与需求挂钩，这样，通过对需求的变化，我们将需求不变的部分筛选出来，可用的公共用例也就筛选出来了，测试者可将更多的精力放在需求变化的部分构建新用例。
二是基于类似应用业务需求的公共用例库。
基于相同或类似的业务应用需求，就和楼主说的一样，系统都是一样的，在构建公共用例库时，应该从功能点出发，将流程与参数分离，以达到用例复用的目的。
基于类似应用业务需求的公共用例库，在编辑时建议采用二维图表构建，原理如图：
示例如下：
与楼主举的2个例子比较，这种格式应该更直观，在参数的选择上，可采用等价类分法选择。
接下来回答楼主的3个问题：
1、公共用例尺度应该如何把握？
这个尺度，我有些不太明白，是指用例的颗粒度，还是指其他的？
对于用例的颗粒度，这个我觉得应该根据团队成员的共识与项目情况决定。
2、带参数化的公共用例难于评审（TD,QC这类可以带参数的，其他我不是很了解）
我们团队的评审分两种：
一是有项目组参与的评审，个人认为在这种评审中，项目组主要关注流程方面。
二是测试团队的内部评审，相比较上一种评审，这种评审可能更关注参数的选择。
3、测试人员的水平还有测试人员编写用例的表述及方法。
测试人员水平，没什么好说的，只有通过工作学习提升。
现在我编制一份测试相关文档，都需要写三份，以便于测试者实行统一的规范：
一是空白格式，这没什么好说的。
二是填写规范或作业指导书，估计楼主也会写，至少口头有在宣导。
三是实际案例。完成了空白格式与规范后，由于个人理解不一，有时候写出来千差万别，这时候你就得写一些实际的案例，通过案例结合规范，使得团队达到同一表述。
[ 本帖最后由 woodcraft 于 2009-9-8 16:39 编辑 ] 还没接触到，进来学习下先 公共用例可以节省用例的开发成本，这点毋庸置疑，但也得结合实际情况 感觉楼主有点牛的 形成公共用例难啊，我们单位讨论这个问题很久了。还没有结论。。。有个设备经常测，每次用例都要变动
公共用例想法很好，实施很难，主要还是看尺度的把握
1、首先，偶们需要定义公共用例使用的范围，也就是偶们设计公共用例的目的。通常有以下几种：
1）只在一个项目中使用
2）在类似的项目中使用
3）在所有项目中使用
根据选择的使用范围不同，所需的工作量有几何的变化。偶们经常使用的公共用例都是1）、2）种，但是往往偶们定的目标是第3）种，所以经常会导致领导觉得偶们做的公共用例实用性不强。
2、针对公共用例不同的应用范围，偶们再来具体的划分工作细节。因为本人的能力有限，偶只谈第1）种应用中的功能测试内容。
在项目需求确定后，偶们可以在整理需求时得到以下信息：
1）不同功能模块的完全相同的操作：比如数据输入测试（可分为：编辑框、CheckList选择框、布尔选择框、数据包输入等等），根据输入数据的方式分类，再根据各个输入条件限制分类（比如编辑框可能有些要求全字符输入，有些要求只输入数字字符等），基本可以得到若干个公共测试用例。（这种公共用例设计比较简单，维护成本也较低，是用的最为广泛的）
2）关联模块的相同操作：比如有AB两个功能模块，B在实现某个功能时，需要调度A模块的a功能，则可以把a功能的测试提取出来作为一个公共测试用例，在B模块测试时，只需在a功能的测试用例中加入一个预置条件即可。（这种公共用例设计较麻烦，维护成本也较高，在用例整理和维护上花费的时间也比较多，常常是根据项目实际情况完成一部分即可）
3）关联功能的组合操作：在2）的基础上，将各个模块的子功能划分为极小的单元，每个单元都是一个公共用例，通过组合完成功能测试。单元就像是：输入数字、点击OK按钮等等（个人认为这种做法相当复杂，不赞成使用）
其实就像15楼说的那样：“公共用例可以节省用例的开发成本，这点毋庸置疑，但也得结合实际情况”
关于LZ的三个问题……
1.公共用例尺度应该如何把握尺度决定于公司/项目的预期成本,多大的投入带来多大的回报。尺度越小自然越专业，不过用句俗话：看着专业，用着麻烦。
建议尺度颗粒控制在一个独立子功能即可（有完整的独立输入和输出），比如编辑框、完成一次数据存储操作、完成一次拨号呼叫等都可以。
2.带参数化的公共用例难于评审（TD,QC这类可以带参数的，其他我不是很了解）
首先，参数化是用来做什么的？看着更专业？还是看得更清晰明白？
如果追求于后者，那么建议参数化的国度符号选用大家一眼都能看明白的东东，比如：按下《A按钮》——>进入（B界面）
3.测试人员的水平还有测试人员编写用例的表述及方法。
测试人员水平只能在实战中提升，注意总结测试经验，并时刻将实际所得与理论相比较。
测试用例编写最好全公司固定一种格式，这样也能高效的保障评审“大家都能看懂”…… 首先：我觉得漏掉了一个最重要的部分，公共用例的设计就是为了抽象一些经常用到的，有共同点的操作，但是，前提肯定是很常用的，这样才能保证成本的最小化，如果仅仅用一次的用例，就算再简单，也不需要写为公共用例的。
其次：公共用例一般能完成某一单一的功能，这要看具体情况，如果有几种情况相差比较小，ok，可以把他们总结起来，写成一个公共的用例，可以通过设置某些参数的形式使其完成预期的功能，但是，有个原则：肯定有一种情况把所有的参数都用上（师傅告诉我的，我思考了很久，觉得非常正确）
再次：没有了~~哈哈
页:
[1]
2
