关于热修复测试的问题

关于热修复测试的问题

目前Android业内，热修复是各大APP必备的功能，为了有效保障产品质量，测试同学需要予以足够的重视。本文主要介绍热修复基本原理以及最后方案的选择，并基于个人项目经验列举测试热修复过程的一些注意事项。

1、什么是热修复

用一个可能不恰当的比喻：移动产品是一口铁锅，出现一个破洞(发现漏洞)，影响使用。为了应急和成本考量，暂不买新锅(发版更新)，补锅匠(开发者)使用锡或者铁水(补丁包)补好漏洞，使得锅正常使用(完成修复)。

2、为什么需要热修复

2.1 传统解决方法存在问题

移动产品发现问题传统的解决方案是：

发现产品bug;

开发修复bug;

测试验证;

重新发包;

用户通过应用商店下载更新或者应用检测更新;

这种流程存在问题：

重新发版成本高，推广和运营成本的投入常常是测试同学不容易察觉;

用户下载安装成本高，用户手动下载和安装是需要耗费时间和流量;

bug修复时效性差，重新发版且需要用户允许更新安装都会拖延修复的及时性;

频繁修复发版会导致体验性差，用户流失率提高;

2.2 热修复有效解决问题

传统的方案存在上述的问题通过热修复技术方案可以有效解决：

发现产品bug;

开发修复bug，生成补丁包;

测试验证补丁包生效性;

将补丁包部署到云端;

应用自动下拉补丁包并修补问题;

热修复方案有效解决传统方案的问题：

无需重新发版，降低推广和运营成本;

用户无感知，且流量消耗小;

修复率和时效性高，减小损失;

3、热修复有哪些方案

目前业界的热修复技术方案大致可以分为以下5类：

Native Hook

以Dexposed为例，其直接在native层进行方法的结构体信息对换，从而实现完美的方法新旧替换，来实现热修复功能。

Java Multidex

以Qzone超级补丁为例，其Hook ClassLoader.pathList.dexElements[]。因为ClassLoader的findClass是通过遍历dexElements[]中的dex来寻找类的。

Java hook

以Robust为例，其实现原理是在编译打包阶段自动为每个class都增加了一个类型为ChangeQuickRedirect的静态成员，而在每个方法前都插入了使用changeQuickRedirect相关的逻辑，当 changeQuickRedirect不为null时，可能会执行到accessDispatch从而替换掉之前老的逻辑，达到fix的目的。

Dex替换

以Tinker为例，其主要原理和Qzone超级补丁一致，优化方案，通过下发差量包使得补丁包最小化，同时支持资源和so的更新。

混合优化

以Sophix为例，结合了Andfix和全量合成dex技术。

4、我们的选择-tinker

业界的热修复方案各有各的特点，最后基于综合考量，我们选择的方案是tinker：

平台兼容性好，修复率高：基于和之前方案的对比，tinker方案的修复率有大幅的提高，实际验证过程，目前的tiker版本支持android Q版本的修复;

开源免费：商业考量，免费好用是最重要的，总是可有的提高市场占比，有利于技术的成熟;

社区活跃，持续版本更新：过程中出现的问题可以被及时的解决修复;

修复功能强大：支持资源和so的修复;

5、测试过程注意事项

基于tinker实际测试过程中遇到的问题，小编简单总结测试过程遇到的经验和教训。

5.1功能测试阶段

1. 功能测试：代码修复，资源修复和SO修复逻辑验证;

这个是热修复基本的功能测试，不做赘述;

2. 功能测试：SDK更新时需要注意系统版本适配;

新功能测试和SDK升级时，均需要主要5.0以下系统和5.0以上系统的生效性验证。在项目实际测试过程，曾经发现过SDK升级时5.0以下手机冷启动就出现崩溃，最后发现与与分Dex方案Multidex在Android5.0前后版本引用策略不同有关。所以建议升级SDK升级时需要注意系统适配;

3. 产品逻辑：思考如何查看统计线上修复率;

这个逻辑容易被很多产品和测试同学忽略，与功能逻辑无关，但是测试过程需要思考，上线热修复补丁包后如何查看是否下载成功，加载成功与否。建议测试过程多思考除了功能逻辑以外的一些事情。

4. 策略逻辑：确保可以清除补丁包或者版本升级后不生效;

这个策略逻辑是否重要，但凡所有的事情优先想好退路，在思考修复功能逻辑之前，优先思考删除补丁包的逻辑，如果开发如果没有添加相关策略逻辑，那么，下发的补丁包存在问题导致修复失败将是灾难性的问题;

5. 策略逻辑：思考如何解决同一版本，不同渠道打包可能导致基准包不同的问题;

不同公司的不同产品线打包可能存在差异性，在实际测试过程曾经出现一个问题，热修复功能验证通过，但是市场，测试和产品基于自身需求，修改打包配置项重新打包，导致同一个版本，虽然代码逻辑相同，但是系统重新打包导致混淆存在差异。如果该版本需要下发热修复补丁包，可能需要不同的基准包编译对应的补丁包，导致热修复功能的可用性降低;

6.功能测试：非目标app包在下载补丁包后不会生效且不会出现崩溃;

这个是热修复基本的功能测试，也是必须要注意的。

5.2热修复下发阶段

在出现线上问题，需要下发补丁包时，测试同学在进行相关测试过程需要注意：

1. 功能测试：成功修复问题;

验证相关线上bug可以被成功修复，且不会出现连带bug;

2. 策略逻辑：可以清除补丁包;

这个是必须要重视的，虽然之前的功能测试中已经覆盖到，但是实际对线上下发补丁包时必须优先测试下发的补丁包可以通过之前约定的策略清除;

3. 性能测试：注意热修复下发后对于启动性能的影响;

通过tinker的原理可知，下发热修复补丁包后对app的启动性能。故在实际下发补丁包并修复成功后，需要测试启动相关性能;