我现在在写一个比较大型项目的测试用例
看过需求后，本着详细描述的原则，我在测试用例上写了比较详细的预输入结果（基本上数据输入结果，页面显示结果，光标定位等等页面显示的信息），但这样做描述反而烦琐起来，如果这些用例由我测试，我这样写完全没问题，因为我自己写的我看得懂，但是用例不可能我写我测试，测试是这个项目组安排的，到时候给别人测试，这样会照成他们的困难增加

大家觉得应该怎么写测试用例？

很简单比如一个简单的输入保存，
我会写：
预计输入：**字段（用**代替具体）输入无效数据的，点保存
预计输出：1.系统提示：**数据无效，请重输
          2.鼠标停留在该无效数据字段上
          3.该输入信息被保留但不保存该数据信息。

比如一个删除，我会写：
预计输入：选中一条具体信息，点删除（简化条件说法，反正该信息可删除）
预计输出：1.无提示，该条信息被删除。
          2.无法通过相关查找、查看等操作查找到该信息
          3.该数据被放入回收站内，通过回收站的恢复功能，可以恢复该数据，并且恢复后数据与删除前一致。
          4.光标选中被删除行的下一条数据，如果碰到最后一行，光标应指向最后行

我的描述大概是这类型的，感觉很烦琐，但是想想，其实就是详细描述一切结果，简化的结果就是该信息被删除，其他都不用管或许也可以了，可我有时候感觉都需要考虑到这些其他操作的影响，大家说说看如何编写更好的测试用例？

LZ的测试用例写的还是挺仔细，挺好的，很全面！仔细看了你举的两个例子，我认为可以把你的用例在进行拆分。比如那个删除的用例。预计输出中的3，4都可以再被写成一条测试用例。你可以把你的用例分成一个个group.比如删除这个gropu就可以包含三条case,分别对应你的里面的1，2，3，4几个预计输出。

引用:

原帖由 alancheny 于 2008-3-18 11:29 发表
LZ的测试用例写的还是挺仔细，挺好的，很全面！仔细看了你举的两个例子，我认为可以把你的用例在进行拆分。比如那个删除的用例。预计输出中的3，4都可以再被写成一条测试用例。你可以把你的用例分成一个个group.比如 ...

这样会造成大量的测试用例，目前这个项目预计1000条测试用例，写在TD上已经相当多了，如果步骤一直增加，恐怕执行起来更多更烦琐了。

像那种通用操作，可以不写在用例的，或简而代之，或做一个通用的模板。

特别是业务型系统，更注重的是业务逻辑，“小问题”不导致大问题的，可以后期考虑或低级别。

引用:

原帖由 higkoo 于 2008-3-18 14:06 发表
像那种通用操作，可以不写在用例的，或简而代之，或做一个通用的模板。

特别是业务型系统，更注重的是业务逻辑，“小问题”不导致大问题的，可以后期考虑或低级别。

这个建议好，考虑中。。。但是测试用例有1000多，如果前期仅仅考虑业务逻辑，其他比较“小问题”不去考虑，后期来做维护用例会相当麻烦，而且也很耗时
很感谢，现在就是有点想只看业务逻辑还有结果，其他比较小的东西最后考虑。

[ 本帖最后由 鹭岛 于 2008-3-18 17:04 编辑 ]

建议将测试用例分类，功能测试用例描写你所举的例子，对于简单功能，常识性的，可以简化描写。功能测试用例应用于功能测试阶段，既功能测试用例的测试对象为一个模块。然后对于业务逻辑，编写系统测试用例，在系统测试用例中只描述业务逻辑、数据流等内容。如果你的测试策略更细的化，可以编写集成测试用例。这样可以在一定程度上解决测试用例的管理和后期维护问题。

建议将测试用例分类，功能测试用例描写你所举的例子，对于简单功能，常识性的，可以简化描写。功能测试用例应用于功能测试阶段，既功能测试用例的测试对象为一个模块。然后对于业务逻辑，编写系统测试用例，在系统测试用例中只描述业务逻辑、数据流等内容。如果你的测试策略更细的化，可以编写集成测试用例。这样可以在一定程度上解决测试用例的管理和后期维护问题。