51Testing软件测试论坛

标题: 黑盒测试如何保证需求的覆盖度？（08-02-22）（获奖名单已公布） [打印本页]
作者: 51testing    时间: 2008-2-22 13:47
标题: 黑盒测试如何保证需求的覆盖度？（08-02-22）（获奖名单已公布）
软件测试如何达到一定的覆盖度是个非常重要的问题，它是我们测试分析和测试设计工作的基础和出发点。在白盒测试中，我们可以用逻辑覆盖（语句覆盖、分支覆盖、条件覆盖、路径覆盖）等来指导我们的测试分析和设计，并用来评价我们测试工作的充分性，但在黑盒测试中，我们所追求的是需求要达到一定的覆盖度，那么如何衡量需求被覆盖的程度呢？又如何保证去达到一定的需求覆盖呢？请结合您的思考和实践，畅所欲言，希望各种观点在碰撞中产生火花。

       非常感谢各位会员积极参与，截止至２月２９日１７：３０分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励，此外，其他所有参与讨论的会员也将获赠积分２０。礼品和积分将在下周内送出。

　　　　　　　　　　　　　　  
获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
shenlake
当当购物卡50元
二等奖
huior
300论坛积分
huang-xl
三等奖
1qazse4
100论坛积分
fengjingqiong
jack8032
作者: red-hat    时间: 2008-2-22 14:16
版主能不能先谈一谈自己高见啊!!
作者: bobli    时间: 2008-2-22 15:58
楼上的同学，还是你来谈谈吧！
作者: dong_gd    时间: 2008-2-22 16:49
标题: 黑盒测试及其覆盖率
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试，要想尽可能的覆盖所有测试，就要根据以上测试方法，详细地列出测试用例，细分功能点，提高测试覆盖率。
作者: red-hat    时间: 2008-2-22 17:01
用例密度不就是衡量测试充分性的一个重要指标吗??
作者: wait921    时间: 2008-2-22 17:31
我觉得保证需求的覆盖度前提是对需求或是说程序的功能了解透彻，然后要确定什么是常规情况，什么是极限情况，什么是非法情况；
划分这些以后就是编写详尽的测试用例（但是这里又出现了疑问，什么才算是详尽的测试用例，不可能把所有情况都列举出来，这就需要根据测试员本身的经验，也可以向程序员讨教一下，哪些情况属于同种类型，哪些地方需要测试所有可能的情况），然后进行测试，把这几点做的越好就越可能提高黑盒测试时需求覆盖度。

呵呵，个人拙见，希望看到更多大侠的意见看法
作者: bigstone81    时间: 2008-2-22 17:39
对于项目而言，tpm或者tc  设计规格 需求分解 测试方案...测试用例，测试执行
(功能，性能，压力，可靠性)这些都是根据实际用户应用场景设计得
每个公司都是一套根据公司实际情况得流程，关键是每个步骤都要有人跟踪，每个过程都需要评审（内部和同行），争对评审记录做相应修改 ....想说得挺多，但发现懒得打字了
作者: iori    时间: 2008-2-22 17:40
我觉得黑盒测试很难达到覆盖所有测试的需求，在某些场合存在一定的局限性和不足。目前大多数还是通过用例的密度和回归的次数来衡量吧，听听其他人高见
作者: 清风随雨    时间: 2008-2-22 17:41
标题: 个人意见_仅功能覆盖
黑盒测试包括功能测试和性能测试,这里我只发表关于功能覆盖率的个人见解,不对之处请大家指正.
        功能测试的覆盖率在我认为就是测试用例功能点的覆盖率.首先,就要做好需求管理工作.将系统的功能按照子系统、模块、功能点的划分进行详细统计。以便于针对需求的变更作出记录。同时，结合测试用例，保证用例包括到最小功能点。需求如果发生变更，及时对用例库进行维护。其次，要保证测试用例的有效性，针对功能点的测试范围要尽可能的全面，但决不是穷举测试。
    通过这两点，应该能够满足对功能测试的覆盖率的保障。
作者: Johnny521    时间: 2008-2-22 18:08
需求的覆盖程度其实完全可以转化为测试用例的覆盖率来考虑，测试用例的覆盖率现在有些公司也在做，不过成效不是很大，一般可分为几种做法：
1、借助于工具：但目前似乎还没有一种比较适合的工具来分析
2、使用一些特殊的图标来分析：比如需求矩阵等
3、人为控制
要进行测试用例覆盖率的统计，个人认为需考虑以下两点：
1、如何才能做到很好的量化
2、目前我们的实际情况是否有必要做此量化
当然测试用例的覆盖率，目前我也没有一个好的方法，期待楼下的精彩
作者: lzlsunfire    时间: 2008-2-22 18:17
首先要认真分析软件需求，将需求点详细整理，设计对应的测试用例，保证用例覆盖到每个功能点。还要分析软件各个部分间的关系，设计应用于模块间的测试用例。
再者，要做好用例的评审。评审时细化到每个用例与需求间的关系，必竟多几个人会有不同的思路和想法，可以在已有用例的基础做进一步的审查和补充，更好的保证需求的覆盖度。
作者: sunqiang1024    时间: 2008-2-22 18:33
黑盒测试的需求覆盖度，很难保证100%的覆盖，只能做到尽可能多的覆盖，我觉得首先应该是对这个系统的功能根据需求完整的了解，不能说全部背下来，也要大致的熟悉，还有就是要对业务上的知识进行了解，如果对业务根本完全一无所知，那可想而知很难写出好的测试用例，也就谈不上需求的覆盖度了，同时看到楼上说的那些测试方法虽然很好，不能只追求与表面，更应在深层次的去剖析，找到问题的根本所在，这样长期的积累，对与需求的覆盖度也是很有帮助的，而且我觉得需求的覆盖度的意义很广泛，不仅应该包括功能上的，还要包括例如用户界面上的美观性，直观性，功能上的易用性等等，因为现在的用户在这些方面的要求程度也在逐步的加大，总之要想保证需求的覆盖程度，不是一朝一夕的事情，而是需要在平时不断的去积累，团队成员的互相配合，毛主席说的理论要和实际相结合啊，这样黑盒测试的需求覆盖度才能有保证，要从量变到质变，否则的话就是纸上谈兵了，这个只是我的个人见解，有不妥之处还希望多多帮助啊。
作者: xiao小尾巴    时间: 2008-2-22 18:35
受益匪浅.
作者: yhfeifei    时间: 2008-2-22 18:43
先根据需求测试人员编写详细测试用例，针对写出的测试用例进行评审，评审需要开发人员参与，针对模块化的测试用例进行讨论，权衡测试用例的可执行性以及测试用例的一些盲点。

