测试容错代码

Question

我目前正在开发一个服务器应用程序，如果我们已经同意尝试并维护一定级别的服务的话。我们要保证的服务级别是:如果请求被服务器接受，并且服务器向客户端发送确认，我们希望保证即使服务器崩溃，请求也会发生。由于请求可以长时间运行，并且确认时间需要短，所以我们通过持久化请求，然后向客户端发送确认，然后执行各种操作来满足请求来实现这一点。在执行操作时，它们也会被持久化，因此服务器在启动时就知道请求的状态，还有各种具有外部系统的协调机制来检查日志的准确性。

这一切似乎都运行得很好，但我们很难用任何信念来说这一点，因为我们发现很难测试我们的容错代码。到目前为止，我们已经提出了两种策略，但这两种策略都不完全令人满意：

• 有一个外部进程，监视服务器代码，然后尝试在外部进程认为是测试
• 中的适当点时关闭它，该应用程序将导致该应用程序崩溃某个特定的临界点--

。

第一种策略的问题是外部进程无法知道应用程序的确切状态，因此我们无法确定我们达到了代码中最有问题的点。我对第二种策略的问题，虽然它给予了更多的控制权，如果出现了错误，那就是我不喜欢在我的应用程序中插入错误，即使是可选的编译等等。我担心太容易忽略错误注入点，让它滑到生产环境中。

Answer 1

我认为有三种方法来处理这个问题，如果可用的话，我可以为这些不同的代码提供一套全面的集成测试，使用依赖注入或工厂对象来产生这些集成过程中的中断操作。

其次，使用随机杀死-9运行应用程序和禁用网络接口可能是测试这些功能的好方法。

我还建议测试文件系统失败。如何做到这一点取决于您的操作系统、Solaris或FreeBSD，我将在一个文件中创建一个zfs文件系统，然后在应用程序运行时对该文件进行rm。

如果您正在使用数据库代码，那么我也会建议测试数据库的失败。

依赖注入的另一个替代方案，可能也是我使用的解决方案是拦截器，您可以在代码中启用崩溃测试拦截器，这些拦截器会知道应用程序的状态，并在正确的时候介绍上面列出的故障，或者您可能想要创建的任何其他故障。它不需要对现有代码进行更改，只需要一些额外的代码来包装它。

Answer 2

对于第一点，一个可能的答案是对外部过程进行大量的实验，从而增加影响代码中有问题部分的可能性。然后，您可以分析核心转储文件，以确定代码实际崩溃的位置。

另一种方法是通过保存库或内核调用来增加可观察性和/或可命令性，即不修改应用程序代码。

您可以在维基百科的页面上找到一些资源，特别是在软件实现故障注入部分。

Answer 3

你对故障注入的关注并不是一个根本性的问题。您只需要一种万无一失的方法来防止这样的代码在部署中结束。这样做的一种方法是将错误注入器设计为调试器。也就是说，故障是由进程外部的一个进程注入的。这已经提供了一定程度的隔离。此外，大多数OS提供某种访问控制，除非特殊启用，否则无法进行调试。在最原始的形式中，它将它限制为root，而在其他操作系统上，它需要一个特定的“调试特权”。当然，在生产中没有人会有这种情况，因此你的错误注射器甚至不能在生产上运行。

实际上，故障注入器可以在特定地址设置断点，即函数或甚至代码行。然后，您可以对此做出反应，例如，在某个断点被击中三次之后终止该进程。