敏捷软件开发是近些年来比较热门的话题，敏捷开发只是提供了一个思想和方法论,而要在实际的工程中正确运用它，并真正显现出它的优点和产生实际的效果，这对于每个团队而言一开始都是一个挑战，尤其是对那些习惯了传统瀑布模式的团队。
敏捷是整个团队的敏捷，不只是团队中某个角色或者某个阶段的敏捷，开发、测试和项目经理等所有角色都要敏捷起来。敏捷方法的采用对团队每个成员都提出了新的挑战，尤其是测试人员。之所以这样说，是因为相对于传统的瀑布模型，敏捷开发所要求的频繁交付，给测试所留出的时间更为紧迫，要求测试人员更早的介入和更及时地完成测试任务。如何在这么短的时间内完成测试的计划和实施呢？如何有效地避免回归问题的出现？手工测试人员如何能更好的融入到敏捷团队？等等问题接踵而至，这都需要测试人员不断的思考和尝试。
无论是哪种开发模式，软件的开发过程都可以归结为：人、工具和过程这三个因素，三者的有机结合才能更高效的完成任务。
为了支持敏捷开发，VS 2010应用程序生命周期管理中引入了MSF for Agile Software Development v5.0过程模板，用于辅助敏捷团队在实际工程中进行敏捷实践，它支持Scrum敏捷开发过程框架。本文将从工具角度出发，介绍Visual Studio 2010如何帮助测试人员更胜任敏捷项目中的测试工作。
在VS 2010中，微软首次为测试人员设计了一款专用的集成测试环境，称为微软测试管理器2010（Microsoft Test Manager 2010，以下简称为MTM）。之所以称之为集成测试环境，是因为MTM的功能涵盖了测试计划、测试用例、手动测试用例的执行和录制回放、自动测试用例执行、创建信息丰富的Bug、验证Bug、以及与测试实验室管理相关的对策是自动化相关的功能等。下图展示的是MTM测试计划的操作界面，它以树形的层次结构来组织测试用例。MTM测试计划的操作界面测试用例
在MTM 中，测试用例被分类至各个测试用例集，结构十分清晰。测试用例只是逻辑上从属于某个测试用例集，并没有物理从属关系，即一个测试用例可以同时被分在多个测试用例集内，比如某个测试用例性质上是一个性能测试，但是由于该用户故事的诉求就是性能改进，我们也就很自然得可以将其作为该用户故事的验收测试，此时我们就可以将此测试用例添加到验收测试和性能测试两个测试用例集中；另一个例子是给每个用户故事都定义了不少测试，这些测试用例都应该能在用户故事测试用例集下找到，但是这些测试既可能是手动测试也可能是自动化测试用例，所以它们又会被本别归类至测试用例集。在这种逻辑分类的支持下，我们可以很容易的根据需要指定运行测试集中一部分测试用例。比如，我们可以定义一个签入测试的测试用例集，挑选最基本的若干个测试置入其中，这样在每次签入前通过运行这个测试用例集就能帮助我们确保签入的代码不至于破坏最基本的功能，即保证了版本随时可运行可测试，这无疑为测试带来了更多的方便。具体如何创建测试用例集的结构，团队可以根据自己项目的特点，灵活运用此功能，制定分类规则以提高工作的效率。
敏捷是整个团队的敏捷，不只是团队中某个角色或者某个阶段的敏捷，开发、测试和项目经理等所有角色都要敏捷起来。敏捷方法的采用对团队每个成员都提出了新的挑战，尤其是测试人员。之所以这样说，是因为相对于传统的瀑布模型，敏捷开发所要求的频繁交付，给测试所留出的时间更为紧迫，要求测试人员更早的介入和更及时地完成测试任务。如何在这么短的时间内完成测试的计划和实施呢？如何有效地避免回归问题的出现？手工测试人员如何能更好的融入到敏捷团队？等等问题接踵而至，这都需要测试人员不断的思考和尝试。
无论是哪种开发模式，软件的开发过程都可以归结为：人、工具和过程这三个因素，三者的有机结合才能更高效的完成任务。
为了支持敏捷开发，VS 2010应用程序生命周期管理中引入了MSF for Agile Software Development v5.0过程模板，用于辅助敏捷团队在实际工程中进行敏捷实践，它支持Scrum敏捷开发过程框架。本文将从工具角度出发，介绍Visual Studio 2010如何帮助测试人员更胜任敏捷项目中的测试工作。
在VS 2010中，微软首次为测试人员设计了一款专用的集成测试环境，称为微软测试管理器2010（Microsoft Test Manager 2010，以下简称为MTM）。之所以称之为集成测试环境，是因为MTM的功能涵盖了测试计划、测试用例、手动测试用例的执行和录制回放、自动测试用例执行、创建信息丰富的Bug、验证Bug、以及与测试实验室管理相关的对策是自动化相关的功能等。下图展示的是MTM测试计划的操作界面，它以树形的层次结构来组织测试用例。MTM测试计划的操作界面测试用例
在MTM 中，测试用例被分类至各个测试用例集，结构十分清晰。测试用例只是逻辑上从属于某个测试用例集，并没有物理从属关系，即一个测试用例可以同时被分在多个测试用例集内，比如某个测试用例性质上是一个性能测试，但是由于该用户故事的诉求就是性能改进，我们也就很自然得可以将其作为该用户故事的验收测试，此时我们就可以将此测试用例添加到验收测试和性能测试两个测试用例集中；另一个例子是给每个用户故事都定义了不少测试，这些测试用例都应该能在用户故事测试用例集下找到，但是这些测试既可能是手动测试也可能是自动化测试用例，所以它们又会被本别归类至测试用例集。在这种逻辑分类的支持下，我们可以很容易的根据需要指定运行测试集中一部分测试用例。比如，我们可以定义一个签入测试的测试用例集，挑选最基本的若干个测试置入其中，这样在每次签入前通过运行这个测试用例集就能帮助我们确保签入的代码不至于破坏最基本的功能，即保证了版本随时可运行可测试，这无疑为测试带来了更多的方便。具体如何创建测试用例集的结构，团队可以根据自己项目的特点，灵活运用此功能，制定分类规则以提高工作的效率。
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货