大伙说说，测试案例需要细到什么程度？

tf721

大伙说说，测试案例需要细到什么程度？我说的是测试步骤。  是指明方向让测试人员去发挥测试呢，还是把测试步骤和测试数据都准备好，只需要执行就行了。

Jackc

测试用例的度取决于测试资源与测试目标。

两者中，测试资源占较大比重，测试目标的比重较轻。

毕竟，没有资源的目标只是空想。而目标可以为资源的分配提供依据。

所以，LZ说的两种方式在国内都很常见，只是各自公司根据自身的测试资源和目标做出的相应测试策略而已。

liangshi

> 是指明方向让测试人员去发挥测试呢，还是把测试步骤和测试数据都准备好，只需要执行就行了。

让测试人员去发挥。一遍一遍地执行详细的流程，会将人退化成机器，一个没有主动思考能力的测试者不能发现问题。一个没有创造性的工作，会让人厌烦，一个厌烦自己工作的测试者不能发现问题。

用测试案例描述测试目标，测试策略和大致的步骤。让测试者根据自己的经验、对软件的理解去实施测试。有些测试者没有经验，需要测试领导带着他具体实施几次测试。

zhangting85

功能测试的测试用例一般是两种设计方法
传统的过程用例设计方法由IEEE提出，就是你说的把步骤和数据都写进去。那么你用这种方法，一旦系统变更了，就会陷入大量用例需要大量变更的噩梦之中。

敏捷方法发展至今，已经有一种新的方法，是只指明测试点，而不写测试步骤。比如文本框的测试，就这样：
1.合法数据
2.过长的数据
3.空数据
如此，仅仅是一个例子。此方法由Agile Consultant Brian Marick提出

我个人倾向于Marick的方法。

注意，这仅仅是说功能测试，回归测试则有不同的写法。

[ 本帖最后由 zhangting85 于 2010-8-5 15:23 编辑 ]

liuwwb

这个问题我也很迷惑！
以前一个在华为工作的人告诉我，测试用例的描述越傻瓜越好，这样就让一个不熟悉项目的人来执行测试用例都可以顺利执行，而这就说明，这个要写的很细，似乎就如楼上所说，传统的测试用例设计方法！这样一旦变更，可能真的会陷入修改测试用例的噩梦中。
但如果不细，由测试员自由发挥，我觉的太有可能漏掉很多东西了，这显然导致，不同的测试员执行测试用例的结果是不一样的。
本人刚作测试，是菜鸟，在这个问题上一直很纠结！

Jackc

其实在测试前期不用过于纠结这个粒度问题，不同企业的粒度标准都不一样。在不同的企业只需参考它们以前的类似文档的相同粒度分布就可。

当你在做了几年，逐渐了解测试粒度策略后，就可以尝试自己定义粒度，优化测试用例，甚至是方案了。

xnliuying

牛粪

看给谁用，新手or熟手，自己or别人，其实没遗漏才是真理