我发现日志文件分析的方法出乎意料，但在许多层面上都非常有益。在我看来，例如，在测试更常规的Web应用程序时可以使用相同的方法。
是否有人从这种测试方法中获得实践经验和教训？
#1 楼
Web应用程序有些不同，因为Web服务器处理多个不相关的客户端。如果您正在寻找一种模式，仅知道页面Y紧随页面X是不够的-您还需要知道这些事件是否在同一会话中发生。有时，这些信息可在日志中找到；有时候，不是。当然，在经过NAT转换的世界中，您不必一定依赖客户端的IP地址。日志分析和自动机反向工程对于负载测试也很有用，除了您不用分析记录的事件，最终，按照与您在日志中看到的比例和模式生成事件。
最后，如果您想从输出对应用程序的行为进行反向工程，则最好确信该应用程序主要工作。
#2 楼
是的，我们将日志监控用作测试过程的一部分。要求每个手动测试人员在测试过程中监视日志（tail -f），以在测试过程中查找隐藏的错误/异常。此外，如果抛出客户端异常，我们的UI将弹出一个对话框。这些通常会导致自动测试失败，并开始调查。
最后，我们有一个脚本，该脚本每晚运行一次，以汇总日志文件中的所有错误和异常，与已知问题列表进行比较，并向团队发送电子邮件以查找出现的新错误在日志中。这触发了调查。 （相同的脚本也可以在生产环境中运行）
评论
Mar Science Laboratory方法的有趣之处在于，它使用跨事件类型的模式来检测错误，而不是查找堆栈跟踪或错误消息。看来他们也可以使用其工具来自动生成候选模式。
–user246
2012年8月6日19:39
#3 楼
我们广泛地依赖日志分析，而不是用于Web应用程序，而是用于测试嵌入式代码（从低级驱动程序到应用程序）。 ，这将完全改变您的策略。我们的Perl框架具有简化的API，用于分析脱机日志和/或处理同步/异步在线事件。
请注意，使用日志可以更轻松地分离表示法和逻辑层。
#4 楼
我们的日志是分析的主要对象之一，因为应用程序没有UI，并且我们从日志和网络输出中获取所有信息。另外，我们对日志记录功能也有特殊要求。通常，我们设置最大详细程度，并使用grep，tail和awk等工具来处理日志文件。
#5 楼
在以下情况下，日志非常有用基于不同级别（调试，信息），您可以找到中间值，最终值并与日志中的条目进行比较
错误@ UI级别，您可以从日志中捕获步骤/错误详细信息
完成测试后，粗略检查日志中的异常是否会引发任何内存泄漏/越界异常，超时
周期并不是所有的信息都会在设计文档中捕获，功能流程，分配，数据比较，清理将仅从日志中更详细地介绍
mtail，代理检查，文本板，notepad ++等一些工具，可以快速地通过日志分析异常
日志对于质量检查了解技术实施，识别功能状态变化，查找异常非常有用
评论
这不是真正的测试，更不用说验收测试了。这样的日志分析更多地是关于维护和部署后发现问题，而不是测试预部署以确保代码正确。是否有人拥有以下文件：compass.informatik.rwth-aachen.de/ws-slides/havelund.pdf？请寄给我，谢谢。对我来说，我们想分析日志文件以获取一些底层错误或应用程序不足。