我已经遇到了这个问题，我怀疑是否有一种标准的方法可以解决这个问题。

ATC结果被分配有由结果上下文生成的哈希（例如方法或函数的作用域） 模块）。 只要哈希值不变，就只能通过基线隐藏该发现。

据我所知，它的基本目的是忽略ATC持续监视的系统中的（未修改的）遗留代码，但是一旦您进行了修改，就必须进行清理 您更改的位置的"周围"。 所需的工作很大程度上取决于现有源代码的结构。

我记得检查了博客建议的隐式增强点，但是发现它已经由于内部ATC代码的重构而消失了。

我用来检测新发现的解决方案是在DEV和Q＆A中针对同一对象同时执行ATC，并确定两个结果集（比较对象，测试类和测试）之间的差异 码）。 我是从解决方案管理器完成的，但是我想它可以集成到开发系统本身中。 ATC在SATC_CI_API包中提供了一个公共API。

我们在ATC的先前公司中进行了自定义更改。

我们使用了代码的版本历史来过滤ATC找到的issus。

我没有源代码，但是可以工作。

...，在我忘记之前：基线有一个结束日期（默认只有21天）。 以前，这也是我的错，我认为基准行不通。
因为创建基准线的寿命只有180天甚至365天，所以我无法做到。

它一如既往地...

在大多数情况下，基线按设计工作：仅新的或 检查更改的行。 但是，如果您更改了函数混搭接口或其中包含"："的数据定义，则将检查整个定义，因为ATC将此视为已更改的语句。