测试容错代码

Question

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

这一切似乎都工作得很好，但我们很难用任何信念来说这一点，因为我们发现测试容错代码非常困难。到目前为止，我们已经想出了两种策略但也不是完全满意：

• 有一个外部进程看服务器代码，然后尝试，并在外部进程的想法把它扼杀掉是在测试的适当点
• 添加代码，将导致崩溃一定知道临界点
应用

我与第一个战略问题是外部进程无法知道应用程序的确切状态，所以我们不能肯定我们”重新编写代码中最有问题的一点。我对第二个策略的问题，虽然它提供了更多的控制权，但是错误需要，我不喜欢有代码在我的应用程序中注入错误，即使是可选的编译等。我担心看起来很容易过分注入点并让它进入生产环境。

Answer 1

我认为有三种方法可以解决这个问题，如果可以的话，我可以为这些不同的代码片段提出一套全面的集成测试，使用依赖注入或工厂对象在这些集成过程中产生破坏的行为。其次，使用随机kill -9运行应用程序，并禁用网络接口可能是测试这些事情的好方法。

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

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

依赖注入的另一种替代方法，可能是我将使用的解决方案是拦截器，您可以在代码中启用碰撞测试拦截器，这些知道应用程序的状态并在正确的时间引入上述故障，或您可能想要创建的任何其他人。它不需要修改你现有的代码，只需要一些额外的代码来包装它。

Answer 2

第一点可能的答案是将实验与外部过程相乘，以便增加影响有问题的代码部分的概率。然后，您可以分析核心转储文件以确定代码实际崩溃的位置。

另一种方法是通过对库或内核调用进行存根，即不修改应用程序代码来提高可观察性和/或可命令性。

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

Answer 3

我正要写一样贾斯汀:)

我会建议在测试过程中，以取代可能是记录组件（如果你有一个，如果不是，我强烈建议要实现的组件一...）。将代码替换为生成错误的代码相对容易，并且记录器通常会获取足够的信息来了解当前的应用程序状态。

此外，确保测试代码不会投入生产似乎也是可行的。尽管我会劝阻条件编译，但是应该使用一些配置文件来选择日志记录组件。

使用“随机”杀死可能有助于检测错误，但由于其非确定性而不适合进行系统测试。因此我不会将它用于自动测试。

Answer 4

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

实际上，故障注入器可以在特定地址，即函数或者甚至是代码行处设置断点。然后你可以对此做出反应，例如通过在特定断点点击三次后终止该过程。