51Testing软件测试论坛

标题: 测试用例的数量应该怎样统计？ [打印本页]

作者: xingcyx 时间: 2006-4-25 15:25
标题: 测试用例的数量应该怎样统计？
我们部门的成员之间对于这个问题出现了一点小小的分歧。
有人说应该是一个功能点算一个用例，有的人说应该是一组输入数据就算一个用例，有的人说一个大的用例就是一个用例。甚至还有人觉得讨论这种问题没有什么很大的必要。
但是我觉得我们要做专业的测试，对这种问题一定要有一个明确的说法。不知道各位的公司都是怎么做的，业界通常的标准又是什么样的，我们准备尽量向业界的标准靠拢，这样以后和人沟通起来才有共同语言。欢迎大家踊跃讨论。

作者: binary 时间: 2006-4-25 15:59
功能点和用例之间,有时是1对1,有时是1对多,这要看你的用例是如何设计的.

作者: xingcyx 时间: 2006-4-25 16:06
现在的问题不是怎么设计，而是怎么统计。
我们经常看到一些资料会说到，对于一个复杂的系统，测试用例的数量会达到成千上万之多。可是按照我们实际的操作和算法，我们一个系统通常只会用到几十个用例就了不起了，如果单从这两个数字来看，别人很容易就认为，我们的测试不够全面，不够专业。所以我想，有些事情，还是要按照标准（如果有的话）来做会比较好。

作者: 慢慢变胖 时间: 2006-4-25 16:34
如果你们的test case和test data分开的话，你可以统计tests的数量作为你们执行的工作量
设计的工作量分为test case和test data的数量
当然绝对数量并没有什么很多的参考意义，还应该对数据进行分类加权才能得出真正的工作量数据

作者: lile 时间: 2006-4-28 10:35
各公司测试用例设计的粒度不同，适合自己的需要，适合业务的需要即可，测试用例的数量统计方法，我觉得说明不了测试作得是否专业。对于进行工作量的统计还可以，不过用例还是不能简单的以数量来看，设计一个很简单的功能点的用例可能很容易，可能一天能设计10个这样的用例，但是对于一个相对复杂的功能，可能一天才能准备两个用例，光靠数量是说明不了问题的。测试用例设计的覆盖率和有效性，才是说明测试是否专业的依据之一。

作者: slide 时间: 2006-4-28 13:28
仅靠数量来评价是不全面的。
但有个思路你可以考虑一下：

如果不需要任何修改就可以重复执行，而且执行起来不会出现差异的操作过程，可以作为一个测试用例的最小统计单位。

可以考察一下，你自己说的大测试用例，每次可以无差别的执行吗？如果配置条件或环境出现了一些变化，你的测试用例是否需要修改呢？如果修改的话，那么就应该算是又增加了一个测试用例，尽管和原有的用例非常相似。
举例来说，你把所有测试内容合并为一个大用例，用例数量为１，但每次执行都会增加一个类似的大用例，而且修改起来工作量很大。很明显这样的划分是有问题的，这样的用例可以定义为有问题的用例。

对于设计不好的系统，这样有问题的测试用例会很多，会给管理和维护带来非常大的麻烦。对于设计比较好的测试用例，相对要稳定得多。
举例来说，你如果把用例的执行和数据分离开后，测试用例的数量会大大下降，可以把多个用例合并为１个，但效果执行效果会更好。

对于用例来说，质量比数量更值得关注。

作者: aricone 时间: 2006-4-29 09:27
感觉楼上说的非常好，用例的维护还是一个大问题。测试用例的主要目标就是更好的指导测试，不是表面功夫。所以，质量重于数量。尤其是现在国内软件行业的情况，项目中的变化还是比较频繁的，无论是大变化还是小调整，任何风吹草动都需要测试及时的调整自己的策略和用例。维护问题很实际..

作者: xingcyx 时间: 2006-4-29 12:19
几位说得都非常好，我本人也是很赞同。
但是基于现状，
1、很多时候，在某种程度上，领导和客户看重的就是表面工夫。你之前的测试工作做得如何，如何做的，他们不关心，但你最后出具的测试报告，如果是相当专业而规范的，他们就会认可你的测试工作。
2、质量重于数量，这点毫无疑问。然而不可回避的一个问题是，所谓质量始终是一个很主观的概念，当你难以从其它方面来证实你的用例质量是足够好的时候，只能通过数量上来说话了。这是一个很现实的问题。当然，我在这里排除无意义的一味地堆砌数据的那种极端情况。说白了，你说你的用例设计得好，没有数据说话，别人凭什么相信你？你说你的一个用例花了两天才想出来的，别人要有疑问，你的用例真有这么复杂吗？或者这是你的工作效率低下的表现？毕竟，质量是主观的，数量才是客观的。
3、对于不了解软件测试的那些人，我们不能要求他们都有我们这么“高”的觉悟，这里还有个沟通的问题。甚至，同样是做测试的人，也应该有共同的语言，才利于沟通。讲白了就是，最好有一个统一的标准和计算方式，尽管有的标准并不是那么容易制订的。

