【IT168 技术】微软在昨天正式发布了Visual Studio 2010 Beta 2(内部开发代号 Dev10)，同时也宣布了正式版本的发布日期为2010年3月22日，也就是春节后啊!MSDN订阅用户可以在今天开始下载Beta 2，其它用户则要到美国时间10/21号才能下载，也就是我们中国时间22号。我很高兴能够马上就用上Beta 2版本的Visual Studio 2010，与Beta 1相比变化还是不小的，先不说功能上有啥变化，仅Logo的变化就让人小吃了一惊。一改使用了十几年的“红绿蓝黄”，采用了全新的“紫蓝”Logo，乍一看还挺不适应的，毕竟用了VS十多年，对老Logo还是有感情的，呵呵!

　　图1 老Logo，再怀念一下!

　　图2 新VS Logo

　　图3 新MSDN Logo

　　有关VS 2010 Beta 2的下载、安装和新功能特性等方面的信息，可以访问 http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx ，这里就不再多说了，作为一个测试人员，俺更关心的是它在测试方面的内容。

　　对于测试人员而言，VS 2010 带来了更多崭新的功能，这些新功能贯穿了整个测试周期 ： 测试计划、测试执行和测试执行进度跟踪。虽然VS 2010 RTM还不是正式版，但是从微软发布的Beta 2我们也可以体验一下这些新的功能。 根据以往微软的开发流程和习惯，Beta 2和最终的RTM版应该是八九不离十的。VS 2010 引入了一个全新的工具，称作“微软测试与实验室管理器” (Microsoft Test and Lab Manager， MTLM)，MTLM是一个单独运行的工具 (内部开发代号“Camano”)，用于创建测试计划、管理测试用例、运行测试用例以及测试结果管理等。

　　在安装VS 2010套件的时候会一起安装上，其界面还是很漂亮的，不像是传统的WinForm程序，应该是完全用WPF编写的。MTLM是单独运行的一个工具，运行它不需要启动Visual Studio IDE。也许很多人会问：为什么不把它集成到VS IDE中，而是作为一单独的程序呢?我能够想到的答案是：测试和实验室的管理的功能相对比较独立，作为一个单独工具使用会更轻便。如果只是用来管理实验室或者执行测试用例，就可以只安装这个工具，在安装界面中可以选择只安装MTLM工具吧?——有待下次安装时确认。

　　我在自己的机器上安装了MTLM，第一次运行了这个工具后才发现，MTLM仅是一个测试和实验室管理功能的客户端，也就是个“配角儿”，真正的“主角儿”原来是Team Foundation Server(TFS)服务器，更确切的讲应该是TFS 2010 Beta 2。MTLM是完全依赖于TFS的，它运行起来的第一个界面就是要你去连接指定的TFS服务器，否则也就到此为止，寸步难行了。我们知道，TFS是微软的软件开发生命周期管理(ALM)套件的核心服务器端，将MTLM与它进行紧密绑定更进一步凸显了微软软件生命周期管理软件的战略，这其实从VS 2005和2008就已经逐步开始了，2010更进一强化了这战略。VS不再单单只是面向开发人员或者是测试人员角色，而是要提供一个平台来有效协调和支持开发过程中各个角色，并使他们能够彼此紧密联系进行协作。就象早在VS 2008中就已经支持Excel和Project和TFS连接一样，这也是趋势，设想以后很可能所有和软件开发过程相关的工具都会与TFS绑定。在学习的过程中总有很多细小的问题和发现无处归类留作备忘，用这种Q&A的方式的蛮好的，不用写很多东西，随时有新的发现就随时写些东东，比较轻量级，挺好的!在这里列出一些VS 2010测试功能使用中遇到的问题：

　　问题 1.Microsoft Test and Lab Manager (MTLM)工具能和TFS 2008、2005一起工作吗?

　　答：不能。因为测试和实验管理是服务器端功能，这些功能仅在TFS 2010上支持。

　　问题 2.MTLM如何对用户访问权限进行管理?

　　答：MTLM没有单独的用户权限管理，它应该是依赖于所连接的TFS工程的用户权限配置。

　　问题 3.MTLM所管理的对象是如何在TFS端存储的呢?

　　答：Test Plan、Test Suites和Configuration 都是保存在TFS服务器端的数据库中，而Test Case则是以工作项(Work Item)的形式保存在TFS上的。在TFS 2010的默认工作项类型中，新增加了Test Case类型，就是用来保存Test Case对象的。因为工作项是具有历史信息记录和查询功能，所以Test Case对象的所有历史更改信息都可以查询到。而Test Plan、Test Suites和Configuration就不具有历史查询功能。

　　问题 4.什么是Shared Step?

　　答 ：Shared Steps是指共享的测试步骤。每个Test Case是由一系列的测试步骤组成的，每个测试步骤包括要执行的操作以及对操作结果的验证。有些测试步骤是可以在多个测试用例中所共用的，就可以把它当作Shared Steps，比如说如果我们要从测试VS，第一步总是要启动VS并确认VS IDE显示出来了。这样一个步骤是所有对VS进行测试测试用例都必须要执行的，我们就可以把它创建为Shared Step。TFS 2010的默认工作项类型中，新增加了Shared Step类型，就是用来保存Shared Step对象的。

　　问题 5.哪里有最新的VS 2010测试功能的文档?

　　答：http://msdn.microsoft.com/en-us/library/ms182409(VS.100).aspx，读好MSDN的文档是了解好办法。

　　问题 6.MTLM里可以“Add requirements”来扩展Test Plan，这里requirement是指啥呢?

