按时、定期发布的补丁包可以帮助客户获得持续提高的产品质量和用户体验。
由于补丁包包含的内容来源于已经被客户发现的问题及未被客户发现的潜在问题，应用补丁包将有效帮助其他的用户规避遇到类似问题的风险。
补丁包测试最大的目的在于能给产品带来持续的质量提升。质量是一个产品的生命，所以补丁包测试的驱动之一往往就是产品开发团队和售后支持团队通过对当前已知的问题的分析和评估，共同选择在一个最合适的时机推出产品的升级补丁包。
补丁包测试存在的坑
在系统测试阶段，以及产品上线后，都会发一些补丁包修复bug。补丁包测试会有很多坑，比如：
问题1：测试人员不清楚开发提交的补丁包修改了什么代码（有时候我们即使知道只增加了一个按钮，但我们测试人员也不能保证提交的补丁包中，只有按钮那一部分代码有变动，比如合并代码时出了错呢？），为了以防万一，对于开发提交的代码，均会进行所有模块的回归验证。从而导致补丁包的测试耗时较长，效率比较低。
问题2：项目代码管理混乱（普及一下程序员修改代码的方式：把跟线上环境相同的代码成为主干，未上线的那部分代码叫做分支。为了不让未经测试的代码污染主干代码，每个开发修改代码时都是自己加一个分支（N个程序员就可能有N个分支），甚至是在分支的分支上面进行修改），分支较多的时候，就可能导致在测试环境验证完了，但打包的时候漏掉某个分支代码或者多打包了某个分支代码，导致线上环境出了问题。
补丁包评估的方法
1、对待测的版本进行代码监控（代码版本管理工具（如SVN）一般都有这个功能），从发版后的版本号开始到待测的版本，均需要通过代码监控进行review并给出回归范围，具体可参考如图：
2、与开发进行沟通，确认开发修改了什么、为什么修改、可能影响的范围等，三方集体对改动范围进行评估。
3、专人负责代码合并、上传。
补丁包评测方案的内容
1、当前版本分支及Version code（蓝色标注为事例参考）
Android_V5.8_29310
2、版本跨度
Android_V5.8_29281~Android_V5.8_29310
3、此次发版涉及到的改动
①资讯模块异常情况下崩溃保护
②尝试修复线上崩溃
③修改xxxx的Bug
4、根据代码监控对提交的每笔代码分析结论
关于收藏网址图标的主要修改：IconsController..java 中对打开系统icon库openIconReceived添加了异常处理，不影响其他模块；
针对三星特定机型AR翻译中传感器参数问题主要修改： RotationVectorDetector.java中对添加异常处理，当传感器返回的event.value的 长度超过4时，进行数据处理
5、根据代码改动分析、与开发的沟通评估测试范围
关于AR翻译中传感器参数问题崩溃的问题，建议进行回归，并且最好选择三星的相关机型进行；
关于视频播放监听器添加非空判定，无需回归，但希望在测试生效性过程可以有所关注。
6、补丁包测试中涉及到的具体机型系统（依赖于项目组的测试机及用户机型占比）
华为&荣耀：mate9、荣耀4X
三星：note5、note3、note2
OPPO：OPPO N1
小米：红米1S、小米2（5.0）
魅族：MX5
……
7、补丁包测试中设计到的测试负责人
xxx模块 负责人
8、测试预期完成时间点
期望2017年6月29日完成，预期2h