产品、运营、技术、测试:产品发布前的自查表格(附范例版)

发表于2015-11-23
评论0 753浏览

前面的闲聊:这几天都是忙女神直播项目,每天匆匆忙忙,做产品,还是需要在第一现场,白天在公司策划协调沟通,晚上就在直播现场测试直播流程,体验线上与线下的配合。

 

一个貌似简单的活动流程,一旦牵扯线上和线下的配合,涉及两个页面,两个屏幕的切换,就无比纠结。

 

减法,在第一版尤为关键,明天继续做减法。

 

做过的几款直播类产品,都会多多少少出现问题,内测真的很重要,即使当天没问题,一个小小的变化,哪怕是某个机器移动了些许位置,都有可能导致直播问题发生,所以在开播前,所有设备都需要检查调试。

产品在上线前,需要做什么?

 

上一篇文章从产品、运营、开发、测试的角度进行了上线自查的介绍,应大家的要求,补充产品经理上线自查表格范例。

另外,腾讯安全管家的产品经理Nili说,补充一条:

 

版本目标是否明确?目标验证的标准是什么(留存?使用渗透率?成功率?)?版本目标的等级对应打的评判标准(普通目标--留存率x%,挑战目标--留存率y%)

产品经理的自查

 

  1. 需求文档是否补充完整?例如交互图、设计稿是否已经更新;

  2. 客服文档是否已经提交并进行客服培训;

  3. 每个功能特性是否有确定的输入、处理、输出?

  4. 是否有异常结果的处理?

  5. 页面跳转是否有给出明确的地址?

  6. 产品文字是否已检查?(包括但不限于页面文字、广告语)

  7. 发布策略是否已考虑,灰度发布是否在文档中有说明?

  8. 已有功能、标识的改动,在其他模块的呈现,是否覆盖完整?

  9. 如涉及现有产品的老功能删减,需要和客服沟通;

  10. 需求特性是否区分用户身份?

  11. 未实现的需求是否在文档中注明?

  12. 除了正常状态,异常条件下的兼容措施是否考虑?

  13. 统计需求是否明确提出?数据是否正常上报?

草拟了一个产品经理的自查表,供大家参考,手机横屏过来看。

模块

页面

功能点

用户状态

输入(操作)

处理

输出(结果)

异常处理

跳转

文案

统计需求

备注与问题

表格的字段如下:(范例)

范例一:手机注册

自查项目范例
模块手机用户注册
页面手机用户注册页面
功能点用户使用手机注册
用户状态未登录用户
输入(操作)输入手机号、接收手机验证码并输入、输入密码;
处理系统查询是否有重复手机号,发送手机验证码,密码安全性检查;
输出(结果)手机号是否可用;验证码是否正确;密码是否安全;注册是否成功;
异常处理如无法收到手机验证码,60秒后允许重新发送;
跳转注册成功后跳转产品首页(或者产品教程页、或者首页带新用户教学蒙板)
文案手机号;验证码;获取验证码;密码,重复密码;注册;
统计需求成功注册人数;注册页面PV/UV;点击重发验证码PV/UV
备注与问题每个手机仅允许注册一个账号;

范例二:公屏聊天

 

自查项目范例
模块公屏聊天
页面首页
功能点用户发表公屏文字信息,并支持弹幕显示。
用户状态登录用户。
输入(操作)输入文字,并点击发送。每条字数限制20个字。每条发送间隔X秒。屏蔽敏感词。
处理文字敏感性判断;公屏聊天条数计算,支持XXX条文字并发显示;公屏聊天记录不存储;
输出(结果)

公屏显示用户昵称、VIP图标、发送信息内容;每个用户必须看到自己发送的信息,当公屏同时并发消息条数超过XX条,仅显示XX条;

点击用户VIP图标,引导进入VIP开通、续费流程;

异常处理敏感词显示为***号;被禁言用户给出提示;无法获取用户昵称,则显示用户ID;
跳转第一版公屏聊天不支持链接跳转;
文案

