购买前如何测试邮箱检查器的准确性

使用一小组预期结果已经通过独立方式确认的账户，测试邮箱检查器。 样本不应只包含成功登录；还应保留测试条件， 并比较保存输出与应用显示的结果。

这种方法可以评估与实际流程有关的准确性： 检查器能否区分访问完成、凭据被拒、所需账户操作， 以及无法完成的检查。 下文介绍的是评估方法，而不是 Mail 的基准测试。

建立已知账户样本

使用自己拥有或获准管理的账户。 记录预期结果之前，通过独立且适当的服务商登录流程确认当前状态。 已经处于登录状态的浏览器标签页，并不是对输入文件中密码的一次新测试。

样本应覆盖真实列表中的服务商。 包含可用账户，并在能够取得时加入验证或锁定状态已经独立确认的账户。 只有在小规模授权测试中，才使用受控的错误密码； 避免反复触发服务商保护机制。

记录证据和时间，不要假定状态始终不变。 密码可能更改，账户可能要求验证，服务商也可能暂时不可用。

记录检查条件

每次比较都使用固定的输入样本。 记录所选方式、回退设置、线程数、超时、重试和连接配置。 如果比较两个检查器，也要记录无法配置成一致的差异。

将账户身份验证与可选额外任务分开。 如果要评估的是登录检查准确性， 应先比较登录结果，再根据无关的可选任务做判断。

有用的记录应为每个账户保留一行，包含以下字段： 服务商、预期结果、证据时间、检查方式、观察到的状态、原始错误和检查时间。 妥善保护密码和会话资料；评估摘要不需要重复这些内容。

比较分类结果

逐个检查不一致的结果。 将未完成登录记为 Success，会产生虚假的成功； 将传输错误记为 Invalid，则是另一种分类问题。

已知条件	需要检查的结果
身份验证完成	检查器是否确认访问已完成
服务商拒绝提供的凭据	是否记录凭据被拒绝
服务商要求账户操作	该要求是否仍然清楚可见
连接无法完成	检查是否保持未解决状态

Mail 的 Outlook 方式要求有访问令牌，才算 Success。 密码看似被接受、但服务商登录流程尚未完成时， 这是可以具体检查的判断标准。 存在 Cookie 并不等同于满足成功条件。

单独统计未解决的检查

不要在不说明的情况下，省略困难检查以让准确率显得更高。 记录有多少账户得到了确定结果，有多少仍未解决。

例如，假设样本包含 25 个账户，其中五次检查超时， 这五次需要单独计入未解决数量。 其余 20 个账户符合预期，并不能证明全部 25 个账户都被正确分类。

将分类错误与完成率分开。 两者都重要：工具可能正确分类了已完成的检查， 却让过多服务商账户未完成，无法满足实际需要。

检查可重复性和保存输出

在记录好的条件下重复检查小样本，并逐账户比较结果。 将差异与服务商当前状态核对之后，再判断是否由软件造成。 保留较早运行，使比较能够被追溯检查。

在 Mail 中，检查本地 History 以及状态和错误输出文件。 确认保存的记录与可见结果一致， 并且技术故障仍然能够与 Invalid 区分开。

判断检查器是否适合自己的列表时，应使用这些证据。 具有清晰未解决案例、可以重复的评估， 比没有样本、条件和 Success 定义的准确率宣传更有价值。