自动化测试

2022-03-25 10:00:00
大前端全栈开发
转贴:
公众号
2414

概念:什么是自动化测试,简单来讲就是一个操作软件的软件,然后可以对操作的结果进行验证。这里的定义是跟被测软件分离,这个我不是很同意这句话,有些自动化测试是进程内的,需要inject代码来运行测试代码,甚至有些直接类似病毒附加二进制代码并且运行在被测程序的进程内(确实见过一个软件是这么做的,直接改二进制代码然后在进程内运行一个socket server来执行测试)。

分类:既然是一种软件,那我们就简单按照有没有UI,分为非UI和UI的自动化测试程序:

  • 常见的非UI自动化

    • 大部分的Unit Test

    • API test

    • Integration Test等


  • 常见的UI自动化

    • 带UI的Unit Test,比如mock掉底层代码,仅仅测试UI逻辑

    • 带UI的API Test,比如我以前工作过的一个Team是做UI的component的,大部分的API都是跟UI相关的

    • 功能测试。大部分的UI自动化测试是功能测试。或者说是Regression Test(应该是翻译成回归测试吧)

    • ....

特点:我们来看看这两种测试各自的优点:

  • 非UI

    • 简单。测试代码相对容易写,容易调试

    • 运行稳定。除非代码逻辑变化,一般不需要改测试代码。而且不容易受到外在因素影响

    • 好维护。运行稳定,就不需要经常去更新测试代码

    • 运行速度快。一般执行速度比UI的测试要快很多

    • 容易模拟出错情况。构造错误情况比UI操作容易的多


  • UI

    • 覆盖范围广。简单说,就是不挑食,只要是有UI的程序,只要是支持Accessibility的程序都可以做。

    • 不需要被测程序源代码

    • 最大程度模拟用户操作 (有些操作比如用InvokePattern,还是跟用户点击鼠标不太一样,但是我们可以通过模拟鼠标事件来达到完全一样的效果)。这个就浅显易懂了,毕竟用户是用鼠标键盘操作的,不是写代码来用的……


选择: 那一般我们怎么去选择用非UI还是UI呢?重要的话说三遍:

能不用UI自动化测试就不用,能不用UI自动化测试就不用,能不用UI自动化测试就不用

主要是UI自动化测试有以下显著缺点:

  • 大部分写UI自动化测试的人员没有丰富的代码经验,甚至有些UI的自动化测试是通过录制回放脚本来完成的。 自动化测试代码也是软件代码,应该遵循软件开发从设计开始的所有流程(不仅仅是UI自动化测试代码),这里还是赞同微软的SDET的说法

  • 在整个软件开发过程中,越是底层的代码变动的频率越低。比如底层类的实现和用户界面相比,显然UI变化最频繁,并且最晚稳定下来

  • 为了满足设计的要求,很多程序的UI大量使用了自定义控件,但是又没有遵循微软的Accessibility标准(甚至根本不知道有这个东西)。导致没有任何的自动化测试工具可以操作和获取信息进行测试验证……

  • UI在Windows各个版本中,显示并不完全一样(从UI自动化测试工具的角度看)

