测试容错代码

Question

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

这一切似乎都运行良好，但我们很难确信地说出这一点，因为我们发现很难测试我们的容错代码。到目前为止，我们提出了两种策略，但都不能完全令人满意:

• 让外部进程监视服务器代码，然后尝试在外部进程认为测试中的适当时间点将其终止
• 将代码添加到应用程序中，这将导致它在某个知道的关键点崩溃

我对第一种策略的问题是外部进程无法知道应用程序的确切状态，因此我们无法确定我们是否击中了代码中最有问题的点。我对第二种策略的问题是，虽然它可以更好地控制故障发生的情况，但我不喜欢在我的应用程序中注入(inject)故障的代码，即使有可选的编译等。我担心它会很容易忽视故障注入(inject)点并将其滑入生产环境。

Answer 1

我认为有三种方法可以解决这个问题，如果可行的话，我可以建议对这些不同的代码片段进行一套全面的集成测试，使用依赖注入(inject)或工厂对象在这些集成过程中产生损坏的操作。

其次，使用随机 kill -9 运行应用程序并禁用网络接口(interface)可能是测试这些东西的好方法。

我还建议测试文件系统故障。你将如何做到这一点取决于你的操作系统，在 Solaris 或 FreeBSD 上我会在文件中创建一个 zfs 文件系统，然后在应用程序运行时 rm 文件。

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

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