测试自动化技能树

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

测试软件的最佳方法不只一种.除手动测试外,根据您的具体开发环境,您可使用商业测试自动化框架.开放源代码和内部测试自动化框架,以及自定义测试自动化脚本.所有这些方法都各有优缺点. 自定义测试自动化脚本的优势是编写快捷且最为灵活.但是,可管理性是自定义测试自动化的瓶颈.超大批量的测试脚本.测试案例数据和测试结果使得测试不堪重负.幸运的是,您可使用 Visual Studio 2005 Team System 管理自定义测试自动化.我将使用一些屏幕快照对此进行解释.首先,请考虑图 1 中所示的执行测试

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

如果您经常使用测试自动化操作工具,那么您可能对测试自动化框架的概念十分熟悉 .测试者们会经常寻找一些建议.参考,以及解决方案,但是框架只是您所需要考虑内容 的一半.如何构建您的测试代码,使您所测试的应用软件的测试过程最便利取决于有效自 动化操作的第二个步骤. 这篇文章重点强调第一个步骤,它可以帮助您理解如何有效地使用您所拥有的工具. 这个步骤包括以下几个论题: 对象和属性 使用浏览器的常见问题 验证点 低级的指令 脚本帮助器超类 对于每个论题,您可以在这篇文章末尾的参考资源中找到相关附加信息的连

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

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

这是两个很绕口的词.而且乍一看起来好像就是同一份工作.今儿聊聊我个人对于这两者的认识. 举例: 有一天,一家手机公司要做一个UI自动化测试,于是他们聘请了一名工程师. 这个工程师需要做的事情,首先就是setup一个自动化测试环境.单单从这方面来说,测试工程师和自动化工程师需要做的是完全一样的.比如搭建起来一套完整的UiAutomator环境. 之后就会有区别了.当环境搭建好以后,测试工程师的主要精力就会铺到编写脚本,执行测试上.而自动化工程师则会把精力放在如何优化UiAutomator环境上 比

测试自动化小组尝试过另一款芬兰同事开发的新型框架,名字叫做robotframework,如今已经开源.这个框架本身使用Python语言开发完成,用来开发可接受性测试,是关键字驱动的测试自动化框架,支持多种测试用例的格式,我最喜欢的是使用表格的HTML文件格式.框架非常好用,各方评价都非常高,但是由于核心的开发者都在芬兰,杭州本地需要有人能够进行培训.辅导,才有可能做到快速地推广使用.于是测试自动化小组的同事参加了该框架的高级培训,以及如何进行入门级培训的培训,然后向杭州研发中心的其他同事提供培训

在敏捷开发中, 我们都知道要将功能切割, 每次做些小功能, 然后持续交付价值给客户. 因此当你在开发每个小功能时, 你会不断进行以下事情: 1. 从主干 check out 程序代码到分支 2. 开发团队在分支进行开发 3. 小功能开发完后, 将分支程序, merge 回主干 4. 在主干进行测试 可是通常这样在第四步时, 就会遇到一堆错误. 这是因为小功能还没确认是否正确, 就和整个系统和起来测试, 将导致问题多多. 如果有很多小功能要放进来时, 这种情况就会更恶化. 因此有些团队可能会这样做