Robot框架下的软件自动化测试技术

北京中电普华信息技术有限公司 张露雨 李 佳

软件开发技术发展得越来越快的同时对软件质量的要求越来越高，测试变得尤为重要，软件测试是质量保证的重要手段。随着开发周期日益缩短以及系统越来越复杂，手工测试很难在短时间内完成高质量的测试，会耗费大量的人力物力。引入自动化测试，可以明显缩短测试工期，减少人力物力成本。自动化测试已经被广泛应用于各种类型的测试中。本文主要内容有：自动化测试的优缺点、适用范围，自动化测试框架及工具、Robot Framework在项目中的应用、常见问题处理方式等。

近几年来，人们对软件质量的要求越来越高，软件生命周期中软件测试工作变得越来越重要，软件测试是软件质量保证的关键步骤。传统的手工测试速度慢、效率低，当测试周期很长、重复性操作过多时，手工测试很容易变得枯燥无味，也可能会出现由于间隔时间过长，缺陷描述不清晰等因素，导致回归测试无法重现问题；自动化测试可以提高测试效率，减少测试时间，很好的解决了手工测试的瓶颈。本文将围绕Robot框架分析研究自动化测试技术在项目中的应用。

1 自动化测试意义及适用项目特征

1.1 自动化测试的意义

自动化测试是将手工测试行为转换为机器执行的一个过程，即通过自动执行程序语言编写的测试脚本模拟手工执行测试用例对软件进行测试。我们通常所说的自动化测试主要是说通过程序设计，使计算机按照预定的流程自动测试软件，自动记录软件缺陷以及自动分析测试结果的一种测试，自动化测试可以节省人力资源、时间和硬件资源，有效提高测试效率。

一般情况下，大型软件开发项目测试工作量普遍很大，测试又是软件生命周期中十分重要的环节，几乎占据一半的时间来进行软件测试，一些可靠性要求非常高的软件，测试甚至可以占据更多的时间，一个软件从开发到上线需要经过很多次的回归测试，每一次回归测试工作存在大量重复性操作的情况，并要求做到细致准确，自动化测试最适合代替人工去完成大量的重复性工作。

表1展示了自动化测试的优势及手工测试的局限性。

虽然与手工测试相比，自动化测试具有很大优势，但自动化测试也有自己的限制，自动化测试往往是提供一个框架、一种工具，维护难度较大，且不是所有的测试用例都可以转化为自动化测试用例，例如数据正确性、页面布局是否美观、业务逻辑是否满足需求等还是需要手工测试来完成，此时手工测试发现的缺陷比自动化测试发现的缺陷更多。自动化测试可以提高效率、复用性、可靠性等，虽然有很多优点，但也只是软件测试的一部分，无法完全代替手工测试，自动化测试是对手工测试的一种补充。

表1 自动化测试与手工测试

1.2 适合自动化测试项目特征

一般情况下，项目满足以下几点可采用自动化测试。

（1）项目周期足够长

自动化测试前期需要很多准备工作，自动化测试框架的设计、测试脚本的编写及调试均需要相对较长的时间来完成。如果项目周期较短，没有足够的时间去支持以上工作，那么此类项目就不适合做自动化测试。

（2）软件需求稳定，不会频繁变动

测试脚本维护成本很大程度上会受测试脚本稳定性的影响，针对频繁变动需求的项目来说，测试人员需时刻关注并更新与变更后需求相关的测试脚本。测试脚本的维护本身也是一个代码开发、调试的过程，必要的时候可能还需要修改自动化测试框架，如果维护测试脚本的成本高于节省人力的成本，则说明此类项目不适合进行自动化测试。如果一个项目中部分模块需求稳定，则可仅针对这些模块进行自动化测试，其余模块依然采用手工测试。

（3）需要在多种平台上重复运行相同测试场景

对于需要在多种浏览器或者大量不同移动端上执行相同测试场景的项目，如果采用手工测试则需要将每个测试用例反复执行多次，自动化测试是此类项目一个不错的选择，可以减少大量重复性操作，提高测试效率。

2 自动化测试框架简要介绍

