产品迭代流程图

测试用例评审

文档提前同步相关与会人员

研发阶段

用户需求

参与人员

需求变更

推广应用阶段

是

否

用户是谁

需求理解参与需求评审

参与验证测试对功能点验收

产品部门验收通过

需求池管理

1.测试报告

1.排期计划表2.人员任务分拆表

验收演示会议

UI页面视觉设计

BUG包括：需求BUG、设计BUG、功能BUG需求Bug，指由于客户需求描述不清晰或错误、需求收集人员自身原因及需求本身模糊难于分析、获取等原因，导致客户需求获取不准确，后期产品不能满足客户、用户的要求设计Bug，是指产品在最初设计时由于未考虑全面，而使产品在使用中存在的一些潜在的缺陷。功能Bug，是指计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。建议从以下几点进行区分:1、产生的时间不相同:需求Bug:产生于项目前期设计Bug:产生于项目前期或中期功能Bug:产生于项目中期或后期2、产生的原因不相同:需求Bug:客户需求描述不清晰或错误、需求收集人员不够专业、需求本身模糊难于分析、获取等原因设计Bug:系统框架、通讯模式、库表设计、编写语言等选择不当，导致后期扩展棘手、安全性低等功能Bug:开发工程师需求理解错误、代码编写缺陷等原因3、造成的影响不相同:需求Bug:对整个项目的影响极大，会直接拖后项目的进度、加大项目成本、降低客户对公司的评价设计Bug:后期功能扩展、性能、安全性等可能会遭到威胁功能Bug:影响用户使用体验、影响数据、资金安全4、处理方式不相同需求Bug:重新收集需求，重新设计和开发 (需求Bug是对项目成本和进度影响最大的因素)设计Bug: 重大缺陷必须修复，小设计缺陷在下一次发布时更新(一般难于修复或修复成本较大)功能Bug:直接修复缺陷，重新发布或更新5、Bug的直接责任人不相同需求Bug:业务人员、需求专员、项目经理等设计Bug:架构工程师、数据库工程师、技术经理、项目经理等功能Bug:开发、测试工程师

1.工时评估表

异常处理

研发自测

平台定位

编写测试计划

技术方案设计

需求变更导致（研发+测试）工时增加＞3天

功能/接口测试

编写测试用例

推广情况/市场反应、产品数据、用户使用意见收集

提BUG

参与验证测试按照业务场景进行验收

用户痛点

审批通过需求变更

用户痛点用户需求

产品上线发布、部署

产品、运营、售前/销售

第一轮功能测试及修复后

公司战略规划

项目应用

业务方验收通过

运维监控，定时巡查（服务器、带宽等）

1.产品使用文档发布/更新

设计侧（UI/UE）

技术方案评审（研发内部）

产品侧（产品经理）

进入需求池

测试排期

测试侧（测试人员）

产品、运营、研发、测试、设计

（运营、产品、运维）协同解决问题

性能测试（含压力测试）

产品、研发、测试

确认版本重点方向

完成研发

审批不通过需求不变更

切图

1.计划表

产品培训手册/推广材料

研发排期

输出文档

修复BUG/优化

是否与设计效果一致

回归测试

研发过程中需求细节沟通

测试验收阶段

需求评审会

1.测试记录

各方确认需求

最终需求文档邮件抄送各方

交付项目业务需求

产品、研发

目标定位、目标用户、用户痛点与需求调研

行业分析、竞品分析、数据分析

整体验收

汇报老板确认是否审批通过

1.PRD需求文档2.原型图

重要环节

需求反讲会

提BUG（需求BUG/技术设计BUG/功能BUG）、优化意见

1.需求功能点清单2.概要业务逻辑

开始研发

需求收集整理

需求确认阶段

1.测试用例

应用疑难解决

同步验收

需求细化

具体变更内容同步开发、运营、售前、测试、老板

对交互体验、视觉效果进行验收

是否符合业务需求及使用场景

公司策略

功能点

需求沟通与分析：优先级、合理性、可行性(含技术可行性）

安全测试

文档同步产品、运营、测试

提优化建议

原型细节沟通

业务需求确认会议

运营数据分析

业务侧（售前团队、平台用户、运营人员）

开发侧（前后端技术人员、运维）

提测

产品推广

平台使用者体验收集

产品、运营、业务方（项目经理、售前/销售、项目客户）研发、测试