　　答：阅读MSDN的文档你会发现，requirement和User Story是可以互换的。实际上Requirement就是User Story，更确切的讲就是TFS上的User Story工作项。项目经理在定义好User Story，测试人员可以从User Story直接来创建测试计划的内容。

　　如果主角儿只有一位的话，整个VS 2010工具的真正主角以不再是作为编码工具的VS IDE，而是ALM的核心TFS。很多很多涉及到团队开发的功能都需要TFS(Team Foundation Server)的支持。

　　那么TFS到底是干啥的呢?从字面上翻译就是：Team团队Foundation基础Server服务器，更更通顺些翻译就是“团队协作基础服务器”，不知道微软的官方中文翻译是怎样的，如果有朋友知道，别忘了告诉一声。我记得它的第首个版本是出现在VS 2005中，当时看到它的时候，还是非常兴奋的，因为总算是可以告别“VSS存代码，Word记Bug，测试人员通知开发人员产品缺陷靠喊”的“手工++”开发模式。有了TFS，你开发过程中的所有“副产品”—— 需求、任务、缺陷和代码等都在一个服务器上，彼此可以互联互通，这感觉真爽啊!

　　下面的图描述了在没有TFS时候的情况，开发过程中的数据都是分别用不同的工具存储，彼此直接相互独立成为了信息“孤岛”，它们彼此之间的联系代表了人的行为实现的它们之间的“沟通”。

　　TFS的使命就是要解决开发过程中的信息“孤岛”问题，通过统一的存储机制是它们的能够协作起来，实现1 + 1 + 1 ... + 第n个1 > n的效果。如下图所示，微软已经为不同的角色提供了丰富的工具来访问TFS数据，同时还提供了TFS Object Model(API)，让第三方厂商就能够开发自己的基于TFS的软件。

　　现在Visual Studio已不再是仅面向开发人员一种角色的软件编码工具，它已变成了一个覆盖整个软件开发生命周期的ALM工具。其实，作为软件工具厂商这也是必然的发展方向，就像IBM也有Rational、ClearCase等工具。作为每一个软件行业的从业人员，无论是开发人员、项目经理、还是测试人员，也要不断适应这个趋势，我认为它只会使我们的工作更简单和更轻松。

　　Test Impact Analysis是Visual Studio 2010测试部分新增加的一个功能，我也不知道该如何翻译其中文名，那就简单点儿，按字面翻译为“测试影响分析”，以下简称为TIA。啥时TIA呢?简单地说，就是根据产品代码变化自动分析出受影响的测试用例。

　　那么这个功能有什么实用价值呢?对于我所在的开发团队而言，其价值可老大了。我们所开发的产品规模比较大、功能比较稀碎，并且是多人合作开发。为了保证产品的质量，我们为产品编写了大量的自动化测试用例 (>5000)，同时还有少部分的手动测试用例(< 200)。为了保证每次产品代码Check-in的质量，在我们开发过程规范中明确指出：每次check in代码之前，必须执行所有相关的自动化测试用例，并全部通过之后才能checkin。这样做的初衷是为了防止regression缺陷的发生，但问题是如何找到“相关的测试用例”呢?如果运行所有的自动化测试用例，大概需要8+小时。仅为了一小的修改就要去华8个小时执行测试用例，显然是不值得。所以我们所采用的方法是将测试用例分类：集成测试用例、功能测试用例和单元测试。其中，集成测试用例数量最少(5~8%)，覆盖了最最基本用户功能;单元测试覆盖数量较大(30%)，但运行速度很快;功能测试用例覆盖绝大多数一般功能和一些边界条件，其数量大运行时间最长(60~65%)。根据这三个分类，我们选择为每个checkin执行所有的集成测试和单元测试用例。这样做的好处是：覆盖了最基本的产品，同时运行时间不是很长。

　　上述方案仅是一种折中的选择，其不足之处也是显而易见的：所选择的测试用例固定不便、不准确，虽然保证了最基本产品功能不会被破坏，但往往不能发现checkin代码对其它功能影响。但在过去，这也是无奈的选择。TIA功能的出现就大大改善了这种情况，它可以帮助我们更精确的从所有测试用例中找出受到代码变化影响的测试用例。

　　在Visual Studio 2010中，启用TIA的方法非常简单，首先打开你的测试工程，然后选择 Test –> Edit Test Settings –> Local(local.testsettings)，再在Test Settings对话框中选择 Data and Diagnostics –> Test Impact，如下图所示：

　　然后，需要重新编译编译整个测试工程，并执行所有的测试用例，以生成TIA所需要的基线数据。通过Test –> Windows –> Test Impact View打开Test Impact View窗口，如下图所示。在没有任何代码改变情况下，窗口中会显示“No tests are impacted”。

　　但是，当你改变了任何产品代码、保存并编译，然后刷新一下Test Impact View窗口，它就会列出来所有受影响的测试用例，选择任何一个测试用例，它还会显示是那些方法被改变影响了这个测试用例，如下图所示。我改变了产品代码中的ExchangeCurrency方法的代码，那么覆盖这段代码的测试用例就被挑选出来。

　　其实，TIA并不是啥特神奇的功能，它实际上是利用了代码覆盖(code coverage)找出了每个测试用例所覆盖到的所有方法调用，生成基线数据，将这些数据保存在工程路径下的testimpactdata.sdf文件中，据此来计算每次代码修改的影响。.sdf是SQL Server Compact 数据库文件，可以在Server Exploer中代开，如下图所示，它一共包含了4张表，有了这些数据我们也可以用它来扩展自己的功能。

　　上述所展示的Test Impact Analysis功能，仅是Visual Studio客户端的功能，其实在TFS服务器端也提供了TIA。具体使用方法，将在以后介绍。