51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 14600|回复: 26
打印 上一主题 下一主题

[讨论] 黑盒测试如何保证测试用例的覆盖率啊?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-3-3 22:51:40 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
如题,向高人请教:黑盒测试如何保证测试用例的覆盖率呢,如果可以,可以举些具体的例子吗?多谢了!
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

27#
发表于 2009-2-11 15:25:24 | 只看该作者

我来回答你的问题

首先要统计测试用例的覆盖率,就的要搞清楚,你测的东西是什么,是什么呢?
1,是代码;2,是需求,需求归根结底还是要转换位代码。

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

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


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

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

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

[ 本帖最后由 jiangyangw3r 于 2009-2-11 15:32 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

26#
发表于 2009-1-14 16:50:49 | 只看该作者
想学习下。
回复 支持 反对

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

24#
发表于 2008-6-4 20:27:39 | 只看该作者
我建议把这个问题放到每周一问里。
每周一问大家的积极性比较高的。
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2008-6-2 18:45:37 | 只看该作者

回复 8# 的帖子

我觉得四个功能点覆盖到了就是全覆盖到了啊。应该是100%。如果你细分功能的话,可能还有许多的功能点,看看有没有覆盖到。
仅个人看法
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2008-6-2 18:43:42 | 只看该作者

回复 8# 的帖子

为什么要34/42呢?
回复 支持 反对

使用道具 举报

该用户从未签到

21#
发表于 2008-6-1 20:21:40 | 只看该作者
学习中
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2008-4-27 11:47:14 | 只看该作者
LZ,貌似你领导问的不对
书上抄来的一段话:测试用例的覆盖率指的是根据测试用例进行测试的执行结果与实际的软件存在的问题进行比较,从而实现对测试有效性的评估
测都没测怎么知道覆盖率啊
回复 支持 反对

使用道具 举报

该用户从未签到

19#
发表于 2008-4-27 11:41:55 | 只看该作者
新人,学习
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2008-4-25 22:16:34 | 只看该作者
楼上有几位说的是测试用例的设计方法,而不是测试用例覆盖率的计算方法

唉,我也在找此类文章,这个东西好像蛮主观的,怎样做到更加客观呢?
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2007-7-19 09:45:31 | 只看该作者
呵呵,咱也是新人,来溜溜看看,看看学学!
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2007-7-17 14:09:14 | 只看该作者
如果按我想的去写用例,我感觉我写的用例实在太多了.不知道怎么简化而且能提高效率
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2007-7-17 13:19:14 | 只看该作者

等待答案ING。。

sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2007-7-17 10:29:38 | 只看该作者
路过
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2007-7-17 10:25:06 | 只看该作者

等待高人解答

等待高人解答
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2007-6-22 11:32:13 | 只看该作者
关注中
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2007-6-22 11:19:38 | 只看该作者
还是没有得出测试的覆盖率如何,从需求和开发的文档,还是无法得出一个具体的数值啊
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2007-5-19 09:25:41 | 只看该作者

如下

当程序开发人员在设计时,多查看需求分析、概要分析。大概了解程序需要完成的功能和需要。
简略得设计测试用例(肯定还需要改,只是设计测试的大概的方向)
当程序开发完成后,大概得从开发人员的设计问档,或从他们口中询问此程序能够实现的功能。并简单得尝试这些功能,了解需要测哪些测试。
这时候编写测试用例
1,边界值法。
2,等价类的划分
3,错误推测法
4,因果图法
5,正交运算法
6,场景测试法
等等一些根据程序和软件的类别 需要用的测试方法
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2007-5-18 14:50:35 | 只看该作者
学习中
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-11 03:34 , Processed in 0.098318 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表