testing - 日志的大统一理论

Question

他们是伐木的大统一理论吗？我们要不要开发一个？问题(只是为了表明这不是讨论:)，我该如何改进以下内容？ (注意，我主要生活在嵌入式世界，但也欢迎非嵌入式的建议)

如何记录、何时记录、记录什么、如何处理日志文件？

您如何记录 - 我通常有宏、#ifdef TESTING 之类的东西。它们写入 RAM，当系统空闲时，一个低优先级进程将它们写出(使用 UDP，因为我做的是嵌入式系统)

您什么时候登录 - 与投票一样，尽早且经常。在每个(不)重要的程序事件中，我都会以不同的级别登录。事件接收、交易成功/失败、数据更新等

您记录什么 - 致命/错误/警告/信息/调试/跟踪包含在 When to use the different log levels? 中

您如何处理日志文件 - 1) 保留它们(在 CVS 中)，无论是通过还是失败 2) 捕获所有内容并稍后过滤，以防我无法重复出现问题。我有工具可以按“级别”(致命/错误/等)、进程、文件等来过滤日志，并绘制消息序列图、转储数据结构、绘制内存使用直方图——我错过了什么？

嗯，二进制或 ascii 日志文件格式？ Ascii 比较笨重，但二进制需要更多处理。我都做了，目前我使用 ascii

问题 - 我是否遗漏了什么，我该如何改进？

Answer 1

您可以用许多不同的方式“检测”您的代码，从启动/关闭事件到单独的机器指令执行(使用处理器模拟器)。在所有的可能性中，什么值得做？不要只是为了完整性而这样做；有一个特定的目标。如果您愿意，可以提供一个商业案例，以及您希望获得的 yield 。例如:

• 深入了解 CPU 任务执行时间/模式以实现优化(如果您需要提高性能)。
• 深入了解其他系统以解决系统集成问题(例如，当您的 VoIP 盒连接到特定对等点时发送和接收的消息是什么？)
• 深入了解错误的性质(用于现场诊断)
• 协助发展
• 协助验证测试

我认为没有统一的日志记录理论，因为您所做的将取决于许多细节:

• 数据量
• 数据类型
  • 事件
  • 流式音频/视频
• 可用存储空间
  • 存储速度
  • 存储容量
• 提取数据的可用 channel
  • 带宽
  • 费用
  • 可用性
    • 24×7 互联网连接
    • 需要实地考察
    • 需要打开生锈的大门，爬梯子到屋顶，在填写 OHS 文档后插入电缆
    • 需要等到南极冬季结束，冰盖融化
• 随机访问与线性访问(例如，如果压缩它，是否需要从头开始读取以解压缩并访问某个随机点？)
• 需要在错误条件下生存
  • 看门狗重启
  • 可能的数据损坏
    • 由于电源故障
    • 由于存储介质不可靠
    • 需要在飞机失事中幸存

至于 ASCII 与二进制，我通常更喜欢保持日志记录简单，并将任何漂亮的演示文稿放在解码数据的 PC 应用程序中。在 PC 软件(例如用 Python 编写)中创建用户友好的演示文稿通常比在嵌入式系统本身中更容易。