灰度普通用户
测试工程师
项目经理
运营配置文档
研发工程师
命中灰度的设备（编辑设备/dns命中）服务功能逻辑正常
联调
micase分配和记录执行结果，保证基本功能正常
灰度环境回测
项目流程
确认的需求PRD
发布全量用户
需求阶段
评审阶段
项目阶段
开发阶段
联调阶段
测试阶段
发布阶段
参与岗位
线上回测
需求方案评审
细节再评审
线上普通设备命中了新的服务，且功能逻辑正常
开发后端功能
情况说明
问题记录
保证客户端版本的发布和上线
产品经理
服务部署在测试环境
新需求测试用例
保证预览服务达可灰度上线质量
客户端发布
制定项目计划
问题的提交/修复/验证
整体回归测试
设计师
1、研发，产品，测试都参与测试用例评审环节，从业务能力，技术实现方案沟通把控测试用例的质量2、冒烟用例：提供给研发工程师，保证执行通过冒烟用例的需求达到了可提测的质量
预览回测
项目背景
客户端封包
进版需求确认
设计交互方案
项目背景可行性分析
开发客户端功能
开发需求（编码）
运营
产品运营
确认需求的发布的版本
上线后，需要关注线上版本质量情况
研发工作量/排期
测试方案规划
流程
测试思维导图，测试用例评审
技术文档
1、针对新需求的测试一共有四轮测试环境，预览环境，线上灰度，线上全量 这部分由于没用剥离后端测试，会有一定工作量上的重叠，可作为后续优化点之一 2、线上数据的配置，需要编写配置文档，提供给运营并沟通预期的配置效果，这块儿目前对测试和运营都有时间成本上的占用，如有更有效的方式，双方均可降低时间成本3、封包后的客户端仍然会暴露一些问题，需要具体分析一下产生的原因和考虑解决方式 4、回归测试的用例颗粒度比较大，部分用例没有明确的前置条件和预期结果，需要统一的规划和梳理
服务线上灰度
需求调研
可上线的服务（服务端完整测试和问题修复）
测试环境下的功能测试
开发自测（冒烟）
实现方案变更
需求初版方案
产出
1、确认方案研发/测试工作量和排期 提测deadline 2、根据我们的工作量和排期，判断是否有风险以及确认需求发布的版本
测试工作量/排期
现有的客户端功能全部验证完毕，问题全部关闭
1、文档的规范性，比如明确逻辑改动和新增参数还有字段的含义2、文档的提供时间依赖于个人撰写时间，如果后期想做接口测试，这部分资料的提供时间和内容都很重要
产品验收/设计验收
服务线上全量
项目目标
服务上预览
超内/内测
技术方案评审
接口文档
测试思维导图，测试用例设计
需求/技术方案评审
各个研发的工作量/排期
问题的提交/修复/验证
冒烟用例
冒烟的质量仍然存在一定问题，提测的版本在测试进行冒烟时有冒烟测试不通过的情况，根本原因在于，每个研发关注的自身的实现部分，但业务是串联的，需要把 后台配置/接口逻辑/客户端逻辑 三者串联起来，所以我理解需要一个人去lead这件事
线上数据的配置
确认的技术方案
产品进行可行性分析和初步方案整理
通过研发自测/冒烟测试的版本
1、方案初期的变更较多，每次变更都必须同步到所有相关人员 并更新文档2、文档的标准化，有效信息的含量，是否易于理解，阅读时能够得到我们需要的信息内容
回归原有基本功能
解决/确认/关闭 所有的客户端问题
