1.可以复用的用例。
2.操作频繁的用例。
3.在以往项目中经常使用的用例。
LZ的表述应该是结合配置管理工具执行的公共用例库的管理层面吧。
放在公共用例库中的信息，应该至少是基线化了的工作产品吧。
可以从用例的组成部分探究哪些用例适合放到公共用例库中，
a。前置条件
b。操作步骤
c。期望结果
d。关联用例
等等。
以上条件如果满足公司统一的规范，那么就可以放到公共用例里。
但是用例的维护工作不是一蹴而就的，需要进行公共用例库的定期维护。
综上所述，什么样的用例纳入到公共用例中，如何进行公共用例的构建，标准如何统一，还是一个配置管理问题。
以上仅代表我个人观点。
继续看大家的回帖。
公用测试用例目的为了减少重复性工作，增强用例的可用性
公用测试用例目的为了减少重复性工作，增强用例的可用性。个人认为应该将对输入项的校验，选择框，日期框，必填项的校验，分页校验，浏览器的后退及前进校验，上传附件等作为公用的测试用例。一群牛人
看了各位的高见，我都不知道自己写的能不能叫 测试用例了。公共用例还是非常有用的
做成通用的公共用例个人感觉不可能，都需要根据具体情况修改； 但公共用例对应的检查点是可以通用的，尤其像增删改查，翻页、文本框、列表框等的检查。形成公共用例库对以后的复用非常有用。 我的理解，公共用例库不需要去写具体的操作步骤，而只需要将某类功能需要关注的点写出来就可以了。比如新增功能我们要关注的是：1、新增操作是否有权限控制
2、新增功能入口
3、新增见面元素完整性
测试用户新增界面的元素的完整性。请参照下图：
界面元素不能多不能少
界面元素名称要和下图一致
界面元素类型要和下图一致：文本框、下拉列表框、按钮等等
4、新增界面默认值校验
5、新增界面必填项测试
6、新增界面各元素项测试
分别针对各截面元素项的类型、长度、格式等进行测试。标准参考以下表格：
对于各种异常测试界面的提示信息也需要关注，测试开发是否针对各种异常情况进行捕获。
对于下来列表框、弹出框等的测试（比如数据来源的测试）
7、新增功能的限制
比如什么信息可以新增什么信息不可以新增
8、新增的重复性校验
9、新增重复提交的测试
10、新增的异常情况测试
比如新增的时候系统挂了
11、新增后的影响
新增后界面什么提示；数据库怎么展示；新增后的数据对其他功能的影响等
而以上的公用用例可能又会调用其他的公共用例，比如6界面各元素项的测试，每个元素的展示框测试（比如文本框，下拉框等的测试，可以调用其他公共用例的。
[ 本帖最后由 shaofei19820625 于 2009-9-18 12:10 编辑 ] 我是一名初级测试员，对测试了解的并不是很透彻。所以只能说说自己的拙见：
所谓的公共用例是指不用更改任何用例参数即可止执行的用例，软件框架用例，界面一致性用例，翻页控制用例，内存占用率用例，当页帮助及登录等；
至于各子功能项的增删改查不属于公共用例，因为各个功能的配置参数及预期结果不尽相同；
页:
1
[2]
