测试用例是可追踪的，所以开发者们可以很容易地看出这个代码是否已经为测试做好准备了，以及所有的功能是否都已经实现了。TFS(Team Foundation Server)可以通过Web来访问，所以，我不仅可以通过Visual Studio或MTM（Microsoft Test Manager）来查看那些测试用例，我还可以通过浏览器来轻松地查看那些测试用例，这样的话，每个人都可以查看那些测试用例来指出错误，或者了解测试进展的是否顺利。

TFS(Team Foundation Server) 2010中的测试功能真的很特别，在本文中，我并不会提到那些可以记录测试结果，反复载入Web页面和反复执行CUIT（Coded UI Test）的测试工具，相反，我会提到和项目的测试计划有关的一些管理工作。

在过去，我曾经看到过有些团队用Excel来做测试计划管理，如果你也用Excel来管理你的测试计划......那么，你有大麻烦了。原因是Excel并不是为了管理测试用例而设计的，你可以使用它清晰地记录下你的测试用例，但是你很难把它集成到你的ALM（Application lifecycle management）流程中，同时，阅读起来也是很困难的。主要的问题是Excel中的测试计划和你的流程中的其他产物之间是彼此独立的，即使你把它们放到团队项目的SharePoint站点中来管理，这种情况也不会发生根本性的改变。另外，Excel不能帮助你运行测试，也不能帮助测试工程师记录下测试结果，这通常会引起Excel Test Spreasheet和真正的测试运行结果之间无法一一对应。

有了MTM（Microsoft Test Manager），你现在可以使用强大的TFS(Team Foundation Server)来管理test suite了；举个例子，假设你有一个和应用程序的用户管理相关的用户故事。

图1：一个简单的用户故事

现在，测试团队开始为这个用户故事创建test suite了，有了MTM（Microsoft Test Manager），他们现在可以简单地按“add requirements”按钮，然后选择“User Story”创建一个和那个用户故事相关联的test suite。

（图2：和用户故事“Gestione Utenti”相关联的叫做“Gestione Utenti”的测试用例。）

这样做的主要优势是这个关联性可以通过TFS(Team Foundation Server)来管理，而且，属于这个用户故事的test suite的每个测试用例也可以自动地列出来。如果测试团队在这个Suite中添加了两个测试用例，那么所有的开发者都可以在Visual Studio中看到它们。

（图3：在Visual Studio中你可以看到用于测试这个用户故事的所有测试用例。）

在ALM（Application lifecycle management）中，可追踪性是很重要的。现在，你不费吹灰之力就可以知道和这个用户故事相关的测试用例都是什么了，同时，技术方面的项目经理也可以验证这个用户故事的所有任务是否足以满足那些测试用例的需要。有时，在发现“隐藏的需求”方面，这可以起到很大的作用，假设技术经理看到了这样一个测试用例：
1) 打开那个Web页面
2) 登陆
3) 关闭浏览器
4) 打开那个Web页面
5) 验证你是否还处于登陆状态中。

这个测试用例可能会暴露出一个在其他地方没有明确说明的需求，然后技术方面的项目经理可以创建一个新的任务来支持这个场景。同时，这可以让开发者们看到将会运行在软件的某个模块上的所有测试用例，所以，他们可以容易地看出要发送给相关的测试工程师的每样东西是否都做好准备了。在前面的例子中，开发者们可以实现一个新的功能来支持这个测试用例，这可以避免常见的“乒乓球问题”：
1) 开发者把一个版本发送给测试工程师
2) 测试工程师驳回了这个版本，原因是测试用例XXX没有通过
3) 开发者们在某些地方看到了那个测试用例，然后修改软件，发送另外一个版本。

测试用例是可追踪的，所以开发者们可以很容易地看出这个代码是否已经为测试做好准备了，以及所有的功能是否都已经实现了。TFS(Team Foundation Server)可以通过Web来访问，所以，我不仅可以通过Visual Studio或MTM（Microsoft Test Manager）来查看那些测试用例，我还可以通过浏览器来轻松地查看那些测试用例，这样的话，每个人都可以查看那些测试用例来指出错误，或者了解测试进展的是否顺利。

（图4：你可以通过一个简单的Web浏览器来查看一个测试用例。）

如果你是测试经理，你应该给这个测试用例分配人力资源，而且，你应该把所有的测试用例都分配给测试团队的成员，你还应该计划每个测试用例的执行时间，你可能还需要说明哪个测试用例应该在哪个测试用例之后执行。在Microsoft Project中，这些管理工作可以很好地完成。

（图5：怎样给一个测试用例分配人力资源，在这个例子中，我把Administrator分配给了叫做“Esempio test case chiuso”的测试用例。）

很明显，你可以使用甘特图来规划测试用例的执行过程。

（图6：在Microsoft Project中规划测试用例的执行过程。）

当重新分配测试资源的时候，修改的结果会发布到TFS中。

（图7：使用Microsoft Project的“assign resources”，测试用例63被分配给了Administrator，同时，变更会被发布到TFS中，所以，它们在所有地方都是可见的。）
 
在Microsoft Project中，你可以使用Task Inspector来检查一些人力资源是否因为他们还要从事其他任务而被过度分配了。在图8中，我们可以看到，当把Administrator分配给一个测试用例的时候，那个项目开始“抱怨”了，因为他还被分配了其他的任务。很明显，对于单个的测试用例来说，使用甘特图来进行规划有点大材小用，但是，这只是一个用于展示TFS(Team Foundation Server)和 MTM（Microsoft Test Manager）中测试用例管理灵活性的例子而已。

（图8：因为Administrator被分配了过多的任务，所以项目中的Task Inspector发出了警告。）