专访内容

51Testing老师,能够做一下自我介绍么?
大家好,我是Tynam,意为太难,旨在提醒自己,没有什么事情是可以轻易完成的,都需要耗费大量的时间和精力去努力。就像我选择测试行业,历经坎坷,前路漫长未知,我毅然会用尽毕生精力为之奋斗。

目前就职于西安葡萄城有限公司,担任高级软件测试工程师一职。在软件测试行业中已经摸爬滚打了多年,有些测试经验和自己独到的见解。经常在各大测试论坛网站(博客园、测试窝、51测试圈、微信公众号等)发布测试技术分享。

从进入测试行业起,就一直致力于测试技术的研究,特别是在自动化测试设计、框架搭建和开发上有深入的研究,根据这么多年的经验积累著作了《Python web自动化测试入门与实战》一书。

2020年初新冠疫情爆发后,IT行业出现颓缩,测试人员找工作困难,便暗思自己该做些什么,解决求职困难的问题。在与许多测试人员进行交流后,即刻决定写一些测试人员面试的东西。到目前为止,寻问了多位测试大咖,咨询了近百位测试小白,完成了《测试工程师面试秘笈》一书,在不久之后便可以和大家见面了。
展开更多
点击收起
51Testingweb自动化测试除了大家熟知的功能测试外,还有哪些常见的测试类别?
web自动化测试最主要的就是对系统的功能测试,测试业务逻辑、功能模块、链接、表单、 Cookies等。除此之外我们还可以通过web UI 自动化做很多方面的测试,例如以下方面:
  • 兼容性测试:兼容性测试是web自动化测试的一大特色,可以在不同的操作系统平台使用不同的浏览器对网站进行测试。例如分别在win10、win8系统上分别使用Chrome、IE浏览器测试。
  • 易用性测试:易用性主要表现在页面功能易于用户使用,色彩搭配适合。例如可以测试图片大小和位置、各种边框、颜色、字体、背景色、按钮大小等。我们还可以测试文本内容,检测文字描述的正确性。例如title、字段说明等。
  • 稳定性测试:是在一定的环境下、给定的时间内、测试系统可以正常运行。web自动化可以模拟用户使用该系统,如果系统发生故障则可自动做记录。
  • 压力测试:在理论上使用分布式可以模拟用户给系统加压进行压力测试,但是有点麻烦,成本也大,一般没有测试人员这样使用。

使用web自动化我们可以做一些其他的测试,比如控件、插件的测试,例如项目中使用的日期控件。

总结:web自动化测试是最接近人行为操作的模拟测试,可以代替需要手工测试的许多重复工作,益处颇多。
展开更多
点击收起
51Testing有很多人不知道该如何开始上手web自动化测试,对于手工测试人员而言,web自动化该如何入门?学习web自动化有什么前提条件吗(前置技术能力,例如前端技术,数据库,代码)?对于前置技术需要掌握到什么程度?
我一直认为,自动化测试重在设计、构造的思想上,并不是什么技术。如果想入门自动化测试,首先要将自己做手工测试的那一套思想转换成自动化测试思想。例如要如何设计才能让测试用例不断的重复的运行,降低测试用例之间依赖,数据怎么准备,怎么销毁等。其次才是掌握一定的技术知识。下面给大家画了一个图作以简单的说明。


以上只是简单的入门知识点,如果需要想研究的透彻,则需要深入的学习,包括selenium源码的研究。
展开更多
点击收起
51Testingweb自动化测试工具和框架有哪些,企业中较为常用的有哪些,这些工具/框架的优势是什么,又有哪些不足之处?
web自动化测试框架和工具有selenium、RobotFramework、QTP、Katalon Studio、IBM Rational Functional Tester、watir等等。目前最受欢迎的框架是selenium,使用率最高的工具是RobotFramework。下面简单的介绍一下selenium和RobotFramework:

selenium
selenium是一系列基于web的自动化工具,提供一套测试函数,用于支持web自动化测试。能够完成界面元素定位、窗口跳转、结果比较,函数灵活,使用方便。

selenium具有以下优点:
  • 具有很多工具:selenium IDE、Web Driver、Grid
  • 免费、开源
  • 支持多种编程语言:Java、C#、PHP、Python、Perl、Ruby
  • 支持多种浏览器:Internet Explorer、Firefox、 Google Chrome
  • 可以运行在多个平台上:Windows、Mac、Linux