自动化测试已经在测试行业广泛应用，如何选择一个合适的测试框架变得尤为重要。为此，我们需要了解目前行业中主流的自动化测试框架，这样才能从中选择最适合自己接触的项目的测试框架。现在主流的自动化测试框架有：Robot Framework、RedwoodHQ、Jasmine、Pytest等。

2.1 主流自动化测试框架简介

（1）Robot Framework

Robot Framework（RF）是用于验收测试和验收测试驱动开发（ATDD）的自动化测试框架。基于Python编写，但也可以在Jython（Java）和IronPython（.NET）上运行，提供跨平台支持（Windows、Linux或MacOS）。

首先Robot Framework使用关键字驱动测试的方法，这样简化了自动化测试过程，对于没有编程经验的测试人员来说使用Robot Framework编写的测试数据更加便于理解。其次Robot Framework由各种独立项目开发的测试库和工具组成，生态系统相对较为丰富，且Robot Framework具有较高的可扩展性，对于未来市场和行业出现的变化有较好的应对能力。

（2）RedwoodHQ

RedwoodHQ可以使用大部分流行的编程语言来编写测试脚本，比如JAVA、C#、Python，并且RedwoodHQ支持多人协作编写并运行测试用例。RedwoodHQ关注一个重大项目的全部测试过程，可以说是目前主流平台中对用户、测试人员最友好的测试平台。

（3）Jasmine

Jasmine适用于网页项目、Node.js项目，是一个由JavaScript的行为驱动开发的测试框架，也是一个单元测试框架。但是除了JavaScript之外Jasmine还可以在Python、Ruby语言运行，并且可以在服务器端运行客户端测试。Cis支持比较广泛，且内置用于断言的语法，使用起来十分方便。但是Jasmine难以异步测试且大多数情况下Jasmine需要一个测试运行器才能进行测试。

（4）Pytest

Pytest是基于python语言的单元测试框架，适用于复杂度低且规模较小的项目。使用起来相当简洁高效。最大的特点就是易于使用，它入门简单，对没有代码编程经验的人相对容易上手。官方提供了相当多的支持文档与参考实例，支持参数化操作，支持部分测试步骤的跳过，可以重复执行失败的case，对第三方插件兼容性较高，并支持自定义扩展。且Pytest编写代码相对简单，代码容错率较高，可以搭配图形用户界面一起使用，使测试工作可以进行得更加轻松。但是Pytest只适用于复杂度、系统规模都不大的项目，性能和运行效率方面无法支持市面上规模较大的系统。

综上所述，从扩展性、易用性、测试人员能力等方面综合考虑得出结论Robot Framework框架是最适合当前公司项目使用的自动测试框架。

2.2 Robot Framework详细介绍

Robot Framework是一款使用python创建的用于功能自动化测试框架，由于Robot Framework支持多个客户端或者多个接口同时同步测试，又具有很高的扩展性，且可以通过关键字驱动，使用效率较高、难度较低，所以Robot Framework目前在测试行业中应用广泛。

（1）Robot Framework使用txt文件保存测试用例，使用制表符分隔数据，便于适应不同的编辑软件使用，甚至可以使用excel等软件创建用例，使用十分方便。没有编程基础的业务人员也可以使用Robot Framework框架编写测试用例。

（2）设计测试用例时可以根据使用需要设置变量，且Robot Framework架构支持常用的循环语句，有利于测试用例的泛用和复用。

（3）支持标签操作，可以对测试用例进行分类，便于规范测试用例。执行时可以只执行部分测试用例。

（4）Robot Framework框架支持数据驱动、关键字驱动在内的多种驱动。

（5）Robot Framework框架支持对现有关键字的调用，可以以现有关键字为基础创建新的关键字，方便创建更加复杂更加高级的测试用例。

（6）Robot Framework框架生成的测试报告、测试日志均是html格式文件，方便阅读，方便提供给没有编程能力的管理人员阅读。

（7）Robot Framework自带事件的监听接口，用户可以自行定义测试用例执行前执行后的对应动作。方便自定义测试用例中的前置条件和后置条件，便于测试用例的连续操作，能有效提高测试用例的泛用性和复用性。

