测试用例评审
文档提前同步相关与会人员
研发阶段
用户需求
参与人员
需求变更
推广应用阶段
是
否
用户是谁
需求理解参与需求评审
参与验证测试对功能点验收
产品部门验收通过
需求池管理
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.测试用例
应用疑难解决
同步验收
需求细化
具体变更内容同步开发、运营、售前、测试、老板
对交互体验、视觉效果进行验收
是否符合业务需求及使用场景
公司策略
功能点
需求沟通与分析：优先级、合理性、可行性(含技术可行性）
安全测试
文档同步产品、运营、测试
提优化建议
原型细节沟通
业务需求确认会议
运营数据分析
业务侧（售前团队、平台用户、运营人员）
开发侧（前后端技术人员、运维）
提测
产品推广
平台使用者体验收集
产品、运营、业务方（项目经理、售前/销售、项目客户）研发、测试
