上线前如何测试你的应用：实用发布前测试计划

测试应用上线前，先列出用户必须能够完成的几个关键流程，分别用笔记本电脑和手机，以全新用户的身份走一遍，然后尝试各种可能出错的情况：数据为空、输入错误、使用第二个账户、网络缓慢。涉及金钱或隐私数据的测试要格外小心，发布后还要在线上网址上重复主要流程。最后，请一位从未接触过应用的人在旁边试用，你只观察、不插手。

这件事不需要专门的测试团队，也不需要测试框架。你只需要一份清单、一两个小时，以及认真逐项点击的耐心。

第一步：列出最重要的流程

流程指的是用户前来完成的、从头到尾的一项任务。大多数应用真正重要的流程有三到六个。以一款预约应用为例：

1. 注册账户并确认
2. 找到一节课并预约
3. 取消预约
4. 为课程套餐付款
5. 员工：查看今天的预约

如果你已经编写过用户故事，那么其中的验收标准就已经是你的测试用例。如果还没有，就为每个流程写一行，说明“成功”是什么样子。

为它们排序。那些直接影响收入或每位用户都会用到的流程（注册、登录、核心操作），应当优先、重点测试。

第二步：以新用户身份测试顺利路径

“顺利路径”指的是流程按预期正常进行。请以陌生人的视角来测试：

• 使用无痕窗口，这样你没有登录，也没有保存的数据。
• 使用一个全新账户，并使用你能收到验证邮件的真实邮箱。
• 从首页或某个链接开始，而不是从你在开发时收藏的页面开始。

新用户没有任何数据。很多缺陷只有在列表为空、个人资料没有头像、还没有任何购买记录时才会暴露。你自己那个塞满测试数据的账户，会把这些问题隐藏起来。

第三步：尝试把它搞坏

现在，把每个流程再走一遍，并故意做错误的操作。

刷新这一点尤其值得留意：如果你点击时一切正常，但在更深层的页面上刷新会出现 404，请参见部署后如何修复 404 错误。

第四步：用两个账户测试权限

对于任何带账户的应用来说，这都是最重要的测试，也是最常被跳过的。

创建两个普通用户 A 和 B，如果你的应用有管理员角色，再创建一个管理员。

• 以 A 的身份创建一条记录。然后登录 B。B 能否看到、编辑或删除它？除非设计如此，否则 B 不应该能做到。
• 以 A 的身份复制其中一条记录的网址。然后登录 B，直接打开这个网址。
• 以普通用户身份，通过输入网址的方式访问管理员页面。
• 完全退出登录，再尝试访问同样的网址。

如果这里发现问题，修复之前不要上线。检查必须在服务器上完成，而不能只是隐藏一个按钮。我们的AI 搭建应用安全检查清单有更详细的说明。

第五步：在真实设备上测试

请在真正的手机上打开应用，而不只是把浏览器窗口缩窄来看。

• 每个按钮都能不放大页面直接点击吗？
• 键盘会不会遮住你正在输入的输入框？
• 表格和宽内容是可以滚动或自动换行，还是把整个页面撑向一侧？
• 不用捏合放大，文字能清楚阅读吗？

如果条件允许，至少用一台 iPhone（Safari）和一台安卓手机（Chrome）测试一下。Safari 在日期、视频和固定定位元素等方面有其特有的问题。

第六步：端到端测试金钱和邮件

任何涉及扣款或发送邮件的功能，都需要完整地走一遍。

支付。 使用你的支付服务商的测试模式和测试卡号。检查成功付款、被拒付的银行卡，以及取消结账的情况。确认付款后，订单或订阅会在你的应用中显示，而不仅仅是在服务商的后台。如果你的应用依赖 Webhook（即支付服务商发送给你服务器的消息），请确认这些消息在线上应用上能够正常收到，而不只是在开发环境中。然后在正式上线前切换为正式密钥，完成一笔真实的小额付款，并退款。

