项目管理流程规范图

灰度普通用户

测试工程师

项目经理

运营配置文档

研发工程师

命中灰度的设备（编辑设备/dns命中）服务功能逻辑正常

联调

micase分配和记录执行结果，保证基本功能正常

灰度环境回测

项目流程

确认的需求PRD

发布全量用户

需求阶段

评审阶段

项目阶段

开发阶段

联调阶段

测试阶段

发布阶段

参与岗位

线上回测

需求方案评审

细节再评审

线上普通设备命中了新的服务，且功能逻辑正常

开发后端功能

情况说明

问题记录

保证客户端版本的发布和上线

产品经理

服务部署在测试环境

新需求测试用例

保证预览服务达可灰度上线质量

客户端发布

制定项目计划

问题的提交/修复/验证 

整体回归测试

设计师

1、研发，产品，测试都参与测试用例评审环节，从业务能力，技术实现方案沟通把控测试用例的质量2、冒烟用例：提供给研发工程师，保证执行通过冒烟用例的需求达到了可提测的质量

预览回测

项目背景

客户端封包

进版需求确认

设计交互方案

项目背景可行性分析

开发客户端功能

开发需求（编码）

运营

产品运营

确认需求的发布的版本

上线后，需要关注线上版本质量情况

研发工作量/排期

测试方案规划

流程

测试思维导图，测试用例评审

技术文档

1、针对新需求的测试一共有四轮测试环境，预览环境，线上灰度，线上全量  这部分由于没用剥离后端测试，会有一定工作量上的重叠，可作为后续优化点之一 2、线上数据的配置，需要编写配置文档，提供给运营并沟通预期的配置效果，这块儿目前对测试和运营都有时间成本上的占用，如有更有效的方式，双方均可降低时间成本3、封包后的客户端仍然会暴露一些问题，需要具体分析一下产生的原因和考虑解决方式 4、回归测试的用例颗粒度比较大，部分用例没有明确的前置条件和预期结果，需要统一的规划和梳理

服务线上灰度

需求调研

可上线的服务（服务端完整测试和问题修复）

测试环境下的功能测试

开发自测（冒烟）

实现方案变更

需求初版方案

产出

1、确认方案研发/测试工作量和排期 提测deadline 2、根据我们的工作量和排期，判断是否有风险以及确认需求发布的版本

测试工作量/排期

现有的客户端功能全部验证完毕，问题全部关闭

1、文档的规范性，比如明确逻辑改动和新增参数还有字段的含义2、文档的提供时间依赖于个人撰写时间，如果后期想做接口测试，这部分资料的提供时间和内容都很重要

产品验收/设计验收

服务线上全量

项目目标

服务上预览

超内/内测

技术方案评审

接口文档

测试思维导图，测试用例设计

需求/技术方案评审

各个研发的工作量/排期

问题的提交/修复/验证 

冒烟用例

冒烟的质量仍然存在一定问题，提测的版本在测试进行冒烟时有冒烟测试不通过的情况，根本原因在于，每个研发关注的自身的实现部分，但业务是串联的，需要把 后台配置/接口逻辑/客户端逻辑 三者串联起来，所以我理解需要一个人去lead这件事

线上数据的配置

确认的技术方案

产品进行可行性分析和初步方案整理

通过研发自测/冒烟测试的版本

1、方案初期的变更较多，每次变更都必须同步到所有相关人员 并更新文档2、文档的标准化，有效信息的含量，是否易于理解，阅读时能够得到我们需要的信息内容

回归原有基本功能

解决/确认/关闭 所有的客户端问题