关键是需求分析、做测试首先要理解需求，通过需求，针对每一个页面或者是模块写出测试用例、然后是同行评审、TL级评审。黑盒测试的覆盖率取决于需求的理解程度。据一个简单的例子，如:登陆权限判定、必须理解，那些用户有那些权限。如果没有理解好需求，在多的测试方法也白搭。

以下纯属个人观点，不恰当之处望各位高人指点

黑盒测试如何保证需求的覆盖度？

    既然是保证需求的覆盖度，那就要对需求进行详细的分析。
    1.将SRS转化为UML图
    2.使用RTM对需求进行跟踪
    3.针对每个功能点，使用不同的用例设计方法，设计测试用例，达到需求覆盖率100%
        4.分析软件的显示和隐示需求，再设计用例。

穷举测试
但做穷举测试是不可能的事情

1.熟悉业务，需求，规格
2.根据测试思想设计测试用例，尽可能全
3.对设计出来的用例进行赛选
4。执行

黑盒测试主要是针对产品需求和功能实现的测试.覆盖面主要是在产品和功能上.

根据CMMI定义，当从需求采集的时候，就已经制定了验收测试用例，为什么这个时候制定验收测试用例，也是为了保证测试的时候能满足客户的需求，所以要想测试覆盖率高首先要对需求进行需求分析，把需求中提及到的所有功能都在测试过程中测试到；并且需求是个宏观的概念，客户提出需求的时候也是在提出功能，而黑盒测试也是针对功能的测试，所以黑盒的测试主要还是针对客户的需求；当进行黑盒测试的时候，首先要保证所有的功能的基本实现，继而在所有功能的基础上进行其他的类型和方法的测试来验证在实现功能的时候是否带进了其他的问题，个人认为黑盒测试的覆盖率是无法达到100%的，通过详细的对需求进行分析，只能是提高和保证测试的覆盖率。

根据CMMI定义，当从需求采集的时候，就已经制定了验收测试用例，为什么这个时候制定验收测试用例，也是为了保证测试的时候能满足客户的需求，所以要想测试覆盖率高首先要对需求进行需求分析，把需求中提及到的所有功能都在测试过程中测试到；并且需求是个宏观的概念，客户提出需求的时候也是在提出功能，而黑盒测试也是针对功能的测试，所以黑盒的测试主要还是针对客户的需求；当进行黑盒测试的时候，首先要保证所有的功能的基本实现，继而在所有功能的基础上进行其他的类型和方法的测试来验证在实现功能的时候是否带进了其他的问题，个人认为黑盒测试的覆盖率是无法达到100%的，通过详细的对需求进行分析，只能是提高和保证测试的覆盖率。

看到前面有朋友说编号,突然想到在CMMI中有份文档叫《需求跟踪矩阵》。

首先从认真分析软件需求，将需求点详细整理，设计对应的测试用例，这些都是必不可少的步骤，我想说的是在设计用例的时候应该尽可能的覆盖所有的功能点，用例不在多，要有针对性，在设计有效用例的同时也应该有无效的用例，我觉得这样就能更好的达到覆盖的效果了，新手愚见，不对之处请多多指教

大家说的都很有道理啊，呵呵。我仔细看了一下，对于黑盒测试的覆盖率保证
确实不能像白盒那样量化。但是只要明确客户需求，采用多种测试方法编写测试用例，同时抓住关键功能测试点，我们还是可以减少功能测试的冗余性及其漏洞的。但是需要绞尽脑汁，鞠躬尽瘁啊

看了楼上诸位的回帖，好像感觉每个人的公司需求、测试都非常正轨，可能是俺的命苦，公司在软件工程这块，针对需求和测试还处于初级阶段，但在这种情况下，黑盒测试要想完全保证需求的覆盖度，就会有一定的难度，因为需求也不完善。。。