测试完之后进行总结也是很必要的，可补充编写测试用例时未考虑到的地方。
作者: yhfeifei    时间: 2008-2-22 18:44
没有绝对完整的测试，只有逐步完善~
作者: 水上飘    时间: 2008-2-22 18:56
发表一下我的个人观点
我觉得黑盒测试要更全面的覆盖需求应该做好以下几点：
1.首先要很好的熟悉和理解需求，只有理解了需求才能写好用例
2.要对业务知识很清楚，清楚业务知识才能把用例设计的更全面更准确
3.用例设计要考虑全面，要涉及到用户基本需求还要考虑必要的伪需求，界面的美观统一、提示信息的友好、操作的方便性等等都要考虑到
4.测试方法要合理、覆盖面要广，等价类划分、边界值、因果图等等
经验丰富了碰到的情况多了也就考虑问题全面了，所以经验也很重要
只是个人的一些理解，期待高人指点
作者: xiao小尾巴    时间: 2008-2-22 18:58
执行测试是更好的理解需求的一个过程.不断的测试,需求会被不断的挖掘不断的深入.我们所提到的覆盖度可能要从经度和纬度两个方面考虑.我想,即使百分百覆盖了需求文档,也不能百分百覆盖需求.
一,需求一直都在变
二,真正的需求需要不断的理解,挖掘才能被无限接近.但不可能完全达成最原始的需求
三.需求的提炼过程可能存住一些不真实需求,及需求的缺失.
.....
以上种种要求我们,测试时多熟悉业务,多方面了解产品.真正站在使用者角度理解需求.
作者: 特别关注    时间: 2008-2-22 20:27
标题: 本公司测试工作经验
首先根据需求分析和概要设计、详细设计、数据库设计等文档，编写测试计划和测试用例。
测试执行：
1、功能测试。
     所有功能的实现，应用相关测试方法：等价类划分、边值分析、因—果图、错误推测等；
     数据库检查；
     关联性测试；
     页面测试；
     用户体验。
2、性能测试。
3、安装测试。
4、验收测试。

[ 本帖最后由 特别关注 于 2008-2-22 20:28 编辑 ]
作者: zhangjinyan    时间: 2008-2-23 00:13
标题: 黑盒测试
系统测试是黑盒测试的范畴，黑盒测试也叫功能测试，不需要了解代码内部的逻辑，只是实现外在功能实现，需要构造输入一些操作而得出预期的输出。如何去度量它？
A、依据SRS得出一个需求列表；
B、对SRS进行学习和分析——用UML画出用例图跟活动图；
C、针对每一项需求考虑他所包含的隐式需求有那些？这需要对行业知识的了解和一定的工作经验；
D、依据需求构造用例；
E、依据测试用例执行用例。
这是我新手组织的一点东西，献丑了。
作者: retifax_test    时间: 2008-2-23 00:19
1.需求者讲解需求
2.测试人员、开发人员分析文档，共同探讨需求的实现，向需求者提出问题，并由需求者作出详细解释，尽量作到对需求了如指掌
3.测试人员根据讨论内容编写需求文档的测试分析(功能点、风险点、测试难点、可能造成对其他功能的影响等),并与程序及其他测试人员探讨可以改进的部分加以改进
4.测试人员根据上一阶段编写的测试分析写出测试用例,并且由需求者,测试人员,程序等功能相关人员共同进行评审,并进行适当修改
5.严格执行测试用例,并在测试过程中及时与程序及需求者交流测试过程中发现的疑难点.如发现用例不足及时进行增删修改
6.建立完备的错误收集机制，然后使用通过全部用例后的稳定版本（或含有极少量不足的稳定版本）在内部进行大规模试用(monkey)。
作者: hukx    时间: 2008-2-23 00:34
标题: 黑盒测试如何保证需求的覆盖度？（08-02-22）
通过最近工作我体会测试覆盖度是取决客户对软件的要求，客户专注是什么方面，有些小错误是客户就这样想还是我们自己想象出来得结果，现在大多数软件都不是完全按照软件流程在走，很多时候需求分析是在不同时期，软件需求是不同，所以对于软件质量要求不同。
好像谈走题咯，好，现在回答主题。
我觉得为了保证黑盒测试覆盖率，首先得分析下软件，可以我们要分那几个模块来编写test case，或测试点，分析好测试点后，我们开始写个List, 看下我们还有什么遗漏的，这个可以是设计test case得阶段，看这个点是等级来分析这个地方test case数量，内部覆盖方法可以参考等价划分，边界值等方法，我觉得我们还是要多想些异常的操作方法，异常得方法就可以找到很多遗漏，在不断多模块了解，我们对很多不同操作都可以做些尝试，这里面就隐藏问题。
作者: dazhijn_China    时间: 2008-2-23 12:38
标题: 黑盒测试如何保证需求的覆盖度？（08-02-22）
看到楼上诸位朋友各抒己见，自己也按耐不住啦！说一下自己在工作中对本期问题的一点愚见。
首先，要对需求理解全面、准确，以便找出测试点，包括明确的和隐含的，功能方面的、非功能方面的，还有业务流程方面的；非功能方面又分安全、界面、性能等；
其次，与最终用户、需求分析人员、设计人员及开发人员的交流沟通，便于解决测试需求分析中遇到的疑问，形成全面的测试需求分析，明确我们的工作内容；
第三，采用一些教材或资料文档中提到的黑盒测试常用的测试方法，如边界值法、等价类、因果图等，设计出正常及非正常两类测试用例，重点是非正常的测试用例，同时考虑非功能性方面的验证用例；
第四，再次结合需求文档对用例的集中评审，确保个别工程师工作的疏漏及误解。

差不多就这么多吧，具体项目具体分析，在实践中不断更新、积累才是硬道理。
作者: 瘦黄花    时间: 2008-2-23 15:50
标题: 黑盒测试如何保证需求的覆盖度？（08-02-22）
也来谈谈我的愚见。
    黑盒测试最重要的就是功能测试了。被测试的产品能不能满足客户要求得业务功能是最要关注的。所以，业务知识的学习就显得特别重要。吃透业务，了解用户需求，是我们达到高测试覆盖度的基础。

