【技术创作101训练营】拥抱变化的自动化测试系统

PPT:

拥抱变化的APP自动化测试系统-V6.pptx

演讲稿:

P1-P2:大家好,今天跟大家分享的主题是拥抱变化的自动化测试系统。

介绍

P3:作为一个从业十多年的测试经理,从过程管理做到研发,从研发做到测试,扎根测试十多年,经历过单机版、CS系统、BS系统、B/CS系统、3D沉浸式系统、云计算,等等数十个产品和项目,在传统或者敏捷开发项目管理模式下,推动自动化测试都有一个痛点,就是不断变化的系统对已实现自动化用例的冲击。

P4:今天根大家分享的主题是如何在不断变化的需求和页面下,打造一个健壮的APP页面自动化测试系统。

变更对自动化测试的挑战

P5:在APP的自动化测试中,我们遇到过一个令人悲伤的故事。我们的自动化测试人员从无到有,从零开始学习研究APP自动化,花了半年的时间完成了产品主要业务用例的自动化,刚用了几个星期,种种原因下,产品页面重构了!!!元素都变了,用例都废了!虽然提前把页面、数据、用例都实现了分离,但是扛不住操作步骤都变了!伤心,愤怒,难过,没办法,又花了几个星期重写了用例,结果没用多长时间,产品业务重构了!!这个产品已经是做了好几年相对成熟的产品了,但是现在是一个拥抱变化的时代!!这样用例又得跟着重构一次!

P6:也有一些项目在项目热度很高的时候,有钱有人,花了大力气实现了数千个上万个自动化测试用例,结果用了没多久,项目自动化人员撤走了,维护这些用例成了不可承受之重。因为执行这些用例就要数个小时,当页面变化或者功能变化造成自动化测试失败,去维护这些用例的成本就更高了。到最后这些写好的自动化用例大部分都“死了”,因为再也不会去执行。

P7:一个稳定的自动化测试系统,要受到多种变更带来的挑战:

页面变化:包括界面元素增删改,元素位置变化,定位属性发生变化,等,一旦发生,写好的自动化用例就会失败。

业务流程变化:更大范围的变化,涉及到业务功能和流程的变更,这样失败的自动化用例会更多。

相关系统变化:接口定义变化,返回值变化,环境变化,都会造成自动化用例的失败。

还有其他的各种变更,都可能会造成自动化测试用例的失败。

怎么才算是健壮的自动化测试系统呢?

P8:成功率高:同样的用例跑来跑去都是一样的结果,不会出现以下情况。第一遍成功了,第二遍又失败了;我的机器上成功了,换个机器执行就失败了;这个版本成功了,下个版本失败了;等等。

维护成本低:当变更发生时,修改点少而且好修改。通俗易懂,新的自动化人员可以很快上手维护。

我们想做的是,在拥抱变化的锤炼中,慢慢打造健壮性越来越好的自动化测试系统,降低维护自动化的成本。

P9:咱们分析一下会造成自动化测试失败的变化原因:

页面元素找不到了。可能位置变了,可能名字/ID变了,甚至可能被删了。

期望结果对不上。可能是业务变了,可能是多了一个弹出窗口步骤变了,也可能是相关系统的返回值变了。

为了拥抱变化,自动化测试系统要做好以下准备:

提高成功率:

P10:一次编辑,处处成功

部分功能变化,只有少数用例失败。操作步骤变化时,仅影响变化流程,其他业务不受影响,让变更辐射范围最小化。比如淘宝上商品上架流程变了后,购买下单流程虽然用到了商品,但是购买下单流程的自动化不需要修改。

相关系统接口发生变化时,非交互业务用例不受影响,隔离交互操作。

降低维护成本:

P11:页面元素变化时,可以修改一处,其他联动变化,降低其维护成本。比如有200个用例都用到了页面A,当页面A变化时,只需要修改页面元素定义,那200个用例都不用修改。

期望结果发生变化时,只影响当前用例。

不同测试数据,相同的测试步骤,只需要写一遍。这样测试数据发生变化时,只需要修改数据即可

代码写的通俗易懂。

打造健壮的页面自动化测试系统

P12:

这里给大家介绍下一种提高页面自动化健壮性的解决方式,大家可以根据项目的实际投入和精力,参考不同的方案,通过一步步的锤炼,逐步打造一个在各种变更和问题中浴火重生的自动化系统,逐步降低自动化的维护成本,提高其使用效率,创造更大的价值。

写好的代码

分层之前,先解决掉失败率的问题。同样的用例第一遍成功了,第二遍又失败了;我的机器上成功了,换个机器执行就失败了。这个是技术的问题,技术不熟练,代码写的不到位,就会出现这些问题。如何解决这些问题呢?

多写多练:我知道这个建议很土,简直是太实在了,但是提高技术的最佳途径就是多练习,熟能生巧,这个是很难绕过去的。天资聪颖擅长举一反三的天才有,毕竟是少数,不在讨论之列哈。

多读书:踩在别人失败的肩膀上,吸取他们的经验,避免犯常识性的错误,少走弯路。

多执行几遍代码:在不同机器上,不同环境下,甚至是同样的环境下,尽量多运行一下自己的代码,自己就能发现这些问题,改正错误了。错误改正了,失败率就降低了。

研发是我们的好兄弟。自动化用例离不开产品研发兄弟的支持,页面元素好定位,自动化代码好实现,需要研发同事在开发时符合一定的规范,例如给页面元素加ID,页面变化时尽量保持ID不变,等等。

P13:下面是APP页面自动化测试中一些我们趟过的坑,给大家提个醒:

