黑盒测试如何保证需求的覆盖度？（08-02-22）（获奖名单已公布）
软件测试如何达到一定的覆盖度是个非常重要的问题，它是我们测试分析和测试设计工作的基础和出发点。在白盒测试中，我们可以用逻辑覆盖（语句覆盖、分支覆盖、条件覆盖、路径覆盖）等来指导我们的测试分析和设计，并用来评价我们测试工作的充分性，但在黑盒测试中，我们所追求的是需求要达到一定的覆盖度，那么如何衡量需求被覆盖的程度呢？又如何保证去达到一定的需求覆盖呢？请结合您的思考和实践，畅所欲言，希望各种观点在碰撞中产生火花。非常感谢各位会员积极参与，截止至２月２９日１７：３０分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励，此外，其他所有参与讨论的会员也将获赠积分２０。礼品和积分将在下周内送出。
获奖名单奖项获奖名单奖励答案链接一等奖shenlake当当购物卡50元99#二等奖huior300论坛积分61# huang-xl 30#三等奖1qazse4100论坛积分 26# fengjingqiong 66# jack8032 92# 版主能不能先谈一谈自己高见啊!! 楼上的同学，还是你来谈谈吧！
黑盒测试及其覆盖率
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试，要想尽可能的覆盖所有测试，就要根据以上测试方法，详细地列出测试用例，细分功能点，提高测试覆盖率。 用例密度不就是衡量测试充分性的一个重要指标吗?? 我觉得保证需求的覆盖度前提是对需求或是说程序的功能了解透彻，然后要确定什么是常规情况，什么是极限情况，什么是非法情况；划分这些以后就是编写详尽的测试用例（但是这里又出现了疑问，什么才算是详尽的测试用例，不可能把所有情况都列举出来，这就需要根据测试员本身的经验，也可以向程序员讨教一下，哪些情况属于同种类型，哪些地方需要测试所有可能的情况），然后进行测试，把这几点做的越好就越可能提高黑盒测试时需求覆盖度。
呵呵，个人拙见，希望看到更多大侠的意见看法 对于项目而言，tpm或者tc设计规格 需求分解 测试方案...测试用例，测试执行
(功能，性能，压力，可靠性)这些都是根据实际用户应用场景设计得
每个公司都是一套根据公司实际情况得流程，关键是每个步骤都要有人跟踪，每个过程都需要评审（内部和同行），争对评审记录做相应修改 ....想说得挺多，但发现懒得打字了:lol 我觉得黑盒测试很难达到覆盖所有测试的需求，在某些场合存在一定的局限性和不足。目前大多数还是通过用例的密度和回归的次数来衡量吧，听听其他人高见
个人意见_仅功能覆盖
黑盒测试包括功能测试和性能测试,这里我只发表关于功能覆盖率的个人见解,不对之处请大家指正.功能测试的覆盖率在我认为就是测试用例功能点的覆盖率.首先,就要做好需求管理工作.将系统的功能按照子系统、模块、功能点的划分进行详细统计。以便于针对需求的变更作出记录。同时，结合测试用例，保证用例包括到最小功能点。需求如果发生变更，及时对用例库进行维护。其次，要保证测试用例的有效性，针对功能点的测试范围要尽可能的全面，但决不是穷举测试。
通过这两点，应该能够满足对功能测试的覆盖率的保障。 需求的覆盖程度其实完全可以转化为测试用例的覆盖率来考虑，测试用例的覆盖率现在有些公司也在做，不过成效不是很大，一般可分为几种做法：
1、借助于工具：但目前似乎还没有一种比较适合的工具来分析
2、使用一些特殊的图标来分析：比如需求矩阵等
3、人为控制
要进行测试用例覆盖率的统计，个人认为需考虑以下两点：
1、如何才能做到很好的量化
2、目前我们的实际情况是否有必要做此量化
当然测试用例的覆盖率，目前我也没有一个好的方法，期待楼下的精彩:handshake 首先要认真分析软件需求，将需求点详细整理，设计对应的测试用例，保证用例覆盖到每个功能点。还要分析软件各个部分间的关系，设计应用于模块间的测试用例。
再者，要做好用例的评审。评审时细化到每个用例与需求间的关系，必竟多几个人会有不同的思路和想法，可以在已有用例的基础做进一步的审查和补充，更好的保证需求的覆盖度。 黑盒测试的需求覆盖度，很难保证100%的覆盖，只能做到尽可能多的覆盖，我觉得首先应该是对这个系统的功能根据需求完整的了解，不能说全部背下来，也要大致的熟悉，还有就是要对业务上的知识进行了解，如果对业务根本完全一无所知，那可想而知很难写出好的测试用例，也就谈不上需求的覆盖度了，同时看到楼上说的那些测试方法虽然很好，不能只追求与表面，更应在深层次的去剖析，找到问题的根本所在，这样长期的积累，对与需求的覆盖度也是很有帮助的，而且我觉得需求的覆盖度的意义很广泛，不仅应该包括功能上的，还要包括例如用户界面上的美观性，直观性，功能上的易用性等等，因为现在的用户在这些方面的要求程度也在逐步的加大，总之要想保证需求的覆盖程度，不是一朝一夕的事情，而是需要在平时不断的去积累，团队成员的互相配合，毛主席说的理论要和实际相结合啊，这样黑盒测试的需求覆盖度才能有保证，要从量变到质变，否则的话就是纸上谈兵了，这个只是我的个人见解，有不妥之处还希望多多帮助啊。:lol :handshake 受益匪浅. 先根据需求测试人员编写详细测试用例，针对写出的测试用例进行评审，评审需要开发人员参与，针对模块化的测试用例进行讨论，权衡测试用例的可执行性以及测试用例的一些盲点。
测试完之后进行总结也是很必要的，可补充编写测试用例时未考虑到的地方。:) 没有绝对完整的测试，只有逐步完善~:handshake 发表一下我的个人观点
我觉得黑盒测试要更全面的覆盖需求应该做好以下几点：
1.首先要很好的熟悉和理解需求，只有理解了需求才能写好用例
2.要对业务知识很清楚，清楚业务知识才能把用例设计的更全面更准确
3.用例设计要考虑全面，要涉及到用户基本需求还要考虑必要的伪需求，界面的美观统一、提示信息的友好、操作的方便性等等都要考虑到
4.测试方法要合理、覆盖面要广，等价类划分、边界值、因果图等等
经验丰富了碰到的情况多了也就考虑问题全面了，所以经验也很重要
只是个人的一些理解，期待高人指点:handshake 执行测试是更好的理解需求的一个过程.不断的测试,需求会被不断的挖掘不断的深入.我们所提到的覆盖度可能要从经度和纬度两个方面考虑.我想,即使百分百覆盖了需求文档,也不能百分百覆盖需求.
一,需求一直都在变
二,真正的需求需要不断的理解,挖掘才能被无限接近.但不可能完全达成最原始的需求
三.需求的提炼过程可能存住一些不真实需求,及需求的缺失.
.....
以上种种要求我们,测试时多熟悉业务,多方面了解产品.真正站在使用者角度理解需求.
本公司测试工作经验
首先根据需求分析和概要设计、详细设计、数据库设计等文档，编写测试计划和测试用例。测试执行：
1、功能测试。
所有功能的实现，应用相关测试方法：等价类划分、边值分析、因—果图、错误推测等；
数据库检查；
关联性测试；
页面测试；
用户体验。
2、性能测试。
3、安装测试。
4、验收测试。
[ 本帖最后由 特别关注 于 2008-2-22 20:28 编辑 ]
黑盒测试
系统测试是黑盒测试的范畴，黑盒测试也叫功能测试，不需要了解代码内部的逻辑，只是实现外在功能实现，需要构造输入一些操作而得出预期的输出。如何去度量它？A、依据SRS得出一个需求列表；
B、对SRS进行学习和分析——用UML画出用例图跟活动图；
C、针对每一项需求考虑他所包含的隐式需求有那些？这需要对行业知识的了解和一定的工作经验；
D、依据需求构造用例；
E、依据测试用例执行用例。
这是我新手组织的一点东西，献丑了。 1.需求者讲解需求
2.测试人员、开发人员分析文档，共同探讨需求的实现，向需求者提出问题，并由需求者作出详细解释，尽量作到对需求了如指掌
3.测试人员根据讨论内容编写需求文档的测试分析(功能点、风险点、测试难点、可能造成对其他功能的影响等),并与程序及其他测试人员探讨可以改进的部分加以改进
4.测试人员根据上一阶段编写的测试分析写出测试用例,并且由需求者,测试人员,程序等功能相关人员共同进行评审,并进行适当修改
5.严格执行测试用例,并在测试过程中及时与程序及需求者交流测试过程中发现的疑难点.如发现用例不足及时进行增删修改
6.建立完备的错误收集机制，然后使用通过全部用例后的稳定版本（或含有极少量不足的稳定版本）在内部进行大规模试用(monkey)。
