MsTest noob - 如何以正确的方式设置测试基础设施
我们是一家拥有影响深远的 MSDN 许可证的 MSFT 商店。
经过多年的错误做法，我们终于要开始做自动化测试了。 我的小组是这里的豚鼠。我们需要创造以前没有的东西。我们研究了众多的选择。有些人可以很好地使用开源替代方案，例如 CC.Net、Bamboo、MbUnit 等。我们希望提供>MsTest、CodedUI、Team Build 是一次很好的尝试……也可能是因为 MSDN 许可和 MSFT 的关注。
以 MSFT 方式做事的优点和缺点是 MSFT 制造单一的东西。你必须安装各种能够很好地配合使用的工具，但与外部人员配合则不一定。优点是，如果事情做得正确，一切都会相当顺利。有门控签入、使用 TFS 存储报告等选项。
坦率地说，我对所有选项感到困惑。我们传统的构建系统是由一堆 Perl、批处理脚本、可执行文件组合在一起的，但现在构建团队切换到 Team Build，这应该更干净，但在大多数情况下，它只是相同的旧 Perl 垃圾的包装器。
我也倾向于将一些东西组合在一起进行测试，因为我至少可以看到这些部分是什么。所以，我设想穷人的版本是： * 专用的快速计算机来运行测试 * 一些脚本将构建文件（测试代码以及产品代码）复制到该计算机。 * 一个批处理/perl 脚本，它将从命令行运行 mstest.exe，并对某些测试 dll 中的某些按类别过滤器执行一些测试批处理（该产品非常庞大，我们确实希望按各种类别组织测试）。 * 一些脚本将使用 psexec.exe (http://technet.microsoft.com/en-us/sysinternals/bb897553) 从构建服务器远程调用后一个脚本，并从共享驱动器获取 xml 输出，然后向感兴趣的人发送包含结果的电子邮件。
这可能可行，但我不得不担心错误处理在处理如此多的潜在故障点时的效果如何。最好能够利用 MSFT 所创造的一切，以“正确的方式”进行配置。我只是不知道在哪里可以找到好的指南。你做过这样的事吗？
如果我们要用完分配的时间，最终我们将希望拥有一组测试计算机。其他值得关注的事情是 - 为了使编码的 ui 测试成功，我认为用户必须登录，所以我不确定 psexec 在这里是否会有很大帮助。
您能否分享您的积极/消极经历，或许为我指出一个好的指南？谢谢！
We are a MSFT shop with a far-reaching MSDN license.
After many years of doing things wrong, we finally have to start doing automated testing.
My group is the Guinea pigs at this. We need to create what was not there before. We looked at the multitude of options out there. Some people get by just fine with open-source alternatives such as CC.Net, Bamboo, MbUnit, etc. We want to give MsTest, CodedUI, Team Build a good try ... might as well because of MSDN licensing and MSFT focus.
The plus and minus of doing things the MSFT way is that MSFT makes monolithic things. You have got to install various tools that play with each other nicely, but with outsiders - not necessarily. The plus is that when things are done correctly, it should all function rather smoothly. There is the option of gated check-ins, of using TFS to store the reports, etc.
Frankly, I am confused by all of the options. Our traditional build system was hacked together with a bunch of perl, batch scripts, executables, but now the build team switched to Team Build, which ought to be cleaner, but for the most part it is just a wrapper to the same old perl crap.
I am inclined to hack things together for testing too, because I can at least see what the pieces are. So, I envision the poor man's version as:
* A dedicated fast computer to run tests
* Some script to copy build files (test code as well as product code) over to that computer.
* A batch/perl script which would run mstest.exe from command line and execute a few test batches on some by-category filter within some test dlls (the product is so huge, that we do want to organize tests by various categories).
* Some script which will invoke the latter script remotely from the build server using psexec.exe (http://technet.microsoft.com/en-us/sysinternals/bb897553), as well as grabbing the xml output from a shared drive, and then sending out an email with results to those who are interested.
This can probably work, but then I have to worry about how well error handling can work with so many potential points of failure. It would be nice to configure things the "right way", taking advantage of whatever MSFT has cooked up. I am just not sure where to turn for a good guide. Have you done something like this?
Eventually we will want to have a farm of test computers, if we are to run out of the allotted time. Something else of concern is - for coded ui tests to succeed, I think a user has to be logged in, so I am not sure if psexec will be of much help here.
Can you share your positive/negative experience, point me to a good guide perhaps? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您想开始使用 MS 工具进行测试，这里有一些我想到的提示：
如果您有 MSDN 订阅，请通过在网络上安装测试控制器并在每个网络上安装测试代理服务来安装测试设备。将收集诊断数据的机器。请参阅以下链接以供参考： http://msdn.microsoft.com/en-我们/library/dd293551.aspx。
将测试项目添加到您的解决方案中。请参阅以下博客文章的第一部分：http://blogs.microsoft.co.il/blogs/eranruso/archive/2010/03/27/visual -studio-2010-coded-ui-test-user-guide-create-a-simple-coded-ui-test.aspx。
可以通过添加测试项目时自动添加的 .testsettings 文件来配置自动化测试选项（您也可以手动将这些文件添加到解决方案中）。
安装 Team Foundation Server（推荐 2010），以便利用每日构建的自动化测试。如果您想使用 VS2010 测试管理器工具来定义测试环境并计划手动测试（这些可以通过 CodedUI 完全自动化），您还需要 TFS 2010。自定义新的自动化构建以在构建后设置/部署应用程序，并将构建设置为运行测试。单元测试可能不需要部署，但 Web 性能和 CodedUI 测试类型则需要部署。
如果您拥有 VS Ultimate 或 Test Professional 许可证，您还可以进一步使用“实验室管理”功能设置虚拟测试实验室。
Here are some tips off the top of my head if you want to get started with testing using the MS tools:
If you have an MSDN subscription, install a Test Rig by installing the Test Controller on your network and the the Test Agent service on each of the machines that will be collecting diagnostic data. See the following link for reference: http://msdn.microsoft.com/en-us/library/dd293551.aspx.
Add a Test Project to your solution. See the first part of the following blog post: http://blogs.microsoft.co.il/blogs/eranruso/archive/2010/03/27/visual-studio-2010-coded-ui-test-user-guide-create-a-simple-coded-ui-test.aspx.
Automated test options can be configured through the .testsettings file(s) that are added automatically when you add a Test project (you can also manually add these files to your solution).
Install Team Foundation Server (2010 recommended) in order to take advantage automating your tests with a daily build. You will also need TFS 2010 if you want to use the VS2010 Test Manager tool to define test environments and plan manual tests (these can be fully automated with CodedUI). Customize your new automated build to setup / deploy your application after build and set the build to run tests. Deployment will likely not be necessary for unit tests, but they will be for Web Performance and CodedUI test types.
If you have VS Ultimate or Test Professional licenses, you can also go further and set up virtual test labs using "Lab Management" features.