我们有一个完整的实验室管理环境，在夜间构建中运行编码UI测试。我们试图实现的是在所有编码UI测试之前运行我们的集成测试(带有SQL连接的常规TestMethod())，以验证我们的db脚本是否正确执行，并且没有导致任何问题的新更改。
到目前为止，我已经找到了一种通过.testrunconfig远程执行测试的方法。我们使用这种方法的问题是，不可能选择连接到团队项目的测试控制器，所以我猜这只对在实验室管理之外的物理机器上运行测试有用?一种选择似乎是为每个集成测试创建一个测试用例，并且应该与UI测试一起运行，但感觉管理数百个测试用例只是为了运行集成测试会有很多维护。另外，最好将不同类型测试的测试运行完全分开。
有什么简单的方法可以实现这一点，我完全错过了?或者我是否必须修改实验室构建模板才能部署和运行测试?
我猜这只对在实验室管理之外的物理机器上运行测试有用?
如果您通过.testrunconfig远程运行测试，则必须将测试代理连接到另一个未连接到团队项目的测试控制器。不幸的是，据我所知，在实验室管理下运行的环境是不可能的。
这个方法怎么样:
- 创建包含所有集成测试的有序测试。
- 创建一个新的测试用例"集成测试"，并通过有序的测试将其自动化因此，您不必维护数百个测试用例。如果要对集成测试进行分组，还可以创建多个Ordered Tests，然后创建一个包含它们的"main" Ordered Test。这样可以更容易地分析测试结果，特别是当您有很多测试时。
- 让集成测试作为现有的夜间构建的一部分运行。
- 创建一个新构建定义，它不启动构建，但使用最后一次成功的夜间构建，并使用实验室构建模板让您的CodedUI测试运行。
这样，您将为不同类型的测试运行不同的测试。
唯一的缺点是你必须"同步"这两个构建…您可以稍后安排第二次构建，这样您就可以确保第一次构建已经完成。
我知道，这并不完美。但是这样你可以很容易地实现你的目标。我不确定是否有替代解决方案，但在我目前正在进行的项目中，我们在我们的夜间构建中，在过程选项(Process>Basic>AutomatedTest>TestAssembly)下设置了单元和集成测试程序集。
这是通过改变默认构建过程模板(不是实验室默认)一点来实现的，正如你所建议的(我认为这是标准的，但已经有一段时间了)。