应用Visual Studio 2010 辅助敏捷测试 (一)
敏捷软件开发是近些年来比较热门的话题，《敏捷宣言》四条主要精神和十二条基本准则概括了敏捷开发的基本思想。围绕着这些基本概念和思想，产生了一系列的轻量级方法，如：极限编程、测试驱动开发、Scrum、特性驱动开发等。虽然具体名称、过程和侧重点不尽相同，但是相对于非敏捷的开发方法而言，它们都更强调面对面的沟通、团队不同角色之间的紧密协作、频繁交付新的可用的软件版本、紧凑而自我组织型的团队等。敏捷开发只是提供了一个思想和方法论，而要在实际的工程中正确运用它，并真正显现出它的优点和产生实际的效果，这对于每个团队而言一开始都是一个挑战，尤其是对那些那些习惯了传统瀑布模式的团队。
敏捷是整个团队的敏捷，不只是团队中某个角色或者某个阶段的敏捷，开发、测试和项目经理等所有角色都要敏捷起来。敏捷方法的采用对团队每个成员都提出了新的挑战，尤其是测试人员。之所以这样说，是因为相对于传统的瀑布模型，敏捷开发所要求的频繁交付，给测试所留出的时间更为紧迫，要求测试人员更早的介入和更及时地完成测试任务。如何在这么短的时间内完成测试的计划和实施呢？如何有效地避免回归问题的出现？手工测试人员如何能更好的融入到敏捷团队？等等问题接踵而至，这都需要需要测试人员不断的思考和尝试。
无论是哪种开发模式，软件的开发过程都可以归结为：人、工具和过程这三个因素，三者的有机结合才能更高效的完成任务。有人会说：《敏捷宣言》四条主旨精神的第一条就是“个体和交互重于过程和工具”，工具还有那么重要吗？回答是肯定的，工具很重要，这条主旨所提到的是“重于”而不是不要。为了支持敏捷开发，Visual Studio 2010（以下简称为VS 2010）应用程序生命周期管理中引入了 MSF for Agile Software Development v5.0 过程模板，用于辅助敏捷团队在实际工程中进行敏捷实践，它支持Scrum 敏捷开发过程框架。本文将从工具角度出发， 介绍Visual Studio 2010 如何帮助测试人员更胜任敏捷项目中的测试工作。对于工具与人的关系而言，好的工具应该是将人从重复和机械的劳动中解脱出来，让人有更多的精力和时间花在有创造性地劳动上，而由工具去完成将繁琐和冗余的事务性操作；而对于工具和过程的关系，工具是过程能够得到确实落实和准确执行的基石，很多时候我们总是依赖于人去执行某个过程或者流程要求，但人的执行往往带有一定不稳定性和主观性，而工具则可以帮助我们准确客观的执行。
一、团队有效协作的基石 ——Team Foundation Server
敏捷开发强调人与人之间的有效沟通和紧密的团队协作。对于测试团队和测试人员而言，首先应该需要考虑的是：如何让测试工作更有效的集成整个敏捷开发的活动中去？而不是将测试工作仅作为一个“附件”或者可有可无的副产品。当然，这会受到团队组织形式和开发过程的限制，例如：采用功能小组模型的团队，所有角色成员（PM、开发人员、测试人员）隶属于同一个功能团队，客观上其沟通就更为方便；而对于采用纵向按职能划分团队的公司而言，测试和开发在隶属关系上是分开的，相对在沟通上障碍就会更多些。无论是哪种组织形式，好的工具能帮助促进和统一各个角色间的信息互通和共享，而不是要让他们彼此之间更为孤立、工作在各自的一亩三分地（Silo）中。Team Foundation Server 2010（以下简称为TFS 2010）就是这样的工具，作为整个团队协作的核心，它统一了团队不同角色信息、实现了信息之间的有效互联互通、彼此之间的共享和关联，例如：TFS 2010 定义6 种默认的工作项类型，如下图所示。
其中，Test Case 和 Shared Steps 是2010 专门为测试新加入的。不要小看这些工作项，它们之间有着丰富的关联关系，这种关系背后所代表是角色之间的关系。对于测试而言，它将测试和团队紧密的结合在一起。例如：Test Case 工作项用来详细定义和管理测试用例，它还可以和User Story 相关联，也就是将测试和用户需求进行了关联，用户可以从需求追溯到覆盖的它的测试用例，这背后体现的是测试人员和需求人员/PM 的协作；Test Case 还可以与Bug关联，通过这种关联可以挖掘出哪些 Bug 被测试用例覆盖，哪些还没有，这种关联体现了测试人员与开发人员的写作，如果是自动化测试用例，则体现了手工测试人员和自动化工程师的协作 ；Bug 还可以可以和签入集（Change-set）关联，可以找到为了修复Bug，开发人员修改过哪些产品代码，这体现了测试人员和开发的关联。
敏捷开发频繁的迭代和较短的迭代周期，对项目管理的精确性、透明性和可见性都提出了更高的要求， 尤其对于那些项目复杂和人员较多的团队。Task 是另一个重要的工作项类型，它用于管理开发过过程中的所有任务项，包括：开发、测试以及需求等任务，统一管理开发中的所有任务，统一计算项目的开销和剩余工作量等。例如，项目的燃尽图就是由它产生出来的。现在，人们虽然在理论和概念上已经非常认同软件测试的在工程中的重要地位，但在具体实际操作中，测试却仍然被看作是低于开发和需求分析等的“二等公民”。当然这是由于多方面的综合因素造成的，从管理技术角度讲，这是由于测试工作本身缺乏可度量性和可见性，从导致了测试工作的透明性的缺失，团队往往看不到测试工作的进度和所带来的成果，从而意识不到测试的真正作用。对于测试人员自身而言，缺乏可度量性也让自己无法对工作进度准确把握，进而失去了对自己工作的目标感和认同感。将测试工作同其他工作一样的用Task 工作项管理起来，增加了它的可度量性和可见性。将测试工作和其它任务一起统筹，时刻确保测试被作为整体中的一部分进行考虑，所有的测试任务都被作为Task 工作项记录下来，例如：编写测试计划、设计测试用例、自动化测试用例等等，每项任务都有三个默认时间估计数据需要填写，它们是：Original Estimate、Remaining 和Completed，分别代表了任务的预估时间、剩余工作量和完成工作量。
为了增强敏捷过程的透明性和可见性，TFS 2010 定义了很多的报表和仪表板（Dashboard），它们会自动生成各种报表，以可见的方式描述敏捷项目的健康状况，这其中就有很多反映测试工作的报表，如下面所示。Stories Overview 展示了用户故事的进展情况，包括了每个用户故事的测试用例覆盖数量和执行结果，以及相应的Bug 数量；Test Dashboard 显示了测试用例的状态，包括正在设计的用例以及设计完毕可以执行的用例数量，现实当前Bug 的状况，包括未被修复和以修复Bug 的数量。
全文收录于2010年InfoQ中国《架构师》7月刊 “Visual Studio 2010之美”，作者：软件测试开发工程师周京生。