因此我的看法是，我们要摒充那种过分的表面工夫，但也绝不能因噎废食，所有的表面工夫都不做。就像文档一样，不是也有很多程序员认为程序文档和注释都是表面工夫吗？事实上并不是这样的。毕竟如果我们要想有进步，向著更专业的方向迈进，那就要比别人多考虑一点。

[ 本帖最后由 xingcyx 于 2006-4-29 12:23 编辑 ]

作者: lile 时间: 2006-4-29 17:00
这里有一点个人看法，呵呵。
1、质量是客观的，可以通过很多客观数据来体现的。
bug数量，达到的性能指标，负载承受能力，系统连续稳定运行时长，用户体验测试时的通过率和满意度，系统功能对需求的覆盖率等等很多指标，都可以用来反映质量。
2、测试报告是否专业和规范，可以从一个角度反映测试是否专业和规范，但是测试计划、测试设计、测试用例、测试策略、测试流程、测试方法等等，也都能够反映测试的水平和专业程度。我觉得领导和客户不一定是只从测试报告来看测试工作，粗看好像是看重表面功夫，但最后肯定还得看测试的质量，如果系统交付后客户投诉不断,有很多的bug在里面，老板和领导一定还会回来找测试的麻烦的，不管你当初的报告写得多漂亮。
3、用例设计的好坏也是可以用数据来说明的。
找两个人对同一个功能设计用例，不一样的用例找出来的bug在数量和质量上是不一样的。为什么不同的人测试同一个功能，能发现不同的bug？用例设计的质量改进了，发现的bug的数量和质量一定会提高，所以可以通过用例发现bug的数量和质量，来说明用例设计的好坏。
4、用例是不是复杂，不是谁觉得的问题。复杂就是复杂。
一个复杂的用例，涉及基本流程、备选流程，正常操作，异常操作，或者一个订单的多个状态转换，配合的数据有正常数据和非法数据，数据可能有多组，数据可能需要预先准备和设计。这个复杂不复杂，用例摆在那一看就知道。
不知道这些意见对不对，大家拍砖，呵呵。

作者: fxlizard 时间: 2006-5-11 23:30
测试用例的粒度划分... 是测试用例设计的永恒的话题...
没有最合理,只有适合你!

作者: lindechangling 时间: 2006-9-12 11:20
很赞同3楼的意见，如果测试用例和测试的数据分开的话，工作量的统计和测试用例的统计就需要按照公司自己的定义来计算了。

作者: lankle_2003 时间: 2006-9-12 18:38
大量的实践证明，测试用例只能在一个方面上去控制质量，因此用例的数量决定不了整个产品的质量
测试用例数量的度量在不同的阶段会有变化，在初期的设计阶段，数量会越写越多，都了测试阶段，要对用例进行维护，有增有减，到了后期，基本变化不是很大
测试是否全面，是否专业，会涉及到很多方面，大的方面如管理、流程、沟通等，小的方面如测试用例、用例的优先级、用例的划分等，单从数量上说明不了什么问题

作者: xihong2004 时间: 2006-9-17 23:05
衡量用例质量的标准，是功能覆盖度
不是数量

作者: yaya1361 时间: 2006-9-18 17:16
个人以为，测试用例的质量还是最重要，一般对一个功能点都会设置至少一个正确用例再加N个错误用例，理论上说对每一个能发生错误的地方都要保证有一个错误测试用例来验证，但实际中很少能做到这样。

我比较赞同采用覆盖法来做为测试用例设计的标准，而不是简单统计数量。

作者: xingcyx 时间: 2006-9-19 15:37
楼上几位说的都很有道理，但似乎都有以偏概全之嫌。我不否认覆盖度的作用，但是你如何来计算覆盖度？一个功能点设计一个用例就算覆盖到了吗？难道你们做测试到最后都没有一个数据来说话？（我们的测试报告目前也没有描述用例数量这个指标，但我很希望以后能有）。我希望各位继续讨论，真正能够回答我开这个贴想要讨论的问题。

作者: wzb521 时间: 2006-9-19 18:26
不会，帮你顶，关注ing

