软件测试如何达到一定的覆盖度是个非常重要的问题，它是我们测试分析和测试设计工作的基础和出发点。在白盒测试中，我们可以用逻辑覆盖（语句覆盖、分支覆盖、条件覆盖、路径覆盖）等来指导我们的测试分析和设计，并用来评价我们测试工作的充分性，但在黑盒测试中，我们所追求的是需求要达到一定的覆盖度，那么如何衡量需求被覆盖的程度呢？又如何保证去达到一定的需求覆盖呢？请结合您的思考和实践，畅所欲言，希望各种观点在碰撞中产生火花。

主要要做好测试需求分析测试需求分析分两步：

1，测试需求的获取需求的来源：

显式需求

（1）原始需求说明书

（2）产品规格书

（3）软件需求文档

（4）有无继承性文档

（5）经验库

（6）通用的协议规范隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析

2，需求的分析 ，产生测试需求文档将不同的需求来源划分成一个个需求点，针对每一点进行测试

分析，

（1）界定测试范围

（2）利用各种测试设计的方法产生测试点。
　

目前测试对需求的覆盖程度已经作为判断测试质量的一个标准，但不同的测试类型和需求类型如何

判断测试的覆盖程度？

1、一般来说，非功能性测试的覆盖程度比较好判断，如性能和压力测试，可根据需求中明确的性能指标进行测试分析和设计，另外也可通过分析系统在生产中实际使用情况，来分析一些隐含的需求，如系统是否需要连续运行、系统故障后恢复的级别、并发访问的程度等。

2、功能性测试的覆盖程度是比较难判断的，用例数不能完全说明对需求的覆盖，因为用例数和测试点的力度划分相关，测试点划分的越细，用例数量越大，但不能说明覆盖程度高。

我们的做法一般是先根据用户需求确定测试优先级，重点需求测试点划分的比较详细，测试用例要覆盖所有的情况，如正常值、边界值、特殊值等；一般性需求测试用例覆盖所有的正常等价类；测试用例设计上划分为单功能测试用例和测试场景设计，单功能测试覆盖的需求中的功能点，测试场景覆盖需求中的业务逻辑；另外测试设计全面与否，很大程度取决于需求的质量，取决用户是否真正明白自己想让系统做什么。

看了上面高手的分析，真是受益匪浅啊~！~我也同意首先要透彻理解需求文档，把不明白的地方与开发人员、设计人员沟通。
理解完需求后，我们就得开始写测试需求了，在测试需求了，我们将对软件或项目进行庖丁解牛的手法，将其功能模块细分出来，然后将模块中的功能点分解出来，我们得保证最后的功能点为最小分子，不能再进行下一步分解拉。（当然我们可以借助一些测试需求编写工具拉）测试需求细分出来后，剩下的就是编写测试用例了。每个最小分子需求对应写一个测试用例，用例中要将能想到的方法步骤全部写出来，大家开会讨论，不漏掉。执行“不抛弃任何一个方法、不放弃任何一个idea”。至于相关联的功能模块之间，我们也得考虑设计测试用例。（这些只针对黑盒测试的功能测试）

个人见解，大家一起讨论学习！！

黑盒测试覆盖度保证的一些观点看了楼上这么多人的答复我受益匪浅，我也说说自己的意见。

我们一般拿到需求说明书并且测试目的严格已需求说明书为根据，即使需求变动了，那也是先变需求说明书我们这边才跟着变动测试用例等，当然这是理想状态，但我们不就是向着理想前进吗？我想回答这个问题的前提应该是需求已经确定了，所以我觉得关于需求的确定问题就不应该是在这里讨论。单单只是讨论黑盒测试（或者说黑盒测试用例）如何保证需求的覆盖度。

1、对需求的分析：保证覆盖度首先要保证对需求点提取的覆盖率。测试一切以需求为根本和中心指导，如果在开始覆盖度就不高，那么你后面做的再好也就那样了。

2、设计测试用例：对于分析提取的需求点编写对应的测试用例，而用例的编写必须要依据科学的方法才能有权威、公正性，尽量减少个人因素的影响，那么可以使用等价类、边界值、因果法、错误推测法等，但同时使用这些方法编写测试用例是又很大的依赖与测试人员自身的素质（性格、专业知识等），所以我们在尽最大的可能平稳（公正）做好自己本分的工作那么就可以很大一部分覆盖率了。

3、测试用例评审：但每个人都是不同的，思考方式、方向等都是不同的，你想到而我没想到的情况是非常多了（随着经验的增多会逐步减少），这样就遗漏了方面，覆盖率也就不够了，所以评审是必然的，它可以确定并补全测试用例。此后黑盒测试覆盖率的前期发展至高了。

4、执行测试：测试用例编写确定好了后就是测试执行了，

1）、测试用例执行100%覆盖。

2）、但测试用例覆盖率还是未达到100%，其中等价类、边界值、因果法这些有逻辑依据的方法是很好覆盖且一般不容易出错，但是错误推测法这类方法主观性很强且不好推测，所以也要根据实际情况来做一些调整、增加的测试行为，同时也要更新测试用例来提高用例下一次的测试覆盖率。

以上！

个人拙见！

个人看法：在测试方法方面，可做如下注意：

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

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

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

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

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

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

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

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

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

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