黑盒测试和白盒测试的区别
```html 去年帮一个团队排查线上故障，黑盒和白盒测接口返回的测试数据莫名其妙少了一个字段。开发查了半天日志没头绪，区别最后我让他把那段代码的黑盒和白盒测中间变量打出来看看——问题出在一个条件分支上，某个边界值没覆盖到。测试这就是区别白盒测试干的事：你得看见代码里面发生了什么。而黑盒测试呢？黑盒和白盒测你只管输入账号密码点登录，登不上去就报bug，测试至于后端是区别查了数据库还是调了缓存，跟你没关系。黑盒和白盒测 说白了，测试黑盒测试是区别「用户视角」，白盒测试是黑盒和白盒测「开发者视角」。黑盒测试把软件当成一个不透明的测试盒子，你只能通过输入和输出来判断它有没有毛病。区别功能测试、界面测试、兼容性测试，大多属于这一类。测试人员不需要懂代码实现，照着需求文档写用例就行。比如一个计算器App，你输入2+3，期望得到5，实际得到6，那就是bug。至于它是用Java写的还是Kotlin写的，用了什么算法，黑盒测试根本不关心。 白盒测试则反过来，盒子是透明的，你能看到里面的逻辑结构、分支条件、循环路径。单元测试是最典型的形式——开发人员自己写测试代码，针对某个函数或方法，验证每条语句、每个判断分支是否按预期执行。我见过一个支付模块，白盒测试时发现某个if-else里，else分支写的是 两者的覆盖目标也不一样。黑盒测试追求需求覆盖率——需求文档里写的功能点，每个都要有对应的测试用例。白盒测试追求代码覆盖率——语句覆盖、分支覆盖、条件覆盖、路径覆盖，一层比一层严格。不过覆盖率这东西别迷信，我见过项目硬凑100%语句覆盖，结果一个空指针异常照样漏掉，因为测试用例根本没模拟null输入。 成本差异也很明显。黑盒测试用例设计相对独立，测试人员可以不懂编程，上手快，但用例数量容易膨胀，回归测试时跑一遍耗时耗力。白盒测试需要读代码、写桩模块、搭测试框架，前期投入大，但一旦跑起来，定位问题精准得多。有个做嵌入式开发的朋友跟我说，他们那儿的白盒测试能精确到某个寄存器的某一位有没有被正确置位，这玩意儿黑盒测试想都别想。 实际项目中，两者不是二选一的关系。单元测试阶段白盒为主，集成测试和系统测试阶段黑盒为主。但很多团队把白盒测试完全甩给开发，测试团队只做黑盒，结果就是开发写的单元测试往往只覆盖正常流程，异常分支全靠线上用户去踩。反过来，只做黑盒测试，遇到偶现的并发问题或者内存泄漏，你连复现都困难，更别说定位了。 我自己的习惯是：拿到一个新模块，先黑盒跑一遍主流程，心里有个底；然后翻代码，看关键路径和边界条件，补白盒用例；最后再把黑盒用例里那些容易出错的场景，对应到代码层面去验证。这样两边都不偏废。测试这活儿，说到底就是跟bug玩捉迷藏，黑盒让你知道哪里有坑，白盒让你知道坑是怎么挖出来的。return true，而实际业务逻辑应该是return false。这种错误黑盒测试很难抓到，因为触发条件极其特殊，但代码一读就露馅了。