这个用例确实写得比较细，覆盖功能和界面测试用例，我们一般会把界面测试用例单独列出来提供界面测试用例的利用率

我们公司的测试用例格式一般
主要流程
分支流程
约束
边界
并发

里面不涉及具体的数据量

先下来看看，多看多学习

ding,我很想看看，但是下不了,积分不够

个人觉得，这样的测试用例执行起来，测试成本太大了，对于一个小公司的测试组来说，无法行通。

  学习学习挖.

是个很不错的用例 谢谢楼主了

是个很不错的测试用例!
但是就如大家所说,我想如果仅仅只是给出了一个需求分析文档,没有设计和界面文档,就怕很难写出这么详细的用例吧?

看Word的总是感觉不习惯,看都都是Excel!

大家都说好，那我下来看看，学习下

不管怎么样  都可以学到东西的

先看一下

写的 很仔细
覆盖率也很高

是不是一些可以合并，不然还是太多了！

看看

看看，比较和自己工作中用到的有哪些区别

引用:

原帖由 szxutao 于 2004-10-29 10:33 发表
项目越大，用例越要写的细致

要完全按照那么细的用例去执行么？如果是600个用例执行一次那不是要花最少2天时间，那里还谈得上回归。而且一发现问题又不能存着要立刻反应给开发人员，开发人员对代码一进行改动那是不是又要从新开始执行用例，那不累死人了？

看完了觉得里面至少还要增加一列，测试用例编号；或者说里面的测试项与测试用例是等价的就不需要；
还有用例是按照1、动作2、输入字段。。来组织用例的 那有没考虑到如果2个输入字段之间的联系，如果2个无效输入字段会产生什么结果
或者说当A字段对B字段产生限制时能否测出。
如果设计定的是提交前发现错误这么写应该没问题，如果是提交后反馈错误就有点小问题吧
总结来总结去觉得场景描述法与步骤描述法写的用例区别在与场景描述法没有傻瓜帮助法式的描写步骤。那么场景描述法的风险会在那呢？
我也不清楚，我觉得我偏向于场景描述的方法与格式。

[ 本帖最后由 x00ganlu 于 2008-2-26 13:15 编辑 ]

这就是好？无语

无所谓好坏了，方法和tool是用来解决问题，无所谓好坏之分
不同方法解决不同问题，不同的context不同的方法会有不同的效果，当然也会有些宣称是包治百病的良药
建立自己的方法库，根据不同的context组合使用这些方法才是关键
做什么都要关注效率和有效两个因素

学习一下  多谢版主啦