51Testing软件测试论坛

标题: 又和leader闹翻了~被批中 [打印本页]
作者: wgfxman    时间: 2004-7-8 21:15
标题: 又和leader闹翻了~被批中
今天开会又和leader意见不一致，哎，最终还是我的屈服:s:s:s:s
为什么同类用例不能合并？就为了满足足够多的用例量？为了满足leader自我感觉良好的覆盖率？
哎，郁闷！！！
作者: wgfxman    时间: 2004-7-8 21:17
标题: 请教
同类的用例是不是能够合并？
哪位高手给指点指点？
同样是输入合法性的校验，为什么不能合并写？
作者: jackei    时间: 2004-7-9 10:47
测试用例书写格式的原则是易用，易维护，而不能单纯的追求数量。如果认为可以合并并在合并后不会降低覆盖率，那么完全可以合并。同类的用例完全可以复用同一个测试过程，而只需要准备不同的测试数据即可。
作者: jackei    时间: 2004-7-9 10:48
小可已经在一篇文章中对这个问题有过论述，应该会发表在《程序员》第八期。
作者: fuzengbin    时间: 2004-7-9 17:26
标题: 当然那可以了
测试工作要看效果，而不是表面文章！:d
作者: wgfxman    时间: 2004-7-9 18:52
标题: 谢谢大家支持
呵呵，在我能保证覆盖率的情况下可以合并，jackei是不是能推荐一下用例的有效率或者覆盖率的计算方法，对于所写的用例怎么才能确定达到了满意的覆盖率？您发表的文章例遍有没有关于覆盖率和有效率的计算方法？
作者: jackei    时间: 2004-7-10 15:52
抱歉，并没有包括覆盖率的计算方法，不过你可以通过rational工具中requisiterpro和testmanager的联合使用来实现。
作者: wgfxman    时间: 2004-7-12 12:30
俺们没有工具用呀:,(
作者: wind    时间: 2004-7-12 20:40
通常一个测试用例应该只测试一种情况，不应让一个测试用例完成太多的测试任务，这样不利于测试用例的复用。也许你说的情况不是这种，但应该考虑到。
作者: ting_yt2    时间: 2004-7-16 17:11
Originally posted by jackei at 2004-7-9 10:47:
同类的用例完全可以复用同一个测试过程，而只需要准备不同的测试数据即可。


我又糊涂了 既然是同类的用例为什么要用不同的测试数据呢？
就像wind说的“通常一个测试用例应该只测试一种情况”
作者: wuxiongyu    时间: 2004-7-23 14:12
一把钥匙开一扇门。
作者: realrain82    时间: 2004-8-12 14:16
Originally posted by ting_yt2 at 2004-7-16 05:11 PM:


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


我也不明白，我想是不是在对回归测试时的测试数据说的啊？大家说我说的对吗？
作者: realrain82    时间: 2004-8-12 14:34
还是为了避免一组测试数据有偶然性，所以要对一个测试用例设计多组测试数据呢？那这多组数据的数量要根据什么确定呢？
作者: pent    时间: 2004-8-26 16:48
先把测试用例按一定的规则分成若干个等价类后，在每个等价类中设计若干测试数据（注意考虑边界），至于多少组数据应该没有什么标准吧。
作者: archonwang    时间: 2004-8-29 23:29
编写测试用例很花时间的，一个简单的输入输出可能包含上百个路径。不太可能一下就写全的。我一斑都是一边编写，一边更新，一边测试。不知道还有没有更好的办法了？
作者: zhang_samuel    时间: 2004-9-11 14:16
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
测试用例：
序号        操作过程描述
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
如果对同一类功能仅仅用一个测试用例，是不太妥当的一种方式，对一个功能，也应该用不止一个的用例来测试，所以，你的leader不同意也有一定的道理，但是如果只是单纯的为了追求用例的数量和覆盖率的话，那就太过分了，这个等同于政府部门只做政绩不顾人民死活啊！
作者: Lighthouse    时间: 2004-10-22 13:07
各位：
首先：测试越多越好。
其次：同类用例如果已经独立，最好不要合并。
第三：如果可以合并，那就说明当初的分类或者任务的分配是有问题的。
最后，分析一下：
楼主主观的以为：
为什么同类用例不能合并？就为了满足足够多的用例量？为了满足leader自我感觉良好的覆盖率？
我认为是绝对不正确的，因为楼主连leader为什么不合并的原因都没有搞清楚，就来发牢骚。所以，这里的同仁是不应该主观的支持楼主的。
作者: 依伊卜舍    时间: 2004-10-25 09:11
楼上说得好！
有时自己认为可以合并，但是可能考虑得不够周全呢？再认真分析一下，是否真的不能合并是最重要的！
作者: pktest    时间: 2004-11-13 12:40
标题: 其实要考虑清楚合并的前提条件
作者: wintersea    时间: 2004-11-15 15:49
看了jackie说得，受益匪浅
但是如何判断是同类的测试用例，能够复用同一个测试过程？
作者: bitter    时间: 2004-11-15 16:33
wgfxman, 我不太理解什么叫"同类用例"?  你是说类似呢, 还是同一功能呢?

就你的帖子里说的:"同样是输入合法性的校验，为什么不能合并写？",  如果是说系统的两个不同功能, 同样都有输入合法性校验的话, 假如你能确定合法性校验的功能都是同一部分代码在同样的上下文(context)中处理的, 而且你的目的只是检查合法性校验的功能,那么你就可以只写一部分.

但是在这种情况下, 你所使用的就不再是黑盒技术, 因为系统的内部对你来说不再是未知的.

至于覆盖率, 我想你没有说明是哪种覆盖率, 如果是需求覆盖率,那么很简单, 每一条需求都要有对应的测试用例(一个或多个), 如果是代码覆盖率(测试执行了多少代码),就复杂的多.

一般来说, 黑盒测试又被称做基于功能的测试, 设计测试用例时要参照功能规格说明,
每一条功能都要有自己的测试用例.  不管两个功能有多么的相似, 也要有各自独立的测试用例, 因为系统是一个黑盒子, 没法知道是怎么处理的.  两个功能可能有同样的输入, 但是一定不会有同样的处理. 否则开发者就应该把他们合并为一个功能.
作者: ax2004    时间: 2004-11-18 22:20
非常支持楼上所说的话: "每一条功能都要有自己的测试用例.  不管两个功能有多么的相似, 也要有各自独立的测试用例, 因为系统是一个黑盒子, 没法知道是怎么处理的.  两个功能可能有同样的输入, 但是一定不会有同样的处理. 否则开发者就应该把他们合并为一个功能."
作者: sanss    时间: 2004-11-19 13:55
我不是很同意一把钥匙开一把锁的说法，通常单一的功能在测试后期BUG不多，但几个功能集成后BUG就会凸显出来，有些BUG需要几把锁组合后才能出现的，而这种BUG是非常之多的，所以分类的同时要考虑好组合
作者: wintersea    时间: 2004-11-19 16:35
同意楼上的楼上的说法，在测试的时候一定要为每一个单一的功能写测试用例
然后再考虑多个单一的功能有组合的情况。
作者: Nio    时间: 2004-12-8 16:59
如果影响了代码覆盖率，应该不会是同种类型的测试用例吧？
作者: 浅草    时间: 2004-12-14 15:35
如果测试一个信息输入页面，对输入框要判断输入的合法性，如果有很多这样的页面，每个页面有很多的输入框，是否需要对每个输入框的非法输入都设计多个用例。这样的用例能否合并？

[ Last edited by 浅草 on 2004-12-14 at 15:37 ]
作者: wintersea    时间: 2004-12-15 13:53
在写测试用例的时候，对于这个问题我也很疑惑，怎么没人回答问题呢？
作者: snake    时间: 2004-12-15 15:47
Originally posted by 浅草 at 2004-12-14 03:35 PM:
如果测试一个信息输入页面，对输入框要判断输入的合法性，如果有很多这样的页面，每个页面有很多的输入框，是否需要对每个输入框的非法输入都设计多个用例。这样的用例能否合并？

[ Last edited by 浅草 on  ...


我个人觉得浅草说的这样的用例还是不合并的为好，你可以用等价类划分的方法构造用例。
因为每个输入框的非法输入都可能会导致不同的预期输出，如果合并了，那么有一个输入方式导致的输出结果异常，则整个测试用例都执行失败了，这是不合适的。
这样，测试用例的粒度太大了，不能说明当前被测试软件的质量情况。
作者: wangying1982_0    时间: 2004-12-18 13:01
标题: 怎样能改善我目前的状况
我现在测关于专业用于网吧的一个信息平台，这个项目没有相关的文档，不要说测试用例，连用户需求都没有，测试也没有目标。每天大多数时间都在等开发那边能提供新的版本测试，请大家帮帮忙，想想我怎么样能改善目前这种状况。
作者: ghost    时间: 2004-12-20 11:04
标题: 为什么不把你老大的意见和想法说一下呢？
这样大家也不用只看你的片面之词来指则他人了。
他的考虑是什么呀？你问过了吗？
作者: snake    时间: 2004-12-20 17:56
Originally posted by wangying1982_0 at 2004-12-18 01:01 PM:
我现在测关于专业用于网吧的一个信息平台，这个项目没有相关的文档，不要说测试用例，连用户需求都没有，测试也没有目标。每天大多数时间都在等开发那边能提供新的版本测试，请大家帮帮忙，想想我怎么样能改善目 ...

wangying1982_0，这个是软件测试目前存在的比较普遍的问题，公司刚成立测试部的时候开发部也是没有需求规格说明文档的，甚至有的项目是我写的需求文档（因为老板也有足够的重视），你也可以利用“在等开发那边能提供新的版本的每天大多数的时间”来思考你对你的测试有价值的需求是什么，并去找他们提出很多问题，当你的问题能够一针见血的时候，你就会发现你的测试有效性会增加，测试的目标是你自己定给自己的，而不要等着别人给你，我不太擅长言语，如果有什么词不达意的地方或者与你的想法有出入，请回帖大家讨论

[ Last edited by snake on 2004-12-20 at 17:59 ]
作者: happymei    时间: 2004-12-22 11:06
标题: ：）
Originally posted by jackei at 2004-9-12 12:02 AM:
测试用例：
序号        操作过程描述
1        输入用户名。
2        输入密码。
3        确认登录。

序号        用户名                        密码        预期结果
1        正确的用户名        正确的密码        登录到系统并转到系统主界面
2        正确的用户名        错误的密 ...



偶还是喜欢这种写测试用例的方式，简单明了。测试步骤跟测试数据分离，比较方便管理！
作者: snake    时间: 2004-12-22 11:25
的确是简洁明了啊，可惜这样的用例在我们公司无法通过专家评审的，理论和实践之间我还要继续寻找最佳的结合点
作者: walker_lai    时间: 2006-9-3 14:10
可以尝试下用因果图法来确定输入的条件、动作和输出的结果来确定一条测试上应该叫做规则的东西，在其中，如果条件、动作不一样，但是结果一样，是不是可以考虑合并输入的条件、动作！
作者: scarlet    时间: 2007-10-10 16:55
同类用例当然可以合并，这样有利于以后的用例维护
作者: zzytion    时间: 2007-10-10 20:50
等价分析法也不能范围太广,细致可能更容易发现更多的BUG



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2