在这篇文章中,给大家分享一下我这些年实践自动化的经历,特别是那些不是那么成功的经历,希望能够给你带来一些思考和共鸣。
做自动化测试时会遇到以下一些难点:
同时,在这我为大家准备了一份软件测试视频教程(含面试、接口、自动化、性能测试等),就在下方,需要的可以直接去观看,也可以直接【点击文末小卡片免费领取资料文档】
软件测试视频教程观看处:
【2024最新版】Python自动化测试15天从入门到精通,10个项目实战,允许白嫖。。。
?
无论是功能测试,还是自动化或者性能测试,第一步要做的,是明确测试范围和需求指标。对于自动化测试来说,特别是UI自动化,并不是所有的功能点都适合做UI自动化。
根据具体的业务情况和项目稳定程度,选择UI自动化+API自动化结合,选择合适的业务点来进行针对性的自动化测试方案设计,才是最佳方案。
对大多数功能测试人员来说,系统架构不用太多关注,但对于自动化或者性能测试人员来说,系统架构是前期需求分析、技术方案选型设计的一个重点。
比如系统开发的编程语言,使用的数据库类型,通信服务框架(如果要进行API自动化,那么系统所采用的通信协议是绕不过去的一点),应用服务器的部署等,都是需要考虑的。
PS:我目前就职的这家企业,数据库使用的是微软全家桶套餐里面的SQL server,而我测试脚本开发语言是python,它本身对SQL server和Oracle的支持并不是很好,导致在数据库配置时候,踩了很多坑。
当然,我最后也解决了这个问题。关于数据库的支持问题,只是我遇到的问题里面的一个很小的部分。
熟悉系统架构的另一个原因是:比如系统采用的开发语言是java,自动化测试人员本身使用的脚本开发语言也是java,那么兼容性就是很好的,而且有技术问题,也可以找开发同事帮忙解决,这样无形中也节省了很多时间,而且对自己的技术提升,也是不小的帮助。
熟悉了系统架构后,针对性的考虑自动化测试方案设计,技术方案选型,才是最好的方式,不要用固有的方式来解决不同的问题,而要用不同的技术方案解决不同的问题。
关于这点,个人认为应该通过分析沟通来确认系统是否适合自动化测试工作。那么,什么样的系统适合进行自动化测试?
如上图所示,我大概罗列了一些适合进行自动化测试的项目所具备的一些特征,当然,不需要全部具备,只需要满足几点即可以考虑进行自动化测试(红色线条标注部分为基本的条件)。
当然,项目情况不仅仅是这些,还有其他的一些点,也是需要考虑的,比如:
①文档管理
文档包括需求文档、测试方案、测试用例、测试规范、开发规范、数据库表设计文档、接口文档等。
如果文档不太完善甚至没有对应的文档,那么自动化测试工作,前期的准备工作就需要投入更多的时间和精力。
PS:比如要进行API自动化,但是没有接口文档,没有数据库表设计文档,那么关于API的接口说明,入参出参说明,这将带来很多附带的工作量,而文档数据的统计,又是一件很麻烦的事情。
有时候需要数据库确认接口对数据的影响,对应的数据库表字段,如果没有相关文档说明,那么自己整理以及和DBA沟通熟悉,就需要花费很多的时间和精力。
而很多企业对自动化的认识太片面,认为自动化可以替代人发现很多BUG,且追求短期的明显效果,而如果没有较完善的文档管理,那么自动化测试人员在前期的准备阶段花费的时间将影响leader对个人能力和工作效率的怀疑,可以说这也是目前国内很多企业存在的弊端。
问题总归是要解决的,如果遇到这种类似的问题,那么在任务拆分和工时预估时候,可以将这些因素考虑进去,计算在个人工时中,并注明原因,在和leader甚至更高层评估中,抛出存在的问题,推动问题的解决,这也是自动化测试人员的一种价值体现。
②流程管理
项目的需求迭代是否稳定?从需求评审到开发、测试、发布上线是否有比较规范的流程?
如果需求迭代较快或者不稳定,那么自动化测试的脚本维护工作量将成倍增长;如果没有较好的流程管理,自动化工作的进展总会遇到很多不可描述的坑,沟通成本,变更成本等,还会影响到测试方案的设计和规划。
在自动化测试中,需要针对性的熟悉了解这些问题点,做好应对的准备。自动化测试过程中,变化是最大的挑战!!!
这里的“目标”,指的是个人对工作的目标设定和leader对自动化工作的期望,站的角度不同,理解不同,因此期望的结果不同。并不是要达成完全的一致,我这里想表达的是沟通的重要性。
个人针对系统情况,技术架构,测试范围的理解,对应的自动化测试方案设计和目标设定,应该与leader不断沟通,不断调整,达成一定程度上的一致,这样也能避免很多后续的麻烦。
当然,目标的设定,也应该根据具体的自动化测试需求,进行任务拆分,评审,不断调整,这是一个持续不断的调整的过程,需要耐心和坚持!
自动化测试脚本开发,也需要基于不同的环境,而环境的选择,需要考虑不同的情况,下面一一列举说说我个人的思路:
1、SIT环境:
SIT环境,也称为系统集成环境,就是我们常说的测试环境,如果测试脚本是基于SIT环境开发调试,那么就需要SIT环境相对来说比较稳定。
但是大部分时候,SIT环境因为需要多次的提交测试,交叉影响较大,且SIT环境和生产环境还是有一定差异的(至于为什么,相信测试童鞋,都明白其中的痛点)。
2、UAT环境:
UAT环境,就是我们所说的验收环境,当然类似的,也有灰度环境等。UAT环境相对SIT环境来说,是比较稳定且和生产的一致性较高的,很适合进行自动化测试脚本开发和调试,以及日常的测试回归。
但自动化测试的作用又不限于这点,还可以进行发布后的生产冒烟,定时轮询测试等。
3、生产环境:
如果在生产环境进行测试脚本开发和调试,以及测试执行,那么就需要解决以下几点问题:
①网络问题
一般我们的SIT和UAT环境都是部署在企业内部,网络环境也是走的内网,请求解析和外网有一定区别。在生产环境运行脚本进行回归冒烟的话,需要考虑真实的用户操作环境,不同的网络对测试结果影响。
而且测试脚本中,sleep最好能不用就不用(特别是UI自动化,强制等待容易带来很多不可控的变数)。
②数据污染问题
生产环境进行自动化测试回归冒烟,需要对测试所产生的数据进行隔离处理,否则会导致业务受到影响,并且对生产的数据造成污染。常用的数据隔离方法如下:
测试白名单账号、网络标记、线程标记、测试数据落入对应的测试库,某些业务还可以使用MOCK对象和挡板。
关于数据隔离这几点,在性能测试中,也是需要考虑的一个重点,当然性能测试中也经常使用这些方法进行数据隔离,避免生产数据污染带来的影响。
之前的博客做接口测试需要哪些技能有介绍过,自动化测试的核心是持续集成。那么一个独立的不受影响的持续集成环境是必须的。
持续集成环境也叫作CI环境,类似的还有CD环境(持续交付)。
这些应用,在敏捷测试中,应用的比较多,不过目前行业内,我个人了解到,越来越多的企业开始搭建持续集成环境,这样做的好处是很多的,比如:
①版本迭代提测,可以通过CI服务一键提交,节省时间,提高效率;
②如果需要造大量的测试数据,可以通过一个小脚本,只需要进行配置,点击启动按钮即可;
③发布生产环境时候,可以通过CI服务自动化打包部署,避免了人手工打包配置时候的误操作等问题;
④自动化测试脚本,部署在CI环境后,只需要点击启动,或者设置出发条件,定时任务的形式,来做到生产定时轮询,发布后冒烟等测试工作;
这里的策略,可以从下面几个角度来说:
1、任务拆分
确认测试范围和需求指标后,将自动化测试任务进行粒度更小的拆分,将工作内容所需时间精确到人/天的范围,按时完成任务,有问题不断调整;
2、优先级
任务拆分后,对任务进行优先级排序,通过评审沟通,确认先完成哪些任务,然后完成哪些等。
测试方案设计中,可以考虑分为第一期、第二期自动化测试任务,比如第一期实现自动化测试在一定程度上的覆盖率,先实现PC端的自动化测试,第二期可以考虑移动端的自动化测试覆盖,第三期可以考虑自动化测试平台的开发等等。有目标有计划,根据项目变化和进度不断调整。
自动化任务的优先级排序,可以参考这几点:
①用户使用频率越高的优先级应该最高;
②系统基础功能应该排在优先级前列;
③系统核心功能(比如支付、订单)应该较早的覆盖;
④历史记录中生产出现问题叫多的功能点,应该考虑尽可能的覆盖;
3、工时预估
前期的准备工作(比如范围确认、需求分析、CI环境部署、测试方案设计、技术框架选型、文档整理等)完成后,需要针对具体的拆分后的任务进行工时预估,以确认工作阶段性的进展,方便随时调整。工时预估需要考虑以下几点:
①自动化测试人员个人的技术能力,特点;
②项目情况、流程管理、系统架构的变化程度;
③测试方案技术实现的难易程度;
自动化测试道路上,全是坑!!!
工作中我们会遇到很多问题,有沟通问题、管理问题、技术难点、以及一些不可描述的问题,但只有想办法解决这些问题,我们才能在工作中不断提升,完成工作,获得该有的收获。
不同的企业存在不同的各种各样的问题,没有完美的公司,因此工作中,学会适应环境,融洽沟通,也是工作中必须的一项内容。
工作的本质就是拿钱消灾,解决问题,创造价值!!!
所以,良好的心态,坚持不懈的态度,解决问题的思路,是需要自动化测试童鞋所具备的。。。
以上就是我个人在自动化测试过程中遇到的一些问题,挑战,以及自己的一些思考和解决方法,希望能为看到的童鞋提供一定的思路和帮助,仅供参考。。。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。