大家好我是饲养员，今天跟大家细说下什么是白盒测试。
在进行日常测试的时候，我们大部分时间花在手动的功能测试上，功能测试又可称为手工测试，官方一点的学名叫黑盒测试，当然作为测试工程师，我们一般俗称点点点。
黑盒测试是一种软件测试方法，它的主要目的是检查软件的功能和性能，而不考虑软件的内部实现和代码。在黑盒测试中，测试人员不了解软件的内部结构和实现，只能根据软件的需求文档（PRD）、用户手册或其他相关文档，来设计测试用例和执行测试。
在进行黑盒测试时，不需要看代码，而是直接根据需求文档编写黑盒测试用例，根据测试用例就可以进行业务测试。
那什么是白盒测试呢？
白盒测试是一种软件测试方法，它通过检查和评估软件代码的内部结构和实现细节来测试软件的功能、安全性和稳定性。在白盒测试中，测试人员通常具有软件开发和编程的知识，可以访问代码和系统的内部结构，以检查代码是否符合规范和标准，是否遵循最佳实践和设计原则。
对比黑盒测试和白盒测试的最大区别，就是测试工程师能否看到开发写的代码。白盒测试究竟该怎么做，在一直做点点点的同学心里一直是一个谜，其实白盒测试本来在业界并没有完整的方法论标准。看过许多软件测试相关书籍以及博客，大家了解到的白盒测试理论一般局限在白盒测试的分类以及 6 种常用白盒测试的覆盖方法。
若按照覆盖严格程度来看，语句覆盖< 判定覆盖 < 条件覆盖 < 判定条件覆盖 < 条件组合覆盖 < 路径覆盖，即在这 6 种覆盖方法中最严格的是路径覆盖。
看到这里对于新人小白来说，可能就会产生疑问了，做好白盒测试，是不是只要达到最严格的路径覆盖就行？理论能够指导实践，我们可以根据覆盖方法进行白盒测试，但不管是黑盒还是白盒测试，测试的目的都是在有限的测试时间内，尽量发现更多的 Bug，而不是追求更加严格的测试覆盖率。
那么做好的白盒测试的关键点到底是什么呢？抛出一个观点就是理解代码，换句话说就是能看懂开发写的每一行代码，并定位到有问题的代码行，至于是否要达到白盒测试中的非常严格的覆盖程度是次要的。
为什么会这么说？主要是因为看懂代码是发现 Bug 的最快方式，扫一眼就能知道这里会不会有 Bug，当然想拥有这样过眼就能发现问题的能力，需要掌握扎实的计算机基础以及看过几万甚至几十万行代码。另外开发写的代码当中，有的逻辑并没有分支，所以达到语句覆盖就行，个别存在多个分支的情况可以考虑加大覆盖程度，如到达条件覆盖，但达到更高的覆盖率意味着测试时间会拉长。
测试是否要去看开发的代码，是一个长久以来比较有争议的话题，持反对意见的同学认为没必要看，公司没要求，自己也看不懂，有问题直接抛给开发。
但从目前测试行业来看，以及微服务架构和前后端分离的流行，互联网大厂的测试早已经划分出一种测试角色，叫服务端测试，也称 SQA（Server QA），这种工种承接的日常测试工作，基本以接口测试，Code Review，以及后端代码的白盒测试为主，也是目前在测试行业里面发展相对前景较好的岗位。
综上，能够看懂代码对于我们测试来说，只有好处没有任何坏处，在就业环境如此差的今天，测试能看懂代码就是一道分水岭！
从看懂代码语法，再到理解代码，再到定位 Bug 到代码行，提供修改建议，是一个循序渐进的过程。
代码究竟怎么看才能快速发现问题，应该关注哪些测试点，拿一个比较典型的接口来举例子，下面是一段伪代码，描述了一个很常见的业务场景，如果 Redis 缓存中有数据，则读取 Redis 当中的数据，没有数据则读取数据库 DB 里面的数据。
如果要测试这段代码，需要检查 Redis 里面有数据的情况下，是否能正常从 Redis 当中读取数据。同理，需要检查在 Redis 没有数据的情况下，能否正常从 MySQL 当中读取数据。
为了便于验证数据，我们可以使用编程语言自带的打印函数，如各大编程语言当中的 print 函数，PHP 当中的 var_dump，或者调用代码框架当中已经封装好打印日志函数。
测试这段代码的核心关键是在于理清数据流，变量 var 从哪里来，接下来又会在哪些地方去使用，理清数据流同样也是白盒测试当中的关键点。
留一个思考题，假设在测试过程当中，发现 Redis 里面有数据，但是经过 Debug 后发现，代码逻辑走到了读取数据库当中的数据，这个问题产生的原因是什么？
在白盒测试当中，理解代码和理清数据流是做好白盒测试两个关键点，至于能够在白盒测试当中发现多少问题，取决于测试工程师对于技术的理解深度。
