在 AI、SaaS 和 Web 技术的交叉领域构建产品。撰写关于实验、产品开发、增长以及我所学到的东西。

访客提交了联系表单并看到“成功”。网站所有者从中了解到了什么？

仅仅是面向访客的页面显示了确认信息。所有者尚未确认相应的咨询能否在业务预期接收的位置被找到，或者是否有人能够回复它。将这些视为独立的检查点，可以让联系表单测试更加精确，而无需猜测可能出了什么问题。

这种区分并非仅仅是理论上的。在一份 Shopify 社区报告中，联系表单提交看似成功，但并未通过电子邮件送达。该个别报告并不表明该问题发生的频率。它确实说明了为什么应当独立检查显示结果和业务侧结果。

将咨询路径建模为可观测状态

出于测试目的，定义三个可观测状态：

这些是观测结果，而不是可以互换的成功定义。第一个描述的是界面。第二个描述的是业务方能够定位到的内容。第三个描述的是收到之后采取的行动。即便是第三个检查点也有边界：发送回复本身并不能验证收件人是否收到或阅读了它。

这个模型之所以有用，是因为它能防止不完整的测试看起来是完整的。确认信息的截图只能确立第一个状态，而非全部三个状态。反过来，如果业务方找到了咨询但尚未尝试回复，那么测试只确立了接收，而没有测试回复步骤。

你不需要知道差距的根本原因就能准确地记录它。这个模型的意义在于让差距足够具体，以便进行调查。

设计一个可在两端匹配的测试

考虑在现有网站上提交一个带标记的测试。在消息中放入一个独特的短语，例如“Inquiry path test 2:15”，并记录输入的地址和提交时间。该短语只是日后识别此测试的一种方式；它并不声称任何特殊表单能力。

提交前，确定业务方将在何处查找该咨询以及由谁执行该检查。然后以访客身份提交表单，并准确记录屏幕上显示的内容。在预期目的地，查找该独特短语，并将找到的咨询与您提交的详细信息进行比对。如果找到，则发送与该测试咨询关联的回复。

结果可以记录为一条简短追踪：

| 检查点 | 待回答的问题 | 示例测试记录 |
| --- | --- | --- |
| 确认 | 面向访客的页面显示了什么？ | 已显示确认 |
| 接收 | 是否在预期目的地找到了匹配的咨询？ | 已找到匹配咨询 |
| 回复 | 是否针对该咨询发送了响应？ | 已发送回复 |

示例列描述的是一个假设的已完成测试，而非从真实网站观察到的结果。对于实际测试，应记录实际发生的情况，而不是填写预期答案。

独特短语之所以重要，是因为它将访客侧的观察与业务侧的检查连接起来。如果没有匹配它们的方式，找到一条咨询并不一定能确定找到了该特定测试咨询。匹配步骤是此诊断的技术核心：它将两个独立的观察转化为一次提交的追踪。

假设确认出现了，但检查预期目的地的人找不到测试咨询。可辩护的结果是：“已显示确认；本次检查期间未找到匹配咨询。”这还不是对原因的诊断。

这种措辞保留了两个重要限制。第一，屏幕上的结果与接收检查不一致。第二，“本次检查期间未找到”描述了观察的范围。它并不声称该咨询不可能存在于其他地方，也不声称某个特定组件失败了。

当某个检查点尚未测试时，同样的原则也适用。如果尚未找到匹配咨询，则将回复检查点标记为“未测试”，而不是报告回复失败。如果找到了咨询但没有人发送响应，则记录回复步骤未被实际执行。这些区分可能看起来过于琐碎，但它们能在有人调查或重复检查时保持测试记录的有用性。

一种紧凑的记法是：

为每个条目附上相关细节：显示了什么、在哪里查找了询问，或哪个测试询问收到了回复。仅有一个绿色对勾会丢失解读结果所需的信息。

“联系表单可用”对于单个测试来说是一个过于宽泛的验收标准。一个更可测试的版本是：“对于此带标签的提交，面向访客的确认信息出现了，匹配的询问在业务预期位置被找到，并且针对该询问发送了回复。”

该陈述并不承诺未来每次提交都会表现相同。带有未定位询问的测试也不能确定还有多少其他询问（如果有）受到影响。它只说明该测试实际覆盖了什么。

如果在检查不成功之后进行了更改，请使用新的带标签提交并再次运行检查点。否则，设置或工作流中的更改可能被误认为询问路径已验证的证据。验证来自观察新测试，而不是来自进行更改。

对于现有网站所有者来说，这是一种实用的诊断方法，而不是要求建立复杂的测试系统。从一个可追踪的询问开始。将界面结果、业务接收和回复保留为单独的条目。当证据止于一个检查点时，让结论也止于那里。

在 AI、SaaS 和 Web 技术的交叉领域构建产品。撰写关于实验、产品开发、增长以及我所学到的东西。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Hacker Noon