背景
  项目是基于Ruby on Rails开发的web程序,应该说项目中的测试实践是很好的,具有高覆盖率的单元测试以及比较合理的集成测试。存在的问题是,所有的单元测试和集成测试都是针对后端代码的,前端的JavaSript代码没有单元测试(这个是有历史原因的,暂时没法改变)。这也意味着针对前端UI的修改是没有底层的单元测试来保障的,只能依靠高层级的UI自动化测试和手工测试来保障。
  我们近刚刚完成了一个story,是纯前端的开发工作,结果在上线后发现我们在修改页面模板文件时,忘记了其他地方也在使用同样的模板文件,导致了部分页面样式错乱,甚至无法访问。这个bug在现有的UI自动化测试和手工测试中都被遗漏了,直接发布到了产品环境上,后来通过线上日志才被发现。不得已我们只好把版本先回退,修复bug后再重新上线,release的时间推迟了一周,可以说整个团队为此付出了严重的代价。
  痛点
  作为团队的QA,出现这样的问题自然让我很不好受,颜面无光。。。抛开没有做story业务分析,手工测试场景遗漏等问题,聚焦在现有的UI自动化测试上,以下是我感知到的一些痛点:
  1、UI自动化测试的稳定性不高 - UI自动化测试是用ruby版本的selenium实现的,存在着众所周知的问题,例如不够稳定,经常由于页面加载超时,UI交互复杂等问题导致测试失败,使得自动化测试结果的有效性不高,失去了它本来应该具有的价值。
  2、测试场景覆盖不够全面 - 当然,根据测试金字塔的理念,上层的UI自动化测试应该是小规模的,只覆盖基本功能:

  但是具体到这个项目中,由于前端代码的底层测试缺失,所以不得不依靠高层级的UI自动化测试来覆盖更多的场景,   起码要能完成基本的回归测试,否则手工测试的压力太大。这回到了第一个问题,正是由于UI自动化测试的稳定性不高,所以我只实现了很小一部分功能,以免后续维护的成本太高,而我们遗漏的bug恰恰没有包含在自动化测试的场景中。
  问题分析
  所以,我们的聚焦点集中在了如何提高UI自动化测试的质量上,经过分析,主要的问题有:
  页面加载时间超时
  在用webdriver的方法访问页面时,经常出现加载超时的问题。页面的DOM结构已经渲染完成了,但是在访问某些外部网站时长时间没有响应,导致测试脚本一直卡着无法继续进行,后报超时错误。
  页面交互action太多
  UI自动化测试的一个缺点是所有的执行动作都要通过页面的action来完成,例如文本框输入,点击按钮,而且这些动作的执行结果存在太多的变数,导致后写出来的测试脚本太过脆弱,很容易失败。
  解决问题
  使用异常捕获机制来处理超时等异常情况
  针对页面超时的问题,由于页面的DOM结构已经渲染完成了,所以其实可以继续执行后续的用例。但是如果与外部网站的请求没有全部完成,selenium会认为页面加载没有完成,一直卡在访问页面的get方法上。我的做法是设定一个页面加载的超时时间:
  dr.manage.timeouts.page_load = 30
  超过30秒认为页面加载超时(经过测试,30秒的时间已经足够把页面的DOM结构渲染完成了),然后访问页面时捕获超时的异常:
  begin
  page.open_page
  rescue Selenium::WebDriver::Error::TimeOutError
  puts "ERROR:page load timeout!!"
  end
  这样如果加载超过30秒,会抛出异常后继续向下执行。不致于因为访问某些外部网站请求过慢,而卡在页面加载的步骤,导致整个测试用例失败。同样的策略也可以应用在某些复杂或者不确定的执行结果上,捕获可能出现的异常,提高测试的健壮性,避免非产品原因导致的测试用例失败。
  减少UI测试,增加API级别的测试
  这个观点听上去多少有点荒唐,提高UI测试质量的方法是减少UI测试。。。。但事实是这样,UI测试是自动化成本高,不稳定的测试,能够在低层级完成的测试,例如API层的测试,不要放到UI层去完成,这样会使测试更加稳定和健壮。很多页面action,例如提交表单,点击按钮等,实际都是向后台发送了一条请求,如果测试的是功能,那么完全可以用API来完成这些测试。重点还是在于我们究竟想测什么,是否必须要从UI层去完成这些测试?这是测试结构的设计问题了,这里不展开讨论。
  在这个项目中,我把一些可以在API层完成的测试从UI测试用例中分离出来,用ruby的Faraday库(当然也可以用其他的,例如JS的SuperTest)调用相应的API并对返回数据做校验,这些测试相比于UI测试更加稳定,运行速度更快,整个测试的稳定性便得到了提升。
  将页面交互的action与静态页面内容分开测试
  这个方法的思路和上一个类似,尽量减少通过页面加载和交互来完成的测试。如果测试内容中不包含动态的页面交互步骤,例如只是想测试页面能否正常打开,某一部分的内容能否正常显示等,可以从页面的DOM结构中通过校验某些元素来完成测试。
  举个例子,如果想测试百度首页,可以不用从selenium webdriver中去加载这个页面,直接用ruby的Faraday或者JS的SuperTest去访问"http://www.baidu.com"这个URL。这样拿到的将是一段html的文本,然后再解析这段html文本(例如用ruby的Nokogirl库),获取对应的内容来做校验。例如返回码是200,<title>的内容是“百度一下,你知道”,那么可以认为首页能够正常打开。<img>中的src属性是一个正确的图片文件,可以认为百度的logo能够正常显示。
  这里会产生疑问,如果我是想测试界面怎么办?这回到了刚才那个问题,我们究竟想测什么?如果只是想测功能,那么我们尽量减少对界面的依赖。如果只是想测界面,那么也有其他的办法来完成,例如WebdriverCSS或者PhantomCSS等界面对比的测试工具。当然,有些测试步骤是必须要依赖页面交互的,例如点击某个按钮打开一个新的对话框或者跳转到其他页面,这些测试只能通过webdriver来完成了。
  总结
  通过实际的尝试,我明显感觉到优化后的自动化测试相比于原来有了更稳定的表现,运行速度变快,非产品原因导致的用例失败次数变少。而且自动化测试更稳定后,我有信心去实现更多的自动化测试,扩大覆盖的场景。我的一些感受和收获是:
  1.UI自动化测试的编码实现不难,难的是如何做整体的测试结构设计。在UI测试中覆盖的场景太少达不到测试的目的,场景太多又会成为团队的负担,带来高昂的维护成本,需要和UT/API等测试综合考虑,互相弥补。
  2.UI自动化测试是把双刃剑,它应该是QA后考虑的自动化测试方法。只有当其他层级的测试无法达到目的,或者希望测试的内容必须要通过UI完成时,再去考虑用它。低层级能完成的测试不要放在高层级去完成,在静态DOM结构中能完成的测试不要通过webdriver加载页面去完成。