常见分布式系统 Mock+Proxy在SDK项目的自己主动化测试实战(6)

生成的case例如以下图：

有了强大的正则表达式，再加上多异常组合输入的支持。眼下已经全然能覆盖我们须要的不论什么场景，向开源致敬！

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

最初的版本号比较简单，结构大概是这种：

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

在阶段二我们攻克了几个问题：

- 实现内部循环请求广告，解决手工触发请求的问题

- 监控APP自身出现的crash和ANR

- 解决case失败后能够rerun，

- 解决中途运行中断能够rerun

- 因为一些广告请求失败会触发二次打点请求。因此我们须要把相应的case和打点请求结果匹配上，我们通过在request中添加caseID来解决该问题

- 解决多种广告类型不能连续一次性运行完，须要切换场景的问题

- 当出现期望结果与实际结果不符时，自己主动又一次运行该case 若干次（可配置），假设一直失败计为case失败

该阶段非常明显，我们遇到了运行速度的问题。因为广告种类的添加。我们的case达到了3400余条，因为还须要兼顾广告渲染完毕后的打点结果检查，运行全量case耗时达到了3个小时多。偏离了我们mock测试的初衷。因此如上图所看到的。我们用到了分布式结构。mock server能够通过client指纹信息来调度和发送任务给指定的手机，把case和设备紧密连接在一起，避免反复运行同样的case。

另外我们把config、case、期望结果、运行结果等诸多信息全部迁移到database中，一方面解决频繁的文件读取问题，还有一方面攻克了分布式调度跨server的问题。

截止眼下，我们的测试数据是这种：

Case总数 发现BUG 遗漏的异常处理

前面提到的问题，假设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的强依赖关系

- 正常的功能测试验证

- 业务逻辑产生的漏测率统计

诸如此类的问题还有非常多非常多。尤其是结合项目自身特点，就会更加复杂，希望能通过我们的探索之路给同行们很多其它的启示。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-81263-6.html