为什么要进行日志测试和如何进行日志测试

关键点

1.在分布式的、可扩展的系统（通常包含不稳定的基础设施）中排除故障的效率通常取决于是否有充分的日志记录和搜索设备。

2.唯一事件ID、事务追踪技术和结构化的日志输出等技术，让我们得以透彻地了解应用程序的行为，以及应用程序是否在正常运作。

3.日志记录不再会“拖慢”系统性能，相反地，它在系统故障恢复中有重要的速度增益，尤其是在使用了日志聚合的情况下。

4.我们需要测试核心操作需求，如日志记录。

5.我们可以采用类似功能性需求的方式来测试日志，比如用户故事和BDD场景等。

现代日志聚合和搜索工具为团队的建立、测试和运行软件系统提供了重要的新功能。通过把日志作为一个核心系统组件，并使用如唯一事件ID、事务追踪技术和结构化的日志输出等技术，我们可以获得对应用程序的行为和正常运作的丰富的见解，尤其是跨组件的视图。这篇文章解释了为什么测试日志是有价值的和如何用现代日志聚合工具做日志测试。这种方法使日志成为了一种渠道，使分布式系统更具可测试性。

日志在整体上会为各方面提速

按一直以来的观点，许多人认为，日志会“拖慢”软件。如果使用的是同步文件I / O、慢速磁盘存储、甚至更慢的 络速度，从这些方面来看这种观点有一定的道理。因此，我们往往对在现场环境中运行的软件中记录下来的日志，抱着审慎的态度。然而，异步文件I/O和SSD存储正在成为常态，1GB、10GB，甚至100Gb以太 也越来越普遍，日志的性能特性现在已经变得不同。

现在，除了时间关键型的应用程序，如金融交易和其他复杂算法的情况下，在软件系统中我们已经很少单纯地优化软件的运行速度了。特别是在分布式系统、云和物联 （IoT）的背景下，我们需要考虑的是在发生错误后，恢复服务的时间（通常被称为“平均恢复时间”，Mean Time to Recovery，MTTR）。同时，我们也要考虑在上游（测试）环境里，确定问题原因所需要的时间。

现代日志聚合和搜索工具——比如ElasticSearch、Logstash、Kibana、LogEntries、Loggly、Sematext等等——给我们提供了丰富的方法与我们的软件的进行交互，它提供了丰富的用户接口去判断应用程序的行为，也提供了可编程的REST API来在多台服务器之间搜索和关联事件。

在跟踪一个包裹时，我们可以看到这些状态，比如“到达仓库”、“运输中”和“已送达”等等；这些都代表了特定的状态或事件，并且每一个都有一个系统内的内部标识符（ID）——事件ID。

如果我们想把一个关于发生在日志流中预期或意外事件的测试用例自动化，我们可以通过curl做一个简单的API调用来进行查询。

例如，我们可能想检查发生了一次数据库查询（预期发生事件DatabasePreQuery 和DatabasePostQuery）并且没有出现连接问题（突发事件DatabaseConnectionFailed）。

这里是为DatabasePreQuery事件（你也可以在GitHub找到它）查询Elasticsearch API （在本地运行）的curl命令：

这个查询的结果可能是，例如（为了清晰度重新格式化过，并添加了行数以供参考）：

以上的第10行表明，查询精确地匹配上了一条日志（总命中量为1），并在第13行开始是查询响应，实际的日志消息在第18行开始的。

那么，我们可以使用我们的选择工具，将这些搜索结果输入到我们的数据库中查询测试，以解析JSON的响应并且确定事件是否发生了。

例如，测试用例的基本Ruby实现（你也可以在GitHub上找到它）：

我们使用’json’ Ruby gem包去解析查询前后的curl搜索结果，这些结果是我们先前保存在重命名后的文件中的（前10行）。第12行到第14行说明了我们对测试结果的预期（即日志流中应该包含一个单一的DatabasePreQuery事件，一个单一的DatabasePostQuery事件，并且没有DatabaseConnectionFailed或其他事件）。最后一行是实际的测试（如果我们的期望都是正确的Ruby将返回“ture”，否则就会返回false）。

更复杂的测试（或对事件的分析）可能，比如说，需要在给定时间内搜索所有数据库事件、计算查询次数、故障等。然而，使用的方法和上面描述的是一样的，只是在一个较大的JSON响应包中要执行稍微复杂的迭代代码。

这是一个对这类测试进行curl查询的例子（你也可以在GitHub找到它）：

我们也可以在系统中跟踪一条单一的执行路径，使用当活动最初被启动时我们注入系统的相关的ID：比如，用户点击一个按钮或一个批量作业开始。只要关联ID对于我们在日志聚合工具中的搜索是能够保证唯一的，我们将看到只与该查询有关的结果。

在这里，我们已经有了一个异步的、分布式的系统。当在浏览器中应用程序明确地显示了成功——该文档已经成功更新时，可能实际上还需要启动进一步的工作流程（例如，如果文档审计发现了文件的问题）。

通过使用事件ID和事务跟踪的日志聚合功能，我们就有能力断言，基于在主要事务系统中的某些操作，某些特定的日志消息应该出现在日志聚合系统之中：

有了这个能力去断言我们对系统的行为的期望之后，我们可以写出类似这样的行为水平测试：

这意味着，日志记录已经成为了一种可以扩展我们对分布式系统的测试的方式，只要能够明确在某些具体时刻我们期望哪些行为或事件会被记录下来，然后再去搜索就好了。

结论

对分布式的、可扩展的系统（通常包含不稳定的基础设施）进行故障排除，取决于是否有足够的日志记录和搜索设备。我们需要记录发生在我们的系统中的重要的事件，并通过一个唯一的关联ID将它们关联到一个特定的业务交易（如包裹快递）上。日志聚合和搜索工具使我们能够用一个简单的ID查询来跟踪终端到终端的业务交易。我们也可以查询一个类别的事件以调查组件或系统故障（例如，为了找到导致某次故障的所有的数据库事件）。最后，我们看到，我们可以而且我们也应该以与功能需求类似的方式来测试这些操作需求，即通过用户故事和BDD的场景。 如果对软件测试有兴趣，想了解更多的测试知识，可以加入我的QQ群  高级测试学习大家庭：652068511