按钮文案:发送;

发言间隔小于X秒,提示:发言太快,请在X秒后发送;

被禁言提示:已被禁言,可在XXX申诉;

统计需求发送按钮点击PV/UV;
备注与问题

非注册用户引导注册流程。

发言管理后台设计,支持禁言、解禁、记录用户禁言前发送的最近记录、根据用户ID和昵称查询;

产品运营的自查

  1. 产品的冷启动是否已经准备完毕?

  2. 内容运营的更新机制是否已经确认,并进行部署,是自动更新,还是人工更新,有无更新机制和审核发布机制?

  3. 产品活动运营是否已经进行规划?是否有专人负责?周期性的活动,是否已经有运营模板?

  4. 产品数据是否已经正确上报?是否通过数据测试?数据报表是否已经就绪?

  5. 新媒体运营的账号是否已经建立,是否有专人负责?是否有内容规划?内容获取途径是否已经建立?

  6. 渠道运营是否已经建立,例如应用商店的合作,SEO,ASO的计划和实施;

  7. 用户消费充值的路径是否顺畅?数值是否准确?

开发自查

  1. 每个功能是否全面自测?边界/异常参数的确认和验证(如果有以类似lib方式对外提供被调用API

  2. 是否进行高危函数扫描?

  3. 是否进行安全漏洞扫描?

  4. 是否有内存泄漏的检测和结果(如果是C/C++代码)?

  5. 不必要log是否删除了,以及log信息是否清晰完整详细?

  6. 统计上报是否完整?

  7. 代码在编译环境已编译通过?

  8. 是否有socket泄漏?

  9. 是否影响其他相关模块功能表现?

  10. 自身系统压力是否已评估?

  11. 后端支撑系统负载变化是否已评估?

  12. 是否对业务流量有影响?

  13. 转测试文件和ARS单是否完整

  14. 产品体验是否通过?体验反馈的问题是否已修复?

  15. 是否需要灰度,采用何种灰度方案

  16. 是否需要提前发布配置?

测试人员自查

 

  1. 产品通过测试的发布标准建立;

  2. 用例编写是否100%覆盖需求;

  3. 是否及时有效地修改自动化用例(CGI的修改涉及到自动化用例部分的内容) ;

  4. 用例编写是否有考虑异常逻辑&优化(web前台,性能等)的情况

  5. 是否有认真阅读提测邮件的测试重点,有针对性的编写用例;

  6. 是否有发起用例评审,并根据评审意见修订用例

  7. 测试Bug是否进行有效性跟处理,直至闭环

  8. 版本发布时是否确认Bug单的状态为已关闭或已挂起,否则不允许发布

  9. 测试报告是否及时发送;

  10. 开发完成后,页面重构人员把版本内涉及的文件提取并入测试环境原版本内

  11. 提供相关ARS单信息给开发pm提单操作;

  12. host到测试环境,确认代码版本正确,确保无bug,确保页面准确还原设计稿;

  13. 测试过程中,会提出为改善用户体验以及细节的缺陷,测试人员会通过XXXX系统提交bug单发送给相关责任人;

  14. 评估名下bug单的优先级和处理时间点,统一时间处理;

  15. 处理完成后,及时更新bug单的状态;

  16. 代码是否上传XXX系统?

  17. bug状态是否已更新?

  18. 遗留bug是否已经过PDMPMTE评估?(致命及严重bug需要测试leader和总监确认)

  19. 发布时间和内容是否符合发布规范(例如版本中包含后台server发布,晚上高峰期需要经过审批才能发,日常版本不能包含cgi等)

  20. 配置文件的修改是否恢复;

  21. 外网运营环境版本是否与测试环境一致;

  22. 影响到其他模块表现的,发布前对方测试人员是否已做功能验证并确认ok

  23. 版本发布后是否留守进行外网验证,发出验证报告后才离开

  24. 外网验证的Bug是否有跟进处理(严重Bug要跟进及时处理,其他Bug阶段性的跟进处理)

原文链接

著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台