微服务架构的测试策略(2)

微服务通过网络相互连接，并使用“外部”数据存储

微服务处理通过在各个相关模块之间传递消息，来形成一个请求的响应。特定的请求可能需要与服务，网关或仓库等模块进行交互，松散定义了模块之间的连接。

自动化测试应在最高的粒度可能下覆盖所有这些通信。因此，每个测试将提供一个集中和快速的反馈循环。

资源接收到一个请求，一旦经过确认，就将调用域并开始处理请求。

如果必须对许多模块进行协调来完成业务办理，资源会将其委托给一个服务。不然，它需要与相关模块直接沟通。

需要特别注意连接到外部的服务，因为它们跨越了网络边界。该系统对于远程组件的中断应是有弹性的。网关包含逻辑来处理这些错误情况。

通常情况下，与外部服务通信的粗粒度会超过等值进程通信的粗粒度，以避免API繁琐和等待时间。

同样，与外部数据存储的通信有不同的设计考虑。而一个服务比起外部服务，常常逻辑上更耦合至其数据存储，在通过一个可能导致延迟和中断风险的网络边界后数据存储仍然存在。

网络分区的存在会影响采用的测试风格。这些模块的测试可能耗费较长的执行时间，并可能会由于团队可控制范围之外的原因而失败。

多服务作为一个系统协同工作来提供有商业价值的功能

通常情况下，小组是作为一个或多个微服务的监管者。这些服务交换消息来处理更大的业务请求。就交换格式而言，JSON是目前最流行的，除此之外最流行的是一些使用XML的替代方法。

在某些情况下，异步发布-订阅通信机制比同步的点至点机制更适合用例。 Atom联合格式作为实施微服务之间的发布-订阅的轻量级方式，正变得越来越受欢迎。

由于一个业务请求会跨越多个由网络分区隔开的部件，考虑系统中可能的故障模式是十分重要的。如超时， circuit breakers和隔板等技术可以帮助维持整个系统的正常运行时间，即便一个组成部分停止运行。

在大型系统中，往往有多个团队各自负责不同的限界上下文。

有关外部服务的测试与那些对团队控制下的服务的测试有所不同，因为外部团队的服务的界面和可用性更难得到保证。

单元测试对应用程序可测试软件中的最小单元进行检测，以确定它的运行状态与预期是否相同。

单元测试的大小没有严格的定义，但单元测试一般写在类级别或针对一小群相关类。被测试的单元越小就越容易使用单元测试来体现其运行状态，因为该单元的分支复杂度更低。

通常情况下，编写单元测试的最大难点在于当一个模块应该被分解成独立连贯的几个部分，并应当进行单独测试的时候。因此，单元测试不只是一个有用的测试策略，也是一个强大的设计工具，尤其是在与测试驱动开发相结合时。

通过进行单元测试，可以看到被测部分是否已与其合作者区分开所产生的重要区别。

孤立型单元测试(Solitary unit testing)重点集中于通过观察测试模块运行状态的状态改变进行测试。这完全通过被测单元的接口完全将其视为一个黑箱测试。

这些测试类型之间没有竞争，经常一起使用在相同的代码库中，以解决不同的测试问题。

（待续）

{测试窝原创译文，译者：大头}

译者简介：大头，在读日本九州大学修士，计算机专业，主研究方向为文本挖掘，及自然语言处理。