产品上线管理办法

1、产品上线管理办法目录目的：为了规范公司开发、产品、测试以及其他与项目相关部门之间流程上更加合理、 规范， 保证产品顺利且高质量的上线展现给用户，现制定各个环节的流程且需要在邮件中必须提供的相关内容。职责：1.2.3.4.产品规划： 负责搜集汇总所有需求，形成完善的产品原型及需求文档， 认定产品bug （标准），决定产品发布。产品开发： 按照产品需求文档完成产品的开发工作，并完成开发自测， 提交自测报告（李兵 +段建功两个 team 出）。测试与质量： 结合 test case 库及产品需求文档进行产品测试，提交测试 报告。发布小组： 负责对产品更新版本进行发布。决策机制：1.内部：产品部门提交

2、上线报备 （至少提前半天）， 由产品规划总监确认。 涉及到如下功能播放器、后台系统、广告系统、发布系统、搜索功 能的情况，由研发副总裁确认。2.外部：由网站部总编辑确认。四、工作机制1. 产品立项：i.ii.iii.2.3.4.5.6.7.PRD资源支持项目计划 产品开发与自测 产品规划确认功能实现 产品测试 产品规划确认 bug 产品上线：上线会议 工作流程：测试标准开发测试产品启动段阶试测交提试测收接试测束结件条线上提交测试：版本所有相关说明的邮件通知问题确认需求文档、设计说明Y修复问题接收测试：测试时 间、负责人以及测 试注意事项邮件反馈1测试执行：bug记 录结束测试 馈测试结果测试报

3、:邮件反 艮，输出 S告8.9. 沟通机制： 原则：面对面、及时沟通。测试人员应尽量把问题描述清楚, 并提供图片或问题地址、 测试环境等, 为开发人员确定 问题提供便利,对于双方存在分歧的问题可以采取以下方式：1：测试人员主动与开发人员电话或面对面沟通，把问题发现的条件，判断问题的依据等 与开发人员沟通清楚，也听取开发人员的分析。2 通过邮件问题报告方式把测试的观点依据发送给开发工程师，并抄送双方领导，以书 面形式获得更多的信息。可以邀请开发工程师和相关部门的同事领导共同开会探讨问题的解决方式，以达成共3识。1、提交测试（开发、产品部）项目提交测试版本前,尽量请开发或者产品确保相关的文档提供给

4、测试进行提前熟悉,保证测试时间不耽误在熟悉文档上。 （如果时间紧急,可特殊处理）提交测试版本,邮件内容如下： 项目名称： XXXX开发或产品负责人： XXXX项目预估时间： XXXX （例如预计何时上线） 需求文档或说明： （无具体需求文档,则请提交版本说明 ） 测试环境：例如绑定地址、测试地址等；项目 bug 指派人：（主要负责人、相关人员）2 、 接收测试（测试部）测试人员在接到版本测试任务，需要先熟悉邮件相关的内容是否有影响测试的问题存在，如果没有，可发送接收测试邮件，邮件内容如下： 测试项目名称： XXXX 测试负责人： XXXX 测试时间： XXXX （第一轮测试、第二轮测试备注说明

5、：1测试期间，请不要将修复的bug,及时更新到测试环境，以免影响测试效率和时间（除了严重影响测试执行工作的问题可及时反馈、及时修改外）；2、 第一轮结束测试, bug 修改完毕之后,请提交复测申请。3、 项目上线前,无提交复测申请,则测试不随时跟踪改变bug 修改状态。确保 bug 已解决的定义为：开发修复并更新 bug 状态提交复测申请。4、 上线前测试报备：测试验证确认并关闭bug，且严重问题必须解决方可上线。3 、 结束测试（测试部）则需要说明。项目进入测试结束部分，完成最后一轮测试，则请测试负责人，发送邮件给项目所有相 关人员。邮件内容如以下： 测试项目名称： XXXX 测试时间： X

6、XXXX 测试负责人： XXXX 测试 bug 问题主要体现：例如：功能未实现、链接错误、设计不合理等； 测试 bug 是否影响上线： （测试角度分析，并说明问题风险，若无风险， 测试提交 bug 列表（严重问题标示红色字体） ： 测试报告文档输出。4 、上线条件（产品部）无论是否上线均请邮件产品部或者项目负责人， 需要根据测试报告分析是否符合上线。中说明原因，并及时反馈给此项目所有相关人员知晓。五、Bug 认定标准及分级1、严重错误 出现这种bug，技术人员需立即放下手头工作，马上解决。例如：A 、视频无法正常播放；不能全普屏幕观B、播放器功能无法正常使用（如不能清晰度切换，不能拖拽时间轴观

7、看, 看等问题）；C、广告无法正常播放；D、统计数据无法正确上报；E、随机出现问题，可复现、概率高并影响视频正常播放； 2、次要错误 这种问题，收集整理随下次版本更新一起解决。例如：a、不影响视频正常播放；b随机出现问题，不容易重现且不影响用户正常的视频观看;C、辅助性功能问题，例：无法跳过片头、片尾，无法续播等;3、不合理或别扭 这种问题，经过与产品人员商定后，如需调整则随下次版本更新一起解决。例如：a、界面显示不友好；b、提示不友好等；c、功能设计不合理;4、微不足道 这种问题，进行收集后统一发布版本更新。例如：a、不影响用户正常视频播放；b不影响广告正常播放；C、不影响统计数据正常上报；

8、5 、新特性 反馈给产品人员，如需添加，单独制定开发计划，实现功能。例如：a、添加此功能后有助于提高播放器体验； 6 、歧义问题 ,以下三种情况技术人员不认为是bug。例如：a、在Flash Debug版本下出现的问题（debug是开发人员使用工具，为了分析问题具体到变 量抛出的异常，用户不会安装，不会影响用户正常观看视频。）b网速持续低于20K/S出现的随机问题：（网速低于了 20K/S，已经无法播放我们网站视频, 随机出现的问题，不具备修复意义。 ）C、系统、浏览器自身 bug导致的问题。（例如：遨游、TT、世界之窗等浏览器的某些版本 不支持cookie，不属于播放器问题）测试流程图1 、

9、产品测试流程测试流程开发工程师测试工程师产品T需求分析、设计动启试测开发设计文档需求文档测试'用例测试方案编写测试用例评审计 设 试 测测试数据、环境准备行 执 试 测长周期测试版本提交测试版本d 测试实施明、确认测I试周期I测试问题记录文档 a（bug管理系统）p-N I,T回归测试.问题是否解决、引发问题 1版本紧急程度问题跟踪确认束结试测Y上线Y *J测试报告分析产品测试流程图1、 短周期：适用于小幅度改版或者修复部分bug,提交的测试版本，每轮测试时间在 以内的测试流程。2、 长周期：适用于新产品或者在旧产品基础上大于5个功能模块的产品改进所提交的测试 版本，每轮测试时间在 1周以上的测试流程。说明:A. 测试启动：1、测试组参与产品需求讨论。2、依据项目开发计划和需求文档编制测试计划。B. 测试设计1、根据需求和设计等文档对测试用例进行编制。-O2、系统运行环境的准备包括系统设备、网络设备、软件运行环境C. 测试执行1、开发负责人提交版本提交测试说明。2、测试人员依据测试用例对软件进行测试。3、测试人员将发现的问题进行记录。