测试运行: 使用Team System自定义测试自动化

测试软件的最佳方法不只一种。除手动测试外,根据您的具体开发环境,您可使用商业测试自动化框架、开放源代码和内部测试自动化框架,以及自定义测试自动化脚本。所有这些方法都各有优缺点。

自定义测试自动化脚本的优势是编写快捷且最为灵活。但是,可管理性是自定义测试自动化的瓶颈。超大批量的测试脚本、测试案例数据和测试结果使得测试不堪重负。幸运的是,您可使用 Visual Studio 2005 Team System 管理自定义测试自动化。我将使用一些屏幕快照对此进行解释。首先,请考虑图 1 中所示的执行测试自动化脚本。

图 1 典型自定义测试自动化脚本

测试自动化是非常短的 JavaScript 脚本,对名为 TriMax 的方法(只返回三个整数中的最大一个)执行模块测试。TriMax 方法驻留在典型的 COM DLL 文件中。尽管简单且有效,但使用此类型方法的测试自动化还是有几个缺点。测试结果将存储在何处?此测试运行是根据 DLL 的哪个版本的执行?如何才能与开发团队的其他成员共享这些测试结果?这些结果是否与任何公开错误有关?Visual Studio Team System 专门处理此类问题,如图 2 所示。

图 2 使用 Team System 管理自定义测试自动化

Visual Studio 2005 Team System 由 Team Foundation Server (TFS) 和 Visual Studio 的一个客户端版本组成。您可将 TFS 视为智能后端数据仓库,该仓库用于存储和管理与软件开发项目关联的所有数据,包括源代码、错误、测试结果、规范文档以及其他内容。

我在本专栏中介绍的自定义测试自动化功能在面向测试人员的 Visual Studio Team Edition 中提供。您可从 microsoft.com/downloads 下载 Visual Studio 2005 Team Suite 的 180 天评估版本(其中包括所有版本的功能)以及 Team Foundation Server。

我将在本专栏中向您展示三个示例。第一个示例显示测试人员如何使用 VSTE 来提取一段非常简单的自定义测试自动化,并将其封装到可由 Team System 管理的测试中。第二个示例更进一步,向您显示如何修改自定义测试自动化以便您可以创建测试案例结果(具有更加详细的信息,而不是仅仅通告通过或失败)。我的第三个示例显示如何使用 Team Foundation Server 来存储和管理测试运行结果数据。

时间: 2024-09-24 23:55:57

测试运行: 使用Team System自定义测试自动化的相关文章

Team System: 自定义签入策略

在本专栏的最近三期中,我探讨了 Team Foundation Server (TFS) 版本控制和工作项跟踪 API.我 使用这些 API 构建了一个 Microsoft Word 2003 加载项,为 Word 文档的签入和工作项关联提供 支持,这类似于 Visual Studio 2005 中团队资源管理器的功能.在本期专栏中,我将深入论述签 入说明和策略.您将了解签入说明的工作原理以及如何编写自己的自定义策略实现.在未来的专栏中,我 会将此支持添加到 Word 加载项中. 签入说明和策略

模糊测试: 为Team System创建自定义的测试接口提供程序

在奥兰多参加 Microsoft Tech•Ed 2007 会议时,我有幸在"The Learning Center"的一个开发人员展位工作过.这次经历让我感触最深的是围绕最新的应用程序生命周期管 理 (ALM) 工具所展开的讨论.同时还有大量关于热门方法的讨论,例如敏捷编程和测试驱动的开发 (TDD).因此,Microsoft 的最新 ALM 套件 - Visual Studio Team System (VSTS) 产品倍 受关注. VSTS 为测试人员提供了一些强大的功能和可扩展

用 .NET 开发的轻量级 UI 测试自动化

James McCaffrey 下载本文的代码: TestRun0501.exe (131KB) 本页内容 待测试应用程序 测试自动化脚本 操作待测试应用程序 检查应用程序状态 讨论 手动用户界面测试是一种最基本的软件测试类型,大多数软件工程师首次采用的就是这种测试类型.与此矛盾的是,自动化用户界面测试可能是编写的测试类型中最具技术挑战的一种.Microsoft .NET 环境为您提供了许多编写自动用户界面测试自动化的方式.一种常见而有用的方法是记录击键.鼠标移动和单击,然后在应用程序中回放以确

