在分布式系统中，软件测试工程师如何测试你不知道的东西？

在最简单的C/S模型当中，一次网络通讯会发生这样的过程：加我VX：atstudy-js 回复“测试”，进入 自动化测试学习交流群~~​

1.客户端将消息发送到网络上。

2.网络向服务器发送消息。

3.服务器验证消息。

4.如果需要，服务器更新其状态。

5.服务器将回复发送到网络上。

6.网络向客户端发送回复。

7.客户端验证回复。

8.如果需要，客户端更新其状态。

但随着分布式系统变得越来越复杂，测试已经达到极限。它通常无法解决生产环境的复杂性，例如发生在网络上的随机故障和其他奇怪的间歇性错误；配置限制和配置漂移；未知的呢？你怎么能测试你不知道的东西？

例如，在实例动态启动和停止的系统中，如果任何实例磁盘空间不足会发生什么情况？如果一个实例没有剩余空间来写入日志，它在大多数情况下会快速失败，这是一个真正的问题，因为快速失败会产生一个黑洞。因为它失败得很快，通常会欺骗负载均衡器，认为该实例可以自由地接收更多请求，而这反过来也会导致更多的失败。

如果我们能更早地发现这一点，我们就可以事先进行改进并避免中断。例如：

1 — 使用日志轮换。

2 — 使用集中式日志服务。

3 — 监控磁盘空间。

4 — 在每周运营会议上审查指标。

5 — 当设备上只剩下 10% 的磁盘空间时发出一些警报。

幸运的是，有一种实践可以帮助解决这种未知数——正如你可能猜到的，混沌工程。

混沌工程是一个过程：

1、通过创建破坏性事件（例如服务器中断或 API 限制）来对测试或生产环境中的应用程序施加压力。

2、观察系统如何响应。

3、实施改进。

我们这样做是为了证明或反驳我们对系统处理这些破坏性事件的能力的假设。与其让这些破坏性事件发生在凌晨 1 点、周末和生产环境中，我们不如在受控环境中在工作时间创建它们。混沌工程不是无目的地随机注入故障而是通过精心计划的实验在受控环境中注入故障，以建立对应用程序和工具的信心，以承受动荡的条件。

虽然混沌工程是一个很好的选择，但事实是它很难开始，因为在大多数情况下，你必须将不同的工具、脚本和库拼接在一起，以涵盖可以在系统中注入的所有故障。基础设施、网络、应用程序——每个目标都有不同的工作工具，无论是库、代理还是要安装的容器。客户通常不想在他们的应用程序中安装任何额外的东西——要安装的东西越多，就越复杂。或者，如果必须安装东西，它们需要集中管理和统一。

为此我们选择将 ChaosBlade 封装成一个统一的网页工具，选择 ChaosBlade 的原因是它支持目前主流的故障注入场景，相对其他几个故障注入工具，ChaosBlade 故障注入覆盖的场景最全，支持四大类、几十种常用的故障注入能力。

该网页工具的运行方式是提供一个对于用户非常友好的界面，注入故障时只需要点击相应故障的按钮，该故障会以 HTTP 请求的方式发送到测试环境的 ChasosBlade 中，ChaosBlade 以命令行的方式来执行具体的故障注入请求，同时将返回执行的结果。