上线验收不是“打开首页能看”就结束,而是从交付结果倒推:页面、功能、内容、数据、权限、文档各自达到什么状态才算可交付。执行时先列验收清单,再逐项对照测试环境与正式环境,最后留下可复查的记录和未通过项。
验收前要明确这次交付包含哪些页面、哪些功能、哪些后台操作。把“首页正常”“表单能提交”“手机端不串版”写成可判断的条目,而不是“整体感觉可以”。每条标准至少包含三部分:操作路径、预期结果、判断方式。例如:在手机浏览器打开联系页,填写姓名和电话后提交,页面应出现提交成功提示,后台应能看到这条记录。适用条件是项目已有明确页面清单;如果页面范围还没定,先补范围说明,否则验收会变成无限追加。
验收不只看前台,还要看交付物是否齐全。建议按下面几类逐项核对:
这些资料缺一项,验收就应记为“有条件通过”或“未通过”,而不是口头说“后面再补”。
把验收分成测试环境和正式环境两轮。测试环境重点看功能和内容,正式环境重点看解析、证书、缓存和真实数据。可执行步骤:
如果某项现象时好时坏,先区分“可能原因”和“已经定位的原因”。例如表单偶发失败,可能是网络、接收邮箱限制或程序处理超时,不能直接断定是服务器问题;需要看提交日志和接收端记录后再下结论。
验收表上每一条都应有责任人和复验人。开发负责修复功能与部署问题,内容负责替换正式文案和图片,项目负责人负责确认业务规则。复验时只针对未通过项和受影响的相关项,不重新全量测试,但要把复验结果写回同一张表。判断结果分三种:通过、有条件通过、未通过。有条件通过必须写清剩余事项、完成时间和不完成的影响。
最终交付至少保留:验收清单及结果、未通过项处理记录、账号和权限交接说明、备份位置与恢复步骤、正式环境页面清单。这样后续换人维护时,不需要重新猜测当时做了什么。下一步可以直接拿现有页面清单,按上面的检查项做一次逐条核对,把未通过项转成带责任人和日期的修复任务。