酒店后台白盒测试实践

随着敏捷项目流程的推广，迭代节奏越来越快，对测试人员的技能要求也越来越高，酒店测试组在这种快节奏的环境中，既要做到满足上线节奏，测试质量又不能下降。通过工作中的摸索和琢磨，尝试用白盒测试解决这些问题，目前取得了一定的效果。...



背景介绍： 随着敏捷项目流程的推广，迭代节奏越来越快，对测试人员的技能要求也越来越高，酒店测试组在这种快节奏的环境中，既要做到满足上线节奏，测试质量又不能下降。通过工作中的摸索和琢磨，他们尝试用白盒测试解决这些问题，目前取得了一定的效果，今天分享的就是白盒测试在工作中的应用。



功能测试常见问题

看看下面这些传统功能测试问题，是不是似曾相识，也让你在工作中几度抓狂：

1、开发修改了底层代码，影响业务场景比较多，需要测试进行全流程回归；

2、重构的项目，接手的开发对以前的功能不了解，无法准确产出影响范围，测试只能根据开发整理出来的功能点进行测试，经常会产生遗漏；

3、临时插入的紧急需求，需要紧急上线，测试时间短质量难以保证；

4、业务逻辑功能验证没问题，但是上线后总是出现没考虑的异常场景，例如空指针、内存溢出等；

5、讨论设计方案的时候，因为不了解开发实现，测试无法给出建设性的建议；

6、测试环境出现了问题，无法定位和解决，只能依靠开发同学来处理；

7、发现了bug，只能给出bug产生的过程以及结果，无法进行问题定位；





探索过程

酒店测试组从2016年开始白盒测试工作，借鉴了行业大公司的成功经验，在小组内部长达一年的摸索实施后，从2017年Q3开始全面推广至今，已经与现有的敏捷项目流程融合。

1、白盒测试-codereview的探索

2016.Q1



在订单API敏捷小组内推动codereview开发增量提交代码的流程，组内qa阅读代码能力有限，需要和开发进行一对一review

2016.Q4



组内QA对.net代码结构熟悉，可以独立完成.net代码的review，开始尝试对重构的java系统进行代码review

2017.Q2



订单API小组內已经形成codereview流程，敏捷小组内全部QA成员可以独立进行codereview，快速发现bug并跟踪bug

2017.Q3



推广到酒店后台所有敏捷小组qa，组内进行分享培训，先从diff做起熟悉代码。Q3末50%的测试可以通过diff做代码review发现bug

2017.Q4



组内继续推广，q3对代码不熟悉的同学经过一个季度的积累，q4看代码能力有了质的突破，除了新人对白盒测试暂时没要求外，其余所有qa都可以进行coderview。代码能力有很大提高后，本地起服务打点定位bug

2、白盒测试-静态代码扫描的探索

2017年08月



在订单API敏捷小组内推动静态代码检查流程，测试成员尝试用findbugs插件扫描代码，对于新产生的静态代码Bug录入并跟踪

2017年10月



推广国内酒店后端各小组使用静态代码检查技术，使用findbugs PMD等插件结合实际项目中发现的问题整理静态代码检查规则。

2017年12月



梳理完成PMD静态代码扫描规则，并和开发一起review 1级和部分2级规则，达成共识，开发提交代码后先自行进行规则扫描，规则扫出的规则都需要解决



案例分享

我们以三个典型的通过白盒测试发现bug的案例做简单分享，希望能让大家了解到白盒测试应用对我们测试工作的价值。

1.  代码review发现实现方式的缺陷。虽然功能正确，但是会存在潜在的性能问题

bug编号：36929

Bug标题： [超时取消定时任务重构]codereview 判断订单支付类型和状态不应该取orderpaymentmain表，应该取orderpaymentmaindetail中房费的支付状态和类型

期望结果：应该查OrderPaymentMainDetail表

2.  代码review发现功能逻辑错误

Bug编号：36309

Bug标题： 【GetSupplierInfoBySupplierIDInt】subbranchcode没有赋值，实际写成了给subbranch赋值数据库中subbranchcode

重现步骤：



期望结果：红色框内的字段替换为subbranchcode，给subbranchcode赋值。

3. 静态代码检查发现功能测试很难发现的空引用

Bug编号：36590

Bug标题：【UpdateInfoForWeb接口重构】静态代码检查，变量可能存在空指针异常

重现步骤：



期望结果：获取guests的对象前先判空



白盒测试成果展示

白盒测试成果主要体现在两方面。一方面是bug数量。从下面两张图表中可以看到，白盒测试应用一个季度后，白盒测试发现bug占比从2.9%提高至11.2%并持续保持。另一方面，白盒测试降低了很多隐性成本，测试人员在实际工作中深入了解开发实现方式，提高测试效率和质量，测试工作的漏测率自白盒测试实施后一直保持零记录。







推广心得

今天的分享如果你感觉对工作有帮助，可以按照我们的推广心得一步步在工作中推广，只要把握好前提条件，介入时机和使用场景相信你们团队推行白盒测试也会很顺利。

前提条件：
1. 有一定代码基础，可以看懂开发代码；
2. 了解系统实现架构；
3. 开发提供接口定义和接口地址；

介入时机：
开发提测后，测试就介入，打开开发代码对代码进行codereview。静态代码扫描适合代码基本稳定后再执行。

适用场景：
服务端的测试任务都适用，尤其是一些紧急上线、底层框架改动、重点项目更适用，方便测试人员评估影响点和回归范围，减少测试工时，提高测试质量；

    关注 同程研发中心