白盒测试也称结构测试或逻辑驱动测试， 它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否 与预期的状态一致。
真正的白盒测试是细致的、有组织的，也是费时的。结合自身的业务情况，在笔者业务中开展的白盒测试并不是穷尽覆盖各种逻辑，而是使用分层的思想思考从代码层面如何更多的发现问题，通过在业务功能测试的基础上结合代码去发现代码逻辑中的问题，从而提高整体测试的有效性和效率，主要有方式有：
发现代码问题的一个轻量的手段是通过静态代码扫码进行，很多发布上线的回滚是由NPE造成的；目前笔者所在已经开展了静态代码扫描，对于空指针等规则进行处理，通过代码扫描能够很好的发现问题，减少测试成本。
通过提测前查看开发代码或者参加CR能够提前发现开发代码中的问题，和直接进行测试相比，一些代码问题是隐蔽和有一定条件触发的，从CR中发现往往成本比较低
比如死循环问题，查询未继续翻页造成死循环，当数据量多到需要翻页时触发
如何有效的做CR，一些通用的考虑过点在许多技术文章或者大厂实践中有提到，不再此处赘述。结合笔者业务的CR情况，如下问题是需要重点考虑：
就算不是为了发现代码问题，作为测试也需要关注开发的实现，review开发的代码，从而获得多种信息，通过阅读代码来优化测试执行，见通过阅读代码来优化测试执行
根据PRD和技术方案测试人员进行方案设计和用例设计，方案和用例设计是渐进明细而不是一蹴而就的，一方面方案是比较抽象，而代码逻辑更具体一些，通过查看代码能够思考到之前忽略的一些点；另一方面开发在编写代码的过程中也是渐进明细的，一开始一些细节和逻辑没有考虑到或者考虑清楚，在开发过程中进行了增删和修改，所以之前测试的设计可能和实际逻辑存在了出入。
所以，查看下开发代码有着一系列益处：
在测试过程中需要知道白名单，尤其是业务中有很多判断白名单的地方以及很多特性开放给特定商家使用所以需要用到白名单，可以通过代码中确认。
在测试过程中需要帮助定位问题，如是否命中逻辑以及报错信息，所以需要通过日志以及对应的代码进行确认。
在测试过程中需要知道数据流向，执行时可以确认数据是否正确，所以需要知道对外调用的接口、使用的topic和数据库表以及字段含义。
2.3基于功能行覆盖率补充验证
通过功能测试后，如何确保测试已经完全了呢，一方面需要确保测试的场景是完全的，另一方面需要确保已经实现的逻辑是经过充分测试的。
目前ops提供了功能覆盖率的功能，不管是手工执行或者自动化工程执行，都会记录对新增代码的覆盖，基本上是基于jacoco进行改造实现增量代码
如果过低，需要确认下代码未覆盖的原因，需要关注是impl里面主要逻辑的覆盖情况
需要关注一些典型遗漏的情况，如判断条件分支未进入，异常情况未覆盖，然后分析是否需要补充用例来覆盖该情况。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。