testing - 软件层的自诊断测试？

Question

随着越来越多的努力将软件 block 分成独立的层并使用动态发现和依赖注入(inject)将它们解耦，确定系统中的哪个“层”导致“应用程序”的系统范围故障变得越来越困难".

单元测试有助于确保构成一个层的所有“模块”都按预期工作。但是单元测试的编写方式是通过使用 stub 和模拟等技术隔离每个“模块”。

考虑下面的简单示例:

L1。数据库 -> L2。数据库层 -> L3。 Windows 服务 -> L4。客户申请

例如，如果数据库引擎宕机，那么系统将无法正常运行。很难判断数据库引擎是真的宕机了，还是数据库层 (L2) 代码中存在错误。要进行检查，您必须启动某种数据库管理工具来检查数据库引擎是否正在运行。

我们正在努力实现的是一个开发人员工具，只要系统“出现问题”就可以启动，这个工具将“查询”每一层的“完整性”或“诊断”数据。该工具将提供软件层列表及其“完整性状态”。然后它将能够立即说 X 层是问题的原因(即数据库引擎已关闭)。

当然，每一层都会负责提供自己的“诊断方法”，可供工具查询。

我想我们在这里试图实现的是某种“集成测试”框架或类似的东西，可以在运行时使用(而不是像单元测试那样的编译/构建时间)。灵感来自具有自己的“车载诊断”的物理设备，例如汽车。软件世界中的一个很好的例子是每次打开计算机时都会运行的开机自检。

有人见过或听过这样的事情吗？任何建议或指示肯定会有很大帮助!

Answer 1

您可以拥有一个公共(public)接口(interface)，每个层都将实现为 WCF 服务。这样你就可以连接到每一层并对其进行诊断。提供此诊断可能很有用，但如果您想在任何地方(每一层)实现它，那将是另一件可能会失败的事情——您将如何诊断它？您的系统会大量使用 WCF 服务，这并不好，因为它需要大量维护并使其不太稳定。此外，它需要大量工作才能实现。

我建议的替代方案是建立一个良好的日志记录系统。最低限度是让每个模块在所有 catch 部分记录一个错误，但我建议不止于此，尤其是为了调试目的。我推荐使用免费且非常灵活的 Log4Net。它在不需要时不记录是有效的，这意味着您可以将日志记录级别设置为高，并且即使在生产代码中也不会影响性能。您可以通过更改配置文件中的设置在运行时更改日志记录级别。我经常使用 Log4Net，它运行良好。

一旦您有了代码日志记录的东西，您就可以配置 Log4Net，以便所有日志都进入中央数据库。然后，您将有一个地方可以相对容易地诊断发生了什么、什么失败了、异常或消息在哪里以及什么是异常或消息。您甚至可以设置在出现问题时发送的电子邮件。