左移白盒测试实践

1. 什么是白盒测试

白盒测试也称结构测试或逻辑驱动测试， 它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否 与预期的状态一致。

真正的白盒测试是细致的、有组织的，也是费时的。结合自身的业务情况，在笔者业务中开展的白盒测试并不是穷尽覆盖各种逻辑，而是使用分层的思想思考从代码层面如何更多的发现问题，通过在业务功能测试的基础上结合代码去发现代码逻辑中的问题，从而提高整体测试的有效性和效率，主要有方式有：

• 通过CR或者工具从代码中发现问题
• 基于CodeReview优化用例
• 基于功能行覆盖率补充验证

2.白盒测试实践

2.1从代码中发现问题

发现代码问题的一个轻量的手段是通过静态代码扫码进行，很多发布上线的回滚是由NPE造成的；目前笔者所在已经开展了静态代码扫描，对于空指针等规则进行处理，通过代码扫描能够很好的发现问题，减少测试成本。

通过提测前查看开发代码或者参加CR能够提前发现开发代码中的问题，和直接进行测试相比，一些代码问题是隐蔽和有一定条件触发的，从CR中发现往往成本比较低
比如死循环问题，查询未继续翻页造成死循环，当数据量多到需要翻页时触发

如何有效的做CR，一些通用的考虑过点在许多技术文章或者大厂实践中有提到，不再此处赘述。结合笔者业务的CR情况，如下问题是需要重点考虑：

1. 分页问题
   是否需要分页，分页是否正确，比如商品、店铺的查询分页
2. 循环问题
   尤其是对于使用while的，需要防止死循环
3. 日志打印问题
   日志的级别需要符合实际情况
4. 异常
   确认异常是否需要处理，如何进行返回
5. 事务
   很多时候事务特性不会单独去测或者很难模拟，所以可以关注下事务是否生效
6. 消息
   应用之间的交互往往通过消息进行，消息的测试过程中需要考虑:

• 发送消息不需要幂等
• 消息发送日志怎么打
• 发送消息失败怎么办？需不需要中止业务流程？
• 消息的隔离等问题
• 消息乱序，笔者所在的业务依赖支付消息，其中存在乱序的可能，需要确认是否有相关处理

2.2基于CodeReview优化用例

就算不是为了发现代码问题，作为测试也需要关注开发的实现，review开发的代码，从而获得多种信息，通过阅读代码来优化测试执行，见通过阅读代码来优化测试执行

自己的方案设计是否有遗漏的地方

根据PRD和技术方案测试人员进行方案设计和用例设计，方案和用例设计是渐进明细而不是一蹴而就的，一方面方案是比较抽象，而代码逻辑更具体一些，通过查看代码能够思考到之前忽略的一些点；另一方面开发在编写代码的过程中也是渐进明细的，一开始一些细节和逻辑没有考虑到或者考虑清楚，在开发过程中进行了增删和修改，所以之前测试的设计可能和实际逻辑存在了出入。

所以，查看下开发代码有着一系列益处：

• 很多细节在技术方案评审中如果没有特别清楚，可以通过代码review补充了解，比如校验逻辑有很多检查点，当初测试用例设计的时候可能有所忽略。
• 如果实际的方案和之前的有所出入，那么用例可以进行更新，减少了实际测试时才发现有问题的改正和确认成本。
• 优化测试用例。通过等价类划分等方式可以优化用例，减少无效和冗余用例，通过查看开发的代码，确认之前的等价类划分是否准确，比如像业绩提成这样逻辑比较复杂而且测试因子比较多的场景，搞清楚哪些因子是前置处理哪些是后置处理，哪些因子之间是相互独立的，有助于优化用例的执行

获取能够帮助测试的一些细节信息

在测试过程中需要知道白名单，尤其是业务中有很多判断白名单的地方以及很多特性开放给特定商家使用所以需要用到白名单，可以通过代码中确认。

在测试过程中需要帮助定位问题，如是否命中逻辑以及报错信息，所以需要通过日志以及对应的代码进行确认。

在测试过程中需要知道数据流向，执行时可以确认数据是否正确，所以需要知道对外调用的接口、使用的topic和数据库表以及字段含义。

2.3基于功能行覆盖率补充验证
通过功能测试后，如何确保测试已经完全了呢，一方面需要确保测试的场景是完全的，另一方面需要确保已经实现的逻辑是经过充分测试的。

目前ops提供了功能覆盖率的功能，不管是手工执行或者自动化工程执行，都会记录对新增代码的覆盖，基本上是基于jacoco进行改造实现增量代码

如果过低，需要确认下代码未覆盖的原因，需要关注是impl里面主要逻辑的覆盖情况

需要关注一些典型遗漏的情况，如判断条件分支未进入，异常情况未覆盖，然后分析是否需要补充用例来覆盖该情况。