（8）Robot Framework内置命令接口，可以使用XML格式进行输出，可以与其他测试工具、管理工具结合使用，进而实现整个测试过程的持续集成。

（9）Robot Framework内含大量的测试库，可自动识别、操纵被测对象。

（10）Robot Framework提供了远程测试执行的接口、支持远程调试，方便线上交流。非集中办公的项目也可以使用Robot Framework进行测试。

（11）Robot Framework基于python语言开发，相对较为便于初学者理解。

3 Robot框架在自动化测试中的应用

我司电力营销系统开发周期较长，系统功能较多，涉及了三百多个功能，功能结构类似，其中增删改查等基本维护类操作占据整个系统功能的70%左右，为了适应大众的浏览器使用习惯，该系统需要做目前主流浏览器（IE8及以上、chrome50及以上、firefox50及以上版本）的兼容性测试。如果单纯靠手工来进行测试，需要做大量重复性操作，既费力又耗时，重复性操作持续时间过长的话，可能会有一些测试点会被遗漏，回归测试时也不能确保尽可能覆盖测试点。针对这些功能开发自动化脚本进行测试是一个很不错的选择，接下来简单介绍下基于Robot框架的自动化测试应用，选取新增渠道类型功能为例。

3.1 Robot framework自动化测试环境搭建

（1）安装python，安装完成后配置环境变量。

（2）安装wxPython。

（3）安装Robot framework。

（4）安装robotframework-ride（RIDE是一个图形界面的用于创建、组织、运行测试的软件）。

（5）安装selenium2library。

（6）下载各浏览器版本对应的驱动并拷贝到python安装目录下。

3.2 编写测试脚本

登录脚本编写及调试：

该系统需要对浏览器兼容性进行测试，可以在open browser的浏览器参数部分输入chrome、ie（默认为firefox，可不用输入），并输入测试地址、用户名密码进行登录操作，由于后续操作基于登录功能，为了节省脚本录制时间，将登录脚本进行封装，后续操作时可直接使用，如图1所示。

新增功能脚本编写及调试：

（1）调试脚本时，如果遇到页面跳转后一直返回找不到元素的错误，先不用急着改脚本，可能原因是切换新页面后页面内容较多，部分元素还没有加载完毕，导致找不到元素，可以在定位元素之前插入一条sleep操作，一般可以解决由于页面内容未加载完导致的定位元素失败问题，如果插入sleep依然找不到元素，接下来可以继续查看是否是元素定位有误。

（2）自动化测试常用元素定位方法有8种，包括：id定位、name定位、class定位、tag定位、link定位、partial_link定位、xpath定位、CSS定位。其中xpath定位时，使用浏览器中开发人员工具（F12）选中页面元素后，右键copy其XPath，粘贴至ride中，部分页面元素的XPath没有明显的id、name等唯一值属性，只能从页面html标签开始向下寻找，如“/html/body/div /test /div/div/……/div[2]/button”，直接将其粘贴至ride中调试不成功，会报element not Found的错误，出现这种情况的原因主要是根据维护的元素定位路径未找到元素，此时需要将其格式转化为脚本执行时要求的格式，以//开始，//后面为元素唯一标识（路径唯一的部分可用*替代）。

（3）selenium2library测试库中常用点击操作相关关键字包括：click button、click element、click link、click image等，由于该系统功能菜单/功能按钮大多使用鼠标放在菜单名称处无需点击即可显示下级菜单，因此不能单纯采用click element、click button等点击操作关键字来编写该测试脚本，需要引入mouse up关键字来进行编写。由于该模块功能均需要进入同一模块菜单进行操作，为了方便复用，将进入菜单过程进行封装，如图2所示。

图1 登录脚本编写及调试

图2 新增功能脚本编写及调试

图3 新增功能脚本编写及调试

（4）参数化，robot framework-ride提供参数化设置，通过参数化设置可在脚本中引入变量，以此来解决一些特殊场景的需求。如页面字段存在超长字符校验时，可将该字段参数值设置为固定长度的变量，以此来避免手动输入大量数据带来的工作量。如果遇到页面字段需要输入唯一值的情况，也可将该字段参数值设置为变量的形式，为该变量赋值为随机数等不易重复生成的数据，如图3所示。

