查看完整版本: 黑盒测试如何保证需求的覆盖度？（08-02-22）（获奖名单已公布）

黑盒测试如何保证需求的覆盖度？（08-02-22）（获奖名单已公布）

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

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

　　　　　　　　　　　　　　[color=red][b]  [table=410][tr][td=4,1,410][align=center][font=宋体][size=2][color=red][b]获奖名单[/b][/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=blue]奖项[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=blue]获奖名单[/color][/size][/font][/align][/td][td][align=center][size=2][font=宋体][color=blue]奖励[/color][/align][/font][/size][/td][td=1,1,72][align=center][font=宋体][size=2][color=blue]答案链接[/color][/size][/font][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]一等奖[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]shenlake[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]当当购物卡50元[/color][/size][/font][/align][/td][td][align=center][url=http://bbs.51testing.com/viewthread.php?tid=106504&page=5#pid887412][size=10pt][font=宋体][color=#800080]99#[/color][/font][/size][/url][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]二等奖[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000]huior[/color][/size][/font][/align][/td][td][align=center][size=2][color=#000000][font=宋体]300论坛积分[/font][/color][/size][/align][/td][td][align=center][url=http://bbs.51testing.com/viewthread.php?tid=106504&page=4#pid884915][size=10pt][font=宋体][color=#800080]61#[/color][/font][/size][/url][/align][/td][/tr][tr][td][align=center][font=宋体][color=#800080][/color][/font] [/align][/td][td][align=center][size=2][color=#000000][font=宋体]huang-xl[/font][/color][/size][/align][/td][td][align=center][font=宋体][size=2][color=#000000][/color][/size][/font] [/align][/td][td][align=center][url=http://bbs.51testing.com/viewthread.php?tid=106504&page=2#pid883103][size=10pt][font=宋体][color=#800080]30#[/color][/font][/size][/url][/align][/td][/tr][tr][td][align=center][font=宋体][size=2][color=#000000]三等奖[/color][/size][/font][/align][/td][td][align=center][size=2][color=#000000][font=宋体]1qazse4[/font][/color][/size][/align][/td][td][align=center][font=宋体][size=2][color=#000000]100论坛积分 [/color][/size][/font][/align][/td][td][align=center][url=http://bbs.51testing.com/viewthread.php?tid=106504&page=2#pid882979][size=10pt][font=宋体][color=#800080]26#[/color][/font][/size][/url][/align][/td][/tr][tr][td][align=center][font=宋体][color=#800080][/color][/font] [/align][/td][td][align=center][size=2][color=#000000][font=宋体]fengjingqiong[/font][/color][/size][/align][/td][td][align=center][font=宋体][size=2][color=#000000][/color][/size][/font] [/align][/td][td][align=center][url=http://bbs.51testing.com/viewthread.php?tid=106504&page=4#pid885121][size=10pt][font=宋体][color=#800080]66#[/color][/font][/size][/url][/align][/td][/tr][tr][td][align=center][font=宋体][color=#800080][/color][/font] [/align][/td][td][align=center][font=宋体][size=2][color=#000000]jack8032[/color][/size][/font][/align][/td][td][align=center][font=宋体][size=2][color=#000000][/color][/size][/font] [/align][/td][td][align=center][url=http://bbs.51testing.com/viewthread.php?tid=106504&page=5#pid886808][size=10pt][font=宋体][color=#800080]92#[/color][/font][/size][/url][/align][/td][/tr][/table][/b][/color]

版主能不能先谈一谈自己高见啊!!

楼上的同学，还是你来谈谈吧！

黑盒测试及其覆盖率

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试，要想尽可能的覆盖所有测试，就要根据以上测试方法，详细地列出测试用例，细分功能点，提高测试覆盖率。

用例密度不就是衡量测试充分性的一个重要指标吗??

我觉得保证需求的覆盖度前提是对需求或是说程序的功能了解透彻，然后要确定什么是常规情况，什么是极限情况，什么是非法情况；
划分这些以后就是编写详尽的测试用例（但是这里又出现了疑问，什么才算是详尽的测试用例，不可能把所有情况都列举出来，这就需要根据测试员本身的经验，也可以向程序员讨教一下，哪些情况属于同种类型，哪些地方需要测试所有可能的情况），然后进行测试，把这几点做的越好就越可能提高黑盒测试时需求覆盖度。

呵呵，个人拙见，希望看到更多大侠的意见看法

对于项目而言，tpm或者tc  设计规格 需求分解 测试方案...测试用例，测试执行
(功能，性能，压力，可靠性)这些都是根据实际用户应用场景设计得
每个公司都是一套根据公司实际情况得流程，关键是每个步骤都要有人跟踪，每个过程都需要评审（内部和同行），争对评审记录做相应修改 ....想说得挺多，但发现懒得打字了:lol

我觉得黑盒测试很难达到覆盖所有测试的需求，在某些场合存在一定的局限性和不足。目前大多数还是通过用例的密度和回归的次数来衡量吧，听听其他人高见

个人意见_仅功能覆盖

黑盒测试包括功能测试和性能测试,这里我只发表关于功能覆盖率的个人见解,不对之处请大家指正.
        功能测试的覆盖率在我认为就是测试用例功能点的覆盖率.首先,就要做好需求管理工作.将系统的功能按照子系统、模块、功能点的划分进行详细统计。以便于针对需求的变更作出记录。同时，结合测试用例，保证用例包括到最小功能点。需求如果发生变更，及时对用例库进行维护。其次，要保证测试用例的有效性，针对功能点的测试范围要尽可能的全面，但决不是穷举测试。
    通过这两点，应该能够满足对功能测试的覆盖率的保障。

需求的覆盖程度其实完全可以转化为测试用例的覆盖率来考虑，测试用例的覆盖率现在有些公司也在做，不过成效不是很大，一般可分为几种做法：
1、借助于工具：但目前似乎还没有一种比较适合的工具来分析
2、使用一些特殊的图标来分析：比如需求矩阵等
3、人为控制
要进行测试用例覆盖率的统计，个人认为需考虑以下两点：
1、如何才能做到很好的量化
2、目前我们的实际情况是否有必要做此量化
当然测试用例的覆盖率，目前我也没有一个好的方法，期待楼下的精彩:handshake

首先要认真分析软件需求，将需求点详细整理，设计对应的测试用例，保证用例覆盖到每个功能点。还要分析软件各个部分间的关系，设计应用于模块间的测试用例。
再者，要做好用例的评审。评审时细化到每个用例与需求间的关系，必竟多几个人会有不同的思路和想法，可以在已有用例的基础做进一步的审查和补充，更好的保证需求的覆盖度。

黑盒测试的需求覆盖度，很难保证100%的覆盖，只能做到尽可能多的覆盖，我觉得首先应该是对这个系统的功能根据需求完整的了解，不能说全部背下来，也要大致的熟悉，还有就是要对业务上的知识进行了解，如果对业务根本完全一无所知，那可想而知很难写出好的测试用例，也就谈不上需求的覆盖度了，同时看到楼上说的那些测试方法虽然很好，不能只追求与表面，更应在深层次的去剖析，找到问题的根本所在，这样长期的积累，对与需求的覆盖度也是很有帮助的，而且我觉得需求的覆盖度的意义很广泛，不仅应该包括功能上的，还要包括例如用户界面上的美观性，直观性，功能上的易用性等等，因为现在的用户在这些方面的要求程度也在逐步的加大，总之要想保证需求的覆盖程度，不是一朝一夕的事情，而是需要在平时不断的去积累，团队成员的互相配合，毛主席说的理论要和实际相结合啊，这样黑盒测试的需求覆盖度才能有保证，要从量变到质变，否则的话就是纸上谈兵了，这个只是我的个人见解，有不妥之处还希望多多帮助啊。:lol

:handshake 受益匪浅.

先根据需求测试人员编写详细测试用例，针对写出的测试用例进行评审，评审需要开发人员参与，针对模块化的测试用例进行讨论，权衡测试用例的可执行性以及测试用例的一些盲点。

测试完之后进行总结也是很必要的，可补充编写测试用例时未考虑到的地方。:)

