黑盒测试如何保证测试用例的覆盖率啊？

lxh15

学习中

doublered

为什么要34/42呢？

doublered

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

tjj006

我建议把这个问题放到每周一问里。
每周一问大家的积极性比较高的。

天天乐乐

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

Neoess

想学习下。

jiangyangw3r

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

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

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


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

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

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

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