例如，点具体的按钮，输入具体数据等等

不需要吧，如果测试用例这样写的话，岂不是比说明书还详细

如果不需要，测试人员怎么知道怎样操作？哪个数据有效？

需要！当然需要！越详细越好！

写测试用例是一项很繁复的工作，但是写用例时是越详细越好，确实比较矛盾哪

问题是如果写的太详细，测试人员就太机械式的操作，即使不懂需求也能测试

我觉得用例只要把注重的方面写出来，然后写出预计的效果就可以了,不用写太多的步骤

引用:

Originally posted by 咕嘟咕嘟 at 2004-12-9 09:14 PM:
我觉得用例只要把注重的方面写出来，然后写出预计的效果就可以了,不用写太多的步骤

你如果真的是这样的话，可不可以在你写了测试用例后，给你一部分看看 ，我想学习一下

俺也想学习一下。

一个优秀的公司测试用例的设计方向是：提供可重用率（也就是降低重复劳动），测试实施的自动化。
针对这两个方面而言，测试用例必须做的很详细。

我觉得用例只要把注重的方面写出来，然后写出预计的效果就可以了,不用写太多的步骤


我也是这样一个想法,但是具体写的时候还是按照每个功能,或界面上的每个选项进行编写,用是总觉得写出来到很简单,没有什么深度用例.不知道大家一般写用例的时候都是怎么样的

肚皮，
借你的测试用例给大家看看嘛
我们太感激你了
呵呵

我觉得用例只要把注重的方面写出来，然后写出预计的效果就可以了,不用写太多的步骤


我也是这样一个想法,但是具体写的时候还是按照每个功能,或界面上的每个选项进行编写,用是总觉得写出来到很简单,没有什么深度用例.不知道大家一般写用例的时候都是怎么样的

可惜没有人有固定的模式给我借阅一下
若有，我在所不辞～

其实测试用例应该是有一套规范的，就像开发人员前期在PD中的需求设计一样，在TD中每一个类别的模块都应该有一套自己的结构，这样不同的测试人员在后来交叉执行测试用例时才会能很快适应，不然十年后你写的测试用例就跟你现在写的没什么区别。

引用:

Originally posted by 丁琳 at 2004-12-10 09:48 AM:
肚皮，
借你的测试用例给大家看看嘛
我们太感激你了
呵呵

其实我也想把自己工作中的东西拿出来，让大家批评指正，这样自己才会提高，但是我们做的东西是保密的，我也签了保密协议，绝不能漏出工作中的东西，无奈。

引用:

Originally posted by dionysus at 2004-12-12 02:11 PM:
其实测试用例应该是有一套规范的，就像开发人员前期在PD中的需求设计一样，在TD中每一个类别的模块都应该有一套自己的结构，这样不同的测试人员在后来交叉执行测试用例时才会能很快适应，不然十年后你写的测试用 ...

对td很有研究啊，td我越用越觉得有东西可以学到

郁闷啊，老板要求写出的测试用例要尽可能多的覆盖功能点并且每个功能点的测试目的明确，不希望测试用例中有太多的数据，也不希望测试步骤太详细，可是这样的测试用例在实际测试中效率太低，不懂domain的新手根本测不了

根据情况考虑，太细或者太粗都不好，主要看case是为什么人准备的

同意楼上的观点，测试用例要根据具体情况、测试内容而定~