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