Tfs 如何从代码中禁用CodedUI测试代理？

我们有一个服务来获取XML中的自定义测试并将其转换为CodedUI测试。然后，我们启动一个MSTest进程，将测试加载到测试控制器中，然后将测试分发到各个代理。我们在晚上运行回归测试，所以如果系统出现问题，就没有人来修复系统。当测试程序中出现某些异常时，会弹出一个错误窗口，系统上不能再运行测试。后续测试将加载到代理中，并立即失败，因为它们无法执行分配的任务。在多个系统上进行的数千次测试本应持续一整晚，但现在却在几分钟内失败

我们可以通过测试返回的速度来检测发生的错误，但是我们不知道如何禁用代理以避免它拾取更多的测试

附录：

如果测试失败得很惨，以至于没有更多的测试可以尝试成功运行（如前所述，我们可能没有操作来处理一些可能是新的弹出窗口），那么我们希望禁用该代理，因为不需要在其上运行更多的测试：它们都将失败。由于我们有许多代理同时运行，如果一个代理出现故障（并被禁用），负载仍然可以在没有长串故障的情况下进行分配。这些其他回归测试仍然有机会成功（一切正常）或失败（我们是否错过了另一个弹出窗口，或者这是一个实际的回归失败）

---

20秒内2000次故障并不能说明什么，除了一个系统出现了一个没有人意识到的问题，现在我们浪费了一整晚的测试。2次故障（1次自然故障，1次由上次故障引起）和1次系统停机意味着总夜间运行时间可能会延长一两个小时，我们有关于如何开始一天的有用数据：修复1次测试并重新运行两次故障。

在这种情况下，需要中止测试运行。如果您自己运行mstest，则需要在命令行进程中插入^c。但是：如果没有人来修复它，那么后续测试失败又有什么关系呢？如果只是快速查看哪个测试是导致错误的原因，为什么不生成一个代码ui检查，查看消息框是否存在，并用Assert.inconclusive标记测试为inconclusive。导致该测试的原因将像一个标志一样突出。

如果可以检测到要禁用代理的点，则可以通过运行“TestAgentConfig.exe delete”来禁用代理，该命令将代理重置为未配置状态。

如果没有人来修复它。。。为什么随之而来的测试失败很重要？如果跑步是