上线前的检查，要在别人的设备上打开一次才算完

把这个产品从头用到尾的，只有一个人

离上线只剩几天。功能齐了，设计也确认过了，包也传上了服务器，看起来只差打开。可是从第一屏一路走到最后一屏的，到现在还只有做它的那个人。

做的人走的是自己修的路。注册表单里填的是习惯填的那组值，到支付页的顺序也是自己排的那一版。这条路走过几十遍，当然不会卡。问题在于第一批用户不是从这条路来的。他们从搜索结果直接落在详情页，注册到一半关掉窗口，一小时后再回来，支付过程中按了浏览器的返回键。

所以上线前的检查，与其说是勾掉了几条，不如说是谁走过哪条路。把清单拉长，往往不如把清单上没有的那条路走一遍。

连成一条线走一遍

一屏一屏分开检查，最后会得到一种状态：每一屏都没问题，服务却用不了。用户做的事本来就不是一屏，而是从进来到把事办成的一条连续的线。把那条线不断开地走一遍：注册、收验证邮件、登录、加购、付款，再去找刚才那笔记录。

出问题的地方大多不在成功之后，而在失败之后。卡被拒了、验证邮件一直没来、支付中途按了返回、同一个按钮连按两下。顺利的那条路在开发过程中看过几十遍，失败的那条路却常常一次没走就上线了。重复下单，或者钱收了却没有订单，就是从这里冒出来的。

再注册一个新账号。开发时用的账号早就攒了权限和数据，团队里没人见过空状态。今天早上刚注册的人看到的是什么，只有新账号能告诉你。

发出去的东西，落地了才算数

屏幕上显示已发送，和这封信躺在对方的收件箱里，是两回事。咨询表单、注册验证、重置密码、订单确认、通知。这些在真发到一个真实地址、并且在那边被打开之前，都不算确认过。

开发阶段一般用一个只收不发的测试工具验证，那种工具根本不会把邮件送出去。一旦切到真实投递，发信域名的认证就成了关口。主流邮箱服务这几年已经把 SPF、DKIM、DMARC 记录当成发信域名的前提，缺了就进垃圾箱，或者干脆被拒收。这些记录握在管域名的人手里，不在写代码的人手里，所以它们经常是上线之后才被发现的。

收的那一端也看一次。如果咨询表单发出的邮件正安静地堆在负责人的垃圾邮件里，那就是表单一切正常，只是咨询永远到不了。

旧手机、慢网络、没登录的窗口

做产品的那台机器一定是最新的、屏幕宽的、网快的，而且早就登录着。把这四条一次性全部打破。用一台用了几年的真机打开，用无痕窗口从首页进来，再看网慢的时候页面是按什么顺序画出来的。图片重的站点，只有在这种条件下才露出真实的样子。

可见性设置也放在这一轮里看。开发环境通常屏蔽了搜索引擎，那条屏蔽跟着上线，网站对人正常打开，对搜索结果永远不出现。反过来也有：测试地址一直开着，同一份内容在两个地方都能访问。这两种在屏幕上都看不出来，都会在几周后变成一句为什么搜不到。

退得回来吗

再怎么查也总有上线之后才冒出来的东西，所以最后一个问题不是查了什么，而是有没有地方可以退。有没有人知道怎么退回上一个版本，这件事是几分钟就能做完还是要花一下午，如果这次改动动了数据库，备份是什么时候的。

把不可逆的部分单独标出来。界面和代码退回去就没事了，迁移过或删掉的用户数据、已经发出去的邮件、已经扣掉的款，退不回来。把这类操作从上线当天挪开，本身就是检查的一部分。

上线的时刻也是个决定。周五傍晚发布，出了事没有人在。报警要在上线之前打开，因为第一天的差别就在于，故障是你自己的监控先告诉你，还是客户打电话告诉你。

“打不开”还不是检查结果

报告如果只有一句支付坏了，修的人就得从零开始复现。点了什么、按什么顺序点的，哪台设备哪个浏览器，哪个账号什么时候，屏幕上出现了什么。这四样附上去，原因通常当场就能收窄；没有，光复现就吃掉一天。一段录屏是这四样最快的版本。

如果查的人和修的人不是同一个人，这个格式要提前约定。上线前的最后几天正是问题集中冒头的时候，没整理过的报告堆起来，修的时间就变成了读的时间。

陌生人的角色，我们来当

Weple 的上线前质量检查，就是替你走一遍团队没有理由去走的那些路。把不能出问题的流程做成真实浏览器执行的自动化测试，换着浏览器和屏幕尺寸再跑一轮，并且故意塞进真实使用中才会出现的条件：空值、超长输入、慢网络、连点、返回键。不需要仓库权限，一个能打开的地址加一个测试账号就够。我们接哪些事、按什么单位计价，写在价格说明里。开发还没做完就叫我们也可以，而且通常更好，因为查出来的东西还有时间改。发现的问题会附上复现步骤、录屏和严重程度交回给你，直接转给开发就行。