但也有不足,它仅针对web系统进行测试,像APP、exe程序等是不支持的。

RobotFramework
RobotFramework是一款python编写的功能自动化测试框架。提供可视化界面,具备良好的可扩展性,支持关键字驱动,可以同时测试多种类型的客户端或者接口,可以进行分布式测试执行。主要有以下优点:
  • 易于使用,采用表格式语法,统一测试用户格式
  • 重用性好,可以采用现有关键字来组合新关键字
  • 支持变量
  • 支持创建基于数据驱动的测试用例
  • 结果报告和日志采用HTML的格式,易于阅读
  • 提供标签以分类和选择将被执行的测试用例
  • 平台、应用无关
  • 功能全面、支持协议级接口的测试,GUI界面的测试,数据库的测试,移动APP的测试,命令行测试等
  • 易于扩展,提供了简单的api,用户可以自定义的基于Python或者Java的测试库
  • 易于集成,提供了命令行接口和基于xml的输出文件
  • 可以与版本管理集成(Jenkins)
展开更多
点击收起
51Testingselenium和RobotFramework都能用于web自动化测试,从您的角度而言,更倾向于哪一种,为什么?
两者各有优缺点。selenium多在编程语言中使用,RobotFramework是可视化自动化测试工具中的一个经典。如果让我推荐的话,我推荐selenium,然后再反过来研究RobotFramework。如果自学自动化测试的话,可以先从RobotFramework工具入手,理解自动化测试到底是怎么做的,做的是什么,毕竟熟悉工具比掌握一门语言要容易的多。有了理解之后再学习selenium,使用编程语言写脚本。当对编程语言、selenium有一个深入的学习之后,再反推 RobotFramework的实现,研究RobotFramework都实现了什么,是怎么实现的,如此才能彻底理解RobotFramework。在此期间,可以尝试写一个简易的、类似RobotFramework的自动化测试工具。
展开更多
点击收起
51Testingweb自动化测试都有哪些设计模式,例如数据驱动(DDT), 页面对象(PO),关键字驱动,行为驱动等,这些分别指什么,各自应用场景都有哪些?
自动化测试中有线性模型、模块化驱动模型、数据驱动模型、关键字驱动模型和行为驱动模型。下面给大家分别介绍一下:

线性模型:
线性模型是指将录制或编写的脚本与应用程序的操作步骤对应起来,就像流水线工作一样,每一个步骤对应一行或多行代码。每一条流水线(每个测试脚本)都是相对独立的,且不产生其他依赖与调用,这样产生的脚本叫线性脚本。这是在自动化测试早期采用的一种测试模型,由于工作脚本是线性的,所以也叫线性模型。线性模型的每一个脚本都是独立的,且几乎没有其他依赖和调用。开发成本比较高,而且代码的复用性特别差。

应用场景:
  • 可以快速编写测试脚本。
  • 完成某个操作流程。
  • 需要每个脚本单独运行。
  • 初学自动化测试的人员使用。

 模块化驱动模型:
模块化驱动测试借鉴了开发编程的模块化思想,是将重复的代码提取到一个公共的模块,然后在需要的时候调用封装好的公共模块,如果项目某一个功能有变动,只需要变动相应的脚本,很大程度上提高了编写脚本的效率。比如,登录模块就可以封装在公共模块中,一旦模块中的元素定位有所变动或其他因素影响了模块,只需要在封装的模块中进行调整对应,而不会影响到任何测试用例,机动性、灵活性非常强。维护简单方便,模块变动时只需要对相应的模块封装即可。

应用场景:
  • 使用比较广,目前绝大部分项目都在使用。
  • 多人协作,分模块开发脚本。
  • 代码可以重复使用。

数据驱动模型:
数据驱动是将测试数据和测试脚本分离,通过测试数据的改变驱动自动化的执行,从而产生不同的测试结果。简单地说,就是数据的参数化,输入不同的参数驱动程序执行,从而输出不同的测试结果。数据的保存形式可以是列表、字典,也可以保存在 Excel、数据库、xml 等外部文件中。这样就能够快速地应对测试系统中的大量数据,迅速创建出数百个测试迭代和排列。

