浅 谈 自 动 化
编程
自动化测试的优点:浏览器
自动化测试能够替代大量的手工机械重复性操做,测试工程师能够把更多的时间花在更全面的用例设计和新功能的测试上;并发
自动化测试能够大幅提高回归测试的效率,很是适合敏捷开发过程;高并发
自动化测试能够更好地利用无人值守时间,去更频繁地执行测试,特别适合如今非工做时间执行测试工做时间分析失败用例的工做模式;工具
自动化测试能够高效实现某些手工测试没法完成或者代价巨大的测试类型,好比关键业务7×24小时持续运行的系统稳定性测试和高并发场景的压力测试等;性能
自动化测试还能够保证每次测试执行的操做以及验证的一致性和可重复性,避免人为的遗漏或疏忽学习
自动化测试的劣势:测试
自动化测试并不能取代手工测试,它只能替代手工测试中执行频率高、机械化的重复步骤。你千万不要奢望全部的测试都自动化,不然必定会得不偿失。spa
自动测试远比手动测试脆弱,没法应对被测系统的变化,业界一直有句玩笑话“开发手一抖,自动化测试忙一宿”,这也从侧面反映了自动化测试用例的维护成本一直居高不下的事实。其根本缘由在于自动化测试自己不具备任何“智能”,只是循序渐进地执行事先定义好的测试步骤并验证测试结果。对于执行过程当中出现的明显错误和意外事件,自动化测试没有任何处理能力。设计
自动化测试用例的开发工做量远大于单次的手工测试,因此只有当开发完成的测试用例的有效执行次数大于等于5次时,才能收回自动化测试的成本。
手工测试发现的缺陷数量一般比自动化测试要更多,而且自动化测试仅仅能发现回归测试范围的缺陷。
测试的效率很大程度上依赖自动化测试用例的设计以及实现质量,不稳定的自动化测试用例实现比没有自动化更糟糕。
实行自动化测试的初期,用例开发效率一般都很低,大量初期开发的用例一般会在整个自动化测试体系成熟,和测试工程师全面掌握测试工具后,须要重构。
业务测试专家和自动化测试专家一般是两批人,前者懂业务不懂自动化技术,后者懂自动化技术但不懂业务,只有两者紧密合做,才能高效开展自动化测试。
自动化测试开发人员必须具有必定的编程能力,这对传统的手工测试工程师会是一个挑战。
适合作自动化的项目:
第一,需求稳定,不会频繁变动
自动化测试最怕的就是需求不稳定,太高的需求变动频率会致使自动化测试用例的维护成本直线上升.刚刚开发完成并调试经过的用例可能由于界面变化,或者是业务流程变化,不得不从新开发调试。因此自动化测试更适用于需求相对稳定的软件项目.
第二,研发和维护周期长,须要频繁执行回归测试。
软件产品的生命周期通常都比较长,一般会有多个版本陆续发布,每次版本发布都会有大量的回归测试需求若是短时间的一次性项目,就算从技术上讲自动化测试的可行性很高,但从投入产出比(ROI)的角度看并不建议实施自动化,由于千辛万苦开发完成的自动化用例可能执行一两次,项目就结束了。
第三,须要在多种平台上重复运行相同测试的场景。
这样的场景其实有不少,好比:对于GUI测试,一样的测试用例须要在多种不一样的浏览器上执行;对于移动端应用测试,一样的测试用例须要在多个不一样的Android或者iOS版本上执行,或者是一样的测试须要在大量不一样的移动终端上执行.
第四,某些测试项目经过手工测试没法实现,或者手工成本过高。
对于全部的性能和压力测试,很难经过手工方式实现。好比,某一个项目要求进行一万并发用户的基准性能测试(Benchmark test),难道你真的要找一万个用户按照你的口令来操做被测软件吗?又好比,对于7×24小时的稳定性测试,难道你也要找一批用户没日没夜地操做被测软件吗?这个时候,你就必须借助自动化测试技术了,用机器来模拟大量用户反复操做被测软件的场景。固然对于此类测试是不可能经过GUI操做来模拟大量用户行为的,你必须基于协议的自动化测试技术.
第五,被测软件的开发较为规范,可以保证系统的可测试性。
从技术上讲,若是要实现稳定的自动化测试,被测软件的开发过程就必须规范。好比,GUI上的控件命名若是没有任何规则可寻,就会形成GUI自动化的控件识别与定位不稳定,从而影响自动化测试的效率.
第六,测试人员已经具有必定的编程能力。
若是测试团队的成员没有任何开发编程的基础,那你想要推行自动化测试就会有比较大的阻力。这个阻力会来自于两个方面:前期的学习成本一般会比较大,很难在短时间内对实际项目产生实质性的帮助,此时若是管理层对自动化测试没有正确的预期,极可能会叫停自动化测试;测试工程师一般会很是热衷于学习使用自动化测试技术,以致于他们的工做重点会发生错误的偏移,把大量的精力放在自动化测试技术的学习与实践上,而忽略了测试用例的设计,这将直接下降软件总体的质量。