问题描述：

　　一个系统基本上构造是由：1.增删改查   2.数据流程   这两大块组合的

　　在整个系统中相同的操作、相似的操作可以说比比皆是，如何构造公共的测试用例呢？大家构造过么？

　　问题难点：

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

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

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

　　从2008年初，我就在思考这个问题，如何去权衡这些问题呢，大家来一起讨论，下面是我们公司一个测试人员编写的公共用例里面的正常新增（当然跟我理解的是不一样的）：

　　输入：输入所有字段，执行新增操作

　　输出：

　　能正常完成新增操作。

　　1. 一般有给予相关提示信息，如‘保存成功’。（不强制规定）

　　2. 如果系统有提供数据回显那么回显数据与新增数据是一致的。

　　3. 如果新增数据后有返回到列表，则一般是新增的数据排在首页首行，但也可根据具体的排序需求而定。

　　换成是我来写的话，我会带上参数化：

　　输入：<<<users>>>登录系统，点击【<<<模块1>>>】|| 【<<<模块1子模块>>>】，点击新增，<<<所有字段>>>录入正确有效的数据后，点击保存

　　输出：1. 保存成功并正确返回页面  2. 录入前后数据一致

　　我的方法嘛好处自然是在执行测试的时候知道谁登录，哪个模块执行了什么样的操作，但如果让开发已经公司其他成员来评审的时候，这样的可读性就很低了（毕竟TD上还得经过调用，可读性几乎为0了，评审人员只能查看公共用例模板，调用部分都无法查看清了）

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

精彩回答：

会员wangz：

　　个人感觉什么都应该从最原始的需求出发考虑，偶们是做测试的啊……些公共用力到底是想减少那部分工作，要不然弄得复杂了还不好。太多的形象工作不但没有效率，反而会让人很急躁。

　　公共用例的想法很好，我们也在执行着，但是和楼主的不同，我们建立的公共用例库是仅仅为了节约写用例的成本，使用过程中维护，用例的内容是很具体，如下拉框的测试，复选框的测试，等等，还有就是总结了多个属性关联页面的正交测试方法.个人感觉公共用例不能太设计功能业务上的东西，否则依赖性就太强了很不好……只是从最简单最基础的出发总结出来一些总是重复出现的东西，写成公共的

　　我们还有个库是用于回归大版本用的测试测试用例，类似很多公司的【checklist】，如果从另外一个角度说也算是公共用例的一种。

　　类似你们写的

　　------------------

　　输入所有字段，执行新增操作，可完成能正常完成新增操作。1.一般有给予相关提示信息,如'保存成功'。(不强制规定)2.如果系统有提供数据回显那么回显数据与新增数据是一致的。3.如果新增数据后有返回到列表，则一般是新增的数据排在首页首行，但也可根据具体的排序需求而定。

　　------------------

　　我们不太一样的就是各个功能的主要流程去写，所以就每条详细些，复用起来可能不太好，但也仁者见仁了...哈哈个人感觉

　　评价：

　　我感觉你们考虑的太基于功能考虑多些，最开始我们也想这么做来的但是不但没有得到很好发复，还导致部分人就产生依赖，效率没有提高，但是要做checklist去考虑好像有太模糊了

　　只可惜我们用例就是excel管理，不存在你说的什么参数问题。