应用场景:
  • 可以快速创建大量的测试数据。
  • 一套脚本,多个测试数据应对多个场景。

关键字驱动模型:
关键字驱动和数据驱动很相似,通过关键字的改变引起测试结果的改变,也称为表格驱动测试或基于动作字的测试。关键字驱动模型将测试用例分为 4 个不同的部分:测试步骤、测试对象、测试对象操作和测试对象数据。
  • 测试步骤:对测试步骤的一个动作描述,或者说是在测试对象上执行的动作描述。
  • 测试对象:页面中元素对象的名称,例如邮箱、密码和登录等。
  • 测试对象操作:测试对象上执行的动作名称,例如单击、打开浏览器、输入等。
  • 测试对象数据:数据是指对测试对象执行操作所需的值,例如“邮箱”字段的值为 “tynam@test.com”。

RobotFramework 工具就是遵循关键字驱动模型开发的一个功能强大的测试工具,其封装了底层的代码,提供给用户独立的图像界面,以 “填表格” 形式编写测试用例,降低了脚本的编写难度。

应用场景:
  • 通过可视化工具创建测试用例,适合编写简单的脚本。
  • 项目稳定,测试人员易上手。

行为驱动模型:
行为驱动开发英文名为 Behave Driven Development,简称 BDD,是一种敏捷开发方法,主要是从用户的需求出发强调系统行为。将此模型借鉴到自动化测试中称其为行为驱动测试模型,它是一种通过使用自然描述语言确定自动化测试脚本的模型。用例的写法基本和功能测试用例的写法类似,具有良好协作的益处。这种测试模型使每个人都可以参与到行为开发中,而不仅仅是程序员。每个测试场景都是一个独立的行为,以避免重复,并且已有的行为可以重复使用。

应用场景:
  • 行为驱动模型的思想非常有价值,但是国内还不太流行,在真实的自动化项目中还没有多少人使用。
  • 人人都可以写测试用例。
以上便是对五种自动化模型的简单介绍。对于这五种自动化模型的实现,有一个简单的Demo可供大家参考,下载地址:https://github.com/tynam-yang/AutomatedTestModel
展开更多
点击收起
51Testing企业中常见的web自动化分层框架有哪些,这样设计的意义是什么?
之前和许多测试人员聊过这个问题,目前来说,企业中最常见的分层结构是模块化思想,而它最好的体现便是page-object模型,即页面对象模型。在项目实际应用中一般会分为三层:
  • 对象库层,页面元素和一些特殊控件操作。
  • 逻辑层,封装好的功能用例模块。
  • 业务层,测试用例的操作。

如下图,便是一个简单的PO模型结构,大家可以进入 https://github.com/tynam-yang/AutomatedTestModel 选择模块化驱动模型文件夹查看Demo实例。

目录文件说明:
  • config: 配置文件。
  • data: 测试数据。存放上传数据,还可以细分,例如存放照片 image 目录、 video 目录等。
  • download: 存放下载的数据。还可以细分,例如存放下载的照片 image 目录、 video 目录等。
  • drivers: 驱动文件,存放浏览器驱动。
  • log: 日志文件,存放项目执行过程中的产生的 .log 文件。
  • report: 测试报告。
  • test: 测试文件,存放测试脚本、测试用例等。
    • common: 公用方法,项目相关的方法。
    • pages: 以页面为单位,每个页面是一个 page。
    • case: 测试用例。
    • runner: 对测试用例进行组织。
  • utils: 存放一些其他的方法。
    • HTMLTestRunner.py: 生成测试报告时使用的文件。
    • readConfig.py: 读取配置文件的文件。
    • run.py: 项目入口文件,主要是对 /test/runner 下组织的用例进行执行并且生成测试报告。
    • run.py: 项目入口文件,主要是对 /test/runner 下组织的用例进行执行并且生成测试报告。
    • run.py: 项目入口文件,主要是对 /test/runner 下组织的用例进行执行并且生成测试报告。
    这样做有诸多益处:
    • 集中管理元素对象,便于应对元素的变化。
    • 提高代码重用性,结构更加清晰,维护代码更容易。
    • 后期维护方便,不需要重复的复制和修改代码。