（5）添加检查点，检查点需要根据实际系统实现来进行查找并添加，该系统新增成功后返回查询页面，页面提示“成功”，因此添加检查点可以使用关键字Page Should Contain，查找内容为“成功”。如果可以找到“成功”，说明该用例执行后新增数据成功，否则新增失败，如图4所示。

3.3 执行脚本

执行方式选择pybot，点击【start】开始执行测试用例脚本，用例执行结束后，输出信息、运行日志以及结果报告生成保存至临时文件夹，可以直接使用浏览器打开路径进行查看，如图5所示。

图4 新增功能脚本编写及调试

图5 执行脚本

图6 分析结果

图7 分析结果

3.4 分析结果

Report显示所有用例执行结果，包括用例总数、成功数、失败数以及执行时间，Pass为用例通过，Fail为用例不通过，如图6所示。

如果想查看具体执行情况，可点击用例名称链接跳转至运行日志页面查看详情，如图7所示。

4 自动化测试常见问题的解决方案

4.1 录制脚本需要消耗大量时间

录制测试用例脚本需要耗费大量时间，对于中小型项目来说，使用自动化测试偶反而会拖慢项目的进度。对于开发初期的项目，由于各个流程尚未开发完成，需求变化比较频繁，编写好的用例可能没多久就完全不能用了，导致自动化测试用例的复用性大幅度降低。对以上类型项目可转换测试策略：对于中小型项目，主要采取手工测试的方法，只对某些复用性较强且需要反复测试的项目进行自动化测试。对于大型项目，项目初期不进行自动化测试，通常等到项目中期，流程设计基本确定之后再进行自动化测试。

4.2 修改代码后脚本无法复用

开发修改代码后再执行用例报错，需要重新阅读代码修改用例。

大型项目参与人员较多，不同开发人员修改代码经常会导致以前的测试用例无法继续执行。测试需要重新阅读代码进行排查，费时费力。有时由于测试人员代码阅读能力不够，花很久也无法修正用例。对此团队可以安排测试人员和开发人员不再按照职责化分工作，整个项目尽量按照负责模块划分，让负责同一部分的业务、开发、测试人员坐在一起，并要求在用例无法复用且问题较难解决的时候开发人员配合测试人员进行修改。

4.3 自动化测试不够细致

自动化测试只能发现既定的缺陷，对于新出现的缺陷有时无法识别。

自动化测试可以验证流程不通，界面报错等问题，但是对于界面设计错位或者不美观、等GUI问题一般无法识别。输入预先设定的测试数据或测试数据组合之外的情况如果出现BUG，也无法识别。对此团队决定采用手工测试与自动化测试结合的方式进行测试。每轮首先进行自动化测试，在自动化测试的主要问题解决后开始手工测试，尽量排查出自动化测试无法识别的问题。

4.4 系统架构复杂不好定位元素

现在常用的元素定位方法有8种：1）通过id定位；2）通过name定位；3）通过tag定位；4）通过class定位；5）通过css定位；6）通过link定位；7）通过partial_link定位；8）通过xpath定位。但是如果项目开发时没有为元素设置唯一的标识，那么定位元素会十分困难，且代码修改后用例极有可能无法复用。对此团队可以规范开发过程，尽量对所有元素设定唯一标识，并且规范标识设定规则，这样不仅规范了代码书写要求，还使代码更便于阅读与整改。对于无法设定唯一标识或者较难定位的元素，开发人员将配合测试人员进行定位。有时也可以为了方便测试对部分元素先设定临时的唯一标识，项目测试基本结束时再删去标识，进行相关功能的手工测试，保证删去标识对系统流程验证没有影响。

自动化测试技术还在不断的发展，虽然还有很多不成熟的地方，或许最终也无法完全取代手工测试，但是自动化测试带给项目的便利与效率是毋庸置疑的，在科技日新月异、技术突飞猛进的时代，期待着自动化测试在未来能带给我们更多惊喜。