等待时间时间不合理,比如网速好的时候系统0.1秒就返回结果了,网速差的时候可能1分钟页面都刷不出来,如果没有合理的等待,那网速好的时候写好的用例,在网速差的时候就会失败。

代码中的方法依赖特定环境,比如,代码用了JDK9的新方法,但是运行的机器是JDK7,不支持这个方法。

代码中写死了变量。比如,直接在步骤中写死用账户A的密码,用账户B登陆就失败了。

没有处理不同权限下的情况。比如,用管理员账户可以去创建账户,用普通用户登陆也执行了同样的用例就失败了。

自动化用例写的太多了,维护不过来,有些自动化用例写完就再也不执行了。

分层与隔离

P14:如果没有分层,所有的步骤和测试数据都写到了一起,当有一个变化时,所有的点都要改,工作量大不说,漏改了用例就失败了。我们分层的目的是为了减少修改量,并且降低系统变更带来的失败率。

P15:自动化分层有几种情况,页面自动化的分层和接口自动化有所区别,这里讨论的是页面自动化测试的一种分层实现。

测试数据和用例分离:包括登陆账户信息,被测产品的各种对象,某些操作的期望结果,等等。

测试页面和用例分离:页面元素统一维护,方便变更时修改一处即可。

操作和用例分离:常用操作,与业务无关的通用操作,这些可以封装起来,便于变更发生时只维护一处,减少维护工作量。

测试用例原子化:将测试用例尽可能拆分到小单位,便于后续根据各种场景的需要进行组织和调用。

测试用例的组织:根据各种测试场景的需要,执行不同的测试用例组。

下面介绍使用Appium实现APP页面自动化测试系统时,各种分层实现时的参考实现。

P16:

测试数据是我们的基础,讲测试用例抽取出来有一下好处:

  • 同样的步骤调用不同的数据,验证不同的期望结果;减少代码量,减少维护工作量;
  • 某些测试数据可以在不同系统中通用,比如说同样的业务,有的用APP实现,有的用web实现,有的用H5接口实现,等等;这样某些系统的测试数据可以直接拿来复用。
  • 测试数据独立后,可以统一用一套数据文件读取和维护方式,提高稳定性。

P17:

页面元素的在同一个地方定义后,一旦变化,只需要修改一处。页面定位的方式有很多种,但是页面元素定义只有一处。

我们还可以把页面元素的定位抽取为通用操作封装起来,更好的操作和维护。

P18:

通用操作的封装后,同样是一处定义,处处使用,减少了开发量;一旦变化,减少维护工作量。

通用操作的一般是指与业务无关的一些操作,比如点击,双击,滑动,翻页,等等。

同样的也有一些常用操作的封装起来,在测试用例中调用,也可以提高效率和稳定性。例如,登录,退出,买卖操作中的商品添加,等。

P19:

测试用例在编写中,注意实现原子化。就是说尽可能颗粒小的业务单位。这样做的意义是,越短的执行步骤,失败的可能性越小;越小的颗粒度,引用和调用的时候越方便。

写用例的时候,我们可以把页面校验用例和业务用例分开来写。这样页面变化时,页面校验用例失败,但是业务用例关注的是流程,在基础操作调整完毕后,业务用例不用调整。业务用例关注是流程和数据传递。

我们在写业务用例时,要关注用例调用和调用顺序,提高其稳定性。

P20:

有了上述各种抽取和分离后,稳定的原子化用例可以根据测试场景的需要,执行不同的用例。

功能测试的时候执行所有相关用例;主流程用例关注主要业务用例的验证;等等。

P21:

自动化完成后,如果有条件,可以结合Jenkins实现自动化打包部署和自动化,共同提高产品质量,更多更好的利用已经写好的自动化测试用例,尽早发现缺陷。

基本步骤有:

搭建打包服务器,包括安装Android Studio,下载源代码,配置Android Studio下载需要的支持包,修改配置文件,启动打包服务。能成功的打包出可运行的APK后,这一步就完成了。

配置Jenkins服务器:包括Jenkins的安装,相关插件的安装,创建Jenkins工程运行在打包服务器上,完成源代码同步下载,打包脚本执行,备份生成的测试包。

进一步配置Jenkins工程,完成各种测试环境下的打包,如生产环境,演示环境,测试环境,挡板环境,等。

配置Jenkins工程,根据需要执行指定的自动化测试用例,生成测试报告。

P22:

这是一个实例,通过在Jenkins上执行要生成的各种环境下测试包,然后运行指定的测试用例。左侧是配置的测试脚本的一部分。

小结

P23:

为了打造稳定的自动化测试系统,拥抱变化,减少变更发生时自动化测试系统的维护工作量,提高自动化测试用例的利用率,用的多了,健壮性就逐渐打造出来了。这次我们介绍了成熟的代码,分层和隔离,通过Jenkins推动测试左移,与研发一起利用自动化提高测试质量,这些方式来逐步打造健壮的变化友好的自动化测试系统。

希望这个分享能给大家起到一个抛砖引玉的作用,在大家的工作中提供一点点新思路和帮助。

感谢云+社区提供的机会,本文参加【技术创作101训练营】活动。

本站文章资源均来源自网络,除非特别声明,否则均不代表站方观点,并仅供查阅,不作为任何参考依据!
如有侵权请及时跟我们联系,本站将及时删除!
如遇版权问题,请查看 本站版权声明
THE END
分享
二维码
海报
【技术创作101训练营】拥抱变化的自动化测试系统
P3:作为一个从业十多年的测试经理,从过程管理做到研发,从研发做到测试,扎根测试十多年,经历过单机版、CS系统、BS系统、B/CS系统、3D沉浸式系统、云计算,...
<<上一篇
下一篇>>