项目交付管理规范流程

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

测试阶段

确认需求发布的版本

需求调研

开发后端功能

项目目标

发布生产环境

参与岗位

项目经理运营/运维团队研发工程师测试工程师

需求方案评审

研发工程师

项目阶段

数据配置

开发、联调阶段

系统配置说明书

项目经理产品经理

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

需求阶段

运营配置文档

验收测试用例/测试计划

流程

全量用户使用

联调

测试环境-功能测试

可上线测试/问题修复报告

解决/确认/关闭 所有测试问题

阶段/里程碑计划

产品验收/设计验证

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

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

实现方案变更

用户操作手册

测试问题提交/修复/验证

项目交付管理规范流程

设计交互方案

测试环境-服务部署

系统部署文档

前后端联调

问题提交/修复/验证

项目需求初版方案

接口文档

开发前端功能

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

产出成果物

初版试运行

需求/技术方案评审

上线申请单

评审阶段

开发自测（冒烟）

研发工作量/排期

测试方案规划

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

冒烟用例

问题/缺陷跟踪记录

产品经理研发工程师测试工程师

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

项目经理产品经理研发工程师测试工程师UI设计人员

制定项目计划

研发人员工作量排期

测试工作量/排期

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

系统测试验收报告

项目背景

技术方案评审

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

UAT回测

开发需求（编码）

代码封版待发布生产环境

系统上线保障方案

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

细节再评审

UAT环境-服务部署

发布阶段

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

测试人员工作量排期

试点用户使用

确认的需求PRD

项目背景可行性分析

情况说明

新需求测试用例

项目经理研发工程师测试工程师

产品经理项目经理研发工程师测试工程师UI设计师产品运营/运维

确认的技术方案

上线确认单

技术文档

客户验收报告

技术规格说明书

初版需求确认