安卓热修复测试思路

我们的安卓开发最近研究了一下热修复的功能，调研以后使用的是Tinker；这是开发小哥哥甩给我的Tinker文档：https://github.com/Tencent/tinker/wiki

一、明确测试测试点

让我们先看下Tinker简介:Tinker是微信官方的Android热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用Tinker来更新你的插件。So，可以理解为只要是修改代码，.So库文件和资源文件能够搞定的问题，我们都可以不再发包解决~那么我们在结合一下我们安卓的apk文件结构：1、java代码文件，2、资源文件（Res+assert）,3.so文件，如上测试用例就成功分为三个有效等价类。

• 修改代码

1. 一切修改代码的行为

• 修改资源文件

1. res是app内的icon，颜色和动画等文件
2. assert是app内潜入的H5页面的资源，字体等

• 修改.So动态库文件

1. 直接被调用的C++代码编写的库，包含静态库.a和动态库.so，这些库文件一般不会修改，所以暂不纳入测试范围

       同时wiki上明确了一些Tinker的已知问题：1、Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件(1.9.0支持新增非export的Activity)；2、对于资源替换，不支持修改remoteView，例如transition动画，notification icon以及桌面图标，如上测试用例就成功分为两个个无效等价类。

• 修改AndroidManifest.xml

1. 不支持新增activiting
2. 不支持注册新的服务

• 不支持修改remoteView

1. 不支持修改系统通知样式
2. 不支持修改桌面图标

以上，明确了我们热修复的测试点~

另附：开发考虑到了可能加入热修复可能暂时不用，所有添加了开关功能，只有开关打开的版本才能进行热修复~开关也是要测的！

 二、明确测试流程

1.  开发童鞋在ftp服务器上上传一个包含bug的测试包，并且热修复开关打开
2. 下载测试包到app
3. 开发同学上传path包（vision-1）到ftp服务器,服务器会记录path路径和版本号
4. 冷启动、查看是否修复
5. 热启动、查看是否修复

这段简介在结合安卓apk安装包文件结构：

       1. META-INF\ （注：Jar文件中常可以看到）；

　　2. res\ (注：存放资源文件的目录) ；

　　3. AndroidManifest.xml (注：程序全局配置文件) ；

　　4. classes.dex （注：Dalvik字节码）；

　　5. resources.arsc (注：编译后的二进制资源文件)。