白盒测试和黑盒测试往往是项目中最受争议的两种测试类型，每个人偏爱各不同。现实生活中行业人员大多喜欢白盒测试而忽视黑盒测试，那么项目中又应该如何平衡这两类测试呢？我们先来看两个案例。
案例一：
某移动互联网企业项目正在匆忙的进行中。由于项目的需求，需要招聘若干测试工程师，其中小张因为白盒测试经验丰富而被录取。项目进行过程中，小张搭建了很完善的白盒测试框架并且用例覆盖度也很高，自信满满的等待着项目圆满结束。项目结束后，合作的客户企业以及用户拿到软件之后大为吃惊，产品功能和界面有多处与需求不符，故项目最终失败告终。
案例二：
某企业大型ERP系统因新需求需要重新定制。整个项目过程中，多名测试工程师均仅采取黑盒测试的方式，项目最终因系统定制很人性化而圆满告终。但好景不长，系统在正式使用的过程中遭遇了多次数据处理错误或崩溃，原因正因为测试过程中并没有覆盖到各种实际场景，最终这套系统也因此而不得不重新开发。
上面两个案例也许比较极端，但却在实际项目中经常发生。在一个项目中黑盒和白盒并没有一个绝对的比例，也没有优劣之分，需要根据具体项目的背景或不同的阶段选择合适的测试策略。
在项目产品拥有很多模块，而每个模块处于刚刚开发的阶段的时候，产品模块并不具有界面或完整暴露的接口，从而开发人员开发完毕只能通过白盒测试进行自测。此时的测试更多的会覆盖到模块中每段代码的逻辑以及判断路径，从而在代码结构内部保证了质量。
产品达到一定完成度之后，可以通过黑盒测试对于产品的界面以及模块合并之后的功能进行测试。黑盒测试侧重点则更关心产品的界面显示、功能是否与需求说明书相符，操作体验是否人性化。很多产品界面显示是否友好远远比功能重要的多。
使用黑盒白盒的策略除了与项目阶段有关，还有项目背景有关。一些相对来讲用户群很大，产品集成成本并不大的项目，黑盒测试占的比例相对就会很大。比如各种平台的应用程序、企业系统等。而相对来讲一些大型项目，比如航空航天，白盒测试就必不可少，并且颗粒度需要更细，而黑盒占的比例就会相应减少，同时大大减少了测试的成本。