我有一个n层应用程序，不同的层运行在不同的机器上。我需要在那些不同的机器上执行编码集成测试，最好使用MSTest框架，因为这是其他所有内容的编写。
存在一个编排问题，因为在机器“B”的测试可以运行之前，需要正确设置机器“A”。开箱即用的VS似乎没有处理那种情况，所以我还需要别的东西。
从表面上看，TFS实验室经理似乎是我管理机器，部署代码和运行相应测试所需要的，但皱纹是代码不存在 - 我们使用Perforce进行源代码控制。 / p>
所以
a）是否有人使用来自其他源控制系统的代码成功使用TFS实验室管理器进行测试部署？如果是这样，你是如何设置的？
或
b）是否有任何替代测试框架可以让我将代码部署到多台机器上，执行编码测试并收集成功/失败结果？
答案 0 :(得分：3)
a）我没有使用不同的源代码控制，但我认为使用TFS Lab Manager肯定是可行的。 TFS工作流程＆amp;测试控制器/代理模型基于Lab Manager中的Windows Workflow工作，因此您需要修改构建的工作流程（使用VS中的XAML编辑器或工作流UI）并将任何TFS源代码控制调用替换为您自己的任务集以获取/ version / checkin-out代码。实际上，TFS实验室工作流程与构建工作流程分离，并且可以从UNC路径或其他东西中获取构建的二进制文件。如果选择后者，可以使用MSBuild和Jenkins等其他驱动程序构建代码，然后使用TFS Lab Manager正确执行每个层上的测试。
b）相反，您可以完全使用Jenkins和VMWare插件来启动和关闭VM进行测试。您可以使用Powershell插件和powershell远程处理或其他一些MSTest插件来执行远程测试。这个选项对我来说似乎比较难，但我认为两者都可行。
答案 1 :(得分：1)
根据您的评论
我正在测试的代码是使用VS在本地构建的。集成测试 手动开除。
我希望任何CI平台都可以使用带标签的构建作为输入。
实际上在您的（两个）问题上：我认为在您努力升级到稳定的构建环境之前，您注定要做这是手工/自酿脚本。
拥有构建服务器是一个真正的good的东西，如果你要建立一个现代化的开发环境，你基本上不能做没有它。
如果您被TFS实验室经理所吸引，那么必须使用TFS-Build。如果沿着这条路走下去，你应该考虑将所有内容切换到TFS - 包括源代码控制。
我要说使用Perforce作为源代码控制＆amp;构建/测试的TFS绝对是可能的，但是正确设置构建可能是一件令人头痛的问题（从字面上看，关于源代码控制的所有内容都需要重构为p4友好的调用）。
答案 2 :(得分：0)
我将用我实际做的回答我自己的问题：放弃实验室的想法，因为手头的工作太多了！
一开始看起来很有希望，我确信它有可能付出足够的努力，但正如其他答案所指出的那样，这将意味着实验室工作流程的实质性编辑，以实现我的目标 - 超出我的理由。不仅没有使用TFS构建的代码存在问题，而且我还遇到了试图告诉实验室/测试经理如何运行哪些测试的问题。
最后，我使用powershell脚本拼凑了一个中途解决方案来设置环境（恢复hyper-v快照，复制几个文件并运行一些远程安装）以及内置到VS中的标准MSTest框架以便执行针对环境的测试。