360Qtest专栏 自动生成 case 在 SDK 项目的 mock 测试中的应用 (使用篇)

simple · October 19, 2016 · Last by 测试小书童 replied at November 09, 2016 · 1704 hits

结构流程设计


在整个测试过程中,我们唯一需要人工介入的就是字段值的赋值以及跟error code的对应关系设计,协议字段的取值会受业务影响,暂时无法通过自动化的方式来进行。流程如图所示:

阶段一


最初的版本比较简单,结构大概是这样的:

阶段二


原本的设想是想绕过广告宿主直接调用SDK的API请求广告,从而节省一部分时间,且更容易自动化,但是由于广告SDK本身特殊的设计,这个想法无法实现,因此当时的设计是通过触发APP按钮点击发送request给SDK,再由SDK发送加工后的请求到proxy server,再经过mock server处理数据以后,返回给客户端来显示广告。在此过程中,彻底抛弃了Fiddler重定向的传统做法。

在阶段二我们解决了几个问题:

  • 实现内部循环请求广告,解决手工触发请求的问题
  • 监控APP自身出现的crash和ANR
  • 解决case失败后可以rerun,
  • 解决中途执行中断可以rerun
  • 由于一些广告请求失败会触发二次打点请求,因此我们需要把对应的case和打点请求结果匹配上,我们通过在request中加入caseID来解决该问题 解决多种广告类型不能连续一次性运行完,需要切换场景的问题
  • 当出现期望结果与实际结果不符时,自动重新运行该case 若干次(可配置),如果一直失败计为case失败

阶段三


该阶段很明显,我们遇到了执行速度的问题,由于广告种类的增加,我们的case达到了3400余条,由于还需要兼顾广告渲染完成后的打点结果检查,执行全量case耗时达到了3个小时多,偏离了我们mock测试的初衷。因此如上图所示,我们用到了分布式结构。mock server可以通过客户端指纹信息来调度和发送任务给指定的手机,把case和设备紧密连接在一起,避免重复运行相同的case。
另外我们把config、case、期望结果、执行结果等诸多信息全部迁移到database中,一方面解决频繁的文件读取问题,另一方面解决了分布式调度跨server的问题。

目前的收益


截止目前,我们的测试数据是这样的:
| Case总数 | 发现BUG | 遗漏的异常处理 |
| -------- | -------- | -------- |
| 3498条 | 77个 | 331个 |
前面提到的问题,如果error code尚未明确,case应该如何匹配呢?我们的做法是设定一个基准error code,当运行结果出来后,会有实际结果与期望结果不符的case,拿去和开发对一下就可以,而调整error code期望结果以后,重新生成case也只不过分分钟的事。

我们的执行时间:

收益:协议变更时,只需要修改最开始的存放字段值的文件,后续的建模、case生成、期望结果填充、执行测试用例全部自动完成,测试人员查看运行结果即可


问题总结


由于我们也是第一次在mock测试中实践自动化构造测试数据,包括用到的pairwise模型的合理性和准确性,都属于初次尝试,目前在项目中取得了一定的效果,但是也遇到了很多的困难,个中酸楚不足以一一道来,同时架构和流程还有很多优化空间。

目前依然留存的问题包括:

  • 自动生成case中,int、string、date等字段提取公共case,比如特殊字符、空、null、js等常规异常检查
  • 更复杂的逻辑,比如关联字段依赖、加密字段、随机数、MD5、token等情况
  • 非http(s)的自定义协议
  • 分布式调度的更大规模的使用
  • SDK的自动化测试对于APP的强依赖关系
  • 正常的功能测试验证
  • 业务逻辑产生的漏测率统计

诸如此类的问题还有很多很多,尤其是结合项目自身特点,就会更加复杂,希望通过我们的实践总结能给同行们一些启发或借鉴。

共收到 3 条回复 时间 点赞

按照惯例,需要贴代码,不过我想贴nodejs的规则代码,一来在这里没有任何参考意义,二来篇幅太大,所以就没贴了。

#1楼 @simple 能把代码放到github上不

—— 来自TesterHome官方 安卓客户端

谢谢,很好的思路,分布式这里能详细介绍下吗?

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up