1）.一拿到测试任务，就要全面的去了解此产品/功能相关的业务背景，学习业务知识，知道用户为什么要提出这样的需求？是为了解决什么问题。可以找有相对业务背景、对业务比较熟悉的人进行讲解培训。
2）.分析开发人员编写的需求规格说明书，了解系统是如何实现业务的。并用我们已经掌握的业务知识，批判的看说明书，与开发设计人员对说明书一起进行讨论。
3）.初步了解需求后，大概得看一下产品/功能（不测试，只是大概的了解一下系统界面、业务如何流转。因为需求规格说明书往往和系统实现是有一点差距的。）。然后结合需求说明书开始设计测试用例。
4）.功能测试用例设计完后，与开发工程师、需求分析师进行三方评审。这很重要，通过评审，你能让别人了解你的测试思路，别人也能提出你用例中疏漏的业务情况或一些业务逻辑。因为每个人对业务的了解程度不一样，看问题的角度也不一样。测试工程师根据评审结果，再去修改测试用例，然后发送参与评审的所有人再次审核，都认可后。测试用例编写暂告一段落。
5）.除功能测试用例外，还要设计业务测试用例，即该产品所服务的行业、具体的业务情况。功能测试用例是针对系统的，业务测试用例是针对业务的。系统是为业务服务的，只要满足了基本的业务需要，才是一个可用的系统。所以需要模拟正式的业务情况，对整个产品进行测试。可以找需求分析人员，或专门的业内人士协助。
6）.在测试过程中，有时候会发现需求规格说明书与系统实现不一致的情况，需要向开发工程师、需求分析师确认，如有必要，可以要求他们向用户确认。根据反馈结果来及时修改我们的测试用例或系统实现方式。

全覆盖是不大可能的，只能通过我们的努力去提高测试覆盖率。欢迎大家各抒己见，共同借鉴。
作者: minjuwen    时间: 2008-2-23 19:36
个人认为要保证需求的覆盖度必须要深入理解需求
作者: 1qazse4    时间: 2008-2-23 21:27
看了上面高手的分析,真是受益匪浅啊~！~
      我也同意首先要透彻理解需求文档，把不明白的地方与开发人员、设计人员沟通。
理解完需求后，我们就得开始写测试需求了，在测试需求了，我们将对软件或项目进行庖丁解牛的手法，将其功能模块细分出来，然后将模块中的功能点分解出来，我们得保证最后的功能点为最小分子，不能再进行下一步分解拉。（当然我们可以借助一些测试需求编写工具拉）测试需求细分出来后，剩下的就是编写测试用例了。每个最小分子需求对应写一个测试用例，用例中要将能想到的方法步骤全部写出来，大家开会讨论，不漏掉。执行“不抛弃任何一个方法、不放弃任何一个idea”。至于相关联的功能模块之间，我们也得考虑设计测试用例。（这些只针对黑盒测试的功能测试）

个人见解，大家一起讨论学习！！
作者: 不要长大的小孩    时间: 2008-2-23 22:47
紧跟需求分析！
作者: zyawoo    时间: 2008-2-24 05:36
仅代表个人观点：
在一个平面中，把用户的需求看成一个个零散的点。而需求覆盖度，就是包围了部分点的一个个的圈。需求覆盖度不可能100%，即没有一个圈能包围所有的点。
当需求分析人员把这个圈画好之后，我们一直在完善圈内的点，而忽视了圈外的点。用户一开始跟我们说要一个杯子，下次又说要一个带耳朵的杯子，再下次呢？要加盖的。
因此保证测试中需求的覆盖度，可以先从一个很小的圈开始，然后不断地扩大这个圈。除了要清楚通过的和未通过的功能，还要留意将会实现的和不可能实现的功能。
作者: sky.pei    时间: 2008-2-24 12:47
需求的测试，其实大部分都是业务的测试。常规的业务流程都是固定单一的。这个问题其实就转化成了业务流程的不规范情况的测试。
这种测试时不可能穷举的。
作者: huang-xl    时间: 2008-2-24 13:06
目前测试对需求的覆盖程度已经作为判断测试质量的一个标准,但不同的测试类型和需求类型如何判断测试的
覆盖程度?
1、一般来说,非功能性测试的覆盖程度比较好判断,如性能和压力测试,可根据需求中明确的性能指标进行测试
分析和设计，另外也可通过分析系统在生产中实际使用情况，来分析一些隐含的需求，如系统是否需要连续运
行、系统故障后恢复的级别、并发访问的程度等。
2、功能性测试的覆盖程度是比较难判断的，用例数不能完全说明对需求的覆盖，因为用例数和测试点的力度
划分相关，测试点划分的越细，用例数量越大，但不能说明覆盖程度高。
我们的做法一般是先根据用户需求确定测试优先级，重点需求测试点划分的比较详细，测试用例要覆盖所有的情况，如正常值、边界值、特殊值等；一般性需求测试用例覆盖所有的正常等价类；
测试用例设计上划分为单功能测试用例和测试场景设计，单功能测试覆盖的需求中的功能点，测试场景覆盖需求中的业务逻辑；
另外测试设计全面与否，很大程度取决于需求的质量，取决用户是否真正明白自己想让系统做什么。
作者: ximen120    时间: 2008-2-24 14:42
我觉得。不论怎么样，都要以规格需求说明书为准，可以用其他的测试方法，我觉得只要符合规格需求说明书的要求就可以了。
作者: 王爬爬    时间: 2008-2-24 16:14
1.需求覆盖可以根据软件质量模型的六大特性及其26个子特性来进行
2.具体子特性的覆盖可以结合一些软件测试用例分析方法，例如等价类啊，边界值啊。。等等
作者: bzfyhfyh    时间: 2008-2-24 20:37
标题: 黑盒测试如何保证需求的覆盖度？（08-02-22）
黑盒测试的覆盖率是不可能达到100%的，只能做到逐步完善。
根据软件需求分析和软件测试计划里的要求，采用边界值，等价类，因果法，大纲法等去设计用例，尽可能的做到覆盖，可以让测试用例有适当的冗余。
作者: liangch    时间: 2008-2-25 10:04
黑盒测试首先应该深入透彻地了解客户的需求，因为不可能穷举所有功能点的测试用例，这样既耗费工作量也不能体现客户所关注的重点。所以个人觉得，在情况允许的条件下尽可能多地覆盖客户所更关注的需求：
1、应该结合需求文档，认真分析需求重点，进行用例的设计。
2、对于基本的或通用的功能测试，可以设计公共的测试用例，保证用例设计的质量和效率。
3、对于业务复杂的测试对象，应先绘制流程，保证流程分支的全面覆盖。
另外，还可以通过对用例的评审，检查是否有需要关注而没有设计到用例中的功能点，以补充用例。

