自动化测试和测试自动化的区别

这是两个很绕口的词。而且乍一看起来好像就是同一份工作。今儿聊聊我个人对于这两者的认识。

  举例:

  有一天,一家手机公司要做一个UI自动化测试,于是他们聘请了一名工程师。

  这个工程师需要做的事情,首先就是setup一个自动化测试环境。单单从这方面来说,测试工程师和自动化工程师需要做的是完全一样的。比如搭建起来一套完整的UiAutomator环境。

  之后就会有区别了。当环境搭建好以后,测试工程师的主要精力就会铺到编写脚本,执行测试上。而自动化工程师则会把精力放在如何优化UiAutomator环境上

  比如,大家都知道UiAutomator的case编写完成后,首先需要通过ant编译,然后再通过adb命令进行push,最后才能执行。这一点上,一般来说测试工程师就不会做什么改变了,但是自动化工程师一定会做一个程序或者批处理或者其他的什么,让这几个步骤变成点一下就全干完的事情。

  什么是测试自动化:

  这是一种让测试过程脱离人工的一次变革。对于控制成本,控制质量,回溯质量和减少测试周期都有积极影响的一种研发过程。

  什么是自动化测试:

  通过将测试执行部分部分或者全部交由机器执行的一种测试,叫做自动化测试。这种测试不需要人的实时参与。同时这种测试在小规模应用时会比手动测试昂贵许多。

  自动化测试可以看作测试自动化的一部分。

  不同的工程师,工作不同:

  一个自动化工程师,会比较专注于测试工具的研发。最主要的是这个工程师会从成本的角度去考虑问题。这一点比较像PM。他所做的一切是为了减少自己或者团队的工作量,尽可能的将重复的,有规律可循的工作代码化,自动化。

  一个自动化测试工程师,会比较专注于测试代码的开发,以及测试结果的分析。对于被测设备本身非常感兴趣。他们比较倾向于一种完美主义者,追求的是高质量而经常忽略成本。这一点更像开发人员。

  现在绝大多数公司都会执着于自动化测试,而忽略测试自动化。这一点会让整个AT(automation test,下同)成本变得非常高。

  我曾经面试过一家公司的AT工程师,对方对于AT的做法就是每天都在release新的测试代码,每天都在run不同的测试。每天都在修改之前的case。我说你这个并不是自动化测试,而是一种用代码测试产品的手动测试。这样的测试,经常被冠以自动化测试之名混水摸鱼。

  这家公司很明显的只是将代码单元测试贴上了自动化的幌子。

自动化测试的几个准则:

  并不是将测试用例代码化了,就可以称之为自动化测试了。这是现在很多公司宣称自己做AT的一个噱头。

  AT的代码有很多的要求。

  首先就是你的覆盖面要够广。个位数case的自动化完全没有意义。

  第二就是你的case必须要能够复用:软件每天都在变,如果你的case要天天跟着软件变,那你的case是完全不合格的。

  第三就是测试的规模要够大:要么时间长(case多或者是压力测试),要么测试产品多。这样才能体现出来自动化测试的优势。、

  测试自动化的几个准则:

  第一个就是要减少除工具研发部门外,其他所有测试部门的人力成本。这个是测试自动化追求的终极目标之一。、

  第二个就是提高测试质量,不仅仅包括测试执行的质量,还包括测试的统计质量,数据回溯质量,等等等等。这些质量的提高可以帮助测试团队修正他们的测试方法,而不是每天将精力铺在无止境的数据收集和分析中。

  第三个就是要抢出时间。某一项工作自动化后的时间,要么比人手做时间短,要么可以在非工作的16个小时中进行。通过让电脑OT的方法来解放工程师或者项目经理。

  自动化的三大入手点:

  自动化的三大入手点其实和三大准则是一样的。看哪个需求更加迫切:

  1. 成本:自动化并不一定围绕测试执行,还可以包括测试的准备,log的提取,数据分析等等。将所有的与测试有关的工作逐一列出,然后找到重复的,可以被代码化的部分,评估现有工作成本和自动化成本,寻找到收益最大的工作块并顺序将之代码化。

  2. 质量:和成本差不多,只是在评估的时候需要评估的是该工作块现有的质量状况和需求质量间的差异,寻找到差异最多的那个模块,并将所有质量差的模块逐一进行自动化。

  3. 时间:和以上两点一样,都需要寻找到与测试有关的所有步骤和工作块,将其中关键路径上,动作最慢,耗时最大的部分进行自动化。

版权声明:本文出自 zeustest 的51Testing软件测试博客:http://www.51testing.com/?15030005

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-19 08:17:41

自动化测试和测试自动化的区别的相关文章

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

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

选择测试自动化框架

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

我的软件测试之旅:(12)机遇——测试自动化培训师和教练

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

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

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

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

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

Rational Functional Tester的高效测试自动化技巧

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

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

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

测试自动化技能树

仿照<Diablo2>的技能树系统,结合自己的一些经验体会,整理了一份测试自动化的技能树,仅供参考,大家轻拍~ 说明: 1. 每个技能都有解锁等级(Lv) 2. 除了等级,技能之间还存在依赖关系(见父子节点关系及箭头),开启全部前置技能后,方可解锁新技能 3. 解锁后可以继续为某技能投入技能点,以增强其威力 最新内容请见作者的GitHub页:http://qaseven.github.io/

测试自动化和准时交付直接的关联

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