EICAR 的目的是提供一个将被检测为病毒的跨供应商文件。为什么？例如，假设您正在构建一个允许用户上传内容的 Web 应用程序。在此解决方案中，由于您具有安全意识，您可能希望扫描上传的文件并删除那些恶意文件，然后再将它们传播给用户群中的其他用户。许多防病毒软件供应商都提供了可以执行此操作的命令行可执行文件和解决方案；那么，作为一名软件工程师，你需要的是测试这个结构的东西，或者作为单元/功能/UI测试的一部分自动进行，或者只是简单的旧的“它是否工作”测试。

输入 EICAR 测试文件 - 所有病毒供应商都同意的文件将产生肯定的响应。正如预期使用页面所说：

在现实世界中使用真正的病毒进行测试，就像在办公室里放火烧垃圾箱，看看烟雾探测器是否工作。这样的测试会给出有意义的结果，但会带来不吸引人的、不可接受的风险。

由于您出于测试或演示目的而发送真正的病毒是不可接受的，因此您需要一个可以安全传递的文件，该文件显然不是病毒，但您的防病毒软件会对它做出反应，就好像它是一个病毒。

我的理解是您不使用 EICAR 测试文件来审核您的防病毒产品的状态以及它们的最新程度；在集成场景中，您可以使用它们来测试存在恶意软件的情况，而无需使用真实的、实际的恶意软件。

我认为，创建 Eicar 的主要动机首先是：阻止随机的人以测试自己安装的病毒扫描程序为借口向反病毒供应商乞求病毒样本。

确保签名是最新的新测试听起来很有趣。但是，我建议不要使用原始的 Eicar 文件，而是使用不同的东西。通过这种方式，您可以确保实现了过期算法，除非供应商犯规。使用每日/每周发布的文件可能会更好，但这会导致大量额外成本。

EICAR 的目的不是测试 AV 解决方案在检测病毒方面的效果——因为它是一个长期存在的标准，我们假设任何认为自己是 AV 的东西都会捕获它。它的目的是测试AV 解决方案在确定与病毒的阳性匹配时会做什么。

您可以配置一个解决方案，以便它在捕获某些内容时发送电子邮件 - 但可能您输入了错误的邮件网关，或者可能没有人将 AV 解决方案地址添加到 SMTP 发送白名单中。你怎么知道你的警报是否有效？只有通过测试，正如 Ninefingers 指出的那样，用 a）你知道会“击中”和 b）你知道不会在你脸上爆炸的东西进行测试会少很多麻烦。

它只是一个开/关指示灯，就像指示您的计算机已打开的 LED 一样。但是没有人期望它是一个好的指标，就像 LED 无法判断您的计算机是否崩溃一样。

它有无数的用途。例如，您通过电子邮件网关发送它以查看它是否被阻止。然后你把它压缩起来，看看它是否被阻止。然后你再次压缩 ZIP 文件，连续 100 次，以检测它是否仍然被阻止。您正在测试一项功能，例如 n-level-deep-zip，而不是病毒检测的质量。