补丁包测试方案制定

本文章转载于搜狗测试

补丁包主要涉及到的场景：

相信很多小伙伴对于补丁包不陌生，也有些小伙伴对于补丁包有困惑，什么是补丁包，补丁包的发布在什么阶段呢？小编为大家逐一答疑。

小编所在的团队，正常的测试阶段如下流程所示，各方在项目迭代中按照预期的流程执行任务，测试严格按照流程规范迭代执行。

补丁包发生的时机（流程图中红色框体位置）：

一灰上线后，二灰期间

产品正式发布后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