黑盒测试
黑盒测试要全面的覆盖需求1.首先熟悉业务，对业务逻辑的熟悉有助于对需求功能点的把握
2.结合程序仔细分析需求，提取测试的功能点和重点
3.根据需求编写测试用例，测试用例尽量覆盖所有功能点
4.在测试的过程中完善测试的覆盖度
5.开始测试要兼顾需求、用例和开发环节中易发生错误的地方
黑盒测试方法
在对软件的质量监督中，黑盒测试起着重要的作用；而随着软件开发平台及软件设计思想的进步和发展，特别是rad技术的发展，对黑盒测试提出了更明确的要求，人们发现，必须遵循一定的测试理论，依赖于优秀的测试工具，才能进行科学、完备的测试。 不知道大家在平时工作中是否整理过测试需求!如前面某位仁兄所说,分功能与性能.通过功能来计算覆盖率还好一点,那么通过性能呢?希望高手指教!!!:)
黑盒测试覆盖度保证的一些观点
看了楼上这么多人的答复我受益匪浅，我也说说自己的意见。我们一般拿到需求说明书并且测试目的严格已需求说明书为根据，即使需求变动了，那也是先变需求说明书我们这边才跟着变动测试用例等，当然这是理想状态，但我们不就是向着理想前进吗？我想回答这个问题的前提应该是需求已经确定了，所以我觉得关于需求的确定问题就不应该是在这里讨论。单单只是讨论黑盒测试（或者说黑盒测试用例）如何保证需求的覆盖度。
1、对需求的分析：保证覆盖度首先要保证对需求点提取的覆盖率。测试一切以需求为根本和中心指导，如果在开始覆盖度就不高，那么你后面做的再好也就那样了。
2、设计测试用例：对于分析提取的需求点编写对应的测试用例，而用例的编写必须要依据科学的方法才能有权威、公正性，尽量减少个人因素的影响，那么可以使用等价类、边界值、因果法、错误推测法等，但同时使用这些方法编写测试用例是又很大的依赖与测试人员自身的素质（性格、专业知识等），所以我们在尽最大的可能平稳（公正）做好自己本分的工作那么就可以很大一部分覆盖率了。
3、测试用例评审：但每个人都是不同的，思考方式、方向等都是不同的，你想到而我没想到的情况是非常多了（随着经验的增多会逐步减少），这样就遗漏了方面，覆盖率也就不够了，所以评审是必然的，它可以确定并补全测试用例。此后黑盒测试覆盖率的前期发展至高了。
4、执行测试：测试用例编写确定好了后就是测试执行了，1、测试用例执行100%覆盖。2、但测试用例覆盖率还是未达到100%，其中等价类、边界值、因果法这些有逻辑依据的方法是很好覆盖且一般不容易出错，但是错误推测法这类方法主观性很强且不好推测，所以也要根据实际情况来做一些调整、增加的测试行为，同时也要更新测试用例来提高用例下一次的测试覆盖率。
以上！
个人拙见！ 实践经验：将每个用例和需求都编号，然后做一张对应的映射表。 测试最难的是什么：是对需求的覆盖
通常情况下对于需求的完全覆盖测试是不可能实现的
所以这个问题需要从多个角度来分析
最重要是如何用最少的用例覆盖最多的需求
说白了就是用例设计的方法和原则
这个前面已经有不少朋友提到了：比如说设计用例时参照软件质量6大原则逐个验证；等价类边界值等等一些用例设计方法；……
但是还有其他一些因素会间接影响到这个问题
比如说测试规程的制定：如果测试规程不合理，可能会大幅导致效率的下降，从而没有足够的时间来执行已经设计完成的用例
另外像测试计划中对于风险估计的不足，对于资源分配的不合理等等，所有的一切都可能影响到最终的测试行为对需求的覆盖程度 正确使用软件与非法使用软件,这两种情况都试一下,把能想到的使用软件的方法都试一下 刚进入测试方向，看了这么多，真是受益匪浅阿，我应该多来这看看， 黑盒测试虽然无法保证需求的覆盖度的全面性，但 可以通过编写测试用例，可在不断增加和扩大需求的覆盖度，个人认为：在设计测试用例时，１、应尽力编写得详细点，２、在测试过程中，可以不断地去完善测试用例。
以上纯属个人见解。。。。。:) 这个问题我经常拿来考面试的（高级）测试工程师。
对于问题的回答每个人都有自己的见解：
1。理解URS/UIS/FRS等之类的需求说明书很重要，因为测试用例一般从需求输出，保证测试的覆盖度一般需要建立一个需求说明书和测试用例之间可追踪的矩阵表格，哪些需求点没有覆盖到，自动提醒或者标红表示，比如DOORS具有这个功能。
2。说到覆盖度，这里要谈到测试工程师的测试经验问题，测试工作执行力度问题，即使再多的测试用例也会如同虚设的测试。你们会问测试工程师跟需求的覆盖度有什么关系？理解测试流程工作的人员相信都会明白。
3。需求评审很重要，但不排除有些所谓的管理人员或专家平时都听人家的意见多的，自己心里压根就没有什么想法。一般建议评审在产品经理，项目经理，需求工程师，测试工程师，第三合作方等中进行，保证项目的里程碑的时间点前提下，尽可能安排几次需求评审。需求的完整和清晰度大大增加了测试的假想空间，特别是有些项目经常变更需求的。
回到这个问题暂时归结三个方面：需求和测试用例之间建立追踪的矩阵，有良好测试经验的测试工程师执行测试工作，保证需求的完整和清晰度。 原帖由 sky.pei 于 2008-2-24 12:47 发表 http://bbs.51testing.com/images/common/back.gif
需求的测试，其实大部分都是业务的测试。常规的业务流程都是固定单一的。这个问题其实就转化成了业务流程的不规范情况的测试。
这种测试时不可能穷举的。
说的太对了,对业务有一定了解,所做的需求分析也能达到一定程度! 根据各种测试方法尽量多写测试用例,测试用例越详细,覆盖率越搞 需求的测试，其实大部分都是业务的测试。常规的业务流程都是固定单一的。这个问题其实就转化成了业务流程的不规范情况的测试。这种测试时不可能穷举的。
这个我也同意，但一些约定俗成的检查点还是必须验证到的，比如表单传递页面，对于刷新页面是否会产生的表单重复投递等等类似问题，也是我们用例必须覆盖到的。 我认为软件是给客户的，所以考虑功能覆盖的话，应该从客户的角度考虑覆盖范围，即客户所能及的范围。再从这用户范围用各种测试方法可以缩小测试范围。之后用常用的比如18楼的那种应该能保证覆盖度了。 首先要根据需求编写出详细的测试计划包括测试用例，这其实就是遍历需求的一个过程，在这个过程中首先要了解客户的业务流程，然后按每个模块实现的业务功能来设计用例，在测试的过程中，先把握整体流程，然后到各个模块，最后细化到字段页面的层面 看了好多回贴,忘了自己本来要说什么来着:L 原帖由 xiaomayi0323 于 2008-2-22 21:38 发表 http://bbs.51testing.com/images/common/back.gif
我认为要达到一定的覆盖度,首先应该将需求吃透,细分需求,才能保证设计出来的测试用例最全面的覆盖需求.
同意你的说法。但同时也补充一点，测试用例一定要通过评审，这样需求才能更明确，针对性的覆盖率更高 这是一个开放性问题。没有什么标准答案。面试的时候很多人喜欢问这种问题。经验是最重要的因素。 关键是需求分析、做测试首先要理解需求，通过需求，针对每一个页面或者是模块写出测试用例、然后是同行评审、TL级评审。黑盒测试的覆盖率取决于需求的理解程度。据一个简单的例子，如:登陆权限判定、必须理解，那些用户有那些权限。如果没有理解好需求，在多的测试方法也白搭。 以下纯属个人观点，不恰当之处望各位高人指点
黑盒测试如何保证需求的覆盖度？
既然是保证需求的覆盖度，那就要对需求进行详细的分析。
1.将SRS转化为UML图
2.使用RTM对需求进行跟踪
3.针对每个功能点，使用不同的用例设计方法，设计测试用例，达到需求覆盖率100%
4.分析软件的显示和隐示需求，再设计用例。