有困难就会有探索的精神，公司的状况就是测试人员也过早的介入进来进行需求方面的工作，虽说测试理论方面的知识大家都清楚，但那毕竟是纸上谈兵，当你对一个系统的业务知识都不了解的情况下，想什么因果、穷举等等测试方法如何派上用场，所以关键是在测试能力扎实的情况下对业务了解，把自己置身于需求位置，站的高度不同，考虑事情的深度就不同，测试用例整理的范畴也不同，最终的测试结果也会不同。

归结一点，需求、业务、专业能力，缺一不可：）

个人看法：
在测试方法方面，可做如下注意：
其一，分析出口入口。从入口分析，将可能出现的环境，条件，操作等内容分类组合，然后根据各位测试达人的方法进行整合，逐一验证。从出口分析，将可能出现的结果进行统计，根据结果的不同追根溯源，再找到不同的操作以及条件等内容，统计成文档，逐一验证。

其二，多种测试手法的学习和使用。大家可能更多的关心测试方法，但是具体操作的手法也是需要注意的。毕竟测试方法比较容易找到，各位达人都很熟悉。如果将每个人不同的测试手法总结出来并在自己的测试实施中加以使用，可能会收到意想不到的成果。


在测试流程方面，可作如下注意：
其一，初期要做好需求分析。将需求逐渐细化到小功能点，针对每个功能点进行测试设计。对于完成的测试设计文档，经过项目相关人员的检查评审，做成所需要的初稿。

其二，在测试过程中，根据需求变更和具体测试执行过程中遇到的问题完善测试设计文档。

其三，测试执行结束后，对于出现的问题进行总结。其中包含自己本身发现的问题，也可能会有客户提出的问题。将总结出来的结果融合到测试设计当中去，进一步完善测试设计文档。

对于一次测试，是不可能有覆盖度全面的测试的。需要多次去总结积累，才会使测试越来越全面。


在测试流思维方面，可作如下注意：

其一，测试全面不等于全面测试。不同阶段对于软件测试有不同的要求，比如在0.8版本以前，对于不重要的画面问题或是细小的功能问题就不需要关心。但是在验收阶段，这些内容可能更需要注意。

其二，学无止境，只有不断的去学习不断的去思考，才能使自己测试的能力更强，测试对象的全面性也更完整。

我觉得黑盒测试要更全面的覆盖需求应该做好以下几点：
1.首先要很好的熟悉和理解需求，从MRD,PRD的EDD阶段就要参与进来，了解新的需求，只有理解了需求才能写好用例
2.要对自己所负责的module很清楚，包括UI,FUNCTION，performance等等方面，只有都吃透了才能把用例设计的更全面更准确
3.要学会使用各种设计case的方法学，例如等价法，边界值法，因果图，force－error等等，用例设计要考虑全面，除了要涉及到用户基本功能方面以外，还要考虑到UI界面的美观统一、提示信息的友好、操作的方便性,软件的易用性等等
4.在项目完成以后，根据free test的结果来即使update case也是一种很重要的方法。
只是个人的一些理解，期待高人指点

把需求分类，针对每个分类设定需求优先级（及严重程度），然后针对每个分类设计测试用例，因为测试用例不可能覆盖全部的需求，则用测试用例的覆盖度即可导出系统对需求的覆盖度

本人进入测试行业不久，目前还处于学习阶段。我平常做的就是黑盒测试，那么我就根据自己的一点点经验发表一下拙见，不为别的，只为学习，还望各位大侠多多指教。
黑盒测试我做的最多的是功能性测试。而功能性测试是紧跟着用户需求走的。因此，在功能性测试里，对需求的了解就显得尤为重要。当我们在根据测试用例把所有的功能都测过一遍以后，还可以再返回来，拿着需求说明书，一句话一句话的读。为什么要这么做呢？因为在你写测试用例的时候，很难做到用例的覆盖率达到100％，因此，再次的细读用户需求你很有可能发现自己遗漏在某个犄角旮旯里的东西。这样能起到很好的查漏补缺的作用。
当正常的用例测试过系统后，还可以考虑用一些变态的测试用去测试系统，这样往往会发现很多漏洞哦。
大体来说，功能测试，对于文本字段框，可以一个一个的测，这样花的时间会比较多，也会觉得很繁琐，但是这样真的很全面呀。在业务逻辑方面，只要紧跟着用户需求走，就不会出什么问题，因此，需求管理很重要的。在GUI方面，就要考我们的眼里劲了。当你看一个系统看了很久以后，很有可能在某些地方变的麻木了。因此，这个时候，我们就要停下来休息休息，调整好状态后再来，就会很不一样哦。我觉得这个方法在哪都适用。
对于性能测试可以采用自动测试工具。如果测试的是小的应用软件，那么还可以发动公司的同事、制造大量的数据一起去折磨它，性能不好就会撑不住的。人为的制造高强度高压力的条件来测试性能也很管用，而且也比较全面。

