缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出哪部分功能/需求缺陷最多，从而在今后开发注意避免并注意实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。

我们曾经在一个项目中算过缺陷密度，个人认为是测试用例质量和通过测试发现的bug数来决定的。缺陷密度 ＝ 缺陷总数/功能点总数，式中的缺陷总数就是在测试系统过程中发现的bug数，功能点总数就是测试用例中各个功能点的总数。

总结：黑盒测试如何保证需求的覆盖度？个人认为关键在于测试用例质量，怎么写出高质量的测试用例，就像前面几位仁兄说的以及平时的积累。

[ 本帖最后由 zhangtao 于 2008-2-25 14:42 编辑 ]

从软件开发的V型模型讲，黑盒测试，对应的应该是Functional Specification，所以黑盒测试应该起于Func Spec，终于Func Spec。以该文档作为衡量测试覆盖率的标准。这是我先前的看法。不过楼上的xdjm们提到各系统之间的联系，虽然Func Spec中不一定涉及到，但我觉得也应该纳入测试范围。但这样就不要定量的分析测试覆盖率了。

首先，是对需求的理解和掌握，我认为版主的这个问题根本只是理论上的，在实际中不可能用到，就算能用也不是 100%的覆盖。
其次，一切都从自身利益出发，只满足客户的需求就可以，当然客户也可能有的需求没有说到，但是这都是可以作为和客户谈价钱的筹码。
再次，不可能把软件做的那么完美，至于覆盖程度只是理论上的，满足用户需求即可，多做也只是浪费时间和精力。
最后，理论上讨论就是本身对需求的理解程度，把握需求的尺度，来走黑盒的覆盖，举个例子：
         需求： 拿用户登陆来说，客户需求说的是能让用户正常登陆到该系统进行操作。
         覆盖：我们可以先正常的理解，
           、UI
   1>UI设计要美观，颜色搭配要适当
   2>按钮的颜色状态，有时候有些按钮在不满足其触发状态的时候，要设计成灰色，也就是不可选状态
2、功能需求
   1>主要考虑输入框内数据的限制，比如数字、字符、符号、一些组合输入、长度限制（如果没有长度限制的话，输入n多数据容易引起程序异常退出）
   2>正确的、人性化的提示
3、性能需求
   主要考虑性能方面的需求，比如n个人同时输入，同时提交，会不会引起异常
4、异常中断
   可以考虑一些断网、断电的情况
5、快捷键
   比如是否支持复制、粘贴、剪贴等快捷键

     就可以了，如果还想覆盖的全面些我想都没有什么必要，等客户提出的时候再作讨论。
比如：
1、用多种浏览器测试，当用到TT之类的浏览器，当第一次用输入错误用户名和密码，不登陆，强制关闭电脑，再次开机，点击TT浏览器后，点击恢复之前的网页，此时，之前的登录名和密码还在麽？
2、用多种浏览器测试，当用到TT之类的浏览器，当第一次用输入错误用户名和密码，登陆（不管是否有提示），强制关闭电脑，再次开机，点击TT浏览器后，点击恢复之前的网页，此时，之前的登录名和密码还在麽？

黑盒测试是不需要考虑内部结构，主要对外部功能点进行测试，数据驱动。
所以第一必须了解需求，对需求进行分析，找出所以数据信息进行分类统计（有效数据和无效数据）。
对统计数据采用边界值，等价类划分，异常数据，因果图法进行用例设计，而且对测试用例进行维护。
说的不好，请高手指点！

我认为测试用例应该是能保证覆盖率的方法之一.

关于这个问题应该有两个假设：１，需求写的足够明确清晰；２测试管理人员经验丰富
a,分析需求并请相关人员做详细讲解
ｂ．根据需求写出经过评审的用例
ｂ．根据经验，可以采取交加测试；
ｃ．根据需求的隐含信息增加测试用例，比如多操作系统、多数据库、不同分辨率等。

