搜狗输入法白盒测试的“暴力与美学”

背景：

在输入法白盒测试中我们使用过单元测试、接口测试、集成测试等方法。通过在输入法项目中使用这些方法可以保证我们的输入法代码底层函数的功能正确性。但是经过一些线上问题的分析我们发现还有一些问题是单元测试等无法发现的或者含义发现的，而往往这些问会造成输入法崩溃或者停止响应。提前发现和解决这些问题就成为我们保证输入法质量、提升用户口碑的关键。

哪些问题是单元测试或者其他白盒测试方法难以发现的呢？

1. 跨进程访问

2. 多线程同步、异步运行

3. 共享内存

4. 堆破坏

5. GDI、内存泄露

6. 其它

由于目前白盒测试的有如产出比相对较低，在有限的时间内白盒测试难以覆盖全部的这些问题，所以需要一种折中的方法既保证输入法的线上质量有保证项目版本的快速迭代。

测试方法：暴力测试

所谓的暴力测试是指不需要完全了解代码的实现，对一个功能的输入进行机械的模拟，多个功能随机并发的执行等，然后对一些关键指标进行监控，长时间部署运行达到测试目的。

例如输入法启动子功能测试，我们调用输入法代码把多个子功能封装成多个可以独自运行的脚本。然后让这些脚本随机并发的执行发现程序问题。

如图：代码程序执行入口

如图：代码例子一个可执行的脚本

如图：监控关键指标

如图：运行过程中截图

结果分析：

通过以上“暴力测试”方法。编写测试用例的时间只为平时白盒测试时间的20%。但是发现大量的问题，如程序崩溃问题30个、GDI内存泄露问题4个、内存数据遭到破坏的问题3个等，效果明显高于之前的纯白盒测试方法。

这种介于白盒测试和自动化工具中间的测试工具的复用性也要由于自动化工具，维护成本较低，回归测试中的应用性也较好。

结论：

以上所描述的“暴力测试”方法还是有局限性的，具体应用需要结合项目进行具体分析。

从应用上来看这个方法可以帮助我们在段时间内发现一部分问题，但是不够深入，发现问题也不容易进行定位。把这种方法与白盒测试相结合，根据项目的具体时间安排去选择和取舍适应的测试方法。

原文链接

如需转载该篇文章，请注明来自“搜狗测试”