如何根据症状避免作为集成商的重复代码错误？

Question

将子模块发行版集成到父项目中时，我经常遇到仅在集成时才可见和触发的错误。 这很正常。 错误是正常的。 我们调试它们，修复它们并将其提交到子模块中。

现在已经发生了好几次，后来由子模块开发人员覆盖了这些修补程序，并再次出现在集成了该子模块的项目中。

随着时间的流逝，由于几乎没有智能地跟踪他们的行为和症状，因此很可能遗忘了它，并对其进行了修复。 这是非常耗时的，尤其是在棘手的情况下。

因此，我的问题是：当我再次看到其症状时，如何从技术上存储要“提醒”的错误的“行为”？

有没有解决我问题的工具。 我可以用症状对固定错误进行分类吗？

我的一个想法是使用自定义模式扩展静态分析器（例如Coverity或clang分析器）。 这不会解决行为/症状方法，但是我可以使用在第一次修复过程中创建的模式来分析编译期间的代码：“如果以某种方式编写此代码，那就不好了”。 以我的经验，我可以用这种方式解决很多错误，但不是全部。

我添加了C和C ++标记，因为这些是我正在使用的语言。

更新 ：由于在评论中有问题：我们正在使用git。 并且重新出现的错误会在首次更正后的几个月甚至几年内提交。

更新 ：我们正在使用螳螂进行错误跟踪。

Answer 1

这不是一个工具，而是一个过程。 我已经使用BFV（错误修复验证）测试来执行此操作。 每次修复错误时，都会为其添加自动BFV测试。 测试的名称为BFV＃bugno-这是错误数据库中的错误编号。 作为测试的所有构建的一部分，运行所有BFV测试作为回归测试的一部分。 如果BFV2042失败，您可以在Bug数据库中查找Bug＃2042来提醒它。 如果在接受子模块分支的合并之前运行回归测试，那就更好了。