端到端测试验证系统是否满足外部需求并实现其目标，从端到端测试整个系统。
与其他类型的测试相比，端到端测试的目的是验证系统作为一个整体是否满足业务目标，而不考虑所使用的组件体系结构。
为了实现这一点，系统被视为一个黑盒，测试尽可能多地使用完全部署的系统，通过gui和服务api等公共接口操作它。
由于端到端测试更面向业务，它们经常使用业务可读的dsl，这些dsl用领域语言表示测试用例。
由于微服务体系结构为相同的行为包含了更多的移动部分，端到端测试通过增加服务之间的差距提供了价值。这为在服务之间传递消息的正确性提供了额外的信心，但也确保了任何额外的网络基础设施(如防火墙、代理或负载平衡器)都得到了正确配置。
端到端测试还允许微服务体系结构随着时间的推移而发展。随着对问题领域的了解越来越多，服务很可能被分割或合并，端到端测试使系统提供的业务功能在如此大规模的体系结构重构中保持完整。
端到端测试的测试边界比其他类型的测试要大得多
因为目标是测试完全集成系统的行为，所以端到端测试以尽可能粗的粒度进行交互。
如果系统需要直接的用户操作，这种交互可能通过一个或多个微服务公开的gui进行。在这种情况下，像Selenium WebDriver这样的工具可以帮助驱动GUI来触发系统中的特定用例。
对于无头系统，端到端测试通过使用HTTP客户机的公共api直接操作微服务。
这样，通过观察由测试边界形成的周界上的状态变化或事件来确定系统的正确性。
端到端测试的测试边界比其他类型的测试要大得多
虽然有些系统足够小，以至于单个团队拥有所有复合组件的所有权，但在许多情况下，系统会发展到依赖于一个或多个外部管理的微服务。
通常，这些外部服务包含在端到端测试边界内。然而，在极少数情况下，您可以选择排除它们。
如果外部服务由第三方管理，则可能无法以可重复和无副作用的方式编写端到端测试。类似地，有些服务可能会出现可靠性问题，导致端到端测试由于团队无法控制的原因而失败。
在这种情况下，存根外部服务可能是有益的，这会失去一些端到端信任，但在测试套件中获得稳定性。
编写和维护端到端测试可能非常困难
由于端到端测试比到目前为止讨论的其他策略包含更多的活动部分，因此它们反过来有更多失败的理由。端到端测试可能还必须考虑到系统中的异步，无论是在GUI中还是由于服务之间的异步后端进程。这些因素会导致测试套件的不稳定、过度的测试运行时间和额外的维护成本。
编写尽可能少的端到端测试
考虑到可以通过较低级别的测试实现高水平的置信度，端到端测试的作用是确保所有内容都联系在一起，并且在微服务之间没有高级别的分歧。
因此，在此级别全面测试业务需求是浪费的，特别是考虑到端到端测试在时间和维护方面的花费。
保持端到端测试套件小的一个有效策略是应用时间预算，即团队愿意等待测试套件运行的时间。随着套件的增长，如果运行时间开始超过时间预算，则删除最没有价值的测试，以保持在分配的时间内。时间预算应该以分钟为单位，而不是小时。
关注角色和用户旅程
为了确保端到端套件中的所有测试都是有价值的，围绕系统用户的角色和这些用户在系统中的行程对它们进行建模。这为用户最重视的系统部分提供了信心，并将其他任何内容的覆盖留给其他类型的测试。
像Gauge和Concordion这样的工具可以帮助您通过业务可读的dsl来表达旅程。
明智地选择你的目标
如果特定的外部服务或GUI是测试套件中不稳定的主要原因，那么可以帮助重新定义测试边界以排除组件。在这种情况下，完全的端到端覆盖可以换取套件中的可靠性。只要其他形式的测试使用不同的方法验证片状组件，这是可以接受的。
依靠作为代码的基础设施来获得可重复性
雪花环境也可能是不确定性的来源，特别是当它们不仅仅用于端到端测试时。
如果您已经采用了将基础设施作为代码的方法(这可以极大地帮助管理微服务体系结构的额外部署复杂性)，那么就可以以可复制的方式动态地构建环境。
通过为每一个端到端测试套件的执行构建一个新的环境，可以提高可靠性，同时还可以充当部署逻辑的测试。
使测试与数据无关
端到端测试中一个常见的困难来源是数据管理。依赖已存在的数据会带来失败的可能性，因为数据在环境中被更改和累积。我把这些称为假失败，因为这种失败并不表明软件有错误。
端到端测试所依赖的数据的自动化管理减少了错误失败的机会。如果服务通过公共或内部api支持它们所拥有的实体的构造，则端到端测试可以在执行之前定义它们的世界。对于那些不允许外部构造的服务，可以在数据库级别导入屏蔽数据。
由于以这种风格编写测试的固有难度，一些团队选择完全避免端到端测试，而倾向于直接针对生产环境进行彻底的生产监视和测试。
合成事务(假用户对生产系统执行真实事务)可以作为典型监视技术的补充，以提供对生产运行状况的更多了解。此外，当关键业务指标超出可接受的规范时发出警报可以帮助快速识别生产问题。