我觉得黑盒测试和功能测试不是一个范畴的东西，个人认为黑盒测试是一种测试方法，而功能测试通常采用了这种方法，功能测试也可以采用白盒的方法。
  就我们公司而言，我们会采用黑盒测试的方法去检查软件的几大质量特性，如：功能度、易用性、可靠性、兼容性等。
  对于黑盒测试保证需求覆盖度的问题，我同意大家前面的观点，首先是深度了解需求，这样才能提高需求覆盖度。我觉得可以从两个方面去设计案例，一是按照软件系统界面的功能，利用黑盒测试的方法。二是按照业务流程，设计测试案例。
  以上只是我个人的一些想法，

我来总结一句话吧，就是用尽可能少的测试用例覆盖尽可能多的功能点。

我也说说吧，说的不好，请多多指教。
首先最重要的是吃透需求，然后结合各种测试用例的设计方法来编写测试用例。
在进行黑盒测试的时候我们一个是根据测试用例来进行测试，
另外一个就是发挥自己对业务逻辑的熟悉，来进行一些测试，这时候我们也需要及时更新我们的测试用例。
这样可以是测试用例不断进行完善。

大致就这样吧，大家多指教哈

对于黑盒测试（功能测试），首先是要了解需求；能够对需求分析透彻，才能知道什么是正确，什么是错误；什么样的系统响应更能满足用户的需求；符合用户的操作习惯；适应用户的业务操作流程，也才能正确的设计测试用例，对于测试用例的覆盖性，要能达到100％是不可能的；只能说随着对功能的了解，及其测试经验的积累，能够在测试用例的设计方面更加详实，符合实际需求。

最主要的是做到测试用例先行,做好测试数据的划分!

以前只有白盒才有覆盖率的指标，但看了有些书上也提到过黑盒测试覆盖率。说的是测试覆盖软件需求，我想不通该如何去衡量这个指标，不知各位前辈有何高见？实际测试中结束测试的条件是测试覆盖率么？
我自己认为应该是首先根据软件需求文档列出所有功能点，编写测试用例，测试实际实现的功能点。测试覆盖率=测试过的功能点数/需求文档所有功能点数。不知道是否正确。在实际自动化测试中如何动态显示？还是有很大量的手工工作做。

   关于如何保证需求的覆盖度，除了重点用例设计外，还要考虑到测试策略。

[ 本帖最后由 jane3910 于 2008-2-26 11:48 编辑 ]

首先是对业务系统非常的熟悉，我们有没有发现，起初测试的时候，我们只是发现一些常规的问题，随着对系统理解的深入，我们渐渐地发现了一些很隐藏的问题。
  其次是采用多种测试用例设计方法，从多角度去分析、测试，保证测试的充分性。

如果有正规的需求，就从需求中导出测试用例，因为需求中有详细的需求用例，然后在根据系统的详细设计说明书进行补充，再根据自身的测试经验进行补充，如果没有正规的需求，就需要自己组织，这样就必须对被测对象进行彻底的分解熟悉，再结合自身的经验以及研发的文档进行测试用例的设计，然后通过测试组内的评审完善测试用例。

其实最缺乏的测试用例是当前功能模块和其他相关功能模块（有些看似风马牛不相及的功能，其实还是有内在联系的）关联的部分，这需要对整个被测系统的全面熟悉和不断的经验积累，
甚至在评审中也可能发现不了的问题。

所以测试用例要在测试中不断完善。

好，果然高手如云

就我工作的经验而言，黑盒测试需要保证覆盖率一般需要考虑的有以下几点
1：所有功能点是否完全覆盖
2：一些可以提炼出来的模块比如注册登陆，网站的cookie等它所需要的一些约定俗成的检查点是否有完全的覆盖。
3：黑盒还是有逻辑可言的前台业务逻辑的覆盖也是很重要的组成部分
4：透过一些功能点去猜测背后的程序逻辑查找可能的隐含bug

个人观点：
将需求分解为特性点，也可由产品经理列出产品的特性点，测试用例最基本的就是覆盖这些内容，再将测试方法、经验、项目特性、用户角度等加入测试要点中，再测试界面规范、可用性、业务流程等，最终进行交互测试和回归测试

学习 学习

向大家学习了!呵呵,感谢楼上的各位的精彩说明!