1背景

互联网产品的迭代节奏很快，如何能够在快节奏的周期中，保证产品在线上能够稳定运行呢

2上线前的方案

2.1 冒烟测试全员参与

提测时，组织相关方（PM\RD\UE\UE\QA）的冒烟测试，这样做有如下好处

• 能够预防项目进行过程中需求不同步的问题
• 能够最快的从各方角度发现BUG
• 能够项目小组预知该提测版本的质量现状，对整个测试上线的时间有个预期

2.2 前期最大化的介入需求

最大化的介入需求过程，能够在细节上有更好的了解，这样能够更加深入的覆盖在文档中没有体现的细节

• 需求的评审，QA要提前熟悉需求，带着问题参加评审，这样能让整个评审的过程更有效和高效
• 建立接口测试的常规化流程，这样能够加深对业务底层逻辑和数据流的了解，也能够提升在功能测试阶段的质量

2.3 全功能的checkList

每次版本的迭代，除了新需求的这部分功能需要重点测试和回归，对于之前历史的功能也需要做一个全面的覆盖回归

• 测试用例的内外部评审，测试组内评审和项目组评审
• 整理一个全功能覆盖的checklist
• 整理一个P0级别的checklist，主要是频次使用高和多发性问题的功能，主要是RD和PM参与上线的check

3上线后的方案

3.1 灰度测试

版本上线阶段，通过灰度测试，找一批种子用户试用这个新的版本

• 能够检验新功能的合理性
• 如果产生BUG，能够最小化的缩小影响范围

3.2 线上预防监控

• 基础服务的监控预警，OP
• 服务端的日志监控和错误日志review
• APP端的友盟错误统计和BUGLY问题上报的review

3.3 线上服务定期回归

• 每晚重要功能点和问题多发功能点的回归（可以依照埋点获取数据）
• 线上问题的周分析会，找出疏漏点，优化流程

4 效率上推动

推动力！快速的消除BUG

4.1 推动力如何实施

• 任何一个需求的评审完成后，都积极主动的推动相关项目角色的排期、清晰大家的目标
• 每天早会同步目标，同步问题
• 对于产品设计或者运营过程中不好的地方要善于记录，反馈给PM不断的完善
• 对于系统服务技术方案上不利于用户体验的地方也要记录，反馈给RD同学

4.2 推动力带来的好处

• 留给后期的全功能回归的时间越多
• 有更多的时间去做一些探索性测试
• 线上问题影响的用户面尽量减少

5 改进的点

随着业务的越来越丰富，全功能回归耗费的时间越来越多，必须借助工具来提升效率，同时做到过程数据采集和量化

• 一个好的case管理和执行工具
• 自动化测试的引入