测试用例的数量应该怎样统计？

xingcyx · 发表于 2006-4-25 15:25:31

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

santy1983 · 发表于 2012-6-20 22:37:03

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

sirboss · 发表于 2011-6-13 11:05:54

.......

soarsky629 · 发表于 2011-3-5 15:52:00

我觉得一个用例可以包含好几个小内容

wonder · 发表于 2007-1-16 15:18:30

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

warning · 发表于 2007-1-14 21:27:25

本人一般一个检查点做一个用例

archonwang · 发表于 2007-1-12 13:52:13

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

r_sunny · 发表于 2007-1-12 10:26:42

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

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

smygc · 发表于 2006-12-29 12:47:31

你之前的测试工作做得如何，如何做的，他们不关心，但你最后出具的测试报告，如果是相当专业而规范的，他们就会认可你的测试工作。

太对了

archonwang · 发表于 2006-12-28 14:46:09

按照测试路径划分，一个路径就是一个测试用例，一般10W行代码的项目，至少需要1k的测试用例数量。

r_sunny · 发表于 2006-12-28 10:37:34

贴子变成讨论“如何衡量测试用例质量”的问题了，楼主不急，我也急了！

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

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

我是这样统计数量的。

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

xingcyx · 发表于 2006-10-17 10:59:16

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

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

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

unique_jason · 发表于 2006-9-20 10:24:47

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

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

wzb521 · 发表于 2006-9-19 18:26:12

不会，帮你顶，关注ing

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

xingcyx · 发表于 2006-9-19 15:37:16

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

yaya1361 · 发表于 2006-9-18 17:16:55

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

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

xihong2004 · 发表于 2006-9-17 23:05:11

衡量用例质量的标准，是功能覆盖度
不是数量

lankle_2003 · 发表于 2006-9-12 18:38:34

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

lindechangling · 发表于 2006-9-12 11:20:53

很赞同3楼的意见，如果测试用例和测试的数据分开的话，工作量的统计和测试用例的统计就需要按照公司自己的定义来计算了。

fxlizard · 发表于 2006-5-11 23:30:59

测试用例的粒度划分... 是测试用例设计的永恒的话题...
没有最合理,只有适合你!

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

[讨论] 测试用例的数量应该怎样统计？

相关帖子

站长推荐 /1