又和leader闹翻了~被批中

wgfxman · 发表于 2004-7-8 21:15:37

今天开会又和leader意见不一致，哎，最终还是我的屈服:s:s:s:s
为什么同类用例不能合并？就为了满足足够多的用例量？为了满足leader自我感觉良好的覆盖率？

哎，郁闷！！！

wgfxman · 发表于 2004-7-8 21:17:36

同类的用例是不是能够合并？
哪位高手给指点指点？
同样是输入合法性的校验，为什么不能合并写？

jackei · 发表于 2004-7-9 10:47:31

测试用例书写格式的原则是易用，易维护，而不能单纯的追求数量。如果认为可以合并并在合并后不会降低覆盖率，那么完全可以合并。同类的用例完全可以复用同一个测试过程，而只需要准备不同的测试数据即可。

jackei · 发表于 2004-7-9 10:48:16

小可已经在一篇文章中对这个问题有过论述，应该会发表在《程序员》第八期。

fuzengbin · 发表于 2004-7-9 17:26:41

测试工作要看效果，而不是表面文章！:d

wgfxman · 发表于 2004-7-9 18:52:17

呵呵，在我能保证覆盖率的情况下可以合并，jackei是不是能推荐一下用例的有效率或者覆盖率的计算方法，对于所写的用例怎么才能确定达到了满意的覆盖率？您发表的文章例遍有没有关于覆盖率和有效率的计算方法？

jackei · 发表于 2004-7-10 15:52:50

抱歉，并没有包括覆盖率的计算方法，不过你可以通过rational工具中requisiterpro和testmanager的联合使用来实现。

wgfxman · 发表于 2004-7-12 12:30:05

俺们没有工具用呀:,(

wind · 发表于 2004-7-12 20:40:04

通常一个测试用例应该只测试一种情况，不应让一个测试用例完成太多的测试任务，这样不利于测试用例的复用。也许你说的情况不是这种，但应该考虑到。

ting_yt2 · 发表于 2004-7-16 17:11:50

Originally posted by jackei at 2004-7-9 10:47:
同类的用例完全可以复用同一个测试过程，而只需要准备不同的测试数据即可。

我又糊涂了既然是同类的用例为什么要用不同的测试数据呢？
就像wind说的“通常一个测试用例应该只测试一种情况”

wuxiongyu · 发表于 2004-7-23 14:12:53

一把钥匙开一扇门。

realrain82 · 发表于 2004-8-12 14:16:11

Originally posted by ting_yt2 at 2004-7-16 05:11 PM:

我又糊涂了既然是同类的用例为什么要用不同的测试数据呢？
就像wind说的“通常一个测试用例应该只测试一种情况”

我也不明白，我想是不是在对回归测试时的测试数据说的啊？大家说我说的对吗？

realrain82 · 发表于 2004-8-12 14:34:22

还是为了避免一组测试数据有偶然性，所以要对一个测试用例设计多组测试数据呢？那这多组数据的数量要根据什么确定呢？

pent · 发表于 2004-8-26 16:48:23

先把测试用例按一定的规则分成若干个等价类后，在每个等价类中设计若干测试数据（注意考虑边界），至于多少组数据应该没有什么标准吧。

archonwang · 发表于 2004-8-29 23:29:00

编写测试用例很花时间的，一个简单的输入输出可能包含上百个路径。不太可能一下就写全的。我一斑都是一边编写，一边更新，一边测试。不知道还有没有更好的办法了？

zhang_samuel · 发表于 2004-9-11 14:16:37

Originally posted by realrain82 at 2004-8-12 02:16 PM:

我也不明白，我想是不是在对回归测试时的测试数据说的啊？大家说我说的对吗？

我猜想这里可能是指data driven的测试方式. 比如说
测试一个计算机calculator

测试实例一,测试计算加法
1) 获得输入A
2) 按+号按钮
3) 获得输入B
4)按=号按钮
5)验证结果

这是一个过程,但是数据并不在里面, 可以准备两个文件,文件X中为所有的输入A和B,文件Y中为期望结果.这样一来可以自动化测试实例一,就可以由文件来驱动测试.

这个的好处在于维护方便,只要维护文件X和Y就可以提高覆盖率,
但是坏处也在于维护不方便,当有大量的文件存在时,分析文件的结果可能很痛苦,同时当版本更新时,数据文件也要大量更新,工作量往往被低估.

比如如果一个文件中的数据有100条, 如果变成testcase,就是100个testcase,那就可以获得响应的资源(人力,时间)来修改.但是data driven的话,就一个testcase,但是工作量并不减少很多. 而且不容易应用自动分析的技术,比如有一个bug导致某个数据出错了,整个testcase就fail了,但是如果有100个testcase,就是99个pass,一个fail,容易自动分析结果和自动记录bug.

jackei · 发表于 2004-9-12 00:02:12

测试用例：
序号操作过程描述
1 输入用户名。
2 输入密码。
3 确认登录。

序号用户名密码预期结果
1 正确的用户名正确的密码登录到系统并转到系统主界面
2 正确的用户名错误的密码无法登录到系统并提示密码错误
3 错误的用户名正确的密码无法登录到系统并提示用户名错误
4 错误的用户名错误的密码无法登录到系统并退出当前程序
5 空用户名 …… ……

不知道上面的这个例子大家是否可以明白。测试用例侧重的是对于测试思想或者说思路的描述，或者大家可以把它理解为一种操作的步骤或者流程。而对于同一个流程，在使用不同的测试数据时系统的处理方法和结果有可能是不同的。这就是为什么说一个测试用例可以对于多套测试数据。关于这部分内容，大家如果有兴趣，也可以访问我的个人Blog中的“测试过程实践之测试需求与测试用例”http://blog.csdn.net/jackei/archive/2004/07/20/45964.aspx ，或者参见该文在《程序员》杂志2004年第8期的最终版本。

babybear315 · 发表于 2004-10-22 12:44:02

如果对同一类功能仅仅用一个测试用例，是不太妥当的一种方式，对一个功能，也应该用不止一个的用例来测试，所以，你的leader不同意也有一定的道理，但是如果只是单纯的为了追求用例的数量和覆盖率的话，那就太过分了，这个等同于政府部门只做政绩不顾人民死活啊！

Lighthouse · 发表于 2004-10-22 13:07:57

各位：
首先：测试越多越好。
其次：同类用例如果已经独立，最好不要合并。
第三：如果可以合并，那就说明当初的分类或者任务的分配是有问题的。
最后，分析一下：
楼主主观的以为：
为什么同类用例不能合并？就为了满足足够多的用例量？为了满足leader自我感觉良好的覆盖率？
我认为是绝对不正确的，因为楼主连leader为什么不合并的原因都没有搞清楚，就来发牢骚。所以，这里的同仁是不应该主观的支持楼主的。

依伊卜舍 · 发表于 2004-10-25 09:11:28

楼上说得好！
有时自己认为可以合并，但是可能考虑得不够周全呢？再认真分析一下，是否真的不能合并是最重要的！

		自动登录	找回密码
密码			(注-册)加入51Testing

[讨论] 又和leader闹翻了~被批中

相关帖子

请教

当然那可以了

谢谢大家支持

站长推荐 /1