后台服务项目的白盒测试之旅

本文来自阿网易云社区

作者：孙婷婷

白盒测试起因

17年下半年我开始介入部门新项目的服务v2版本的功能测试。刚接手项目时，感到十分头疼，首先它不像我刚接触测试时做的to C端项目，主要是页面展示操作，黑盒测试足够；其次它不像我刚来网易介入的图像项目，主要通过接口判断图片属性，撸撸产品需求也能通过黑盒测试覆盖功能。

相比之下新项目的项目特点则是：

A.    是一个服务端项目，主要是接口测试；

B.    接口参数需要特定的加密格式加密后传输，服务端需要解密后处理，数据不透明；

C.    接口参数量多达至少30个，接口最后返回类型多达30种，逻辑复杂；

 总结起来，它就是一个数据不透明、逻辑复杂的后台接口服务项目。刚拿到项目的时候我基本处在无从下手的阶段，加密解密太复杂，我连接口测试都不会实现。被逼无奈，先把开发的单元测试用例拿来跑一跑，边跑边了解摸索，慢慢就走上了白盒测试的道路。

测试摸索

我在测试过程中，主要按照通过数据追溯主干，需求用例发散旁支，bug追因查看细节的思路，来一步步抓大放小学习开发代码，同时完成测试任务。

1.追溯主干：

在项目介入过程中，我喜欢通过关注数据的流动来快速了解一个项目的主要实现过程，即撸清从调用一个接口传入参数到获得结果这个过程中数据经过哪些模块，经过加工后落入哪个存储模块。

举例来说，在本次测试摸索过程中，首先梳理项目各个接口的主要功能、梳理接口参数和返回值。由于项目的主要功能接口是collect接口和check接口，则在代码层主要关注这两个相关模块。

 

接着根据接口参数的数据流向走读或者DEBUG代码，查看在主干链路上的流向。由于项目的主要参数是收集的设备和行为信息CheckData，就可以重点关注CheckData的数据处理。在实践中，遵循从上层深入底层的原则，本项目中都是http接口，则可以从代码Controller层入手，跟踪CheckData数据经过哪些系统、模块处理，是否经过kafka、redis、nos等模块，最终存入何处。这步操作，对于后续在测试过程中进一步校验测试数据处理是否正确会有很大帮助；同时面对分布式系统，能让你快速了解整个项目的模块、依赖和架构，分分钟画出系统架构图。

2.发散旁支：

在接触接口后，可以在功能用例的基础上查看重点需求代码发散旁支，了解需求细节，查看或者跟开发讨论了解具体实现方法。结合测试用例，可以边测试边了解代码，补全用例没运行到的代码场景。例如下图中在测试collect接口功能时，已经通过梳理主干看到代码中参数会被解密后解析，此时就可以详细去查看数据处理方法decode和parse，增加些解密解析中的异常场景，也便于后续校验传参是否合理、解析是否正确等。

3.bug追因查看细节

当测试过程中输出结果不符合预期却又不能肯定定性为bug时，就是白盒测试上台的最好时机啦。将项目配置成远程debug模式，复现问题场景，在触发场景过程中单步调试代码，查看代码实现细节，确认每一步是否符合预期最终定位问题原因。将结果自信反馈给相关开发。

对于DEBUG这个过程，没有接触过远程DEBUG的小伙伴，可以首先尝试把代码下载到本地review代码；review熟了可以求助开发，帮着先把代码在本地跑起来进行本地debug；当本地debug玩的飞起的时候，远程debug就也不是问题啦~（为了避免一些环境配置问题，测试环境测试还是比本地环境测试靠谱的）

可以参考二组小伙伴宋亚敏写的远程debug配置：http://ks.netease.com/blog?id=8113

总结：

完成白盒测试，首先建立在非常了解需求的基础上，其次，对于代码有一定的热情，最后也要熟悉java基本知识（如果开发使用其他语言，还需要了解相应的技术知识）。不过还没上道的小伙伴也不用心急，会看到这里，说明你也是感受到了代码的迷人之处准确尝试啦，平时注意积累技术知识，拿一个合适的项目介入实践，白盒测试并不是一个遥远的话题。

在测试实践过程中，由于项目测试确实投入了大量的时间和精力，让我途中质疑过白盒测试的意义，同一个bug，用功能测试方法能否测出来？是否更节省时间人力呢？认真思考后我觉得白盒测试作为一个高技巧的测试手段，在这个过程中我还是收获更多的：

1.     对于业务，有了更加深刻的认识和理解，在和开发产品沟通的时候能更好的传达双方的需求，也获得大家的认可；

2.     技术实力提升，白盒测试虽然增加了阅读代码的时间投入，但是减少了bug沟通成本，让我们有更多的机会去了解开发的技术，扩充技术知识面，提升测试信心。

当然，这个过程确实投入了大量的时间，有些异常顺着开发思路也容易造成异常漏测。不过我觉得这不全是白盒测试的锅，更多的是我一开始黑盒用例设计不完善以及过多依赖白盒的原因，因此以后项目测试中对于多种测试方式的使用分配还需要再磨炼。

最后，以前QA向开发提bug时对话是这样的：

QA：你这个功能实现好像有个bug……

开发gg：什么bug，你环境是测试环境吗，代码有重新部署吗？

QA：最新的测试环境……

开发gg：数据发的对吗？参数接口有没有调错？

QA：确认了好像没错

开发gg：那你重现一下试试？

QA：好……

现在的对话则是这样的：

QA：你这段代码逻辑跟需求不符啊

开发gg：啊，是的是的，我改一下

QA：你这段代码是不是粗心了哇，true和false弄反了哎

开发gg：哎呀好像是的，我改一下

（彩蛋：）

开发gg：你们这边有没有自测用例，让我先自测一下看有没有问题哦~~

最大收获：无形之中，我已经推动了开发自测啦！！

网易云免费体验馆，0成本体验20+款云产品！

更多网易研发、产品、运营经验分享请访问网易云社区。

相关文章：
【推荐】 盘点大数据在游戏行业中的应用