没有绝对完整的测试，只有逐步完善~:handshake

发表一下我的个人观点
我觉得黑盒测试要更全面的覆盖需求应该做好以下几点：
1.首先要很好的熟悉和理解需求，只有理解了需求才能写好用例
2.要对业务知识很清楚，清楚业务知识才能把用例设计的更全面更准确
3.用例设计要考虑全面，要涉及到用户基本需求还要考虑必要的伪需求，界面的美观统一、提示信息的友好、操作的方便性等等都要考虑到
4.测试方法要合理、覆盖面要广，等价类划分、边界值、因果图等等
经验丰富了碰到的情况多了也就考虑问题全面了，所以经验也很重要
只是个人的一些理解，期待高人指点:handshake

执行测试是更好的理解需求的一个过程.不断的测试,需求会被不断的挖掘不断的深入.我们所提到的覆盖度可能要从经度和纬度两个方面考虑.我想,即使百分百覆盖了需求文档,也不能百分百覆盖需求.
一,需求一直都在变
二,真正的需求需要不断的理解,挖掘才能被无限接近.但不可能完全达成最原始的需求
三.需求的提炼过程可能存住一些不真实需求,及需求的缺失.
.....
以上种种要求我们,测试时多熟悉业务,多方面了解产品.真正站在使用者角度理解需求.

