其次，一切都从自身利益出发，只满足客户的需求就可以，当然客户也可能有的需求没有说到，但是这都是可以作为和客户谈价钱的筹码。
再次，不可能把软件做的那么完美，至于覆盖程度只是理论上的，满足用户需求即可，多做也只是浪费时间和精力。
最后，理论上讨论就是本身对需求的理解程度，把握需求的尺度，来走黑盒的覆盖，举个例子：
需求： 拿用户登陆来说，客户需求说的是能让用户正常登陆到该系统进行操作。
覆盖：我们可以先正常的理解，
、UI
1>UI设计要美观，颜色搭配要适当
2>按钮的颜色状态，有时候有些按钮在不满足其触发状态的时候，要设计成灰色，也就是不可选状态
2、功能需求
1>主要考虑输入框内数据的限制，比如数字、字符、符号、一些组合输入、长度限制（如果没有长度限制的话，输入n多数据容易引起程序异常退出）
2>正确的、人性化的提示
3、性能需求
主要考虑性能方面的需求，比如n个人同时输入，同时提交，会不会引起异常
4、异常中断
可以考虑一些断网、断电的情况
5、快捷键
比如是否支持复制、粘贴、剪贴等快捷键
就可以了，如果还想覆盖的全面些我想都没有什么必要，等客户提出的时候再作讨论。
比如：
1、用多种浏览器测试，当用到TT之类的浏览器，当第一次用输入错误用户名和密码，不登陆，强制关闭电脑，再次开机，点击TT浏览器后，点击恢复之前的网页，此时，之前的登录名和密码还在麽？
2、用多种浏览器测试，当用到TT之类的浏览器，当第一次用输入错误用户名和密码，登陆（不管是否有提示），强制关闭电脑，再次开机，点击TT浏览器后，点击恢复之前的网页，此时，之前的登录名和密码还在麽？
黑盒测试如何保证需求的覆盖度
黑盒测试是不需要考虑内部结构，主要对外部功能点进行测试，数据驱动。所以第一必须了解需求，对需求进行分析，找出所以数据信息进行分类统计（有效数据和无效数据）。
对统计数据采用边界值，等价类划分，异常数据，因果图法进行用例设计，而且对测试用例进行维护。
说的不好，请高手指点！ 我认为测试用例应该是能保证覆盖率的方法之一.
个人观点
关于这个问题应该有两个假设：１，需求写的足够明确清晰；２测试管理人员经验丰富a,分析需求并请相关人员做详细讲解
ｂ．根据需求写出经过评审的用例
ｂ．根据经验，可以采取交加测试；
ｃ．根据需求的隐含信息增加测试用例，比如多操作系统、多数据库、不同分辨率等。
我的想法
我觉得黑盒测试和功能测试不是一个范畴的东西，个人认为黑盒测试是一种测试方法，而功能测试通常采用了这种方法，功能测试也可以采用白盒的方法。就我们公司而言，我们会采用黑盒测试的方法去检查软件的几大质量特性，如：功能度、易用性、可靠性、兼容性等。
对于黑盒测试保证需求覆盖度的问题，我同意大家前面的观点，首先是深度了解需求，这样才能提高需求覆盖度。我觉得可以从两个方面去设计案例，一是按照软件系统界面的功能，利用黑盒测试的方法。二是按照业务流程，设计测试案例。
以上只是我个人的一些想法，:)
关于黑盒测试如何保证需求的覆盖度
我来总结一句话吧，就是用尽可能少的测试用例覆盖尽可能多的功能点。 我也说说吧，说的不好，请多多指教。首先最重要的是吃透需求，然后结合各种测试用例的设计方法来编写测试用例。
在进行黑盒测试的时候我们一个是根据测试用例来进行测试，
另外一个就是发挥自己对业务逻辑的熟悉，来进行一些测试，这时候我们也需要及时更新我们的测试用例。
这样可以是测试用例不断进行完善。
大致就这样吧，大家多指教哈:loveliness:
了解需求是关键
对于黑盒测试（功能测试），首先是要了解需求；能够对需求分析透彻，才能知道什么是正确，什么是错误；什么样的系统响应更能满足用户的需求；符合用户的操作习惯；适应用户的业务操作流程，也才能正确的设计测试用例，对于测试用例的覆盖性，要能达到100％是不可能的；只能说随着对功能的了解，及其测试经验的积累，能够在测试用例的设计方面更加详实，符合实际需求。 最主要的是做到测试用例先行,做好测试数据的划分!请高手指点了。
以前只有白盒才有覆盖率的指标，但看了有些书上也提到过黑盒测试覆盖率。说的是测试覆盖软件需求，我想不通该如何去衡量这个指标，不知各位前辈有何高见？实际测试中结束测试的条件是测试覆盖率么？我自己认为应该是首先根据软件需求文档列出所有功能点，编写测试用例，测试实际实现的功能点。测试覆盖率=测试过的功能点数/需求文档所有功能点数。不知道是否正确。在实际自动化测试中如何动态显示？还是有很大量的手工工作做。
关于如何保证需求的覆盖度，除了重点用例设计外，还要考虑到测试策略。
[ 本帖最后由 jane3910 于 2008-2-26 11:48 编辑 ] 首先是对业务系统非常的熟悉，我们有没有发现，起初测试的时候，我们只是发现一些常规的问题，随着对系统理解的深入，我们渐渐地发现了一些很隐藏的问题。
其次是采用多种测试用例设计方法，从多角度去分析、测试，保证测试的充分性。 如果有正规的需求，就从需求中导出测试用例，因为需求中有详细的需求用例，然后在根据系统的详细设计说明书进行补充，再根据自身的测试经验进行补充，如果没有正规的需求，就需要自己组织，这样就必须对被测对象进行彻底的分解熟悉，再结合自身的经验以及研发的文档进行测试用例的设计，然后通过测试组内的评审完善测试用例。 其实最缺乏的测试用例是当前功能模块和其他相关功能模块（有些看似风马牛不相及的功能，其实还是有内在联系的）关联的部分，这需要对整个被测系统的全面熟悉和不断的经验积累，
甚至在评审中也可能发现不了的问题。
所以测试用例要在测试中不断完善。 好，果然高手如云 就我工作的经验而言，黑盒测试需要保证覆盖率一般需要考虑的有以下几点
1：所有功能点是否完全覆盖
2：一些可以提炼出来的模块比如注册登陆，网站的cookie等它所需要的一些约定俗成的检查点是否有完全的覆盖。
3：黑盒还是有逻辑可言的前台业务逻辑的覆盖也是很重要的组成部分
4：透过一些功能点去猜测背后的程序逻辑查找可能的隐含bug
黑盒测试如何保证需求的覆盖度?
个人观点：将需求分解为特性点，也可由产品经理列出产品的特性点，测试用例最基本的就是覆盖这些内容，再将测试方法、经验、项目特性、用户角度等加入测试要点中，再测试界面规范、可用性、业务流程等，最终进行交互测试和回归测试 学习:victory: 学习:lol 向大家学习了!呵呵,感谢楼上的各位的精彩说明! 我的详细解答，请参考
http://www.51testing.com/?10851 个人觉得这个题目有歧义，需求覆盖度自然是按照根据需求文档写出的测试文档来控制的，测试文档越贴近需求文档，自然需求的覆盖度就高。
如果换成黑盒测试如何保证代码覆盖率，这题才有深究的意义，否则只是一道标准的“明知故问”型问题。
