WEB自动化测试业界现状分析-iTest

1 概述

iTest是WEB自动化前端测试服务平台，版本已经上线公测，本文对iTest的功能进行初步试用，同时初步分析其实现原理。

2 功能与原理分析

iTest提供四大测试能力：UI自动化测试(AUI)、多浏览器检测(PMI)、多浏览器测试环境(MTE)和页面坏死链检测(PI)。其中的“UI自动化测试”即当前业界主流的WEB自动化测试，“多浏览器测试”为WEB兼容性测试，后面两个“多浏览器测试环境”是iTest提供的个性化服务。

2.1 UI自动化测试

iTest的UI自动化测试，与通用的WEB自动化测试原理一致，均是使用页面录制回访的方式进行WEB自动化测试。

1.       录制

功能介绍：

iTest开发了一个Chrome插件进行自动化录制，元素的选取支持自动录制与选择录制

自动录制会将手工测试页面的所有操作均记录下来；选择录制可以先用选中的元素，再确定是否录制脚本。

最终录制完成以代码方式维护

原理分析：

结合提供的自定义编码与本地调试功能，我这边大胆来“猜测”其内部实现原理

导入包源码如下：

import com.alibaba.fastjson.*;

import com.alibaba.intl.qa.baseui.log.*;

import com.alibaba.intl.qa.baseui.webdriver.report.*;

import com.alibaba.intl.qa.ui.api.*;

import com.alibaba.intl.qa.ui.aui.*;

import com.alibaba.intl.qa.ui.exception.*;

import com.alibaba.intl.qa.ui.tc.*;

import com.alibaba.intl.qa.ui.util.*;

import org.openqa.selenium.*;

import org.sikuli.script.*;

import org.slf4j.MDC;

import java.text.SimpleDateFormat;

import java.util.*;

a．    从导入包名称可以分析：底层原理还是基于Selenium IDE自动化录制原理（Selenium的原理请参考《Selenium私房菜》），录制后将录制步骤转换为JAVA Junit测试代码维护

b．    当然阿里为了适配iTest平台封装了api、chrome插件与UI适配

录制步骤源码如下：

private void step2() {

        StepLog.currentStep = "步骤2";

        // URL检查及跳转

        browser.attach("www.baidu.com/", "https://www.baidu.com/", false);

        StepLog.currentStepName = ":点击元素[百度一下]";

        StepLog.log(uuid, StepLog.currentStepName, "", "", true);

        // 元素定位数据

        String identify_data = "{\"auiParent\":\"null\",\"className\":\"bg s_btn btnhover\",\"id\":\"su\",\"index\":\"null\",\"innerText\":\"\",\"matchConstVal\":2.4,\"multi_index\":{\"className\":0,\"id\":0,\"nodeType\":0,\"type\":0,\"value\":0},\"name\":\"\",\"nodeName\":\"INPUT\",\"nodeType\":1,\"outerText\":\"\",\"src\":\"\",\"tagName\":\"INPUT\",\"textContent\":\"\",\"title\":\"\",\"type\":\"submit\",\"value\":\"百度一下\",\"xpath\":\"//*[@id=\\\"su\\\"]\"}";

        UIElement element = browser.findElement(identify_data);

        element.click(); // 元素操作

    }

c．    从实际测试步骤来看，还是遵循传统的WEB自动化原理：先进行元素定位，找到元素后再进行元素操作；

d．    通过反编译iTest提供的jar包了解查找元素的方法browser.findElement的原理：从 identify_data中记录的元素属性（classname/id/index/innerText…/Xpath）按顺序循环获取元素的位置，只要获取到就退出循环，而且xpath的获取元素的优先级是最低的。

2.       元素修复

功能介绍：

iTest提供了一个很有意思的功能“元素修复”，也是其对外宣称的“自我修复”，实际上就是相当于脚本回访调试中，对回访失败的步骤中的元素，重新用Chrome录制一边。

因为iTest对于录制的代码禁止修改，我这边仅发现调试中进行元素修改，用例执行过程中是否能够自动修复暂时无法验证。

原理分析：

这个手工修复的原理比较简单，就是基于上述录制原理，增加一个录制步骤，删除原录制步骤即可。是否可以自动修复？这个待验证

3.       云端回放

功能介绍：

iTest支持IE8、Chrome、Firefox三种浏览器的云端回访，即云端测试

原理分析：

这个没啥技术含量，我们的SmartGUI也支持，使用三个Agent进行测试即可

4.       本地测试

功能介绍：

iTest支持本地测试，所谓本地测试即支持内网测试，比如192.168.X.X网段的测试。

只需要在本地安装一个AUI-Agent代理即可，不过这个功能目前我还没用起来，不知道是研发区网络限制，还是本地环境不支持，总之还没用起来 T_T……

待研究后再补充

2.2 多浏览器检测

功能介绍：

多浏览器检测，即多浏览器CSS、JS兼容性测试，目前支持的浏览器类型有Chrome/Firefox/IE8/IE9/IE10/IE11

使用时仅需要新增URL即可，可以检测JS错误，执行后多个浏览器会进行截图展示：

原理分析：

一般测试浏览器的兼容性，主要就是测试JS、CSS的兼容性，iTest的这个兼容性测试完全在后台实现，因此只能进行原理猜测：兼容性测试实际上就是搭建多套浏览器测试环境，并通过Selenium访问URL，捕获浏览器返回的异常信息

如下图，实际手工访问时候，页面补货的异常：

但是这种测试方案有一些缺陷：

1、  必选手工识别所有的浏览器URL后，在该测试平台上进行测试。

2、  兼容性浏览器还是比较少的

2.3 多浏览器测试环境

所谓多浏览器环境，即iTest实现的云桌面测试环境，通过IE远程访问各测试环境

2.4 页面坏链检测

功能介绍：

页面坏链检测与多浏览器检测类似，创建URL后，后台自动进行检测，并反馈无效链接与页面截图。

原理分析：

这个原理比较简单，就是到页面上搜索属性为href=”http://xxxx” 的元素,并访问连接，返回非HTTP 200 OK的即认为是坏链.

3 技术借鉴

3.1 元素定位原理

当前问题：

当前工具部使用的SmartGUI仅支持分别按元素ID/NAME/xpath/struct查找元素，一旦产品开发的页面没有ID，或者修改某一属性时，必然造成元素定位失败，影响用例执行

借鉴内容：

建议借鉴iTest的元素定位原理，通过多个元素属性循环定位元素位置，就会提高元素定位的稳定性。如果做的更智能点，我认为可以全部元素属性都定位一遍，然后通过概率方式优选概率最大的那个元素。

3.2 兼容性测试方案

当前现状：

页面的兼容性测试是对于用户Portal来说是比较重要的，目前公司内各产品都没有专业的兼容性测试平台与兼容性测试方案。

借鉴内容：

阿里的这套兼容性测试方案比较有借鉴意义的就是依托云平台搭建一套公共的兼容性测试平台，提供各种URL与产品进行测试，提升了兼容性测试平台的利用率。

另外，猜测的基于Selenium的代码捕获浏览器异常，可以实现代码实际试验一下。