展开更多
点击收起
51Testing根据您多年的经验web自动化测试中遇到的痛点难点都有哪些?是否都有应对的可行策略?
我从以下几个方面给大家说说在web自动化中会经常遇到的问题,以及解决方法:
1、需求不稳定,项目频繁发生变更
这种问题要从两方面进行分析,是整个项目不稳定还是局部功能不稳定。如果是整个项目不稳定,大部分页面经常发生变动,那么这种项目不建议进行UI自动化测试。界面如果经常变动,脚本就需要重新编写,界面需求频繁的变更导致编写脚本的速度赶不上需求的变化,那么 UI 自动化就显的不是那么有意义。特别是现在许多公司都采用的是敏捷开发,项目周期短,更不太适合做UI自动化测试。如果是局部发生变化,那么建议先对稳定的内容做UI自动化测试,这样可以减少手工测试的压力。不稳定的部分打上标签,待稳定后再进行UI自动化。

2、第三方控件,难以操作
如果遇到项目中引入了第三方控件,但是selenium难以操作,该怎么办?例如日期控件。
这是一个很常见的问。如果是第三方的东西,我们需要查看它的文档说明,接口说明等内容。然后根据文档说明使用可以操作的语言(一般来说,web端的js都可以操作)进行封装,使用时调用即可。例如日期控件我们可以封装成的函数就是 date_operation(date),具体操作步骤需要根据具体场景而定。使用时我们直接调用,传入需要输入的值即可。

3、验证码难以识别
在很多类似登录的地方都会存在验证码,这的确是一个很难解决的方法。当然可以通过去掉验证码、设置万能验证码等方法通过测试。但这种方法对于系统来说明显动了代码,和实际环境中的有所差异。对于验证码问题通常有两种解决方法,第一种,使用机器学习等方法写脚本,识别验证。但是对于测试人员要求比较高,训练也需要花费很多时间。第二种,调用第三方接口,例如尖叫数据的验证码识别、阿里云视觉智能开放平台,调用相关接口识别验证码。
展开更多
点击收起
51Testing哪些项目适合web自动化,哪些不适合,为什么?结合您的经验什么时候投入web自动化测试可行性更高?
UI 自动化测试其实就是模拟手工点击,但它又不像测试人员一样,可以带着思考进行。因此它需要一定的规范,然后遵循这种规范写自动化测试脚本,这样才可以稳定、持续进行运行。所以UI自动化测试比较适合需求稳定且不频繁变更、需要频繁的回归验证、UI 界面稳定、界面控件定义规范可测试性强、开发维护周期长、进度压力小的项目。对于需求不稳定、页面发生频繁变更、开发维护周期短、被测系统开发不规范、可测试性需求不明确的项目不太适合。

我们都知道,UI自动化测试比较适合做回归、兼容性测试,对项目的稳定性要求比较高。因此,UI自动化适合在项目稳定后进行。一般都是在经过手工测试之后进行编写脚本的。但是可以尽早提上日程,进行规划。比如在开需求说明会的时候,将自动化测试提上日程,规划模块划分等内容,在项目稳定后便可立即上手开发脚本。
展开更多
点击收起
51Testing近几年接口测试的热门程度大有超越web自动化的趋势,web自动化测试会被接口测试取代吗?对比接口测试,web自动化测试的优势有哪些?
web自动化是基于页面上的测试,而接口测试是在数据交互上的操作,两者不在一个层面上,所以不会有谁取代谁的情况。根据测试金字塔,我们可以发现接口测试比web UI测试产出的效益会更大,再之web自动化的开发和维护要比接口自动化测试繁琐、费时,更费力,因此企业会不断的提高接口自动化测试的权重,与此也会加大web自动化测试的投入,因为web操作直接面对的是客户,容不得半点马虎。

与接口测试相比,web自动化测试更能模拟出用户的使用场景,全面覆盖需求规格。我们都知道web自动化测试主要用于回归测试和兼容性测试。回归测试是根据设计好的测试用例执行,web自动化就是模拟人为操作,结果可预期的测试,非常适合。兼容性测试是在不同平台、不同浏览器中进行,web自动化可以进行这样的操作。而接口测试就不能完成回归、兼容性这样的测试。
展开更多
点击收起