PS：开发里有工作量估计，就是利用一定的算法算出人/日，比如复杂度，模块功能等。
测试评估，也会根据一定的算法，加入相应的因子，比如版本因子，复杂度因子，技术因子。
最后利用相应乘积进行统计。如果非要找出公式，我觉得加入相应的因子，以及因果关系，是比较好的。比如说：既然我们不能直接计算，那就考虑间接计算，通过最后的测试结果或者其他方式去考虑。
对于楼主的这个数量，估计完全量化是不大可行的，毕竟用例是人设计的，人嘛，都是有功利心的，也就产生了分歧，甚至会设计出一些不必要的用例。比如：分页的DATAGRID，你可以加上GRID的容量测试，即用上亿条数据填充，使之出问题，这个是摸棱两可的，谁也不能说错。

作者: unique_jason 时间: 2006-9-20 10:24

原帖由 xingcyx 于 2006-4-25 16:06 发表
现在的问题不是怎么设计，而是怎么统计。
我们经常看到一些资料会说到，对于一个复杂的系统，测试用例的数量会达到成千上万之多。可是按照我们实际的操作和算法，我们一个系统通常只会用到几十个用例就了不起了， ...

这个功能划分的颗粒度也有关系阿，我们测试部门一般一个不大的项目，case数量一般在2000-3000左右的，我现在的项目的case就3000多个了。几十个我觉得不太可能阿，那样的话，能覆盖全吗？

作者: xingcyx 时间: 2006-10-17 10:59

原帖由 unique_jason 于 2006-9-20 10:24 发表

这个功能划分的颗粒度也有关系阿，我们测试部门一般一个不大的项目，case数量一般在2000-3000左右的，我现在的项目的case就3000多个了。几十个我觉得不太可能阿，那样的话，能覆盖全吗？

看吧，问题就这么来了，所以这个就是我开这个贴讨论的本意了。
我不知道你所谓的2000-3000个用例是如何计算的，而你也不清楚我说的几十个是怎样计算的，因为大家的标准不一样啊，因此你说的这个数字和我说的数字会相差这样大。
如果按我们在实际测试中使用的测试用例模版上来计算，确实只有几十个。

作者: r_sunny 时间: 2006-12-28 10:37
贴子变成讨论“如何衡量测试用例质量”的问题了，楼主不急，我也急了！

在工作中我也对此有疑惑，本人认为测试用例数量的统计应该是按测试数据来统计吧。

一个简单的系统登录功能，就可以设计多个用例，如1用户名为空，密码不为空；2 用户名不为空，密码为空.....

我是这样统计数量的。

还有疑问发贴到“测试用例”那边讨论，那里人比较多！

作者: archonwang 时间: 2006-12-28 14:46
按照测试路径划分，一个路径就是一个测试用例，一般10W行代码的项目，至少需要1k的测试用例数量。

作者: smygc 时间: 2006-12-29 12:47
你之前的测试工作做得如何，如何做的，他们不关心，但你最后出具的测试报告，如果是相当专业而规范的，他们就会认可你的测试工作。

太对了

作者: r_sunny 时间: 2007-1-12 10:26

原帖由 archonwang 于 2006-12-28 14:46 发表
按照测试路径划分，一个路径就是一个测试用例，一般10W行代码的项目，至少需要1k的测试用例数量。

黑盒测试不接触代码如何度量?

作者: archonwang 时间: 2007-1-12 13:52
开发提交项中应会提交该项目的估算的代码行数，另外，也可以从功能业务需求中大致进行估算。我这里的习惯是：将单独测试路径作为一个测试用例，但前提也有，一个测试路径中的测试用数据类型不能重复，这应该也是Rational方式测试用例设计的基本规则。

作者: warning 时间: 2007-1-14 21:27
本人一般一个检查点做一个用例

作者: wonder 时间: 2007-1-16 15:18
其实这个问题也困扰我一段时间，
我也习惯将单独的一个测试路径计算为一个测试用例。
但是我在维护TD的时候，测试用例的标题其实是一个功能点，里面维护的每一个步骤才是我认为的测试用例。
但是目前TD上统计不了步骤，所以TD上统计出来的用例其实是我设计的功能点个数了。

作者: soarsky629 时间: 2011-3-5 15:52
我觉得一个用例可以包含好几个小内容

作者: sirboss 时间: 2011-6-13 11:05
.......

作者: santy1983 时间: 2012-6-20 22:37
我觉得应该是要区分的吧，比如数据测试和界面测试，按等价和边界等测试用例就很多了，更具界面的多少、控件的多少就可以出大量的用例；但如如对业务功能点就行测试的话，一般百来个用例就可以了~~

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)