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