Team System: 工作项目和撤消支持

在本专栏 2007 年 1 月期中 (msdn.microsoft.com/msdnmag/issues/07/01/TeamSystem),我介绍了 如何创建 Microsoft Word 2003 加载项来与 Team Foundation Server 版本控制子系统协同工作. 在 2007 年 4 月期的专栏中 (msdn.microsoft.com/msdnmag/issues/07/04/TeamSystem),我深入探讨了 工作项目跟踪子系统.在本月的专栏中,我将介绍如何向加载项添

Team System: Team Foundation Server版本控制

最初,我并没有想过要开设这么一个专栏,我是在 2004 年 2 月开始酝酿这个想法的.当时,我在位 于雷蒙德的 Microsoft 总部参与一项针对即将推出的代号为"Burton"的产品的软件设计评 审.每次评审会议上,我都会举手提出相同的问题:"有扩展点吗?"两天时间里,我总是得 到一个令我忍俊不禁的答案:"有的,Brian,你可以自定义."Burton 就成了后来的 Visual Studio Team System,而如何对其进行自定义即是

紧耦合金融系统群的测试自动化策略(一)

三句话背景 科技子公司或者IT部门在一个大金融团体里面只能算是个成本中心,对IT团队来说,核心使命就是稳定运营.降低成本.这对于自动化测试来 说,意味着非常有限的资源预算.不稳定的测试环境.复杂的系统耦合关系.严苛的测试数据要求,还有那近乎无理的信息安全规范.如此种种,让我们并不能按照 自己想象的那样去实施自己的规划,以致会走很多弯路:而再回首你会觉得,有时候只是方法欠妥而不是资源不够,有时候只是导向错误而非技术不够高. 关键字:金融系统:自动化测试:单元测试:环境监控:测试数据:持续集成: 传

我的软件测试之旅:(3)同期——加入测试自动化小组

刚被派遣到诺基亚不久,确切地说是刚刚结束新员工入职培训的时候,小组长问我对测试自动化是否 感兴趣,我觉得好像蛮酷的,而且还可以被派到北京去参加两天的培训,英国人授课,何乐而不为呢.这个英国人就是Mark Fewster,<Software Test Automation>的作者,这本书被认为是该领域的开山之作,详细地描述了测试自动化相关的所有细节.战略和战术.于是就这样我加入了只有两个人的兼职测试自动化小组,之所以成立这个小组是因为在国外的其他研发中心使用测试自动化的效果非常好,所以要把它引入

Team System: 工作项跟踪

在我的上一专栏中,我开始说明如何使用 Team System 中公开的 API 为 Microsoft Word 2003 生成源代码控制外接程序.如果在 Visual Studio 2005 中检查团队资源管理器公开的签入对话框 ,则会注意到集成的签入体验是相当丰富的.您不仅可以签入源文件,而且可以使签入与工作项关联,添 加签入注释,以及根据策略验证签入.图 1 显示选中"工作项"选项时的标准签入对话框. 图 1 团队 资源管理器集成的签入对话框 从表面上看这是很简单的,其实不然,签

选择测试自动化框架

基于只使用一种捕获工具例如IBM Rational Robot来录制并且回放测试用例而得出自动化测试工作量是有缺陷的.只使用一种捕获工具来运行复杂且巨大的测试是非常耗费时间和昂贵的.因为这些测试是随机创建的,他们的功能性是很难追踪和重现,而且维护成本也是非常昂贵的. 对于一个刚刚起步的自动化测试小组,更好的选择是使用一种测试自动化框架,它已经定义好了由一些假设,概念和制定工作平台或为自动化测试提供支持的实践组成的集合.在这篇文章中我试着将一些我熟悉的测试自动化框架-特别是测试脚本模块化,测试库构