Visual Studio 2012
连续开发测试
Web 应用程序通常更新或延长每隔几周 （或甚至几天） 中转移的业务需求和客户反馈的反应。 若要支持持续发展，开发周期的每个方面必须更有效率、 更轻量比更多传统的发展进程。 例如，它是即使最小的更改需要一切都要重新测试软件的性质。 但重复一套完整的手动测试每隔几天是不可能的。 这意味着测试最终必须自动，即使他们开始为手动的探索。 在这篇文章中我们展示如何 Microsoft Visual Studio 2012 支持可持续发展环境中测试。
DevOps 周期
当软件部署和运行时，几个软件项目将走到尽头。 从利益攸关者获得反馈，改善或扩展计划，和最终获释，随即在周期再次启动一个新的版本。 此过程中，称为 DevOps，周期所示图 1。
.jpg)
图 1 连续开发周期
在传统的软件项目中，每个周期可以年。 第一个版本通常是丰富的功能，在 DVD 上提供并安装在用户的本地计算机上。 与之相反的是，现代 Web 应用程序中，第一个版本可能很小，但释放扩展及改善每隔几周 （或甚至几天）。
例如，一个社交网站的管理者可能一周，其间他们监控客户是如何使用它尝试一个新的功能。 在试行期结束，他们调整功能的工作原理详细的信息。
在此更快速的周期中，很重要的开发团队想作为整个进程的 DevOps 周期。 特别是，他们需要使周期中的每个活动更加有效，删除任何妨碍周围循环进度的路障。
在测试过程中，我们在这里讨论改进，旨在减少需要通过 DevOps 循环周期的时间。 特别是，这些新的工具和技术旨在减少测试这种循环在传统上造成的瓶颈。
DevOps Cycle 中测试
测试的关键作用是演示实施用户故事和其他要求。 手动运行该应用程序，并行使每个故事只是作为最终用户将最有效的方法来执行此操作。 经验丰富的测试仪适用于各种策略，揭露的 bug，并探讨所有变种和边缘例的应用程序的行为。
当应用代码更改时，它是审慎的做法是重新测试可能取决于它的一切。 软件中的依赖关系通常形成复杂编织，bug 众所周知转似乎无关的更新焦点的功能。 出于此原因，传统的开发团队不喜欢改变的任何组件都已编写和测试。 如上所述，稍作改变的要求完全重新测试，因此如果您手动测试的一切，这需要大量的精力和资源。
与此相反，在短周期中持续发展的内在需要软件的每个部分应经常重新审议，其功能是改善和扩展。 它将无法手动重新测试每一项功能每隔几天。 短周期需要替换手动测试的程序代码的自动的测试。 很快，并且只要你喜欢，您可以运行编码的测试。
应连续开发团队他们的所有测试的都代码，并放弃完全手动测试吗？ 有时有人建议这种做法，但在实践中，有一个高效的妥协，工程，如下所示。
手动测试新的和大幅更改的故事。 当每个测试通过一贯，创建自动的版本的那个故事的测试。 因此，尽管测试总人数逐渐增加，随着该产品的扩展，手动测试的负载保持不变因为手动测试是你只为相对较新的功能做的事情。
事实上，编码的测试，在一个典型的可持续发展项目中的大部分都与应用程序代码编写和测试软件，而不是测试整个应用程序的行为内单个组件的单元测试。 单元测试是一个强大的工具，更新基本代码时保持稳定。
图 2 显示从手动逐渐过渡到随着时间推移，并扩展单元测试和应用程序代码的自动测试。 图中是一种理想的照片 ； 在实践中，大多数队伍自动化只有一定比例的手动测试。 Visual Studio 2012 （和其它版本） 还提供部分自动化，可以用来加快速度的测试，而无需编写代码。
.jpg)
随着时间的推移，图 2 理想过渡到手动从自动测试用例
在 Visual Studio 2012 年测试
让我们看看如何测试由 Visual Studio 2012 和其相关联的产品，Visual Studio 团队基础服务器 (TFS) 和 Microsoft 测试管理器 （MTM) 支持。
如果您的专业测试整个应用程序，你会更感兴趣的 MTM 所提供的支持。 如果您是开发人员，您可能需要在 Visual Studio 2012 年自动化测试支持更大的兴趣。 然而，不断发展，我们需要这两个角色，更密切的关系，有些参赛队完全免除这种区分。 因此，Visual Studio 2012 工具旨在集成的测试、 不同风格和他们支持广泛的测试做法，通过不断发展更多传统的方法。
自动测试与 Visual Studio 2012
自动化测试包括测试通过书面或生成程序代码定义的所有类型。 您在 Visual Studio 2012 年，那里你最初运行它们用于调试创建自动化的测试。
当测试 — — 与它测试的应用程序代码 — — 是正确的您在测试中，应用程序代码和检查。 从源代码储存库，它生成服务由拾并定期运行您的团队生成定义。
单元测试和集成测试单元测试是一个最有效的方法维持无 bug 的基本代码通过在应用程序中的连续变化。
单元测试是一种测试方法、 类或较大的组件，您的应用程序中其他部分、 外部系统和资源的分离的方法。 在实践中，开发人员通常编写集成测试 — — 那就是，在单元测试，但这可能取决于外部数据库、 Web 站点或其他资源以类似的方式编写的测试。 不管怎样，这些测试使用相同的工具和基础设施。
在 Visual Studio 到 2012 年，您可以编写使用任何一种的几个测试框架，例如 NUnit，xUnit 和默认的 VSTest 的测试。 当你有编码的任何这些框架中的测试时，您只需打开测试资源管理器窗口，并选择运行所有。 在窗口中概述的测试结果。
背景测试是有效地在后台运行您的测试，每次您生成解决方案的选项。 第一次执行您的更改而受影响的测试。 这意味着当您工作时，您可以经常看到哪些测试是通过或失败。
隔离单位通过使用正版正货 True 单元测试是指下测试单位断开，它所依赖的代码。 这有很多好处。 如果您单位正在开发，或在同一时间更新它所依赖的其他单位，您可以测试它而无需等待别人来完成。 如果您调整应用程序使用此单元，以不同的方式，或在不同的应用程序中，这些测试和它一起去，并不需要更改。
Visual Studio 2012 提供了两种机制，统称为假货，为一个单位断开及其依赖项。 从您的单位对其边界以外的方法的调用可以由您提供的代码小件处理。 例如，您可以定义截获对任何外部的方法，如 DateTime.Now 的调用的垫片。 因为它总是从农心接收相同的应答，您的设备将在每次调用时演示相同的行为。 您还可以定义存根，所提供的占位符中没有已加载的程序集的方法的实现。
性能和负载测试 Visual Studio 2012 最终提供的性能和应力测试特定的测试设施。 应用程序可以检测和驱动，以便衡量其指定负载下的性能。 Web 应用程序可以驱动与模拟多个用户的多个请求。
编码的用户界面测试编码的用户界面测试让您运行您的应用程序，并生成驱动它的 ui 界面的代码。 Visual Studio 2012 包括专门的工具，用于创建和编辑编码的用户界面测试，还可以编辑和添加到代码自己。 例如，您可能会创建一个简单的过程，要买东西的 Web 站点，然后编辑代码，以添加一个循环，买了很多项目。
编码的用户界面测试程序尤其有用，凡有验证或其他 UI 中的逻辑 — — 在 Web 页中，例如。 作为用户界面的单元测试或整个应用程序的集成测试，您可以使用它们。
手动测试与 Microsoft 测试经理
手动测试可以探索计划内或计划外。 您执行手动测试 MTM 的帮助。 您的应用程序已从签入代码生成的版本通常执行的测试。
通常情况下，手动测试链接到用户的故事 （或产品积压项目或其他要求），并测试的结果显示在项目仪表板上的报告中。 这意味着，每个一个可以快速查看哪些故事已被成功地实施。
探索性测试探索性测试只是意味着运行应用程序，可以试试看。 然而，你为什么需要 MTM，以帮助您运行它？
MTM 可以记录你的行动、 评论和截图，而你的工作。 如果您决定要创建一个 bug 报告，所有此类信息会自动添加到它，使它不必要为您要添加如何重现 bug 的精确描述。 图 3 显示 MTM 探索性测试窗口旁边正在测试的 Web 应用程序的示例。
.png)
图 3 录制屏幕截图和探索性测试窗口中做笔记
MTM 还可以检测应用程序本身，都在客户端和服务器上，可以用来调试该应用程序的记录的事件数据。 此数据将自动附加到您的错误报告。
当该 bug 固定的时你要重复步骤你花在探索来验证此修补程序。 为解决这一问题，您可以从探索性会议，在其中您包括有关步骤生成测试用例。
计划的测试用例的测试的测试用例是您定义为一系列的测试人员应执行的步骤的手动测试。 图 4 显示在一个测试用例中定义的步骤。
.png)
图 4 在一个测试用例中定义的步骤和预期的结果
测试用例提供澄清的用户所需要的好方法。 在短跑运动开始时，当你正在讨论故事或需求与用户和其他利益攸关者，您可以使用步骤作为一个精确的用户将能够在 sprint 年底做例子。 每个测试案例是的要求，只是一个实例，所以每一项要求是通常与多个测试用例相关联。 例如，如果要求是为了能够买冰激凌，一个测试用例将详细介绍的步骤来购买一种特别的风味。 您将创建另一个测试用例来描述购买香料的混合物。 应与利益攸关者讨论的指导原则："时您可以成功地执行这些测试用例，然后我们会考虑的故事将实施。
TFS，在这些故事或要求和测试用例由代表的工作项。 您可以将它们链接一起这样一项规定的进度可以跟踪测试的结果。
当您运行一个测试用例时，这些步骤将显示在屏幕的一侧。 运行应用程序时，您检查关闭的每一步。 结束时，您检查是否通过了测试已关闭或失败。
正如与探索性测试，您的操作，评论，屏幕截图和应用程序数据记录以便您可以非常迅速地创建一个详细的 bug 报告。
他们帮助任何人可靠、 重复测试，即使他们不熟悉应用程序的使用步骤一大优势。 当测试重复的时您可以确信是否通过或失败，这并不只是因为从最后一次以不同的方式运行测试。
您还可以从探索会话生成一个计划的测试用例。 这样有助于确保您始终运行测试使用相同的操作。
自动化手动测试
自动化您手动测试相当一部分，必须尽量减少测试 DevOps 周期中所需的时间。 Visual Studio 2012 支持这种自动化，在几个方面。
录音/播放半自动化可以重新运行测试用例。 运行测试时的第二次和其后时间，MTM 重播的击键和您使用第一次运行的手势。 你要做的就是验证您看到的结果符合步骤中详细说明的期望。
播放使手动测试更快、 更可靠。 它还使它可能分配各同事们可能不完全熟悉应用程序的测试负载。
即使您不完全自动化测试，快速、 可靠的回放有助于减少周期时间的 DevOps。 此功能不需要 Visual Studio 2012 年安装，并不涉及编写的代码。
生成编码用户界面测试你可以从手动测试案例记录运行生成完全自动编码的用户界面测试。 生成的代码将执行相同的操作，则手动测试。 通过在 Visual Studio 2012 年使用一个特殊的编辑器，您还可以扩展测试以验证结果并归纳它以不同的输入数据的重复测试。 图 5 显示了特殊的编辑器。
.png)
图 5 编辑 UI 操作在 Visual Studio 2012 年
链接到测试方法的测试用例可以将一个测试用例链接到任何测试方法中，即使它还没有被从您的测试运行生成。 将报告运行测试的结果，因为如果您曾运行手动步骤。 通常您会将测试用例，链接到集成测试的执行操作手动测试相同，但直接，驱动器的业务逻辑，而不是使用用户界面。
这种方法具有 UI 布局的变化不失效测试的好处。 当开发团队已经创建了一个合适的集成测试，这也非常有用。
Lab Management
当您测试应用程序时，您需要的第一件事是一台机器上运行它。 事实上，大多数应用程序今天需要多台机器。 一个现实的测试环境，您可能，例如，需要所有在单独的计算机上安装一个 Web 服务器、 数据库服务器和客户端浏览器。 图 6 说明了这样一个环境。
.jpg)
图 6 样本的实验室环境测试式销售网站
除了基本的安装，您也要安装可以收集的前面"探索性测试"一节中提到的事件数据的代理。
在 MTM 命名实验室中心功能使所有这一切都简单明了。 劳顾会中心允许您定义实验室环境。 在实验室环境是一套将作为一组用于测试目的的机器。
除了处理分配的机器 （因此意外地不能使用一种别人的测试运行的机器），实验室中心还安装了必要的测试剂。 劳顾会中心提供一个地方你可以快速登录到的任何环境中计算机的控制台。
劳顾会中心也是好的创建和管理虚拟机 (Vm)。 您可以创建一个虚拟的环境、 安装相关的平台软件，然后将存储库副本，每当您想要测试您的应用程序，您可以使用。 你要做的就是 reinstantiate 清洁环境的副本并安装新版本的应用程序的组件。 您还可以自动进行此部署过程。
使用实验室中心 — — 和，特别，利用其设施与虚拟机 — — 可以显著地减少相比更传统的方法去维护一个实验室的实验室设置时间。 劳顾会中心是减少每个 DevOps 周期中所花的时间的重大贡献。
自动化测试 TFS
自动化的测试最初开发者的计算机上执行 Visual Studio 2012 年。 该代码有后尚未签入到的源存储库中，有很多种方法可以通过生成服务运行测试的集成代码。
定期生成生成服务编译代码并运行测试。 您可以创建生成定义，以指定要运行的测试，并可以指定他们应在何时运行。 例如，您可能连续的基础上运行的测试的一套核心并每晚运行更广泛的集。
生成的结果可查看 Visual Studio 2012 年，也可从您的项目 TFS Web 服务。 电子邮件可以通知您的故障。
实验室部署如我们先前所述，您可以指定一组的实验室机器到测试通过使用实验室中心。 通过定义一个实验室生成，可以自动执行此过程。 您生成触发时 — — 例如，当检查代码中，或在一天的特定时间 — — 生成开始通过编译的所有应用程序并测试代码。 如果此操作成功，则分配实验室环境，并且如果它是一个虚拟的环境，它可以设置回到新鲜的状态。 您的应用程序组件然后部署到正确的机器，并从他们那里驱动应用程序指定的客户机上安装测试。
这些测试可以是任何种类的自动化的测试，但通常您使用这种类型的生成执行大型集成测试或测试整个应用程序。
如果您的测试链接以测试用例时，结果将记录针对相关的用户故事或要求，并显示在项目进展报告。
报表
TFS 提供了大量的图表和表格，显示一个项目的进度。 单独或项目仪表板，您可以查看它们。 几个测试的相关报告中。
例如，用户的故事测试状态报告，说明了图 7，当前的短跑显示您正在处理的故事的列表。 除了执行的每个故事的发展工作，图表显示成功或失败的相关测试。 如果故障未在运行测试时发现的由此产生的错误报告还链接到要求。
图 7 用户故事测试状态报告
|
|
|
|||||||||||||||||
在图表上的结果来自于最新运行手动测试和自动化的测试运行。
试验计划的进展报告，说明在图 8，显示为当前冲刺创建多少测试用例和已运行多少。
.png)
图 8 测试计划进度报告，是百米冲刺
有的队想在每一次冲刺，开始时创建测试用例，作为团队的目标。 所有的测试都应为绿色末尾的冲刺。
Visual Studio 2012 和持续发展
现在，您有一些熟悉 Visual Studio 2012 年测试功能，从对整个应用程序手动测试的单元测试的范围。
DevOps 循环意见发展作为只是一人一半的一个过程，它还包含操作的反馈。 根据上下文，DevOps 周期将长期或短期。 如果您正在开发一个核电站，希望你去周围循环非常缓慢。 如果您正在运行的 Web 应用程序，您可能会围绕着它去每隔几天。 慢速和快速周期都同样有效和适当的不同类型的系统。 两者都将纳入测试不同程度的需求。 如果快速循环的持续发展是适合您的项目，它是重要的是要减少在循环中执行每个操作所需的时间。 你也许还在项目中工作时更加慎重的步伐使少角色的开发人员和测试仪比之间的区别。
在 Visual Studio 2012 年可用的工具可以大大减少测试您的应用程序所需的时间量。 这里有几点需要记住：
- 洁净实验室环境可以将设置快速和自动，特别是通过使用虚拟机。 利用实验中心的优势。
- 记录操作期间探索性和计划测试可让您创建 bug 报告快速、 可靠地，减少一个 bug 将会消失，当有人试图重现它的机会。
- 您可以实现从手动测试逐渐过渡到自动化测试。 自动化的测试处理大部分的回归测试，而手动测试侧重于新的和更新的故事。
- 从探索性测试中，您可以生成可重复执行手动测试用例。
- 您可以记录测试运行和回快速而可靠地玩耍。
- 您可以从测试运行生成编码的用户界面测试。或者，您可以将链接分别编码的集成测试，测试用例。
图 9 显示从探索性测试的自动化测试的进展。
.jpg)
图 9 测试进度
- 测试用例可帮助您精确地描述你的用户故事。 您可以使用您的利益相关者写的步骤，减少任何故事所做的事情的误解。
- 测试链接到的要求 （或用户故事或产品积压项目） 所以你可以看到全面的报告上多远已实施用户的需要 — — 不只是在做他们的工作，但在他们是否成功。 测试为在每次冲刺的开发团队提供了目标。
- 测试用例和要求可以链接到演示图板 PowerPoint、 需求文档或统一建模语言模型中。 当您在情节提要中进行更改时，您可以跟踪到测试必要的更改。
- 试验计划的链接在一起测试用例、 代码、 要求、 测试环境和测试设置和团队项目。 如果团队花费几个月才返回以提高产品在别的东西上工作，它很容易重建一切所需的测试。
我们给你的视觉工作室 2012年如何配合 DevOps 周期概述。 现在，您应了解为什么你需要到测试了简化的方法和工具 Visual Studio 2012 提供的旨在帮助您实现这一目标。 如果你想要更多的信息，阅读"测试的连续传递与视觉工作室 2012 RC"在 MSDN 库中 bit.ly/KHdOq4。 它是深入的指南，Visual Studio 2012 提供的测试基础设施的各个方面。 在相关文章包括"验证代码的使用单元测试" bit.ly/dz5U3m 和"测试应用程序"在 bit.ly/NbJ01v。
Larry Brader 一直是微软模式高级测试仪 & 在过去几年的实践团队。 在此之前，他曾担任开发人员和测试人员对军事和医疗技术。
艾伦? 卡梅伦遗嘱是在微软开发司编程的作家。 在以前的生活中他已经开发人员、 软件架构师和开发方法中的一名顾问。
衷心感谢以下技术专家对本文的审阅：侯伟 Hilliker，卡特里娜飓风里昂-史密斯、 彼得教务长和罗希特尔马