随时随地的测试：

       由于分工的不同，开发与测试部门往往会分开，即便集中工作的项目组也常常被分成不同的小组。因为很多“不是我不小心”的bug一旦被测试出来马上成为项目主管要督促完成的任务，为此很多开发人员也需要经常对自己最近完成的工作进行单元测试。“选择待测试的代码，点击鼠标右键，选择Create Unit Tests”，这就是VSTS中启动一个单元测试需要做的。使用VSTS后笔者更喜欢为自己做的库增加单元测试，毕竟强迫自己把某些类的操作示例写在注释里相对而言是个比较繁琐的事情，因为那里没有语法高亮显示，真的要try还不如做个Unit Test，这样几个月后再拿出来看不至于“陌生”了。当然，放在Team这个概念下，VSTS对于各类测试用例的开发和自动化测试就非常有意义了。随着代码行数的增加，每次底层库的修改似乎都是在“涉冰”，那么最简单且比较有说服力的就是让他Run一下，把修改内容自身及其上层相关对象的测试跑一遍确认没有问题，似乎比拿出一大堆Class Diagram和Sequence Diagram更让上层内容的开发人员放心。项目开发到七七八八的时候，运维人员的参与就会密集起来，“现有的设备上能不能跑起来？”、“单个节点能不能支持40个50K长交易的并发调用？”等等，类似的有技术含量但对于开发人员而言算不上什么创造性任务的事情也是必须要面对的，VSTS的Load Test、Web Test可以大大简化这个工作。配合反射机制的框架代码自动生成可以省去以往设计测试用例过程中“八股”化的代码部分，更多的将注意力专注于具体的用例内容设计上，在完成了每个测试点之后，又可以请VSTS自动的调用这些测试点，我们选择开始测试若干时间后，一份格式工整报告就诞生了。

        不过从实用考虑，开发阶段的测试也许还不算最VSTS闪光点的地方，对于一个大型生产系统的维护而言，VSTS提供的各类测试支持更重要，毕竟开发这个行业流动性相对较大，代码、程序集之间错综绞合的依赖关系也复杂，系统运行半年后的维护性开发，或者某某某二期、3期如果没有以往测试内容的支持，必将是某种程度痛苦的经历。VSTS的测试功能也许在很多同行眼中不算同类产品中最出色的，但他是.Net平台开发最“帖”的，起码可以在很多方面提高开发效率：

l         节省了配置管理的工作，通过VSTS + Team Portal，相关工作无逢的串在一起了。

l         拉进了开发人员和测试人员、部署人员的距离，大家在一个产品框架下流水的完成自己所负责的一块工作。

l         考虑到对于绝大多数项目的适用性，成本因素也许是选择VSTS测试功能的一个理由，尤其是Load Test部分。

l         丰富的报表功能，测试设计方案、测试过程记录、测试结果都可以自动生成，尤其在测试驱动的开发模型下，让每个参与者根据测试内容的反馈“知道”是非常关键的。

l         最后它节省了不少时间，对笔者而言省去重复填写表格后，有了更多时间找茶友聊茶。