黑盒测试 vs 白盒测试

测试是一个很古老的话题，几乎有了开发就有了测试。但是随着 DevOps 和敏捷的风潮之后，测试到底应该谁来做、需不需要独立的测试人员、测试到底应该关注什么，反而越来越模糊。至少在最近的几次周会和评审会上，发现大家在这些方面还是有很多的不明确和分歧。

首先，我们先回到测试的目的上。软件测试的目的，和制造业测试的目的是一样的，就是验证交付物的质量。在制造业上，如果是无损的，可以对每件成本做测试；如果是有损的，采用抽样。对于软件来说，没有啥有损无损的区别，因为代码是可以无限复制的。同时，部署在不同机器的代码理论上也不会有什么太大的区别，可能环境因素会造成一定的差异。这里只需要在启动的时候加入轻量的自检流程即可。

软件的测试，主要还是集中在功能的验证上。在开发、集成、验收、发布阶段，都可能有不同角色参与的，视角不同的测试验收工作。

我们要验证交付物的质量，验证软件的功能是否正确，有两种方式去保证：白盒测试和黑盒测试。这两者的区别，我们可以拿买手机来举个例子。所谓的白盒测试，是我了解手机的各个组成，MPU 多少、GPU 多少、内存多少、屏幕分辨率多少、摄像头参数多少、基带芯片参数、操作系统是啥，然后一个个按照我自己要求的参数去做验证。黑盒，就是我对这些具体的内部结构和配置参数都不了解，我只知道我要拿手机来做什么，比如我要能用啥啥啥功能，玩什么游戏要到怎么一个流畅度、拍照片要达到什么效果，然后我拿这些功能一个个去试，符合要求的就是我要的。

软件测试也一样，白盒测试，就是按照我的设计说明书，按照包、类、方法、逻辑一层层往下拆解，验证实现是否符合设计的要求。所以白盒测试是在验证设计，不是验证功能。只做完白盒测试，有可能是一个设计非常优秀、运行稳定、bug 很少的没有用的垃圾。

而黑盒测试，是在验证的功能。我不管你内部是怎么实现的，我也不管你内部的代码是不是写得优美，不管你的表结构是设计合理的还是就一个大 json，甚至我不管你是 for 循环三次还是拆开来写了三次一样的代码，我只管功能是否被正确实现（特定的输入是否有符合预期的输出、用户交互是否符合产品设计、响应速度是否符合要求、用户使用上是否有障碍）。

再举个例子。比如我有一个下单功能，用户在界面上输入信息，确认后存储到数据库，然后回显到界面上，后续用户可以根据 orderId 反查询。

对于黑盒，我只下一个单，看一下回显，根据 orderId 查询一次，如果都符合设计要求，同时在性能和交互上也 ok，那就过了。

对于白盒，我的验证方式是将创建、查询拆开验证的。创建的时候需要验证输入的信息是否争取存储到数据库中，回显到时候需要验证对应 orderId 的 DB 数据是否正确被映射成对用户的输出。同时需要验证 orderId 不存在的情况是否正常的被处理。

比如我写代码的时候写了一个 bug：将 order 中的金额和数量两个字段落库的时候落反了，金额存在了数量里，数量存在了金额字段；查询的时候也是反着查的。这个时候，功能没有问题，黑盒测试是 pass 的。但是对于白盒测试，这个不符合设计，需要被定义成 bug。

明白了黑盒和白盒测试的区别，我们也就明白了测试分工的原则。白盒测试是在测试设计，还是属于开发的范畴，所以白盒测试应该开发来完成。大部分的白盒测试，都是通过单元测试来 cover 的，平时也会构建 CI 来反复的验证。对于系统和系统之间的交互，基于服务契约解耦通过契约测试来 cover：https://xie.infoq.cn/article/a1896759d7f4175a9ecb30125。端到端功能是否可以完整的跑起来，针对产品的预验证，可以交由独立的测试团队完成。

而对于黑盒测试，这个是在验证产品的功能，最终需要是产品来做验证，如果是交互相关的可以由 UED 来验证。同时对于一些特殊的验证，比如性能、错误处理等，可以由专业的测试人员来负责。

总之，我们可以将测试做如下划分：

| df| df |

| ----------- | ----------- |