zycdele 发表于 2007-10-17 16:51:13

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

lovelovecat 发表于 2007-10-18 09:02:12

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

chenjuanMM 发表于 2007-10-18 16:38:18

:victory:学习学习挖.

jimods 发表于 2007-10-18 16:46:57

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

klly2008 发表于 2007-10-19 11:54:50

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

bill024 发表于 2007-12-28 21:14:11

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

cher_chiang 发表于 2007-12-29 14:59:55

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

xiaofei0604 发表于 2008-1-2 19:34:34

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

mirro30 发表于 2008-1-3 11:56:02

先看一下

aiai2004 发表于 2008-1-3 12:17:31

写的 很仔细
覆盖率也很高:lol

gsj326 发表于 2008-1-4 11:40:50

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

lovelysand 发表于 2008-1-8 14:35:23

看看

chbhaha 发表于 2008-2-25 15:53:07

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

x00ganlu 发表于 2008-2-26 12:20:45

原帖由 szxutao 于 2004-10-29 10:33 发表 http://bbs.51testing.com/images/common/back.gif
项目越大，用例越要写的细致
要完全按照那么细的用例去执行么？如果是600个用例执行一次那不是要花最少2天时间，那里还谈得上回归。而且一发现问题又不能存着要立刻反应给开发人员，开发人员对代码一进行改动那是不是又要从新开始执行用例，那不累死人了？

x00ganlu 发表于 2008-2-26 12:31:07

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

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

庖丁解牛 发表于 2008-2-26 17:06:32

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

otsoft 发表于 2008-2-26 17:16:25

学习一下多谢版主啦

imlele 发表于 2008-3-8 20:57:43

的确很详细呢！

别叫我神 发表于 2008-4-2 16:10:46

下载中``学习中，``

Allanwakin 发表于 2008-4-3 14:51:52

下下来学习学习,多谢
页: 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17
查看完整版本: 【原创转贴请注明出处】一份不错的测试用例