产品、运营、技术、测试：产品发布前的自查表格（附范例版）
前面的闲聊：这几天都是忙女神直播项目，每天匆匆忙忙，做产品，还是需要在第一现场，白天在公司策划协调沟通，晚上就在直播现场测试直播流程，体验线上与线下的配合。
一个貌似简单的活动流程，一旦牵扯线上和线下的配合，涉及两个页面，两个屏幕的切换，就无比纠结。
减法，在第一版尤为关键，明天继续做减法。
做过的几款直播类产品，都会多多少少出现问题，内测真的很重要，即使当天没问题，一个小小的变化，哪怕是某个机器移动了些许位置，都有可能导致直播问题发生，所以在开播前，所有设备都需要检查调试。
产品在上线前，需要做什么？
上一篇文章从产品、运营、开发、测试的角度进行了上线自查的介绍，应大家的要求，补充产品经理上线自查表格范例。
另外，腾讯安全管家的产品经理Nili说，补充一条：
版本目标是否明确？目标验证的标准是什么（留存？使用渗透率？成功率？）？版本目标的等级对应打的评判标准（普通目标--留存率x%，挑战目标--留存率y%）
产品经理的自查
需求文档是否补充完整？例如交互图、设计稿是否已经更新；
客服文档是否已经提交并进行客服培训；
每个功能特性是否有确定的输入、处理、输出？
是否有异常结果的处理？
页面跳转是否有给出明确的地址？
产品文字是否已检查？（包括但不限于页面文字、广告语）
发布策略是否已考虑，灰度发布是否在文档中有说明？
已有功能、标识的改动，在其他模块的呈现，是否覆盖完整？
如涉及现有产品的老功能删减，需要和客服沟通；
需求特性是否区分用户身份？
未实现的需求是否在文档中注明？
除了正常状态，异常条件下的兼容措施是否考虑？
统计需求是否明确提出？数据是否正常上报？
草拟了一个产品经理的自查表，供大家参考，手机横屏过来看。
模块 | 页面 | 功能点 | 用户状态 | 输入（操作） | 处理 | 输出（结果） | 异常处理 | 跳转 | 文案 | 统计需求 | 备注与问题 |
表格的字段如下：（范例）
范例一：手机注册
| 自查项目 | 范例 |
| 模块 | 手机用户注册 |
| 页面 | 手机用户注册页面 |
| 功能点 | 用户使用手机注册 |
| 用户状态 | 未登录用户 |
| 输入（操作） | 输入手机号、接收手机验证码并输入、输入密码； |
| 处理 | 系统查询是否有重复手机号，发送手机验证码，密码安全性检查； |
| 输出（结果） | 手机号是否可用；验证码是否正确；密码是否安全；注册是否成功； |
| 异常处理 | 如无法收到手机验证码，60秒后允许重新发送； |
| 跳转 | 注册成功后跳转产品首页（或者产品教程页、或者首页带新用户教学蒙板） |
| 文案 | 手机号；验证码；获取验证码；密码，重复密码；注册； |
| 统计需求 | 成功注册人数；注册页面PV/UV；点击重发验证码PV/UV |
| 备注与问题 | 每个手机仅允许注册一个账号； |
范例二：公屏聊天
| 自查项目 | 范例 |
| 模块 | 公屏聊天 |
| 页面 | 首页 |
| 功能点 | 用户发表公屏文字信息，并支持弹幕显示。 |
| 用户状态 | 登录用户。 |
| 输入（操作） | 输入文字，并点击发送。每条字数限制20个字。每条发送间隔X秒。屏蔽敏感词。 |
| 处理 | 文字敏感性判断；公屏聊天条数计算，支持XXX条文字并发显示；公屏聊天记录不存储； |
| 输出（结果） | 公屏显示用户昵称、VIP图标、发送信息内容；每个用户必须看到自己发送的信息，当公屏同时并发消息条数超过XX条，仅显示XX条； 点击用户VIP图标，引导进入VIP开通、续费流程； |
| 异常处理 | 敏感词显示为***号；被禁言用户给出提示；无法获取用户昵称，则显示用户ID； |
| 跳转 | 第一版公屏聊天不支持链接跳转； |
| 文案 | 按钮文案：发送； 发言间隔小于X秒，提示：发言太快，请在X秒后发送； 被禁言提示：已被禁言，可在XXX申诉； |
| 统计需求 | 发送按钮点击PV/UV； |
| 备注与问题 | 非注册用户引导注册流程。 发言管理后台设计，支持禁言、解禁、记录用户禁言前发送的最近记录、根据用户ID和昵称查询； |
产品运营的自查
产品的冷启动是否已经准备完毕？
内容运营的更新机制是否已经确认，并进行部署，是自动更新，还是人工更新，有无更新机制和审核发布机制？
产品活动运营是否已经进行规划？是否有专人负责？周期性的活动，是否已经有运营模板？
产品数据是否已经正确上报？是否通过数据测试？数据报表是否已经就绪？
新媒体运营的账号是否已经建立，是否有专人负责？是否有内容规划？内容获取途径是否已经建立？
渠道运营是否已经建立，例如应用商店的合作，SEO，ASO的计划和实施；
用户消费充值的路径是否顺畅？数值是否准确？
开发自查
每个功能是否全面自测？边界/异常参数的确认和验证（如果有以类似lib方式对外提供被调用API）
是否进行高危函数扫描？
是否进行安全漏洞扫描？
是否有内存泄漏的检测和结果（如果是C/C++代码）？
不必要log是否删除了，以及log信息是否清晰完整详细？
统计上报是否完整？
代码在编译环境已编译通过？
是否有socket泄漏？
是否影响其他相关模块功能表现？
自身系统压力是否已评估？
后端支撑系统负载变化是否已评估？
是否对业务流量有影响？
转测试文件和ARS单是否完整
产品体验是否通过？体验反馈的问题是否已修复？
是否需要灰度，采用何种灰度方案
是否需要提前发布配置？
测试人员自查
产品通过测试的发布标准建立；
用例编写是否100%覆盖需求；
是否及时有效地修改自动化用例(CGI的修改涉及到自动化用例部分的内容) ；
用例编写是否有考虑异常逻辑&优化(如web前台,性能等)的情况 ；
是否有认真阅读提测邮件的测试重点,有针对性的编写用例；
是否有发起用例评审,并根据评审意见修订用例；
测试Bug是否进行有效性跟处理,直至闭环；
版本发布时是否确认Bug单的状态为已关闭或已挂起,否则不允许发布 ；
测试报告是否及时发送；
开发完成后，页面重构人员把版本内涉及的文件提取并入测试环境原版本内 ；
提供相关ARS单信息给开发pm提单操作；
配host到测试环境，确认代码版本正确，确保无bug，确保页面准确还原设计稿；
测试过程中，会提出为改善用户体验以及细节的缺陷，测试人员会通过XXXX系统提交bug单发送给相关责任人；
评估名下bug单的优先级和处理时间点，统一时间处理；
处理完成后，及时更新bug单的状态；
代码是否上传XXX系统？
bug状态是否已更新？
遗留bug是否已经过PDM、PM、TE评估？（致命及严重bug需要测试leader和总监确认）
发布时间和内容是否符合发布规范（例如版本中包含后台server发布，晚上高峰期需要经过审批才能发，日常版本不能包含cgi等）
配置文件的修改是否恢复；
外网运营环境版本是否与测试环境一致；
影响到其他模块表现的，发布前对方测试人员是否已做功能验证并确认ok
版本发布后是否留守进行外网验证,发出验证报告后才离开
外网验证的Bug是否有跟进处理(严重Bug要跟进及时处理,其他Bug阶段性的跟进处理)