本公司测试工作经验

首先根据需求分析和概要设计、详细设计、数据库设计等文档，编写测试计划和测试用例。
测试执行：
1、功能测试。
     所有功能的实现，应用相关测试方法：等价类划分、边值分析、因—果图、错误推测等；
     数据库检查；
     关联性测试；
     页面测试；
     用户体验。
2、性能测试。
3、安装测试。
4、验收测试。

[[i] 本帖最后由 特别关注 于 2008-2-22 20:28 编辑 [/i]]

我认为要达到一定的覆盖度,首先应该将需求吃透,细分需求,才能保证设计出来的测试用例最全面的覆盖需求.

黑盒测试

系统测试是黑盒测试的范畴，黑盒测试也叫功能测试，不需要了解代码内部的逻辑，只是实现外在功能实现，需要构造输入一些操作而得出预期的输出。如何去度量它？
A、依据SRS得出一个需求列表；
B、对SRS进行学习和分析——用UML画出用例图跟活动图；
C、针对每一项需求考虑他所包含的隐式需求有那些？这需要对行业知识的了解和一定的工作经验；
D、依据需求构造用例；
E、依据测试用例执行用例。
这是我新手组织的一点东西，献丑了。

1.需求者讲解需求
2.测试人员、开发人员分析文档，共同探讨需求的实现，向需求者提出问题，并由需求者作出详细解释，尽量作到对需求了如指掌
3.测试人员根据讨论内容编写需求文档的测试分析(功能点、风险点、测试难点、可能造成对其他功能的影响等),并与程序及其他测试人员探讨可以改进的部分加以改进
4.测试人员根据上一阶段编写的测试分析写出测试用例,并且由需求者,测试人员,程序等功能相关人员共同进行评审,并进行适当修改
5.严格执行测试用例,并在测试过程中及时与程序及需求者交流测试过程中发现的疑难点.如发现用例不足及时进行增删修改
6.建立完备的错误收集机制，然后使用通过全部用例后的稳定版本（或含有极少量不足的稳定版本）在内部进行大规模试用(monkey)。

黑盒测试如何保证需求的覆盖度？（08-02-22）

通过最近工作我体会测试覆盖度是取决客户对软件的要求，客户专注是什么方面，有些小错误是客户就这样想还是我们自己想象出来得结果，现在大多数软件都不是完全按照软件流程在走，很多时候需求分析是在不同时期，软件需求是不同，所以对于软件质量要求不同。
好像谈走题咯，好，现在回答主题。
我觉得为了保证黑盒测试覆盖率，首先得分析下软件，可以我们要分那几个模块来编写test case，或测试点，分析好测试点后，我们开始写个List, 看下我们还有什么遗漏的，这个可以是设计test case得阶段，看这个点是等级来分析这个地方test case数量，内部覆盖方法可以参考等价划分，边界值等方法，我觉得我们还是要多想些异常的操作方法，异常得方法就可以找到很多遗漏，在不断多模块了解，我们对很多不同操作都可以做些尝试，这里面就隐藏问题。

黑盒测试如何保证需求的覆盖度？（08-02-22）

看到楼上诸位朋友各抒己见，自己也按耐不住啦！说一下自己在工作中对本期问题的一点愚见。
首先，要对需求理解全面、准确，以便找出测试点，包括明确的和隐含的，功能方面的、非功能方面的，还有业务流程方面的；非功能方面又分安全、界面、性能等；
其次，与最终用户、需求分析人员、设计人员及开发人员的交流沟通，便于解决测试需求分析中遇到的疑问，形成全面的测试需求分析，明确我们的工作内容；
第三，采用一些教材或资料文档中提到的黑盒测试常用的测试方法，如边界值法、等价类、因果图等，设计出正常及非正常两类测试用例，重点是非正常的测试用例，同时考虑非功能性方面的验证用例；
第四，再次结合需求文档对用例的集中评审，确保个别工程师工作的疏漏及误解。

差不多就这么多吧，具体项目具体分析，在实践中不断更新、积累才是硬道理。

黑盒测试如何保证需求的覆盖度？（08-02-22）

