从APP基础库或SDK升级探索如何做好回归测试-京东云开发者社区

### 1 前言

APP进行基础库升级、SDK替换时，会影响业务代码，但不改变业务逻辑，此时全量回归成本较高，且容易造成场景遗漏。本文旨在通过对新老版本的传参进行DIFF的方式暴露问题，降低人工成本。

### 2 痛点

京管家APP更换定位SDK时，根据研发修改范围、SDK调用模块确认了测试范围，关联功能用UI自动化做了回归测试且测试场景全部通过。但是，后续手工测试过程却发现一个问题，因SDK中的一个方法造成传参中设备号deviceId的值为空。而deviceId不会影响功能执行，甚至对运输侧的流程都没有影响，自动化场景校验中自然不会考虑这个字段，这个字段是在同步路由系统数据时被使用。此时，如果是新人或者对整个流程场景不熟悉的人，极易遗漏这个场景。基于这个需求，我认为对APP传参进行校验是很有必要的。

### 3 解决思路

#### 3.1 丰富UI自动化场景

因基础库&SDK升级这种需求的特殊性--不涉及业务逻辑变动，此时用UI自动化测试的效率较高。在日常需求冒烟测试及功能测试前期编写UI自动化，需要保证用例至少可以覆盖正向流程，并不断丰富测试场景。

#### 3.2 使用工具进行参数对比

用新老版本APP分别进行同样场景的功能测试，通过工具找出不一致的接口或传参，实施步骤：

1. 准备测试数据，保障新老版本的测试数据一致
2. 本地配置mitmproxy代理并设置过滤条件
3. 执行过程中记录app请求及传参
4. 执行结束后对比接口及传参是否一致

### 4 方案设计

#### 4.1 环境配置

- 环境准备：python3.x、mitmproxy、openpyxl
- 数据准备：测试用例、测试数据
- 其他：设备安装mitm证书

#### 4.2 工具整体框架

![](//img1.jcloudcs.com/developer.jdcloud.com/ed4de1e3-fc92-47b1-9c30-913e914c6ba420220825152611.png)

### 4.3 兼容性

- 针对UI自动化脚本，兼容所有框架类型
- 无UI自动化脚本时，可通过手工执行用例的方式记录数据、分析数据

#### 4.4 优劣势分析

**优势：**

- 基于UI自动化执行时，操作简单、效率高：mitmdump -s filter.py -p port启动代理后，执行自动化，自动化结束后分析数据。
- 代理启动后可修改filter.py脚本以适应不同场景，脚本自动加载，不需要重新启动。

**劣势：**

- 基于手动执行时，启动代理，手动执行，执行结束后需手动触发数据对比方法。

### 5 实践案例

#### 5.1 已应用到京管家融合项目

背景：京管家融合第一期是基础库的融合，影响范围较大，但不涉及业务代码的改动，符合该方案的应用场景。

数据准备：京管家日常需求中已经积累了包含运输业务主流程的UI自动化脚本。

1）UI自动化用例：针对车队长、自营司机&三方司机、承运商调度、航空代理员等角色，获取任务、正在进行、异常管理等模块共梳理测试场景70条。

```python
def test_execute_swing_assignment_with_self_employed_driver():
    """自营司机：执行传摆任务"""
    dataf = execute_regional_assignment_with_self_employed_driver_data()
    vehicle_number = dataf.get('vehicle_number')
    carrier_driver_code = dataf.get('carrier_driver_code')
    # 获取最大里程
    mileage = get_max_mileage_by_vehicle_number(vehicle_number)['mileage']
    end_mileage = str(mileage + 2)

# 结束正在进行的任务
    update_trans_work_status_by_carrier_driver_code(carrier_driver_code)
    # 结束出车检查记录
    update_unfinished_vehicle_check_log(vehicle_number, out_operater_code=carrier_driver_code)
    # 结束未完结的行车日志
    update_trans_vehicle_log_by_vehicle_number(vehicle_number=vehicle_number)
    # 创建传摆任务给cpsflt
    trans_work_code = create_trans_work_with_plan_and_deed_swing_assignment()
    # 出车检查
    do_add_out_trans_vehicle_check(vehicle_number)
    # 开始任务
    begin_trans_work(trans_work_code)

driver_on_going_task = DriverOnGoingTask()
    try:
        driver_on_going_task.enter_on_going_page()
        driver_on_going_task.execute_assignment_in_area()
        driver_on_going_task.end_assignment(end_mileage=end_mileage, business_domain=2)
        driver_on_going_task.verify_execute_regional_assignment_result(trans_work_code)
    finally:
        driver_on_going_task.back_to_behind_page(n=3)
```

2）过滤条件filter_info，配置需要过滤的接口数据。比如京管家请求物流网关的接口域名是“https://test-proxy.jd.com/”，在str_in_url中配置该字段，代理会在接收到的接口中过滤出匹配该字段的所有接口。

```python
filter_info = {
# 需要过滤的接口
        "str_in_url": "https://test-proxy.jd.com/",
# 是否需要mock接口
        "switch_on": False

}
```

3）通过工具发现传参问题4个，占融合bug总数的14.29%。

#### 5.2 实践过程中的优化

针对不同app需要进行个性分析，以下是在测试过程中遇到的几个问题及解决思路。

**问题1：**

不同模块会调用同一个接口，但传参不同，此时需要多次记录一个接口及对应传参，那对比的时候如何确认顺序呢？比如，历史任务模块和正在进行模块都会调用/AppHelperApi/selectTransWorkHistoryByAppDriver接口

解决思路：A、对比时按照excel表格记录的顺序依次对比，这种方式适用于app新版本未遗漏任一接口的情况，且执行步骤及测试数据应保障新老版本是一致的；B、针对特定接口做特殊处理，比如该接口在历史任务模块调用时pageSize是20，正在进行模块调用时pageSize时，这种方式适用于非必填参数PageDto在新版本中未遗漏的情况。实际执行过程，会将A、B两种方式结合起来应用。

优化后逻辑：old表与new表按顺序对比接口及传参，接口一致，传参不一致，new表打标Fail；接口不一致，old表的接口在new表不存在，old表打标Loss，old表对比索引加一；new表的接口在old表不存在，new表打标More，new表对比索引加一。

**问题2：**

执行过程中遇到服务器部署怎么处理？

解决思路：校验接口返回值，如果返回值包含 No alive provider...字段则中止程序。对于极不稳定的接口，提供了mock接口的方式，在filter_info中配置switch_on为True，并在modify_response方法中修改返回数据即可。

### 6 总结

保障项目质量是测开岗位的基本要求，提升测试效率、降低测试成本是对我们更高的要求。因此我们在测试过程中要不断发现问题、解决问题，并将解决思路抽离成通用规则、工具。希望本文介绍的DIFF工具能为大家提供帮助。

------------

###### 自猿其说Tech-JDL京东物流技术与数据智能部
###### 作者：范文君