停止项目的GUI测试自动化的错误

进行非原子测试

原子测试只检查一个函数。下面的示例使用 UI 来验证用户是否可以成功签出：

这个测试只有一个断言，所以它很可能是原子的。另一方面，下面的测试不是原子的。

可以看出它正在测试页面的负载，某些字段存在，用户可以登录，用户可以注销。多重断言也是一个非常致命的赠品。

离原子测试越远，从实际 GUI 自动化中获得的稳定性、效率和确定性就越低。（确定性系统是一种在系统未来状态的发展中不涉及随机性的系统。） 

每个 Web UI 交互都是出错的机会。无效的元素定位器、不正确的同步点或新页面更新只是可能导致失败的一些 Web 交互。因此，测试中的这些交互越多，测试就越不稳定。 

因此，自动化测试将变得效率低下，因为必须花费更多的时间来调试误报。考虑一个在 20 分钟内执行的自动化测试，而不是 20 秒。如果第一个测试在第 19 分钟失败，那么必须等待 19 分钟才能调试失败。如果失败比定位器更难，可以花一个小时找出失败的原因。

尝试将手动测试转换为自动化

任何尝试将手动测试套件转换为自动化测试套件的项目都会失败。这个想法和过程从根本上是有缺陷的。首先，不会以与执行手动测试相同的方式编写测试自动化代码。其次，并非所有手动测试都应该自动化，尤其是在GUI级别。

30 分钟的手动端到端流测试可能会发现应用程序中的大量不同错误，因为测试人员可以直观地发现不一致的行为。

另一方面，除了代码告诉自动化执行的验证之外，自动化从来没有，目前也无法找到任何错误。整个网页可能不会呈现，但如果 UI 自动化检查 URL 是否显示正确的字符串，那么该自动化将继续通过。

但是，解决方案不是将所有验证添加到单个测试中（参见上面的错误2）。解决方案是正确应用模拟和状态管理，使应用程序进入所需的配置。然后，验证 GUI 应用程序是否按预期运行。 

在此示例中，第26 行的SetCartState()将 JavaScript 注入 Web 应用程序，以便可以设置应用程序的所需状态，并将用户和一些项目注入购物车。最终，这允许验证用户是否可以通过 GUI 正确执行结帐流程。

尝试通过 Web UI 执行更多操作将无法进行原子测试，并会导致错误2中提到的所有问题。因此，编码测试自动化与执行手动测试用例是一个根本不同的过程。