大家说说看根据需求写测试用例的时候是需要精简还是需要详细描述？

鹭岛

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

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

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

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

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

alancheny

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

鹭岛

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

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

higkoo

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

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

鹭岛

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

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

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

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

gs6431

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

gs6431

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