也来谈谈我的愚见。
    黑盒测试最重要的就是功能测试了。被测试的产品能不能满足客户要求得业务功能是最要关注的。所以，业务知识的学习就显得特别重要。吃透业务，了解用户需求，是我们达到高测试覆盖度的基础。

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

全覆盖是不大可能的，只能通过我们的努力去提高测试覆盖率。欢迎大家各抒己见，共同借鉴。

个人认为要保证需求的覆盖度必须要深入理解需求

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

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

紧跟需求分析！

仅代表个人观点：
在一个平面中，把用户的需求看成一个个零散的点。而需求覆盖度，就是包围了部分点的一个个的圈。需求覆盖度不可能100%，即没有一个圈能包围所有的点。
当需求分析人员把这个圈画好之后，我们一直在完善圈内的点，而忽视了圈外的点。用户一开始跟我们说要一个杯子，下次又说要一个带耳朵的杯子，再下次呢？要加盖的。
因此保证测试中需求的覆盖度，可以先从一个很小的圈开始，然后不断地扩大这个圈。除了要清楚通过的和未通过的功能，还要留意将会实现的和不可能实现的功能。

需求的测试，其实大部分都是业务的测试。常规的业务流程都是固定单一的。这个问题其实就转化成了业务流程的不规范情况的测试。
这种测试时不可能穷举的。

目前测试对需求的覆盖程度已经作为判断测试质量的一个标准,但不同的测试类型和需求类型如何判断测试的
覆盖程度?
1、一般来说,非功能性测试的覆盖程度比较好判断,如性能和压力测试,可根据需求中明确的性能指标进行测试
分析和设计，另外也可通过分析系统在生产中实际使用情况，来分析一些隐含的需求，如系统是否需要连续运
行、系统故障后恢复的级别、并发访问的程度等。
2、功能性测试的覆盖程度是比较难判断的，用例数不能完全说明对需求的覆盖，因为用例数和测试点的力度
划分相关，测试点划分的越细，用例数量越大，但不能说明覆盖程度高。
我们的做法一般是先根据用户需求确定测试优先级，重点需求测试点划分的比较详细，测试用例要覆盖所有的情况，如正常值、边界值、特殊值等；一般性需求测试用例覆盖所有的正常等价类；
测试用例设计上划分为单功能测试用例和测试场景设计，单功能测试覆盖的需求中的功能点，测试场景覆盖需求中的业务逻辑；
另外测试设计全面与否，很大程度取决于需求的质量，取决用户是否真正明白自己想让系统做什么。

我觉得。不论怎么样，都要以规格需求说明书为准，可以用其他的测试方法，我觉得只要符合规格需求说明书的要求就可以了。:lol :lol

1.需求覆盖可以根据软件质量模型的六大特性及其26个子特性来进行
2.具体子特性的覆盖可以结合一些软件测试用例分析方法，例如等价类啊，边界值啊。。等等

黑盒测试如何保证需求的覆盖度？（08-02-22）

黑盒测试的覆盖率是不可能达到100%的，只能做到逐步完善。
根据软件需求分析和软件测试计划里的要求，采用边界值，等价类，因果法，大纲法等去设计用例，尽可能的做到覆盖，可以让测试用例有适当的冗余。

[问题1]如何衡量需求被覆盖的程度？

    首先提一个个人观点。

    我们要覆盖的需求是什么？是一堆令人望而生畏的需求文档吗？No No No。我们覆盖的是实际客户的具体需求。

    所以从需求到黑盒测试覆盖有至少有三个步骤。客户需求－> 需求文档 -> 测试用例 -> 执行黑盒测试：客户的实际需求通过需求分析人员的分析理解，得出需求文档。测试设计人员通过理解需求文档和相关设计文档设计出测试用例。测试人员依据测试用例执行测试。

    那么也就是说我们可以通过一个简单的公式算出需求被黑盒测试覆盖的程度。我们假设需求文档包括了所有客户需求的60%，测试用例包括了所有需求文档内容的70%，黑盒测试执行了80%的测试用例那么需求被黑盒测试覆盖的程度就是：60%×70%×80%。

    但这是理想状态下的结论。实际上这个公式存在很严重的缺陷。它很难量化三个内容：1.客户的需求：我们能弄清客户到底有多少需求吗？NEVER。想都不要想。2.需求文档能描述出现有的已经弄清的客户需求吗？这很难。3.测试用例能够对应上每一条需求吗？

    所以在具体做法上。我们需要有一个妥协就是假定我们已经获得客户当前所有需求。然后我们把需求总结分析成一些条条纲纲再建立两个矩阵一个记录：需求、需求文档矩阵；需求文档、测试用例矩阵和测试用例执行记录。通过两两关联，实现黑盒测试对需求覆盖的程度的计算。

    前面假定了我们已经获得客户当前所有需求。 这个假设并不合理。因此作为这个假设的补充。我们认为，客户需求在不停的变化。这样只要需求文档和测试用例能够根据需求关联变化那么我们计算出来的需求覆盖程度还是有一定精确性的。

    当然要实现需求文档和测试用例能够跟随需求关联变化。如果只靠普通文档那么维护量是相当的大了。所以可以用TD的“需求定义”、“测试计划”、“测试执行”三个模块进行对应的关联管理。

