在自动化测试中,会有一些小白或者只是对自动化感兴趣的人误入自动化测试陷阱中,本篇文章就来总结那些让人高频去踩的自动化测试陷阱。面试
陷阱1:自动化测试工具是万能的!编程
到目前为止,尚未一款商业测试工具能支持从测试计划,到测试设计,再到测试执行的自动化。架构
你常常会在某些测试工具的产品推介会、演示会上看到演讲者展现测试工具的种种好处、优势,让你为自动化测试激动不已;可是他们每每不会告诉你自动化测试的难点所在,实施自动化测试的复杂度,以及所需的投入有多大。并发
陷阱2:一个工具能适合全部项目框架
到目前为止,尚未一款工具能够支持全部操做系统环境。编程语言
你也许会被项目经理要求寻找一款能够支持全部实时嵌入式系统测试的测试工具,而大家的应用须要跑在各类操做系统环境上,包括VxWorks、Integrity、mainframe、Linux和WindowsXP,编程语言包括Java和C++。函数
陷阱3:引入自动化测试工具后,测试人员的负担当即减轻工具
引入自动化测试工具后,并不会立刻就减轻测试负担,事实上一开始每每会增长负担。性能
项目经理每每但愿经过引入自动化测试工具来减轻测试负担。可是经验代表,在一个新项目中尝试实施而且有效地应用自动化测试,每每须要通过一条学习的曲线。测试的负担并不会立刻减轻,可是项目经理却但愿立刻看到自动化测试发挥其威力,但愿立刻看到效果。学习
事实上,在一开始的时候,很大可能会增长测试的负担,由于测试工程师须要一段时间熟悉和掌握测试工具,而与此同时,手工测试一刻也不能中止,所以测试的负担没有减轻,反而加剧了。
另外,自动化测试须要仔细的分析被测试应用程序,哪些部分须要和可以被自动化实现;而且须要仔细地设计和开发测试脚本。这些无疑都将加剧测试的负担,尤为是在初始阶段。
陷阱4:引入自动化测试工具后,进度能够立刻被压缩
上了自动化测试工具以后,总体测试进度不会立刻缩短,相反,在初始阶段,每每会对进度形成必定的延误。
另一个误区是,自动化测试工具能立刻缩短测试时间表。可是因为测试的负担在初始阶段加剧了,所以很天然地,咱们不能期待进度缩短,相反,在引入自动化测试后,咱们应该给初始阶段的进度表预留一些时间。一旦整个自动化测试的流程创建起来以后,咱们就能够期待自动化测试给咱们的进度带来积极的影响。
陷阱5:自动化工具是很容易使用的
自动化测试工具要求测试人员掌握新的技巧,一般须要额外的培训。应该制定培训计划,投入时间和成本,度过学习的曲线。
一般不少工具厂商都会夸大本身产品的易用性,他们会否定所谓的"学习曲线"。工具销售人员一般鼓吹所谓的"录制/回放"能够简单地记录下测试工程师的键盘和鼠标动做,而后再简单地回放出来。
可是,有效的自动化测试远远不只仅是"录制/回放"那么简单。录制下来的脚本须要手工修改,以便让其可重用性和可维护性更强一点、更灵活一点,而这些都须要语言和脚本知识。所以他们须要针对工具和内建的脚本语言接受培训。
陷阱6:全部测试均可以被自动化
并不是全部的测试均可以被自动化。
自动化测试是手工测试的加强。乞求项目中的测试百分百实现自动化是不合理的。在首次引入自动化测试时,最好先验证一下,工具是否能识别出全部对象和第三方的控件。这对于基于GUI的测试工具来讲很是重要,由于这类工具每每在识别一些个性化控件方面有困难,例如一些calendar、spin、grid控件,而这些控件被普遍应用在程序界面中,而且这些控件每每由第三方编写,大部分测试工具厂商未能跟上他们的发展速度。
测试工程师在碰到这种状况时要么放弃这部分应用了难以识别的控件的测试自动化,要么找出一些解决的办法。
另外,还有一些测试是基本上不可能被自动化实现的,例如,测试工程师能够实现自动化地把文档发送到打印机的过程,可是检查打印的效果(是否被正确地打印出来,有没有越过纸张打印线)这部分则必须人工进行。
若是对软件测试、接口测试、自动化测试、面试经验交流。感兴趣能够加软件测试交流:1085991341,还会有同行一块儿技术交流。
至于哪些测试用例应该被自动化实现,能够参考下表决定:
YESNO
测试执行的次数:
测试会被执行屡次吗?
测试会有规律地运行吗?
例如常常被重用,做为回归测试的一部分或每日构建测试?
测试的关键程度:
测试覆盖了软件功能的最关键部分的路径吗?
测试覆盖了最复杂的部分吗?(一般是最容易出错的部分)
测试的代价:
若是手工进行测试的话,是否不可能、很是难以执行,例如并发测试、持久性测试、性能测试、内存泄漏测试等。
测试很是耗时吗?例如须要检查成百上千个测试结果输出。
测试的类型:
测试须要组合不少输入,可是共用一个测试步骤吗?例如同一个功能,用不少不一样的输入来验证。
测试须要在多种软硬件配置环境下执行吗?
被测试应用或系统:
测试是在一个稳定的应用程序上执行的吗?例如功能特性已经基本完成。
使用兼容的技术和开放的架构
陷阱7:自动化能提供百分百的测试覆盖率
并不是全部内容均可以被自动化地测试到。不可能覆盖全部可能的输入,全部可能的组合和路径。
自动化测试能够增长测试的广度和深度,可是仍然没法达到100%的测试覆盖率,由于没有足够的时间或资源。
例如一个简单的登陆界面的测试,假设咱们须要测试它的密码验证函数的正确性,密码长度在6到8个字符之间,每一个字符能够大写或小写,至少包含一个数字,那么输入的可能组合将达到2,684,483,063,360个。
即便咱们能够每分钟建立一个测试,也须要155年来完成全面的测试。所以,不可能穷尽全部可能的输入的测试。
陷阱8:测试自动化就是录制和回放
仅仅录制获得的不是有效的自动化脚本。
不少项目经理仍然把测试自动化等同于使用录制回放工具。而事实上,录制获得的脚本一般是不可重用的脚本,脚本中充满了硬编码的值,这些值应该被参数化,不然脚本仅仅适用于一个测试状况,脚本还应该加入条件判断、循环等结构,以便加强测试脚本的灵活性。
陷阱9:自动化的软件测试与手工的软件测试过程同样
自动化测试所须要的技巧与手工测试所须要的技巧是不同的。
一般,你的项目经理会被那些测试工具销售们迷惑,认为自动化的软件测试就是简单地按一个录制的按钮,产生测试脚本。而事实上并无那么简单。
区分自动化测试所须要的技巧与手工测试所须要的技巧是很是重要的。最重要的是,自动化测试工程师须要掌握软件开发技巧,没有接受任何培训的手工测试人员,或者没有编程背景的手工测试人员,在实施自动化测试时会碰到不少困难。
陷阱10:忘记了测试的最终目标:找到BUG
在自动化测试中,一样要注意把边界值分析、等价类分析、基于风险的测试方法、挑选最合适的测试用例等技术应用起来。
一般在自动化测试过程当中,咱们都忙着搭建自动化框架和编写测试脚本,可是咱们每每忘记了测试的原本目的:找bug。
项目经理可能雇佣了最好的自动化开发人员来搭建框架,使用了最新最好的自动化开发技术,建立了成千上万的自动化测试脚本。可是若是BUG仍然被遗漏了,那些本该被自动化测试脚本捕捉到的BUG,结果没有被捕捉到,那么你的自动化测试仍然会被认为是失败的。
以上内容但愿对你有帮助,有被帮助到的朋友欢迎点赞,评论。