而黑盒测试，尽管需求写得很完善，但是还是需要测试员对业务很熟，要求测试员有一定的业务只是才能够做的好。而这些在需求书上是不会列出来的，都是些经验和行业知识的积累。
白盒测试更难
可能我不懂白盒测试吧,应该白盒测试需要看到代码,分析代码,并不是简单的静态代码检查.所以真正要做好白盒测试你需要有开发的经验,这个不是每个测试人员都有的. 白盒难．． :lol 先说下个人观点吧！黑盒测试肯定比白盒测试要难，这是为什么呢！原因如下：
清晰度对比：
需求规格说明书V详细设计说明书你会觉得那个更清晰些！不说大家都知道了！开发过程中最清晰的就是详细设计了！在测试眼里也是！
可预测性对比：
只要你们熟悉黑盒测试和白盒测试定义，就很容易理解这点，打个比喻：黑盒测试是摸黑走路，你知道前面即将发生什么嘛？只能硬着头皮走啦（怕黑得早被吓哭了）无法预测，白盒测试就不一样了，开灯走夜路比较安全而且可预测。比喻不太好！勿见笑！
枯燥性：
黑盒测试比白盒测试更枯燥，需要更多的耐心！
其实还有很多很多！做得好白盒测试的可以去做开发人员，但是绝对做不好黑盒测试！毕竟黑盒测试要求的是性格和爱好！（纯属个人意见，请勿怪） 白盒入门难 越学越简单
黑盒入门易 越学越全面
小小企业面试题,问这个问题的人肯定不了解测试
支持所有说没有可比性的同行回答这个问题,个人观点,
首先,你应该明白的两个很基本的问题,
什么是白盒测试,什么是黑盒测试,分别在测试的什么阶段使用,
白盒测试测的范围是哪些,黑盒测试范围测的又是哪些
分别使用什么样的测试技术和测试方法,
测试的目的或者作用是干什么
基于以上问题,我个人总结了一下,回答类似问题应该从一下几个方面:
黑盒测试------基于用户的测试,或者说是基于需求的测试,在测试过程中我们一般只做两件事,就是基于用户业务的通过测试,和基于对系统功能,性能,压力,安全性等因素的失败测试
有人给出的黑盒测试的定义是:黑盒测试又称功能测试,或者数据驱动的测试,其实我对这个的理解就是下面我要说的
黑盒测试是有依据的,从测试方面的角度来说,对我们测试最有利的是用户的需求,这是测试的依据,满足了用户的需求,和业务的正常实现,我们可以说软件做完了通过测试
程序员修正了,经常出现的问题,让我们基于失败的数据流不能进入程序或者说程序不予处理,这时候就可以说黑盒测试测完了,中国的大部分软件企业,这时候也改进入测试交付阶段了
白盒测试----基于程序员的测试,或者说基于代码的测试,有人称之为结构测试或者逻辑驱动的测试,从这一点
我们就应该知道,如果你要做白盒测试,必须具备的素质----------逻辑思维能力,同时要注意的是,这里还有结构测试,
这个结构个人的理解不是程序,也不是算法,而是数据结构,为什么这样说呢,从一方面来讲,所有的程序其实现结果就是完成一张表,从这个概念上我们可以说系统就是一个数据库,功能就是一张表,如果你对这个数据库根本不了解,试问如何测试? 另一个方面,从白盒测试的实现技术上来说,不论你是采用白盒的"六种覆盖技术------语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖,还是使用白盒测试方法,什么代码检查,代码走查,之类的,你要做的也是对每个功能点结构的了解,从测试技术来说,和单元测试差不多,你要知道这个单元(功能点)的作用,以及与其他功能点之间的关系,***********变相的回到了对整个系统总体结构的把握
同样区分白盒和黑盒时候我们还要看在测试的各个测试阶段,白盒一般在单元测试^_^文档测试也算
黑盒都是在系统测试了
针对不同公司的不同情况,不管你采用的是V模型,还是X模型,或者W和H 模型,
很多人都会把业务功能的重点,交给经验丰富的开发工程师来做 ,很明显就在这里,如果业务逻辑比较复杂,公司就会考虑白盒测试了
黑盒和白盒没有严格的区分,个人观点,如果没有对程序或者说系统的认识
白盒你根本做不了.但这也不意味着白盒一定比黑盒高
黑盒关注的是功能,
白盒关注的是逻辑
弄清楚本质,才能做好测试,不是吗?
************************一家之言
个人博客:handshake
无聊
白盒、黑盒 都有他们的侧重点，关于难度我刚刚学测试的，发表我个人的意见：对于不会编程的人来说：黑盒比较适合他们入门
会编程的人来说:他们更注重于白盒
测试到了最后的关键步骤：一些重要的的测试都是由黑盒来完成的 问几个问题：
谁说白盒做不了功能测试？
谁说白盒只能做逻辑测试？
谁说白盒不能完成需求覆盖率？
谁告诉你重要的测试都是靠黑盒来完成的？
还有最重要的问题：
你认为黑盒重要，那你自己有没有做过白盒测试？ 不管黑盒白盒，都需要设计用例，编写用例，执行用例
个人认为黑盒用例设计必白盒用例设计难，黑盒用例编写比白盒用例编写易，黑盒用例执行比白盒用例执行难
黑盒比白盒难
黑盒测试 那可是半个架构师耶~白盒 说的难听点 代码工人而已~
一个是全局考虑
一个是局部问题分析
我就是来嘀咕两句~切切~……
[ 本帖最后由 尛蟲蟲 于 2008-11-28 11:46 编辑 ] 黑盒测试 完全是架构师的操作
白盒 说的难听点 代码工人而已
不敢苟同！
我也不想抨击谁是什么低级，没必要，因为我也曾做过黑盒测试，我也不想说白盒多么至高无上，更没理由，因为我现在做开发。
如果你认为黑盒是架构师，我不想反驳你，因为毕竟黑盒了解了业务的架构，但当你面对的系统足够大时，切记你再怎么黑盒你也不可能了解架构。如果你想当然认为白盒只是做做什么逻辑覆盖，做做什么条件、语句、路径什么的，那你更错了，因为白盒需要看你们做到什么程度，看你的责任有多重。我不逃避在迭代次数比较少的情况下，黑盒能更体现性价比，但性价比并不代表谁比谁难。白盒要考虑技术架构，毕竟测试代码，要调用大量的驱动和桩模块，更要虚拟大量的数据，当然还要保持数据及系统环境不会被代码所影响。白盒更要考虑业务逻辑，白盒的测试是为了什么？我Unit执行下来，以什么为正确标准呢，结果，对就是结果。为什么白盒没做太多功能测试的东西呢，因为涉及到前台的，比如我们写的html，ajax什么的，拿java代码是很难完成的。所以，在我工作中，我们的前台展现全是功能测试，业务逻辑、数据逻辑全是Junit。
当你一味的说代码工人的时候，你要想一下，白盒测试的基准是什么，是测试就不会不考虑业务。
谢谢！ 无论是黑盒还是白盒测试入手都容易，
但想要做得更深入那就要点本事了 白盒测试重要！
白盒测试包括了单元测试，单元测试要走读代码或者单步调试程序，这些好多都是需要开发人员完成的，在确认了单元测试到集成测试基本通过后才进行功能测试，性能测试，负载测试等等，如果白盒测试得不够全面，则黑盒测试根本发现不了像内存泄露，误差累计的错误，这些必须要白盒测试才能够查到的。黑盒测试人员无法替代。 49楼的观点太绝对
觉得白盒难，代码头痛..
:victory: 呵呵，我又来了，看大家观点．这次人比较少啊． 个人以为白盒比较难的，因为要先看懂代码，了解开发工程师的算法思想···所以比较难··· 刚入这行，目前只接触过黑盒测试，所以就不丢人现眼发表拙见了。不过我觉得guobin_it说得挺有道理的。
如果能把白盒和黑盒结合起来那不是更好吗？
原帖由 guobin_it 于 2008-11-18 13:07 发表 http://bbs.51testing.com/images/common/back.gif
举个例子：
比如一辆汽车发动机坏了，黑盒测试的人可能一听声音就知道是发动机坏了，高手的话还可以告诉你发动机的哪个部位坏了。但他可能解释不出这个部位的具体构造，也就给不出解决这个问题的方法。
白盒测试的 ... 黑盒不容易做,尤其是到后面! 好好理解什么是白盒测试吧
有机会就去做做白盒测试吧
去理解一下测试驱动开发吧
去看看国外的测试人员是不是都在那做功能测试吧
每次迭代前跑自动单元测试代码，一定是跑的单元吗，难道没有业务逻辑吗？
有很多情况不是不做白盒，而是代价太大罢了，没必要做，但不等于其他的。
个人工作感慨：
我在刚工作时，也是做功能测试的，但现在转开发了，公司要求自己做测试，我的所有测试，只要能通过代码实现，我都会选择Junit。包括插入数据、执行、校验、数据清理，当然，这些显然是要有业务逻辑在里面的。现在的web都将传统的三层增加到了四层、五层，单独划分出业务逻辑层，所以我在这里提醒那些认为白盒不会校验业务逻辑的人，仔细想想白盒都做什么，也不要把自己公司的白盒测试的层次类比到真正的白盒测试。
老说黑盒测试要正向测试、逆向测试，什么正向思维能力、逆向思维能力，难道白盒就不需要吗？
老说黑盒什么性能测试，难道白盒就不做吗？说的土一点，用的QTP、LR是什么，工具。底层是什么？代码，代码怎么做的？白盒能实现他的功能么？显然，能。
在某些公司功能测试人员的业务能力是比开发人员高，但这并不代表所有，因为有些人对技术感兴趣，而有些人对业务感兴趣。
PS：我03年毕业做测试，那时51Testing还没起来，你知道我周围有多少黑盒测试人员转行了吗？去问问吧！（性能、自动化除外，这两个是要接触开发的）
我没有恶意，写讽刺的帖子我也得不到什么好处，我也涉世不深，只是希望在论坛的每个朋友能有自己的人生目标，思考一下自己的行业价值。毕竟，我们都曾经测试过。。。。
谢谢！
