51Testing软件测试论坛

标题: 黑盒测试如何保证测试用例的覆盖率啊？ [打印本页]

作者: xxbb_1926 时间: 2007-3-3 22:51
标题: 黑盒测试如何保证测试用例的覆盖率啊？
如题，向高人请教：黑盒测试如何保证测试用例的覆盖率呢，如果可以，可以举些具体的例子吗？多谢了！

作者: fate 时间: 2007-3-4 20:37
运用好等价类划分,边界值分析,错误推测分析来做应该能保证sdlkfj5

作者: nan3937 时间: 2007-3-6 09:53
写用例一定要明确需求！！！只有需求完全了，才有测试用例的覆盖率一说。
如果你连要做成什么样的都不知道，怎么测呢？
一旦需求明确了，可以做个RTM。每个需求的每个点都要check到，就可以保证覆盖率了。至于设计方式就像一楼说的，运用好等价类划分,边界值分析,错误推测分析。

作者: xxbb_1926 时间: 2007-3-6 12:26
谢谢楼上的两位啊！sdlkfj3 sdlkfj3

作者: susan.ni 时间: 2007-3-6 12:56
黑盒测试的评估基准是测试用例对需求规格的覆盖率.

作者: xxbb_1926 时间: 2007-3-9 10:25
呵呵，谢谢楼上的几位sdlkfj2

作者: zhouxiao 时间: 2007-4-25 15:33
sdlkfj2

作者: tyx 时间: 2007-5-18 14:41
我还是不明白具体的怎么算？如一个简单的小系统，主要有四个功能点：登录，上件文件，下载文件，删除文件，我写了34个测试用例，领导让我算出测试用例的覆盖率，如何计算？？？后来我算出来了，另外又找了8个用例，是四个功能点联合起来，就是做为一个整体来设计的用例，这样的话一共就是42个用例，用34比42，得出来的数就是所胃的测试用例覆盖率吗？？？？？这样算对吗？？？？请高手指点，急~~~~~~，谢谢！！

[ 本帖最后由 tyx 于 2007-5-18 14:43 编辑 ]

作者: 巩员外 时间: 2007-5-18 14:50
学习中

作者: hapliu 时间: 2007-5-19 09:25
标题: 如下
当程序开发人员在设计时，多查看需求分析、概要分析。大概了解程序需要完成的功能和需要。
简略得设计测试用例（肯定还需要改，只是设计测试的大概的方向）
当程序开发完成后，大概得从开发人员的设计问档，或从他们口中询问此程序能够实现的功能。并简单得尝试这些功能，了解需要测哪些测试。
这时候编写测试用例
1，边界值法。
2，等价类的划分
3，错误推测法
4，因果图法
5，正交运算法
6，场景测试法
等等一些根据程序和软件的类别需要用的测试方法

作者: softkk 时间: 2007-6-22 11:19
还是没有得出测试的覆盖率如何，从需求和开发的文档，还是无法得出一个具体的数值啊

作者: zhangj8826 时间: 2007-6-22 11:32
关注中

作者: 21_lu 时间: 2007-7-17 10:25
标题: 等待高人解答
等待高人解答

作者: duff0011 时间: 2007-7-17 10:29
路过

作者: lichao2000 时间: 2007-7-17 13:19
标题: 等待答案ING。。
sdlkfj2

作者: cherubim 时间: 2007-7-17 14:09
如果按我想的去写用例，我感觉我写的用例实在太多了．不知道怎么简化而且能提高效率

作者: abc12000 时间: 2007-7-19 09:45
呵呵,咱也是新人，来溜溜看看,看看学学!

作者: michelle_happy 时间: 2008-4-25 22:16
楼上有几位说的是测试用例的设计方法，而不是测试用例覆盖率的计算方法

唉，我也在找此类文章，这个东西好像蛮主观的，怎样做到更加客观呢？

作者: ninimiumiu 时间: 2008-4-27 11:41
新人，学习

作者: ninimiumiu 时间: 2008-4-27 11:47
LZ，貌似你领导问的不对
书上抄来的一段话：测试用例的覆盖率指的是根据测试用例进行测试的执行结果与实际的软件存在的问题进行比较，从而实现对测试有效性的评估
测都没测怎么知道覆盖率啊

作者: lxh15 时间: 2008-6-1 20:21
学习中

作者: doublered 时间: 2008-6-2 18:43
标题: 回复 8# 的帖子
为什么要34/42呢？

作者: doublered 时间: 2008-6-2 18:45
标题: 回复 8# 的帖子
我觉得四个功能点覆盖到了就是全覆盖到了啊。应该是100%。如果你细分功能的话，可能还有许多的功能点，看看有没有覆盖到。
仅个人看法

作者: tjj006 时间: 2008-6-4 20:27
我建议把这个问题放到每周一问里。
每周一问大家的积极性比较高的。

作者: 天天乐乐 时间: 2008-8-20 19:37
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试，要想尽可能的覆盖所有测试，就要根据以上测试方法，详细地列出测试用例，细分功能点，提高测试覆盖率。

作者: Neoess 时间: 2009-1-14 16:50
想学习下。

作者: jiangyangw3r 时间: 2009-2-11 15:25
标题: 我来回答你的问题
首先要统计测试用例的覆盖率，就的要搞清楚，你测的东西是什么，是什么呢？
1，是代码；2，是需求，需求归根结底还是要转换位代码。

白盒测试的覆盖率根据代码就好统计了，一般的工具都能统计。什么junit 以及微软的白盒测试代码覆盖率统计

那么黑盒测试呢，如果按照一般的测试用例方法，系统—》模块—》功能点—》有效/无效；的方式进行测试用例设计的话，很难确定测试用例是否覆盖了全部的需求内容；而且也没什么技术含量；
其实设计功能与系统测试用例更多的从代码和需求的角度去考虑，比如面向对象语言开发的系统，通过“类关联关系”、“属性之间的依赖”、属性的约束或者叫元素的约束，都列出来，之后全部符合约束的叫有效，一条测试用例或者几条；因为有效条件不是唯一的；那么无效呢？那就多了，一个约束可能有几个路径去设计，而且有的系统约束是组合，这就非常的不好统计了；比如一个简单的例子：一个输入框，输入数据长度不得超过256个字符；那么将一大堆特殊字符之类的输进去是一条测试用例，而复制粘贴又是一条。。。

这么讲吧，，要想统计是可以的，而且完全可以，而且可以最大的保证所设计出来的测试用例可以覆盖所有的功能，属性约束，类关系，功能组合等等。

不过就是费事儿，而且过于繁琐，所以标准的情况，是白盒测试做主要的功能测试，为什么呢，就是在测试方法体的所有条件判断以及其他语句，而且大量的功能缺陷是通过白盒测试来完成的。而逻辑缺陷应该在需求评审的时候发现，比如类关系混乱，循环关联，与现实不符等等，如果在进行系统测试的时候有重大的逻辑缺陷，那肯定是要反工的，必然影响项目时间。

但是,目前国内的情况是，一般公司根本就没有白盒测试，开发人员code后就抛给测试人员，测试人员就必须要做详细的功能测试而系统测试反倒其次，遍历每个元素的约束条件了，如果想达到尽善尽美的话，就需要有代码或者软件工程，UML的基础，可以将一个系统拆分，从系统一直拆分到元素。。。。。

[ 本帖最后由 jiangyangw3r 于 2009-2-11 15:32 编辑 ]

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