测试用例和测试数据分开?

wslss007

最近看了一篇文章,摘录如下:个人建议将测试用例和测试数据分开，测试用例中的操作步骤应主要体现于业务流程的检验，而测试数据主要体现于针对系统的数据处理结果的检验。考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期，提高工作效率。

大家写用例的时候考虑到这个问题吗?是如何理解这段话的？

fpbaggio

貌似说的有些道理
但是偶没有这样做过，都是测试用例和数据在一起
不过偶还不是正式测试

heavy200t

同意这个观点。
我们以前的做法存在误区，想法所有的BUG在一个用例中发现，结果造成用例非常复杂。而且也很难描述。
现在我们的做法是把数据的测试独立出来，通过不同的业务流转来描述数据的变化。
但这样做是否能解决所有问题，这一点我还不确信。因为有很多数据问题是因为操作导致的。

Lemon_s

同意这个观点。

AJan1000

>考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期，...
LZ说的分开理由当中，提到可以减少测试用例的修改量，这个理由个人觉得还不能够成为分开的理由。因为如果是变更导致用例修改，而不涉及测试数据的修改的话，如画面的样式等，这和分不分开并没有什么关系。
先不管分不分开，觉得关键还是说测试用例本身的质量上，测试用例本身描述能够清晰，例如单体测试用例做到只测试一个点，一个功能，而不是描述繁杂，涉及几个功能点都放在一个用例当中。
以上，个人陋见。LX多指教。

wslss007

原帖由 AJan1000 于 2008-11-13 09:47 发表
>考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期，...
LZ说的分开理由当中，提到可以减少测试用例的修 ...

明白，就是要让用例的内容更清晰，步骤明确，上面那段话是我从那篇文章里面copy的，我也不是很理解里面说的原因是否真的可行。

wangjingying

我觉得这个就类似于自动化测试里面的Data Driven的概念。如果用得好的话，确实可以减少将来修改用例的时间，同时也可以使测试用例具备更强的可读性。我很支持这种写法

m2b2x

原帖由 wangjingying 于 2008-11-13 15:04 发表
我觉得这个就类似于自动化测试里面的Data Driven的概念。如果用得好的话，确实可以减少将来修改用例的时间，同时也可以使测试用例具备更强的可读性。我很支持这种写法

嗯，《软件测试自动化》这本书主要讲的就是这个，测试数据和测试脚本分开，提高测试脚本复用率，提高自动化测试的效果，其实也是借鉴开发的思想，自动化测试本身就跟开发差不多

[ 本帖最后由 m2b2x 于 2008-12-9 19:18 编辑 ]

www.itest100.cn

理论上说，数据不同的case都是不同的测试用例

将用例和数据分开，实际上是将测试步骤和数据作为两个独立的部分存在，测试时候再将上述两样组合成实际的测试用例

这是测试用例复用的一个最常见的一种方式

火山

支持这个观点，提高测试用例的复用，不会导致用例修改而牵扯到数据的修改。

nwahlk

分开固然好，能够减少耦合度。但是，就我目前写的case，很多业务流程里面都嵌着零星数据，很难完全剔除出来。个人认为比较适合那种数据完整输入输出的情况。还有个问题，有人能举个例子看看吗？并说明下变化的好处