TFS全称Team Foundation Server。TFS提供了企业级的配置管理功能，采用了基于Web Service的3层架构，用SQL server作为数据存储，具有非常好的性能和伸缩性，能够支持从5人的小型团队，到3500人的企业级软件开发团队。
TFS的总体架构如下：
TFS采用了分层的设计，具有应用层和数据层，由于在设计时充分考虑了系统的可扩展性，即使是单服务器的部署，如硬件配置合理也可以支持400个用户的使用。对于更多的用户，可以通过将应用层和数据层分开部署在不同的机器上，数据层可配置群集，则支持的用户可以达到3500人以上，充分满足企业配置管理发展的需要。
TFS的主要功能：
u 版本管理：工作区（workspace）、变更集（changeset） 、标签
u 并行开发支持：多点（checkout）、分支与合并 、搁置集（shelveset）
u 强化过程管理：链接工作项、静态代码分析、代码覆盖率
u 自动化构建
u 完善的权限管理
u 支持分布式开发
作为一个测试团队的配置管理员，我个人最看重的是权限管理、版本管理、Bug管理这3个部分。对于他的自动化测试功能，不敢多做评论，因为毕竟我对这个功能的使用也不是很深入。不过大体上我还是比较倾向与专业的自动化工具，如QTP。
使用了一年多，我对权限管理和Bug管理这2块还是比较满意的。只是版本管理这块稍微弱了些，没那么好用。
Ø 权限管理
TFS的用户管理可以与Windows域用户集成，并提供了系统级、项目级和文件级的完善的权限管理能力，并且设置方便。我一直都是在Windows用户里进行设置，方便快捷。对于使用了Windows这么多年的大家来说，这点是很好上手的。
Ø Bug管理
TFS里默认带了很多工作项：例如要求、任务、风险、Bug等。用户完全可以自己的定义这些工作项代表了什么。例如，我把要求定义成需求，任务定义为分解需求后开发任务。每个要求下可以链接它对应的任务，每个任务还可以下挂它的子任务，而提交BUG时可以选择它对应的任务。通过这样的链接，我们可以清楚的知道一个需求的完成情况，一个任务的稳定情况。
有点说跑题了。对于BUG管理这块，我觉得和ClearQuest很类似，也可以像CQ那样随意的增加工作模板（TFS增加工作模板的方法见http://www.cnblogs.com/erichhuang/archive/2008/09/30/1325742.html），不过他比CQ好的地方就是上面说的工作项之间的链接。差的地方就是报表的功能吧。
TFS里，对于每个工作项的处理流程、包括界面元素，都可以随心所欲的编辑，因为都是图形化界面操作，拖拉完了设置一下就可以了，相当的方便，这也算是比CQ强的一点吧。
我把TFS里的一个不常用的工作项改为了测试用例，添加了测试用例的审核流程，界面增加了版本元素，执行时间等，这样可以实现测试用例的评审、版本的管理、以及用例的执行情况、每个版本关联的BUG。但是还是有不小的缺陷：因为没有办法复制工作项，所以如果产品的版本变了，那么这些用例就必须再手动的增加一次；而且也没有很好的办法去自动统计每个版本中，每个用例发现了几个BUG，这些BUG是否已经处理完毕等等，都要自己手工去查看，对于这点，还是TD之类的要做的好些。不过因为不想测试组使用过多的测试工具，太过于混乱，所以也只有忍忍。这对于小项目还比较适用，大项目或产品组忌用。
Ø 版本管理
测试中的版本管理涉及的有测试需求的版本、测试用例的版本、相关文档的版本、测试环境的版本，有自动化测试的，还包括公用函数库、自动化脚本等的版本管理。对于这么多东西的版本管理，虽然说TFS集成在.net里，可以和VSS集成，但是它本身的操作方式和界面让人很不适应（我是如此。。。），所以我对于版本的管理，还是使用VSS或CVS（用例的版本没包括）。
对于文件版本管理这类的工具
这有个TFS和VSS的功能对比图，瞅瞅吧
|
TFS |
VSS |
|
|
产品定位 |
全集成的，应用生命周期管理工具 |
版本管理 |
|
架构 |
完全的 client-server 架构 |
独立客户端，没有真正的应用服务器 |
|
团队规模 |
最大 3500 用户 |
个人和小型团队 |
|
存储方式 |
SQL Server 2005 |
文件系统，上限4GB |
|
可靠性 |
完全事务处理，check-in为原子操作 |
非事务处理，check-in不是原子操作 |
|
远程访问 |
为 XML Web 服务优化－－适合企业规模的远程访问和协同工作 |
在Visual Studio 2005 中引入了XML Web 服务－－适合小规模的远程访问和协作 |
|
安全性 |
集成Windows认证， 集成Active Directory |
特定于应用，每个人都具有DB访问权限 |
