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

广告SDK项目是为应用程序APP开发者提供移动广告平台接入的API程序集合，其形态就是一个植入宿主APP的jar包。提供的功能主要有以下几点：

- 为APP请求广告内容

- 用户行为打点

- 错误日志打点

- 反作弊

在项目推进的过程中。逐渐暴露了一些问题：

1. 项目团队分为上海团队（服务端）和北京团队（client），因为信息同步，人力资源等其它原因。服务端与client的开发进度非常难保持同步，经常出现client等着和服务端联调的情况

2. 接口文档不稳定，理解有偏差

3. 协议变化频繁，消息不同步

4. 缺少服务端测试环境，可模拟的真实广告内容太少

5. 协议字段太多，传统的测试用例设计方法easy出现遗漏，尤其是异常情况处理。测试完毕以后测试人员对字段覆盖率没有信心

协议字段演示样例图

{
     "ads": [{
        "action": {  "path": "" },
        "adw":920, 
        "adh":900, 
        "template": "",
        "action_type": 2,
        "adid": "67346778",
        "adm": "",
        "adm_type": 0,
        "deep_link": "",
        "impid": "nXcM_kqBGqL=",
        "tk_act": [""],
        "tk_imp":[ ""],
        "tk_ad_close": [""],
        "tk_clk": [""],
        "tk_dl_begin": ["" ],
        "tk_dl_btn": [ ""],
        "tk_dl_done": [""],
        "tk_dp_suc": [],
        "tk_ins": [ ""],
         "tk_open": [""]
       }],
        "errno": "0"
}

测试用例设计极easy受需求影响，更新起来非常麻烦，成本非常高

手工测试方法运行效率低，且easy漏测

手动测试过程

上述几个问题，当中1、2、3都会对我们的测试工作产生影响。可是属于项目管理范畴。不在本文讨论范围内。那么针对4、5、6、7几个问题，应该怎样解决呢？

首先分析一下问题：

Q: 缺少服务端测试环境，可模拟的真实广告内容太少

A: 因为服务端团队在人力上的不足，无法为我们提供测试环境。通过沟通协商，方法暂定为由服务端同事预先配置好线上广告物料，即固定的线上广告资源。能够覆盖提测的广告类型，在服务端完毕功能逻辑之前，先利用mock方式测试client的功能逻辑以及展示，此时client和服务端后台无需交互。

Q: 协议字段太多。传统的测试用例设计方法easy出现遗漏，尤其是异常情况处理

A: 制定一个可靠的测试用例设计策略，以最少的case覆盖最多的情况。

Q:测试用例设计极easy受需求影响。变更起来非常麻烦，成本非常高

A: 对测试用例进行拆分，分为正常返回情况和异常处理两部分。

正常的处理包含系统环境、网络切换、下载、轮播、缓存、正常打点、安装卸载、UI检查等等须要人工检查的情况，因此这部分我们先梳理checklist，先组内review，再约产品和研发一起review。确保需求的完整性，另外开发过程中的需求变更是不可避免的，对于需求的变化要做到实时更新case。常见分布式系统这部分case覆盖的点要足够全，而文字描写叙述要尽量的精简。确保更新起来能高速响应节奏的变化。而异常的部分。我们的做法是批量自己主动化生成case。生成策略会在以下具体描写叙述。

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