邮件。 用真实地址在两三个不同的邮箱服务商注册。检查邮件能否送达、是否进入垃圾箱，以及邮件中的每个链接是否都指向正式域名，而不是预览地址。

第七步：检查速度和错误

• 打开浏览器开发者工具（右键 → 检查），在每个主要页面上查看控制台标签页。即使页面看起来没有问题，红色的错误信息也值得修复。
• 用移动数据而非 Wi-Fi 在手机上打开网站。如果首屏要好几秒，请先检查图片大小。
• 在 Chrome 开发者工具中运行 Lighthouse 等免费审计工具，快速了解性能和无障碍方面的状况。

第八步：测试线上应用，而不只是预览

预览环境和已发布的应用并不是同一个运行环境。在向别人宣布上线之前，请在线上网址上重复主要流程：

• 发布后的应用是否已设置所有环境变量和密钥？
• 它是否使用了正确的数据库，数据是否符合预期？
• 登录跳转和邮件中的链接是否使用正式域名？
• 在深层页面上刷新，是否能正确加载？

第九步：观察别人使用

给一两个人一个目标（“预约周六的一节瑜伽课”），而不是操作说明。观察他们，但不要帮忙，并记下他们在哪些地方犹豫。这是找出措辞不清和隐藏按钮的最快方法。如果想做更大规模的测试，请参见如何进行测试版测试。

遇到错误时，请把它完整地记录下来，包括复现步骤、预期结果和实际结果。我们关于如何写好一份错误报告的指南给出了格式范例。

使用 AI 辅助测试

如果你是用 AI 构建应用，可以请它帮忙规划和执行测试：

列出这个应用的主要用户流程，并针对每个流程列出最容易出错的边界情况：空状态、无效输入、权限和刷新。整理成一份我可以逐项完成的清单。

用两个不同的测试用户登录，检查用户 B 能否看到或修改用户 A 创建的任何内容，包括直接打开 A 的记录网址。在修复任何问题之前，先报告你的发现。

请把 AI 生成的测试报告当作初步结果。关于金钱和权限的流程，仍需亲自点击验证。

Mythex 中的测试

在 Mythex 中，/test 命令会运行应用测试：智能体会在你的实时预览中驱动浏览器，点击各个页面，截图，并在聊天中报告出错的流程。它最适合针对某个具体流程使用，例如“测试注册和预约一节课”。用 /fix 或普通消息修复发现的问题，然后再次运行 /test。应用测试使用的是预览环境，因此发布后仍需自己在线上网址上检查主要流程。参见文档中的应用测试，以及我们关于如何调试 AI 搭建应用的指南，以便在出现故障时参考。

常见错误

• 只用自己的身份测试。 你的管理员账户里有大量数据，会掩盖空状态和权限方面的问题。
• 只在笔记本电脑上测试。 许多网站的访客大部分是用手机访问的。
• 跳过第二个账户。 数据在用户之间泄露，是应用上线时可能出现的最严重的缺陷。
• 迷信预览环境。 线上应用的设置不同，也要测试。
• 修复缺陷后不重新测试相邻功能。 修改一个表单可能会破坏另一个与之共用代码的表单。

上线前检查清单

• 主要流程已列出并排好优先级
• 每个流程都以全新用户身份在无痕窗口中通过测试
• 空白、无效、过长和重复的输入都已正确处理
• 每个页面的刷新都正常
• 用户无法看到或修改彼此的数据，即使通过网址直接访问也不行
• 普通用户和未登录的访客无法访问管理员页面
• 在真实的 iPhone 和安卓手机上可以正常使用
• 支付已测试：成功、被拒、取消，并且应用在之后正确更新
• 邮件能够送达、不会进入垃圾箱，并且链接指向正式域名
• 主要页面的控制台没有红色错误
• 主要流程已在线上网址上重复测试
• 至少有一位外部人员在你旁边试用过

常见问题