[产品上线管理办法]
产品上线管理办法
目录
一产品上线前准备 (2)
1、提交测试（开发、产品部） (4)
2、接收测试（测试部） (4)
3、结束测试（测试部） (5)
4、上线条件（产品部） (5)
二Bug级别分类 (5)
1、严重错误 (5)
2、次要错误 (5)
3、不合理或别扭 (5)
4、微不足道 (6)
5、新特性 (6)
6、歧义问题, (6)
三测试流程图 (6)
1、产品测试流程 (6)
2、日常监测流程 (8)
四沟通机制................................................................................................... 错误!未定义书签。
一、目的：为了规范公司开发、产品、测试以及其他与项目相关部门之间流程上更加
合理、规范，保证产品顺利且高质量的上线展现给用户，现制定各个环节的流程且需要在邮件中必须提供的相关内容。
二、职责：
1.产品规划：负责搜集汇总所有需求，形成完善的产品原型及需求文档，
认定产品bug（标准），决定产品发布。
2.产品开发：按照产品需求文档完成产品的开发工作，并完成开发自测，
提交自测报告（李兵+段建功两个team出）。
3.测试与质量：结合test case 库及产品需求文档进行产品测试，提交测试
报告。
4.发布小组：负责对产品更新版本进行发布。
三、决策机制：
1.内部：产品部门提交上线报备（至少提前半天），由产品规划总监确认。
涉及到如下功能——播放器、后台系统、广告系统、发布系统、搜索功
能的情况，由研发副总裁确认。
2.外部：由网站部总编辑确认。
四、工作机制
1.产品立项：
i.PRD
ii.资源支持
iii.项目计划
2.产品开发与自测
3.产品规划确认功能实现
4.产品测试
5.产品规划确认bug
6.产品上线：上线会议
7.工作流程：
9.沟通机制：
原则：面对面、及时沟通。
测试人员应尽量把问题描述清楚，并提供图片或问题地址、测试环境等，为开发人员确定问题提供便利，对于双方存在分歧的问题可以采取以下方式：
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、不合理或别扭
这种问题，经过与产品人员商定后，如需调整则随下次版本更新一起解决。
例如：
a、界面显示不友好；
b、提示不友好等；
c、功能设计不合理；
4、微不足道
这种问题，进行收集后统一发布版本更新。
例如：
a、不影响用户正常视频播放；
b、不影响广告正常播放；
c、不影响统计数据正常上报；
5、新特性
反馈给产品人员，如需添加，单独制定开发计划，实现功能。
例如：
a、添加此功能后有助于提高播放器体验；
6、歧义问题,
以下三种情况技术人员不认为是bug。
例如：
a、在Flash Debug版本下出现的问题（debug是开发人员使用工具，为了分析问题具体到变量抛出的异常，用户不会安装，不会影响用户正常观看视频。
）
b、网速持续低于20K/S出现的随机问题：（网速低于了20K/S，已经无法播放我们网站视频，随机出现的问题，不具备修复意义。
）
c、系统、浏览器自身bug导致的问题。
（例如：遨游、TT、世界之窗等浏览器的某些版本不支持cookie，不属于播放器问题）
三测试流程图
1、产品测试流程
产品测试流程图
1、短周期：适用于小幅度改版或者修复部分bug，提交的测试版本，每轮测试时间在1周
以内的测试流程。
2、长周期：适用于新产品或者在旧产品基础上大于5个功能模块的产品改进所提交的测试
版本，每轮测试时间在1周以上的测试流程。
说明：
A.测试启动：
1、测试组参与产品需求讨论。
2、依据项目开发计划和需求文档编制测试计划。
B.测试设计
1、根据需求和设计等文档对测试用例进行编制。
2、系统运行环境的准备包括系统设备、网络设备、软件运行环境.。
C.测试执行
1、开发负责人提交版本提交测试说明。
2、测试人员依据测试用例对软件进行测试。
3、测试人员将发现的问题进行记录。
4、开发人员对测试中发现的bug进行修改。
5、测试人员对解决的bug进行确认。
6、测试人员编写测试状态报告和阶段测试报告。
D.测试结束
1、编制项目测试报告，测试遗留问题报告。
2、提交测试报告和遗留问题报告给产品部和相关部门。
2、日常监测流程。