[问题2]如何保证去达到一定的需求覆盖

首先，保证需求与黑盒测试的关联性。做到有的放矢。

其次，保证黑盒测试的执行程度。做到不停的放矢。

如果要做到高效的需求覆盖，其实有一些具体的操作方法可以借鉴：

1.给需求评级。在测试资源紧张的情况下，这种做法有助于我们找到最需要执行的测试用例。

2.回归测试的自动化实现。回归测试自动化的有点就没必要讲了，在Mercury的产品宣传上我们可以找到好多。实际上这也是我们中的大多数来51上闲逛的原因。

3.制度上的保证。

4.一些对人的激励。包括负面和正面的。负面的比如说：再不提高测试效律，周末加班，你就看不上火箭和黄蜂的比赛了。正面的比如说：加薪。当然就实际效果而言正面激励的效果更明显。

5.实时跟踪需求的变更。大多数情况下，需求就象女朋友的脸一样阴晴不定。如果花了一整天蛮力的测试工作只是在一个已经在前一天已经更改的需求的指导下进行，那么很遗憾，我们又白干了。

黑盒测试首先应该深入透彻地了解客户的需求，因为不可能穷举所有功能点的测试用例，这样既耗费工作量也不能体现客户所关注的重点。所以个人觉得，在情况允许的条件下尽可能多地覆盖客户所更关注的需求：
1、应该结合需求文档，认真分析需求重点，进行用例的设计。
2、对于基本的或通用的功能测试，可以设计公共的测试用例，保证用例设计的质量和效率。
3、对于业务复杂的测试对象，应先绘制流程，保证流程分支的全面覆盖。
另外，还可以通过对用例的评审，检查是否有需要关注而没有设计到用例中的功能点，以补充用例。

[[i] 本帖最后由 liangch 于 2008-2-25 10:08 编辑 [/i]]

1、首先，要有需要测试的“需求”数据，也就是说，黑盒测试的对象。比如，在QC中的测试需求树
2、其次，要有黑盒测试与这些“需求”的关系，也就是黑盒测试用例与“需求”的对应关系。比如，QC中的测试计划对测试需求的覆盖
理论上就这么简单，但实际操作中，“需求”如何划分粒度是一个难点，以“功能”为单位，可能太粗，也可能就够了，以“功能点”为单位，可能又太细。

个人认为：在测试模块功能时，要先满足功能点的测试。这个过程一般在单元测试实现。而实际上在中小型的公司中不存在单元测试这个阶段，直接开始就是集成测试。
因此，我当时多做了一个过程，必须针对划分为最细小的功能进行测试。这里有个简单的地方，因为最细小的功能就是：添加、删除、修改、查询等。
添加/修改/查询，页面元素会比较多，使用正交法是个不错的选择
删除也简单，一般实现记录删除：单条删除、多条删除、全部删除等。
实现了最细小的功能一轮后，进行集成测试，相对就简单多了~~

同意楼上不少人的看法，首先熟透需求，再进行用例设计。对于黑盒，要做到尽可能大的覆盖率，也只能在对需求的熟悉之下，凭借多和开发沟通和个人的经验累积了。所以，对不同的测试对象，对症下药，才能提高覆盖率。

看了楼上各位所谈的,都很有道理,在此本人给出几个测试开发过程度量的公式,无论对白盒和黑盒都有用:
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=运行的测试用例数

首先应该充分了解需求，整理好需求文档。
然后以此为基础，分析需求，整理出各个功能点，编写各个功能点的测试用例，尽量能写全各个功能点的测试用例。
最后再根据测试用例进行测试。但在实际工作中可能来不及写测试用例，或者只写了某些主要功能点的测试用例，这就需要在测试时也结合需求文档，从黑盒测试方法中选择相应的方法，根据对业务功能分析选择测试数据来进行测试，保证需求文档中涉及的功能都能够在程序中执行一遍。