补丁包主要涉及到的场景：
相信很多小伙伴对于补丁包不陌生，也有些小伙伴对于补丁包有困惑，什么是补丁包，补丁包的发布在什么阶段呢？小编为大家逐一答疑。
小编所在的团队，正常的测试阶段如下流程所示，各方在项目迭代中按照预期的流程执行任务，测试严格按照流程规范迭代执行。
补丁包发生的时机（流程图中红色框体位置）：
-
一灰上线后，二灰期间
-
产品正式发布后fix线上Bug
补丁包提测的内容一般是：
-
修复线上待修复的功能逻辑Bug
-
修复线上待修复的崩溃
-
优化线上体验不好的产品需求
补丁包测试存在的坑：
问题1：某A项目版本，在版本二灰期间，对于开发提交的代码，均会进行所有模块的回归验证。从而导致灰度包的发版测试耗时较长，效率比较低。
问题2：某B项目版本，在版本发灰后 ，开发优化了此版本的代码并提交到此代码分支上，灰度后开发修复了线上的崩溃，测试针对线上的崩溃进行测试验证并上线，但是未确认SVN Log，导致代码优化的代码未验证，而线上也出现了问题。
补丁包评估的方法：
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）
魅族：MX2
7. 补丁包测试中设计到的测试负责人
xxx模块 负责人
8. 测试预期完成时间点
期望2017年6月29日完成，预期2h
-