版主的这个问题可能要加一些假设条件才能回答，就是我们手中有一份理想化的需求，是一份规范的需求文档，那么

1、      如何衡量需求被覆盖的程度呢？

我认为就是按照需求描述的功能点或需求点，提炼出测试需求来，为什么要有这样一个步骤，因为实际需求文档描述了显性的需求，许多默认的隐形需求是不会描述的，但是我们测试是需要覆盖到并关注的；然后再根据测试需求来设计测试用例，利用测试用例或测试需求与需求点（或功能点）的关联关系衡量需求的覆盖程度。当然在实际工作中，输出测试需求这个步骤也可以省略，直接生成测试用例，但分析过程是必不可少的。

2、      如何保证去达到一定的需求覆盖？

这个实际上是测试用例的质量和全面性的问题了，通过测试用例评审等手段，保证测试用例的准确性和完整性，实际上就可以达到对需求一定程度上的覆盖，当然也有一些需求是黑盒测试无法覆盖的，可以通过别的方法进行覆盖。

因此我认为通过需求与用例的关联关系（大部分情况是一对多），来衡量需求被覆盖的程度，用组织高质量的测试用例评审，审查等手段，产生高质量的测试用例，从而保证达到一定的需求覆盖。

实际上一些测试管理工具或项目管理工具也体现了这一思想，如TD，就是从需求管理开始一直关联到测试用例和执行。

个人认为，黑盒测试的覆盖主要在于测试系统的功能覆盖，要想达到一定的覆盖度，编写测试用例时需要对系统的需求文件，功能文档等系统的相关文档有充分的了解，特别是对系统实现的功能要了解，并在每个功能的基础上，主要以等价类，边界值，因果图以及错误推测等方法来编写测试用例。以达到功能覆盖的完整。

黑全测试如何保证需求的覆盖度？假设需求是不变的。我们只需要使用黑合测试的策略用等价类、边界值、错误推测、因果图、判定表驱动、正交试验、功能图、场景法等测试就能保证需求的覆盖度。当然这是理想的情况。但是，在真实的项目中需求是在变化的。这就要求做好需求管理。如用TD记录需求的变更，及对需求的管理。就以得到比较高的需求覆盖。个人认为管理好需求，是保证需求的覆盖度的关键点。

主要要做好测试需求分析
测试需求分析分两步：
1，测试需求的获取
需求的来源：显式需求（1）原始需求说明书（2）产品规格书（3）软件需求文档（4）有无继承性文档（5）经验库（6）通用的协议规范
隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析
2，需求的分析 ，产生测试需求文档
将不同的需求来源划分成一个个需求点，针对每一点进行测试分析，（1）界定测试范围（2）利用各种测试设计的方法产生测试点

黑盒测试如何保证需求的覆盖度？
这个应该要看针对什么样的客户,对可靠性和性能,易用性方面的相关要求,所以如果要保证需求的覆盖度,首先是要分析好客户的需求,然后在进行相关方面的设计,
对于功能部分的设计可以采取一系列的测试方法,比如说场景设计,正交设计等等，然后在分析是对性能的要求和可靠性的要求,如果此系统对可靠性要求比较高。那可能
需要考虑一些常用的故障注入方法,如果对UCD要求比较高的话,可能则需要根据一些UCD的相关规范进行测试.更好一点,还搞个用户体验之类来评估次需求的可用性..当然这些都是要
基于成本考虑的...