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管理和执行工具
- 自动化测试的引入