但是,什么东西都是有两面的,虽然有很多的显著缺点,但是也有很多上边列的优点,怎么取舍,怎么样发挥UI自动化测试的优势:

  • 反对盲目的UI自动化测试

  • UI自动化测试开始的时机

  • 反对录制回放脚本

  • 需要考虑UI自动化的投入产出比

  • UI自动化测试不只是脚本,也需要设计

  • 自动化测试应该从软件设计开始

  • 软件设计需要考虑可测试性(testability)

  • 程序设计需要考虑UI框架

  • 程序设计需要考虑非UI自动化测试

  • 团队需要重视Automation Bug

  • 自动化测试脚本也有维护周期

  • 同步和Sleep的选择

  • 什么是一个好的UI自动化测试用例

  • 尽量不用Sleep

  • 单个验证点和功能封装

  • 除了Pass和Fail,也需要有Error

  • UI自动化测试并不是只能用UI状态来做验证。。。



  • 选择UI自动化工具:

  • 看对产品的支持程度。比如产品是用WPF写的,那公司买的工具是否可以识别,是否有其它商业工具可以支持,价格是不是公司有预算去购买等等。

  • 自动化工具的开发语言是否需要学习成本,自动化工具的第三方类库是否丰富,建议选择采用通用语言的自动化工具,比如用python或者c#作为脚本语言的工具。在定义UI节点的时候,自动化工具是否提供方便的方式来生成UI的映射。而且这种映射是否比较容易维护

  • 是否可以方便的调试测试程序,比如是否支持断点和变量值查看

  • 产品里边自定义UI,或者叫自绘制的UI控件的比例,是否是关键节点控件(当然了,如果自绘制UI控件支持的Accessibility的接口,那就没有问题)。比如,产品的最主要功能是绘图,一般绘图区肯定都是自定义控件,而UI自动化工具基本上对绘图区都是无能为力的,那是否有其它方式可以来测试?比如把绘图相关的模块单独拿出来,通过API的方式来操作测试?


  • 反对录制回放脚本

  • 看到有些team把支持录制回放脚本作为评估自动化测试工具的一个必备条件,而且有些就是用录制回放来创建测试用例。些很小的项目,测试用例只有几十上百个倒是问题不大,但是当测试用例个数上百上千的时候,维护测试用例基本上就变成一个繁重的任务。比如一个UI节点细微的变化,可能导致自动化工具没有识别UI控件,那么所有用到这个控件的测试用例都需要更新,查找替换并且保证没有替换错就是一个很大的工作量,更别说一般录制的脚本人工都不容易理解。


  • UI自动化测试不只是脚本,也需要设计

  • 软件测试脚本的开发也是软件开发,脚本必须符合规范,必须经过设计编码测试维护的全过程。

  • 测试脚本的设计: 根据面向对象设计的原则,我们需要对变化频繁的地方进行必要的封装。在这里变化相对最频繁的就是UI本身,而相对稳定的是业务逻辑。所以我们可以针对UI进行封装,然后再封装一层业务逻辑层,所有的测试用例都通过业务逻辑接口进行操作。比如我们要测试一个登录窗口,那么UI层就包含用户名,密码,登录按钮的UI定义,逻辑层包含接口类似login接口,测试用例里边就调用login接口登录并进行必要的验证。

  • 测试脚本的编码:既然是软件工程,那么脚本也必须遵循代码规范,比如python的脚本需要遵循python的代码规范。

  • 测试脚本的测试:脚本是用于测试程序的,那么自身的质量也是至关重要。建议有条件的team进行code review,当然这个很难做到…… 另外就是至少要人工观察脚本的操作,来确定它做了正确的事情。而且需要在不同的系统和机器上测试通过。

  • 测试脚本的维护:UI相对来说比较容易变化,这就导致测试用例的fail,那么我们需要去调试并确认是脚本问题,确认之后如果设计良好,大部分情况下只需要更新UI层就可以了。另外我们需要考虑是否UI变化过于频繁,现在自动化开始是不是正确?


  • UI自动化测试开始的时机

  • 从前边测试脚本的维护可以看出,维护工作量的大小,跟UI变动是否频繁直接相关。我们需要做的事情,就是确定什么时候UI已经稳定了,我们再开始UI自动化,否则还是考虑先人工测试覆盖。当然了,我们也没必要等整个程序的UI稳定,比如一个独立的功能UI稳定了之后,我们就可以先对那个功能进行自动化,然后等待其它功能的UI稳定。

  • 而且一旦UI自动化开始,后边的维护工作也相应要开始

  • 所以我建议开发过程中,有一个milestone叫UI freeze,这个阶段后就可以着手开始UI的自动化测试了。当然,非UI的自动化,比如Unit Test,Integration test和API test应该很早就开始了

  • 另外一种情况,是针对上一个版本release的功能的回归测试,这个是最适合UI自动化的方面。一般来说,这种情况UI变动基本上没有,而且功能比较稳定,测试写好之后,可以有效减轻手工测试的压力,而且可以更专注于新功能的验证。


  • 需要考虑UI自动化的投入产出比

  • 我们先说投入:与软件的投入产出一样,一个设计良好的UI自动化框架,最大的投入应该是创建框架和实现测试自动化脚本,而尽量减少维护的工作量。一个坏的自动化框架,前期可能投入较少,后续的维护和更改的成本可能几倍与前期,甚至到最后只能丢弃掉。

  • 说到产出,自动化测试跑的次数越多,平台覆盖越广,产出就越多,减少手工测试的工作量也越多。一旦自动化测试写好,那就应该让他们持续的跑起来,比如根据情况设置每周,每日,甚至是每次提交自动部署到所有平台运行并报告结果。这个配合Jenkins来实现会比较方便。

发表评论
评论通过审核后显示。
联系我们
  • 联系人:阿道
  • 联系方式: 17762006160
  • 地址:青岛市黄岛区长江西路118号青铁广场18楼