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