产品上线管理办法重点.docVIP

产品上线管理办法 目录 一 产品上线前准备 1 1、 提交测试（开发、产品部） 1 2、 接收测试（测试部） 2 3、 结束测试（测试部） 2 4、上线条件（产品部） 2 二 Bug级别分类 5 1、严重错误 5 2、次要错误 5 3、不合理或别扭 5 4、微不足道 5 5、新特性 5 6、歧义问题, 6 三 测试流程图 6 1、产品测试流程 6 2、日常监测流程 8 四 沟通机制 10 目的：为了规范公司开发、产品、测试以及其他与项目相关部门之间流程上更加合理、规范，保证产品顺利且高质量的上线展现给用户，现制定各个环节的流程且需要在邮件中必须提供的相关内容。 职责： 产品规划：负责搜集汇总所有需求，形成完善的产品原型及需求文档，认定产品bug（标准），决定产品发布。 产品开发：按照产品需求文档完成产品的开发工作，并完成开发自测，提交自测报告（李兵+段建功两个team出）。 测试与质量：结合test case 库及产品需求文档进行产品测试，提交测试报告。 发布小组：负责对产品更新版本进行发布。 决策机制： 内部：产品部门提交上线报备（至少提前半天）， 由产品规划总监确认。涉及到如下功能——播放器、后台系统、广告系统、发布系统、有哪些信誉好的足球投注网站功能的情况，由研发副总裁确认。 外部：由网站部总编辑确认。 工作机制 产品立项： PRD 资源支持 项目计划 产品开发与自测 产品规划确认功能实现 产品测试 产品规划确认bug 产品上线：上线会议 工作流程： 沟通机制： 原则：面对面、及时沟通。 测试人员应尽量把问题描述清楚，并提供图片或问题地址、测试环境等，为开发人员确定问题提供便利，对于双方存在分歧的问题可以采取以下方式： 1：测试人员主动与开发人员电话或面对面沟通，把问题发现的条件，判断问题的依据等与开发人员沟通清楚，也听取开发人员的分析。 2 通过邮件问题报告方式把测试的观点依据发送给开发工程师，并抄送双方领导，以书面形式获得更多的信息。 3 可以邀请开发工程师和相关部门的同事领导共同开会探讨问题的解决方式，以达成共识。 1、 提交测试（开发、产品部） 项目提交测试版本前，尽量请开发或者产品确保相关的文档提供给测试进行提前熟悉，保证测试时间不耽误在熟悉文档上。（如果时间紧急，可特殊处理） 提交测试版本，邮件内容如下： 项目名称：XXXX 开发或产品负责人：XXXX 项目预估时间：XXXX （例如预计何时上线） 需求文档或说明：（无具体需求文档，则请提交版本说明） 测试环境：例如绑定地址、测试地址等； 项目bug指派人：（主要负责人、相关人员） 2、 接收测试（测试部） 测试人员在接到版本测试任务，需要先熟悉邮件相关的内容是否有影响测试的问题存在，如果没有，可发送接收测试邮件，邮件内容如下： 测试项目名称：XXXX 测试负责人：XXXX 测试时间：XXXX （第一轮测试、第二轮测试……） 备注说明： 1、测试期间，请不要将修复的bug，及时更新到测试环境，以免影响测试效率和时间（除了严重影响测试执行工作的问题可及时反馈、及时修改外）； 2、第一轮结束测试，bug修改完毕之后，请提交复测申请。 3、项目上线前，无提交复测申请，则测试不随时跟踪改变bug修改状态。 确保bug已解决的定义为：开发修复并更新bug状态提交复测申请。 4、上线前测试报备：测试验证确认并关闭bug，且严重问题必须解决方可上线。 3、 结束测试（测试部） 项目进入测试结束部分，完成最后一轮测试，则请测试负责人，发送邮件给项目所有相关人员。邮件内容如以下： 测试项目名称：XXXX 测试时间：XXXXX 测试负责人：XXXX 测试bug问题主要体现：例如：功能未实现、链接错误、设计不合理等； 测试bug是否影响上线：（测试角度分析，并说明问题风险，若无风险，则需要说明。） 测试提交bug列表（严重问题标示红色字体）： 测试报告文档输出。 4、上线条件（产品部） 产品部或者项目负责人，需要根据测试报告分析是否符合上线。无论是否上线均请邮件中说明原因，并及时反馈给此项目所有相关人员知晓。 Bug认定标准及分级 1、严重错误 出现这种bug，技术人员需立即放下手头工作，马上解决。例如： A、视频无法正常播放； B、播放器功能无法正常使用（如不能清晰度切换，不能拖拽时间轴观看，不能全普屏幕观看等问题）； C、广告无法正常播放； D、统计数据无法正确上报； E、随机出现问题，可复现、概率高并影响视频正常播放； 2、次要错误 这种问题，收集整理随下次版本更新一起解决。例如： a、不影响视频正常播放； b、随机出现问题，不容易重现且不影响用户正常的视频观看； c、辅助性功能问题，例：无法跳过片头、片尾，无法续播等； 3、