自动化测试与功能测试
什么是自动化测试?
自动化测试是指利用软件测试工具自动实现全部或部分测试,它是软件测试的一个重要组成 部分,能完成许多手工测试无法实现或难以实现的测试。能够正确、合理地实施自动测试,可以 快速、全面地对软件进行测试,从而提高软件质量,节省经费,缩短软件发布周期。
自动化测试一般分为UI 自动化测试和接口自动化测试。
UI自动化测试是指基于界面元素的自动化测试。需要先定位界面元素的路径,然后通过脚本 实现自动化。这种方法因为界面需求的变更频繁,脚本更新频繁,不利于后期的维护工作,造成 自动化工作的成本巨大,已经慢慢被各大公司所淘汰。
随即演变出的就是接口自动化了。接口自动化是指模拟程序接口层面的自动化,由于接口不 易变更维护成本小,所以它深受各大公司喜爱。接口自动化也是本书的重点。它包含两个部分, 功能性的接口自动化测试和并发接口自动化测试。
自动化测试与手工测试的区别
自动化测试和手工测试并没有高低贵贱之分,虽然划分在不同的阶层,但只是出于对测试人 员个人的价值评判而已。以下详细解析这两者的区别。
1.测试目的不同
虽然都是测试,但这2种测试的目的却是截然相反的。
- 手工测试的目的在于通过“破坏”发现系统有bug。
- 自动化测试的目的在于“验证”系统没有bug。
当测试系统处于前期不稳定的时候,做自动化测试将毫无意义,因为程序运行到一半就会因 为某个bug而停止的,而当这个bug未被修复之前所有的自动化测试都会卡在这里无法往下执行。 而当测试系统处于稳定的时候,通过手工测试重复着一样的操作也会变得烦琐和枯燥,所以这两 者在不同的测试阶段都有着不可替代的作用。
2.覆盖范围不同
除了目的的不同,覆盖范围也是不同的。
- 手工测试可以尽可能地覆盖测试系统的各个角落。
- 自动化测试只能覆盖测试系统的主要功能。
试想把所有的测试用例都弄成自动化是一件多么美好的事情,但代价实在太大了,投入的时 间和产出完全不成正比,不夸张地说如果要做到完全自动化测试,所需要的代码量会远远超过开 发编写程序的代码量。所以自动化测试只能挑一些重要和稳定的功能来做,而更多的一些细节的 测试还需要手工测试来完成。
3.智能判断不同
自动化和手工测试还有一个最大的区别是智能判断方面。 计算机程序对于人而言是绝对的服从和诚实的。
举个例子,用计算机程序去计算1+1,结果必然等于2(除非你的程序本身写的有bug, 这不是计算机程序的问题),而如果问一个人1+1等于几,可能会有一个答案“1+1等于我 们”,那这个结果是对还是错呢?如果交给程序判断必然是错的。因此智能判断是自动化测试的 瓶颈,一个操作出现多种结果可能都是对的,但又可能都是错的。
再举个电商的例子,比如有个特价产品只有一份,需要秒杀,有可能抢到,也有可能抢不到。 对于能抢到来说,只有“他”1个人抢到是对的,如果多个人都能抢到那就是错的。对于不能抢 到来说,已经有1个人抢到就是对的,如果没有一个人抢到的话就是错的,这个时候自动化测试 程序该如何判断结果的对错呢?这样的情况比比皆是,虽然有办法通过程序去预置各种条件让结 果唯一化,但需要花大量的时间和精力去优化自动化测试代码,并且还需要分多个自动化测试程 序完成,这个时候还不如人工介入测试进行判断来得方便。
这样看来其实自动化测试能做的还是非常有限的,而更多的时候还是需要手工测试,利用工具也好,逻辑判断也好,又或者让开发修改程序来配合测试也好,总之能达到测试的最终目的就好,从这个意义上来说手工测试也并非没有技术含量,而自动化测试也没有那么无所不能。
同时,我也为大家准备了一份软件测试视频教程(含面试、接口、自动化、性能测试等),就在下方,需要的可以直接去观看,也可以直接点击文末小卡片免费领取资料文档
软件测试视频教程观看处:
2024年Python自动化测试全套保姆级教程,70个项目实战,3天练完,永久白嫖...
自动化测试的困境
自动化测试具有很大的优势,一劳永逸地用程序代替人力,人力干活8小时,而程序可以24小时不停止地干活。但是自动化测试还有一个很大的困境,即由于自动化测试很难持续维护,导致在大多数公司无法普及这种测试方式。
IT行业的竞争日益激烈,产品要保持自身的竞争力就需要不断高速迭代新版本、新功能。这就意味了原来写的自动化测试程序变得不可用了(其中的部分程序),而留给测试人员的时间又往往是很少的,于是只能手工测试保证按时上线,等上完线之后可能过几天又有新的功能要测试。留给测试的时间不够完成自动化测试程序的维护更新,周而复始,久而久之,原来的自动化测试程序已经和当前版本相去甚远了,最后自动化测试就不了了之了。我想这就是人们常说的“愿望是美好的,但现实总是残酷的”。
既然知道是困境,必然就是很难解决的,那有没有折中的办法来减少一定的维护成本,又可以达到一定的自动化测试的目的呢?回答这个问题之前先要看透自动化测试的核心本质,就是元素识别+元素操作+验证结果,大多数自动化测试工具都会提供元素识别和元素操作(鼠标点击、键盘输入、屏幕 touch等),只有在验证结果的时候需要写代码提取实际结果,然后和预期结果进行比较,最后得出测试通过或者不通过的结论。
其实对于写代码的部分来说都是通用的,不同的地方在于获取实际结果的方式变更或者预期结果的变更,工作量并不多。真正烦琐之处在于元素的识别,每个元素其实都由唯一标识来识别,这样才能保证不会操作错元素,好处在于如果元素不变,那唯一的标识也永远不会识别错,这是自动化测试可以实施的基础。但有利自然有弊,一旦元素变了,原来的标识就不可用了,那自动化测试就无法实施了。说到这里如果可以绕过元素识别这一步,将元素操作以接口的形式通过脚本完成,就可以抛弃重量级的自动化测试工具,而通过测试脚本直接实现接口自动化测试。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!