如何确定自动化功能测试是否成功

目标：

场景：

问题： 确定用户是否成功注册的最佳方法是什么。我可以想象以下选项：

如果模拟了任何子系统，则可以检查是否调用了诸如“DB.SaveUser(...)”之类的特定函数。这会破坏功能测试是黑盒测试的想法，并要求测试编写者了解实现。
如果我们使用真实的子系统，例如可以检查数据库中的行是否存在。像上面的尝试那样，这还不够。
可以使用另一个函数（如“UserManager.CheckUser(...)”）来检查用户是否已创建。这将引入另一种经过测试的方法，也可能存在没有“测试对应物”的操作，或者必须实现它们，仅用于测试 - 这似乎并不理想。
我们可以检查结果“SignupResult”和/或检查抛出的异常。这将需要定义方法的接口。这也需要所有方法返回一个合理的值 - 我想无论如何这将是一个很好的方法。

对我来说，最后一种方法似乎是要走的路。我对么？还有其他方法吗？我们如何检查诸如“向新用户发送了一封电子邮件”之类的副作用？

您可能想要熟悉 Test Pyramid 的概念。

设计和实施自动化测试没有单一的正确方法 - 只有 trade-offs。

如果您绝对必须避免了解有关实现细节的任何知识，那么实际上只有一种方法：测试实际系统。

问题在于自动化测试往往会留下持续状态变化的痕迹。例如，我曾经做过类似您所询问的事情，并编写了一系列使用实际系统（REST API）来注册新用户的自动化测试。

运营人员很快要求我关闭该系统，即使它只产生了一小部分实际用户。

您可能认为次佳的做法是针对某些暂存或测试环境进行完整的系统测试。是的，但是您必须相信此环境足以反映实际生产环境。你怎么会知道？通过了解实现细节。我不知道你怎么能避免这种情况。

如果您接受一点关于实现细节的知识是可以的，那么它很快就会变成一个可以接受多少知识的问题。

测试金字塔背后的经验是，单元测试比集成测试更容易编写和维护，而集成测试又比系统测试更容易编写和维护。

我通常发现这类测试的最佳位置是 self-hosted state-based tests，其中只有实际的系统依赖项（例如数据库或电子邮件服务器）被 Fakes（而不是 Mocks）替换。

也许是需求需要进一步细化。例如，您的用户究竟会做什么来验证她是否正确注册？她怎么会知道？我想她会查看系统的响应：“帐户已成功创建”。然后她只知道系统会发布一条消息以响应该有效的创建尝试。对已发布消息的测试是可操作的，只是创建一个帐户则不然。作为更具体的测试，在较低的测试级别，这是可以接受的。

那么想想为什么用户应该注册？只看回复？要求如何：

当用户使用有效的用户名和密码进行注册时，她应该能够使用该用户名和密码的组合成功登录系统。

然后可以添加登录成功的定义，就像用户名和密码的有效性定义一样。

这是可行的，无需了解内部细节。就系统集成测试而言，它应该是可以接受的。