[ 本帖最后由 liangch 于 2008-2-25 10:08 编辑 ]
作者: loho1968    时间: 2008-2-25 10:22
1、首先，要有需要测试的“需求”数据，也就是说，黑盒测试的对象。比如，在QC中的测试需求树
2、其次，要有黑盒测试与这些“需求”的关系，也就是黑盒测试用例与“需求”的对应关系。比如，QC中的测试计划对测试需求的覆盖
理论上就这么简单，但实际操作中，“需求”如何划分粒度是一个难点，以“功能”为单位，可能太粗，也可能就够了，以“功能点”为单位，可能又太细。
作者: dulong    时间: 2008-2-25 11:12
个人认为：在测试模块功能时，要先满足功能点的测试。这个过程一般在单元测试实现。而实际上在中小型的公司中不存在单元测试这个阶段，直接开始就是集成测试。
因此，我当时多做了一个过程，必须针对划分为最细小的功能进行测试。这里有个简单的地方，因为最细小的功能就是：添加、删除、修改、查询等。
添加/修改/查询，页面元素会比较多，使用正交法是个不错的选择
删除也简单，一般实现记录删除：单条删除、多条删除、全部删除等。
实现了最细小的功能一轮后，进行集成测试，相对就简单多了~~
作者: jtiger    时间: 2008-2-25 11:26
同意楼上不少人的看法，首先熟透需求，再进行用例设计。对于黑盒，要做到尽可能大的覆盖率，也只能在对需求的熟悉之下，凭借多和开发沟通和个人的经验累积了。所以，对不同的测试对象，对症下药，才能提高覆盖率。
作者: bht2000    时间: 2008-2-25 12:00
看了楼上各位所谈的,都很有道理,在此本人给出几个测试开发过程度量的公式,无论对白盒和黑盒都有用:
1.缺陷检测有效性百分比(DDE):
DDE=(TDFT/(TDFC+TDFT)×100%
其中:TDFT=测试过程中发现的全部缺陷(即由测试组发现的)
    TDFC=客户发现的全部缺陷(在版本交付后一个标准点开始测量,如,半年以后)
2.缺陷排除有效性百分比(DRE)

DRE=(TDCT/TDFT)×100%
其中:TDCT=测试中改正的全部缺陷
     TDFT=测试过程中发现的全部缺陷
3.测试用例设计效率百分比(TDE)
TDE=(TDFT/NTC)×100%
其中:TDFT=测试过程中发现的全部缺陷
     NTC=运行的测试用例数
作者: pokka    时间: 2008-2-25 14:30
首先应该充分了解需求，整理好需求文档。
然后以此为基础，分析需求，整理出各个功能点，编写各个功能点的测试用例，尽量能写全各个功能点的测试用例。
最后再根据测试用例进行测试。但在实际工作中可能来不及写测试用例，或者只写了某些主要功能点的测试用例，这就需要在测试时也结合需求文档，从黑盒测试方法中选择相应的方法，根据对业务功能分析选择测试数据来进行测试，保证需求文档中涉及的功能都能够在程序中执行一遍。
作者: zhangtao    时间: 2008-2-25 14:33
缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出哪部分功能/需求缺陷最多，从而在今后开发注意避免并注意实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。

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

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

[ 本帖最后由 zhangtao 于 2008-2-25 14:42 编辑 ]
作者: happyya    时间: 2008-2-25 14:52
从软件开发的V型模型讲，黑盒测试，对应的应该是Functional Specification，所以黑盒测试应该起于Func Spec，终于Func Spec。以该文档作为衡量测试覆盖率的标准。这是我先前的看法。不过楼上的xdjm们提到各系统之间的联系，虽然Func Spec中不一定涉及到，但我觉得也应该纳入测试范围。但这样就不要定量的分析测试覆盖率了。
作者: christixo    时间: 2008-2-25 16:01
首先，是对需求的理解和掌握，我认为版主的这个问题根本只是理论上的，在实际中不可能用到，就算能用也不是 100%的覆盖。
其次，一切都从自身利益出发，只满足客户的需求就可以，当然客户也可能有的需求没有说到，但是这都是可以作为和客户谈价钱的筹码。
再次，不可能把软件做的那么完美，至于覆盖程度只是理论上的，满足用户需求即可，多做也只是浪费时间和精力。
最后，理论上讨论就是本身对需求的理解程度，把握需求的尺度，来走黑盒的覆盖，举个例子：
         需求： 拿用户登陆来说，客户需求说的是能让用户正常登陆到该系统进行操作。
         覆盖：我们可以先正常的理解，
           、UI
   1>UI设计要美观，颜色搭配要适当
   2>按钮的颜色状态，有时候有些按钮在不满足其触发状态的时候，要设计成灰色，也就是不可选状态
2、功能需求
   1>主要考虑输入框内数据的限制，比如数字、字符、符号、一些组合输入、长度限制（如果没有长度限制的话，输入n多数据容易引起程序异常退出）
   2>正确的、人性化的提示
3、性能需求
   主要考虑性能方面的需求，比如n个人同时输入，同时提交，会不会引起异常
4、异常中断
   可以考虑一些断网、断电的情况
5、快捷键
   比如是否支持复制、粘贴、剪贴等快捷键

     就可以了，如果还想覆盖的全面些我想都没有什么必要，等客户提出的时候再作讨论。
比如：
1、用多种浏览器测试，当用到TT之类的浏览器，当第一次用输入错误用户名和密码，不登陆，强制关闭电脑，再次开机，点击TT浏览器后，点击恢复之前的网页，此时，之前的登录名和密码还在麽？
2、用多种浏览器测试，当用到TT之类的浏览器，当第一次用输入错误用户名和密码，登陆（不管是否有提示），强制关闭电脑，再次开机，点击TT浏览器后，点击恢复之前的网页，此时，之前的登录名和密码还在麽？
作者: duanmei    时间: 2008-2-25 16:02
标题: 黑盒测试如何保证需求的覆盖度
黑盒测试是不需要考虑内部结构，主要对外部功能点进行测试，数据驱动。
所以第一必须了解需求，对需求进行分析，找出所以数据信息进行分类统计（有效数据和无效数据）。
对统计数据采用边界值，等价类划分，异常数据，因果图法进行用例设计，而且对测试用例进行维护。
说的不好，请高手指点！
作者: lytesting    时间: 2008-2-25 16:25
我认为测试用例应该是能保证覆盖率的方法之一.
作者: xiao*    时间: 2008-2-25 16:50
标题: 个人观点
关于这个问题应该有两个假设：１，需求写的足够明确清晰；２测试管理人员经验丰富
a,分析需求并请相关人员做详细讲解
ｂ．根据需求写出经过评审的用例
ｂ．根据经验，可以采取交加测试；
ｃ．根据需求的隐含信息增加测试用例，比如多操作系统、多数据库、不同分辨率等。
作者: 生活总会更美的    时间: 2008-2-25 16:50
标题: 我的想法
我觉得黑盒测试和功能测试不是一个范畴的东西，个人认为黑盒测试是一种测试方法，而功能测试通常采用了这种方法，功能测试也可以采用白盒的方法。
  就我们公司而言，我们会采用黑盒测试的方法去检查软件的几大质量特性，如：功能度、易用性、可靠性、兼容性等。
  对于黑盒测试保证需求覆盖度的问题，我同意大家前面的观点，首先是深度了解需求，这样才能提高需求覆盖度。我觉得可以从两个方面去设计案例，一是按照软件系统界面的功能，利用黑盒测试的方法。二是按照业务流程，设计测试案例。
  以上只是我个人的一些想法，
作者: zhengyu99    时间: 2008-2-25 17:30
标题: 关于黑盒测试如何保证需求的覆盖度
我来总结一句话吧，就是用尽可能少的测试用例覆盖尽可能多的功能点。
作者: hehekouke    时间: 2008-2-25 18:20
我也说说吧，说的不好，请多多指教。
首先最重要的是吃透需求，然后结合各种测试用例的设计方法来编写测试用例。
在进行黑盒测试的时候我们一个是根据测试用例来进行测试，
另外一个就是发挥自己对业务逻辑的熟悉，来进行一些测试，这时候我们也需要及时更新我们的测试用例。
这样可以是测试用例不断进行完善。

大致就这样吧，大家多指教哈
作者: testxxh    时间: 2008-2-25 21:41
标题: 了解需求是关键
对于黑盒测试（功能测试），首先是要了解需求；能够对需求分析透彻，才能知道什么是正确，什么是错误；什么样的系统响应更能满足用户的需求；符合用户的操作习惯；适应用户的业务操作流程，也才能正确的设计测试用例，对于测试用例的覆盖性，要能达到100％是不可能的；只能说随着对功能的了解，及其测试经验的积累，能够在测试用例的设计方面更加详实，符合实际需求。
作者: springy    时间: 2008-2-26 03:49
最主要的是做到测试用例先行,做好测试数据的划分!
作者: jane3910    时间: 2008-2-26 10:28
标题: 请高手指点了。
以前只有白盒才有覆盖率的指标，但看了有些书上也提到过黑盒测试覆盖率。说的是测试覆盖软件需求，我想不通该如何去衡量这个指标，不知各位前辈有何高见？实际测试中结束测试的条件是测试覆盖率么？
我自己认为应该是首先根据软件需求文档列出所有功能点，编写测试用例，测试实际实现的功能点。测试覆盖率=测试过的功能点数/需求文档所有功能点数。不知道是否正确。在实际自动化测试中如何动态显示？还是有很大量的手工工作做。

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

[ 本帖最后由 jane3910 于 2008-2-26 11:48 编辑 ]
作者: nancy929    时间: 2008-2-26 11:02
首先是对业务系统非常的熟悉，我们有没有发现，起初测试的时候，我们只是发现一些常规的问题，随着对系统理解的深入，我们渐渐地发现了一些很隐藏的问题。
  其次是采用多种测试用例设计方法，从多角度去分析、测试，保证测试的充分性。
作者: 森林一木    时间: 2008-2-26 11:43
如果有正规的需求，就从需求中导出测试用例，因为需求中有详细的需求用例，然后在根据系统的详细设计说明书进行补充，再根据自身的测试经验进行补充，如果没有正规的需求，就需要自己组织，这样就必须对被测对象进行彻底的分解熟悉，再结合自身的经验以及研发的文档进行测试用例的设计，然后通过测试组内的评审完善测试用例。
作者: 麦子华华    时间: 2008-2-26 11:53
其实最缺乏的测试用例是当前功能模块和其他相关功能模块（有些看似风马牛不相及的功能，其实还是有内在联系的）关联的部分，这需要对整个被测系统的全面熟悉和不断的经验积累，
甚至在评审中也可能发现不了的问题。

所以测试用例要在测试中不断完善。
作者: comfort8    时间: 2008-2-26 12:10
好，果然高手如云
作者: xiaoxiabob    时间: 2008-2-26 13:56
就我工作的经验而言，黑盒测试需要保证覆盖率一般需要考虑的有以下几点
1：所有功能点是否完全覆盖
2：一些可以提炼出来的模块比如注册登陆，网站的cookie等它所需要的一些约定俗成的检查点是否有完全的覆盖。
3：黑盒还是有逻辑可言的前台业务逻辑的覆盖也是很重要的组成部分
4：透过一些功能点去猜测背后的程序逻辑查找可能的隐含bug
作者: sense    时间: 2008-2-26 14:21
标题: 黑盒测试如何保证需求的覆盖度?
个人观点：
将需求分解为特性点，也可由产品经理列出产品的特性点，测试用例最基本的就是覆盖这些内容，再将测试方法、经验、项目特性、用户角度等加入测试要点中，再测试界面规范、可用性、业务流程等，最终进行交互测试和回归测试
作者: gfwo778    时间: 2008-2-26 15:10
学习 学习
作者: pangge369    时间: 2008-2-26 16:17
向大家学习了!呵呵,感谢楼上的各位的精彩说明!
作者: huior    时间: 2008-2-26 16:19
我的详细解答，请参考
http://www.51testing.com/?10851
作者: lotuis    时间: 2008-2-26 16:22
个人觉得这个题目有歧义，需求覆盖度自然是按照根据需求文档写出的测试文档来控制的，测试文档越贴近需求文档，自然需求的覆盖度就高。
如果换成黑盒测试如何保证代码覆盖率，这题才有深究的意义，否则只是一道标准的“明知故问”型问题。
作者: lucky5956    时间: 2008-2-26 16:32
标题: 黑盒测试
黑盒测试要全面的覆盖需求
1.首先熟悉业务，对业务逻辑的熟悉有助于对需求功能点的把握
2.结合程序仔细分析需求，提取测试的功能点和重点
3.根据需求编写测试用例，测试用例尽量覆盖所有功能点
4.在测试的过程中完善测试的覆盖度
5.开始测试要兼顾需求、用例和开发环节中易发生错误的地方
作者: adamwu    时间: 2008-2-26 16:33
标题: 黑盒测试方法
在对软件的质量监督中，黑盒测试起着重要的作用；而随着软件开发平台及软件设计思想的进步和发展，特别是rad技术的发展，对黑盒测试提出了更明确的要求，人们发现，必须遵循一定的测试理论，依赖于优秀的测试工具，才能进行科学、完备的测试。
作者: 252090366    时间: 2008-2-26 17:20
不知道大家在平时工作中是否整理过测试需求!

如前面某位仁兄所说,分功能与性能.通过功能来计算覆盖率还好一点,那么通过性能呢?希望高手指教!!!
作者: fengjingqiong    时间: 2008-2-26 17:39
标题: 黑盒测试覆盖度保证的一些观点
看了楼上这么多人的答复我受益匪浅，我也说说自己的意见。
我们一般拿到需求说明书并且测试目的严格已需求说明书为根据，即使需求变动了，那也是先变需求说明书我们这边才跟着变动测试用例等，当然这是理想状态，但我们不就是向着理想前进吗？我想回答这个问题的前提应该是需求已经确定了，所以我觉得关于需求的确定问题就不应该是在这里讨论。单单只是讨论黑盒测试（或者说黑盒测试用例）如何保证需求的覆盖度。
1、对需求的分析：保证覆盖度首先要保证对需求点提取的覆盖率。测试一切以需求为根本和中心指导，如果在开始覆盖度就不高，那么你后面做的再好也就那样了。
2、设计测试用例：对于分析提取的需求点编写对应的测试用例，而用例的编写必须要依据科学的方法才能有权威、公正性，尽量减少个人因素的影响，那么可以使用等价类、边界值、因果法、错误推测法等，但同时使用这些方法编写测试用例是又很大的依赖与测试人员自身的素质（性格、专业知识等），所以我们在尽最大的可能平稳（公正）做好自己本分的工作那么就可以很大一部分覆盖率了。
3、测试用例评审：但每个人都是不同的，思考方式、方向等都是不同的，你想到而我没想到的情况是非常多了（随着经验的增多会逐步减少），这样就遗漏了方面，覆盖率也就不够了，所以评审是必然的，它可以确定并补全测试用例。此后黑盒测试覆盖率的前期发展至高了。
4、执行测试：测试用例编写确定好了后就是测试执行了，1、测试用例执行100%覆盖。2、但测试用例覆盖率还是未达到100%，其中等价类、边界值、因果法这些有逻辑依据的方法是很好覆盖且一般不容易出错，但是错误推测法这类方法主观性很强且不好推测，所以也要根据实际情况来做一些调整、增加的测试行为，同时也要更新测试用例来提高用例下一次的测试覆盖率。
以上！
个人拙见！
作者: beiyu95    时间: 2008-2-26 18:03
实践经验：将每个用例和需求都编号，然后做一张对应的映射表。
作者: 水印无痕    时间: 2008-2-26 18:26
测试最难的是什么：是对需求的覆盖
通常情况下对于需求的完全覆盖测试是不可能实现的
所以这个问题需要从多个角度来分析
最重要是如何用最少的用例覆盖最多的需求
说白了就是用例设计的方法和原则
这个前面已经有不少朋友提到了：比如说设计用例时参照软件质量6大原则逐个验证；等价类边界值等等一些用例设计方法；……
但是还有其他一些因素会间接影响到这个问题
比如说测试规程的制定：如果测试规程不合理，可能会大幅导致效率的下降，从而没有足够的时间来执行已经设计完成的用例
另外像测试计划中对于风险估计的不足，对于资源分配的不合理等等，所有的一切都可能影响到最终的测试行为对需求的覆盖程度
作者: cyj917    时间: 2008-2-26 21:54
正确使用软件与非法使用软件,这两种情况都试一下,把能想到的使用软件的方法都试一下
作者: olancome    时间: 2008-2-26 22:08
刚进入测试方向，看了这么多，真是受益匪浅阿，我应该多来这看看，
作者: crazysusan    时间: 2008-2-26 22:56
黑盒测试虽然无法保证需求的覆盖度的全面性，但　　可以通过编写测试用例，可在不断增加和扩大需求的覆盖度，个人认为：在设计测试用例时，１、应尽力编写得详细点，２、在测试过程中，可以不断地去完善测试用例。


以上纯属个人见解。。。。。
作者: qiucong390    时间: 2008-2-26 23:14
这个问题我经常拿来考面试的（高级）测试工程师。
对于问题的回答每个人都有自己的见解：
1。理解URS/UIS/FRS等之类的需求说明书很重要，因为测试用例一般从需求输出，保证测试的覆盖度一般需要建立一个需求说明书和测试用例之间可追踪的矩阵表格，哪些需求点没有覆盖到，自动提醒或者标红表示，比如DOORS具有这个功能。
2。说到覆盖度，这里要谈到测试工程师的测试经验问题，测试工作执行力度问题，即使再多的测试用例也会如同虚设的测试。你们会问测试工程师跟需求的覆盖度有什么关系？理解测试流程工作的人员相信都会明白。
3。需求评审很重要，但不排除有些所谓的管理人员或专家平时都听人家的意见多的，自己心里压根就没有什么想法。一般建议评审在产品经理，项目经理，需求工程师，测试工程师，第三合作方等中进行，保证项目的里程碑的时间点前提下，尽可能安排几次需求评审。需求的完整和清晰度大大增加了测试的假想空间，特别是有些项目经常变更需求的。

回到这个问题暂时归结三个方面：需求和测试用例之间建立追踪的矩阵，有良好测试经验的测试工程师执行测试工作，保证需求的完整和清晰度。
作者: lgs0540    时间: 2008-2-27 14:16
原帖由 sky.pei 于 2008-2-24 12:47 发表
需求的测试，其实大部分都是业务的测试。常规的业务流程都是固定单一的。这个问题其实就转化成了业务流程的不规范情况的测试。
这种测试时不可能穷举的。

说的太对了,对业务有一定了解,所做的需求分析也能达到一定程度!
作者: zyx88888888    时间: 2008-2-27 14:41
根据各种测试方法尽量多写测试用例,测试用例越详细,覆盖率越搞
作者: xiaoxiabob    时间: 2008-2-27 14:44
需求的测试，其实大部分都是业务的测试。常规的业务流程都是固定单一的。这个问题其实就转化成了业务流程的不规范情况的测试。这种测试时不可能穷举的。

这个我也同意，但一些约定俗成的检查点还是必须验证到的，比如表单传递页面，对于刷新页面是否会产生的表单重复投递等等类似问题，也是我们用例必须覆盖到的。
作者: yinfu0000    时间: 2008-2-27 15:20
我认为软件是给客户的，所以考虑功能覆盖的话，应该从客户的角度考虑覆盖范围，即客户所能及的范围。再从这用户范围用各种测试方法可以缩小测试范围。之后用常用的比如18楼的那种应该能保证覆盖度了。
作者: 随意    时间: 2008-2-27 15:43
首先要根据需求编写出详细的测试计划包括测试用例，这其实就是遍历需求的一个过程，在这个过程中首先要了解客户的业务流程，然后按每个模块实现的业务功能来设计用例，在测试的过程中，先把握整体流程，然后到各个模块，最后细化到字段页面的层面
作者: hellen_ma    时间: 2008-2-27 16:40
看了好多回贴,忘了自己本来要说什么来着
作者: kangyu    时间: 2008-2-27 17:18
原帖由 xiaomayi0323 于 2008-2-22 21:38 发表
我认为要达到一定的覆盖度,首先应该将需求吃透,细分需求,才能保证设计出来的测试用例最全面的覆盖需求.


同意你的说法。但同时也补充一点，测试用例一定要通过评审，这样需求才能更明确，针对性的覆盖率更高
作者: gy21st    时间: 2008-2-27 17:22
这是一个开放性问题。没有什么标准答案。面试的时候很多人喜欢问这种问题。经验是最重要的因素。
作者: jilinzy    时间: 2008-2-27 17:59
关键是需求分析、做测试首先要理解需求，通过需求，针对每一个页面或者是模块写出测试用例、然后是同行评审、TL级评审。黑盒测试的覆盖率取决于需求的理解程度。据一个简单的例子，如:登陆权限判定、必须理解，那些用户有那些权限。如果没有理解好需求，在多的测试方法也白搭。
作者: kou_dou    时间: 2008-2-27 18:54
以下纯属个人观点，不恰当之处望各位高人指点

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

    既然是保证需求的覆盖度，那就要对需求进行详细的分析。
    1.将SRS转化为UML图
    2.使用RTM对需求进行跟踪
    3.针对每个功能点，使用不同的用例设计方法，设计测试用例，达到需求覆盖率100%
        4.分析软件的显示和隐示需求，再设计用例。
作者: dengzhi    时间: 2008-2-27 18:55
穷举测试
但做穷举测试是不可能的事情
作者: binning_001    时间: 2008-2-27 22:02
1.熟悉业务，需求，规格
2.根据测试思想设计测试用例，尽可能全
3.对设计出来的用例进行赛选
4。执行
作者: aou001    时间: 2008-2-27 22:26
标题: 黑盒
黑盒测试主要是针对产品需求和功能实现的测试.覆盖面主要是在产品和功能上.
作者: chengcai    时间: 2008-2-27 22:39
根据CMMI定义，当从需求采集的时候，就已经制定了验收测试用例，为什么这个时候制定验收测试用例，也是为了保证测试的时候能满足客户的需求，所以要想测试覆盖率高首先要对需求进行需求分析，把需求中提及到的所有功能都在测试过程中测试到；并且需求是个宏观的概念，客户提出需求的时候也是在提出功能，而黑盒测试也是针对功能的测试，所以黑盒的测试主要还是针对客户的需求；当进行黑盒测试的时候，首先要保证所有的功能的基本实现，继而在所有功能的基础上进行其他的类型和方法的测试来验证在实现功能的时候是否带进了其他的问题，个人认为黑盒测试的覆盖率是无法达到100%的，通过详细的对需求进行分析，只能是提高和保证测试的覆盖率。
作者: chengcai    时间: 2008-2-27 22:39
根据CMMI定义，当从需求采集的时候，就已经制定了验收测试用例，为什么这个时候制定验收测试用例，也是为了保证测试的时候能满足客户的需求，所以要想测试覆盖率高首先要对需求进行需求分析，把需求中提及到的所有功能都在测试过程中测试到；并且需求是个宏观的概念，客户提出需求的时候也是在提出功能，而黑盒测试也是针对功能的测试，所以黑盒的测试主要还是针对客户的需求；当进行黑盒测试的时候，首先要保证所有的功能的基本实现，继而在所有功能的基础上进行其他的类型和方法的测试来验证在实现功能的时候是否带进了其他的问题，个人认为黑盒测试的覆盖率是无法达到100%的，通过详细的对需求进行分析，只能是提高和保证测试的覆盖率。
作者: 252090366    时间: 2008-2-28 10:04
看到前面有朋友说编号,突然想到在CMMI中有份文档叫《需求跟踪矩阵》。
作者: lindaweng    时间: 2008-2-28 10:51
首先从认真分析软件需求，将需求点详细整理，设计对应的测试用例，这些都是必不可少的步骤，我想说的是在设计用例的时候应该尽可能的覆盖所有的功能点，用例不在多，要有针对性，在设计有效用例的同时也应该有无效的用例，我觉得这样就能更好的达到覆盖的效果了，新手愚见，不对之处请多多指教
作者: electra    时间: 2008-2-28 11:30
大家说的都很有道理啊，呵呵。我仔细看了一下，对于黑盒测试的覆盖率保证
确实不能像白盒那样量化。但是只要明确客户需求，采用多种测试方法编写测试用例，同时抓住关键功能测试点，我们还是可以减少功能测试的冗余性及其漏洞的。但是需要绞尽脑汁，鞠躬尽瘁啊
作者: 秋天的枫叶    时间: 2008-2-28 11:43
看了楼上诸位的回帖，好像感觉每个人的公司需求、测试都非常正轨，可能是俺的命苦，公司在软件工程这块，针对需求和测试还处于初级阶段，但在这种情况下，黑盒测试要想完全保证需求的覆盖度，就会有一定的难度，因为需求也不完善。。。

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

归结一点，需求、业务、专业能力，缺一不可：）
作者: jack8032    时间: 2008-2-28 12:15
个人看法：
在测试方法方面，可做如下注意：
其一，分析出口入口。从入口分析，将可能出现的环境，条件，操作等内容分类组合，然后根据各位测试达人的方法进行整合，逐一验证。从出口分析，将可能出现的结果进行统计，根据结果的不同追根溯源，再找到不同的操作以及条件等内容，统计成文档，逐一验证。

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


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

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

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

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


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

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

其二，学无止境，只有不断的去学习不断的去思考，才能使自己测试的能力更强，测试对象的全面性也更完整。
作者: sanjieyu    时间: 2008-2-28 12:18
我觉得黑盒测试要更全面的覆盖需求应该做好以下几点：
1.首先要很好的熟悉和理解需求，从MRD,PRD的EDD阶段就要参与进来，了解新的需求，只有理解了需求才能写好用例
2.要对自己所负责的module很清楚，包括UI,FUNCTION，performance等等方面，只有都吃透了才能把用例设计的更全面更准确
3.要学会使用各种设计case的方法学，例如等价法，边界值法，因果图，force－error等等，用例设计要考虑全面，除了要涉及到用户基本功能方面以外，还要考虑到UI界面的美观统一、提示信息的友好、操作的方便性,软件的易用性等等
4.在项目完成以后，根据free test的结果来即使update case也是一种很重要的方法。
只是个人的一些理解，期待高人指点
作者: marvel320    时间: 2008-2-28 14:03
把需求分类，针对每个分类设定需求优先级（及严重程度），然后针对每个分类设计测试用例，因为测试用例不可能覆盖全部的需求，则用测试用例的覆盖度即可导出系统对需求的覆盖度
作者: janedeng    时间: 2008-2-28 16:16
标题: 黑盒测试如何保证需求的覆盖度？（08-02-22）
本人进入测试行业不久，目前还处于学习阶段。我平常做的就是黑盒测试，那么我就根据自己的一点点经验发表一下拙见，不为别的，只为学习，还望各位大侠多多指教。
黑盒测试我做的最多的是功能性测试。而功能性测试是紧跟着用户需求走的。因此，在功能性测试里，对需求的了解就显得尤为重要。当我们在根据测试用例把所有的功能都测过一遍以后，还可以再返回来，拿着需求说明书，一句话一句话的读。为什么要这么做呢？因为在你写测试用例的时候，很难做到用例的覆盖率达到100％，因此，再次的细读用户需求你很有可能发现自己遗漏在某个犄角旮旯里的东西。这样能起到很好的查漏补缺的作用。
当正常的用例测试过系统后，还可以考虑用一些变态的测试用去测试系统，这样往往会发现很多漏洞哦。
大体来说，功能测试，对于文本字段框，可以一个一个的测，这样花的时间会比较多，也会觉得很繁琐，但是这样真的很全面呀。在业务逻辑方面，只要紧跟着用户需求走，就不会出什么问题，因此，需求管理很重要的。在GUI方面，就要考我们的眼里劲了。当你看一个系统看了很久以后，很有可能在某些地方变的麻木了。因此，这个时候，我们就要停下来休息休息，调整好状态后再来，就会很不一样哦。我觉得这个方法在哪都适用。
对于性能测试可以采用自动测试工具。如果测试的是小的应用软件，那么还可以发动公司的同事、制造大量的数据一起去折磨它，性能不好就会撑不住的。人为的制造高强度高压力的条件来测试性能也很管用，而且也比较全面。
作者: buzz    时间: 2008-2-28 16:22
标题: 回复：如何衡量需求被覆盖的程度
版主的这个问题可能要加一些假设条件才能回答，就是我们手中有一份理想化的需求，是一份规范的需求文档，那么

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

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

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

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

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

实际上一些测试管理工具或项目管理工具也体现了这一思想，如TD，就是从需求管理开始一直关联到测试用例和执行。
作者: zhouchiyi    时间: 2008-2-28 18:15
个人认为，黑盒测试的覆盖主要在于测试系统的功能覆盖，要想达到一定的覆盖度，编写测试用例时需要对系统的需求文件，功能文档等系统的相关文档有充分的了解，特别是对系统实现的功能要了解，并在每个功能的基础上，主要以等价类，边界值，因果图以及错误推测等方法来编写测试用例。以达到功能覆盖的完整。
作者: apl137    时间: 2008-2-28 18:51
黑全测试如何保证需求的覆盖度？假设需求是不变的。我们只需要使用黑合测试的策略用等价类、边界值、错误推测、因果图、判定表驱动、正交试验、功能图、场景法等测试就能保证需求的覆盖度。当然这是理想的情况。但是，在真实的项目中需求是在变化的。这就要求做好需求管理。如用TD记录需求的变更，及对需求的管理。就以得到比较高的需求覆盖。个人认为管理好需求，是保证需求的覆盖度的关键点。
作者: shenlake    时间: 2008-2-28 21:36
主要要做好测试需求分析
测试需求分析分两步：
1，测试需求的获取
需求的来源：显式需求（1）原始需求说明书（2）产品规格书（3）软件需求文档（4）有无继承性文档（5）经验库（6）通用的协议规范
隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析
2，需求的分析 ，产生测试需求文档
将不同的需求来源划分成一个个需求点，针对每一点进行测试分析，（1）界定测试范围（2）利用各种测试设计的方法产生测试点
作者: 调皮精灵    时间: 2008-2-28 22:56
黑盒测试如何保证需求的覆盖度？
这个应该要看针对什么样的客户,对可靠性和性能,易用性方面的相关要求,所以如果要保证需求的覆盖度,首先是要分析好客户的需求,然后在进行相关方面的设计,
对于功能部分的设计可以采取一系列的测试方法,比如说场景设计,正交设计等等，然后在分析是对性能的要求和可靠性的要求,如果此系统对可靠性要求比较高。那可能
需要考虑一些常用的故障注入方法,如果对UCD要求比较高的话,可能则需要根据一些UCD的相关规范进行测试.更好一点,还搞个用户体验之类来评估次需求的可用性..当然这些都是要
基于成本考虑的...
作者: hhyghr    时间: 2008-2-29 11:47
标题: 回复 4# 的帖子
我支持这个观点。呵呵
作者: cjchm    时间: 2008-2-29 16:08
黑盒测试一般指的就是功能测试，关于黑盒测试该用的方法和技巧，前面的朋友都已经提过了，100％的覆盖是不能的，即便现阶段达到了，需求却是不断变化的。
    那么什么样的覆盖度才算合理，本人觉得此时最重要的事情就是，测试用例的评审工作。抓好评审工作，将用例的设计做好。大家认为可行了，覆盖度的理想值基本上就接近了。
    鉴于需求的不断变更，测试人员也应该及时更新用例，做好版本升级。
    软件的测试在集成测试阶段，不仅要从功能测试方面来测试，还要从易用性，安全性，界面美观性及软件的性能等方面来进行。
    没有100％完美的软件，测试也不可能100％，在平时的工作中也要经常创新和总结，积累经验，提高测试水平，对需求的尽可能透彻的理解，将客户可能发现的bug或者不合理的地方扼杀在萌芽状态，就很不错了。
   以上个人愚见，希望大家多多赐教。

[ 本帖最后由 cjchm 于 2008-2-29 16:09 编辑 ]



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2