基于 WebDriver 的浏览器端自动化测试初步

By | May 8, 2016

工作中对自动化测试的需求以及基于 WebDriver 的浏览器端自动化测试初步认识。

一些背景

做前端为主的交互性应用程序时,如果架构不合理或者代码不规范,后续再加新 feature 或者维护起来非常吃力,很容易引起 regression。而这个问题如果发生在比较庞大的代码库下,更加突出,举个自己亲身经历的例子吧。

Office 365 是微软在商业软件云端化的一个重要布局,其中包括很多很多组件,其中 Office Online 应用程序就是其中之一。 Office Online 其实就是网页版的 Office,它不仅包含 Word/Excel/PPT 等等 PC 端早已渗透的老牌产品,还包含了一些新的适合于云端发布的各种服务,比如说 Sway,Mix 等等。在参与 Word/Excel/PPT 时,本身它的代码库已经很大, 我们新加功能必须要保证新的代码即使崩溃也不能影响原有功能的使用,另外,由于新功能非常依赖 Iframe 以及 PostMessage 等技术,本身臃肿的代码中再引入这些复杂逻辑会变得更加“脆弱”。所以,一旦新的代码引入了比较严重的 bug 之后,总是会有人出来 challenge 说为什么没有 automation (自动化测试)去保护这些 feature,而必须依赖人为的测试找到这些问题。

我之前也已经对内部的测试工具(类似 webdriver的类库)有所了解,但是整体印象不是很好,总觉得有时候不稳定,或者利用类库去模拟人为点击的操作并不可靠,因为浏览器里常常会出现由于资源加载顺序或者网络状况,亦或是不兼容的代码导致莫名的 crash。另外,由于要测试的部分有很多 iframe之间的通信,个人对这类自动化测试不太喜欢,潜在的想法是 — 简单的测试,它可以做,但人为做起来也简单; 复杂的测试,用它做需要花费较大经历去写 code 然后集成到现有的自动化测试框架中去,费事费力,而且计划赶不上变化快,也许刚加的 case 过两天发现已经完全无用了,因为逻辑被改了。

现在又回来研究浏览器端的自动化测试,其实也是抱着复杂的心情:不想总是重复机械的劳动去做测试;需要一些线上测试,一方面从用户视角早些发现问题,另一方便增加流量方便基于log的passive Monitoring发现问题并及时报告。

基于 WebDriver 的测试技术

这里引用网上的一张图,非常的简单易懂,简单的说来:

  1. 浏览器解析运行 web 应用程序,并完成与用户的交互
  2. 每个浏览器(IE,Chrome,FireFox,Safari)都会根据 WebDriver 标准实现一些接口。
  3. 基于上述接口,可以利用不同的编程语言实现不同的封装(如 C#, Java, Puthond, JS, Ruby, 同样要依据一些标准进行),暴露成公用的 API 共开发者用来调用
  4. 开发者可以结合实际情况选择使用某种具体的 API 实现 去完成自动化的测试。

WebDriver 测试的原理

其实,另外一种不太准确但是简单的理解就是,浏览器给我们留了后门,方便我们使用不同的编程语言操作网页(模拟用户的操作)。

不同编程语言实现的 API,可以参照https://github.com/SeleniumHQ/selenium, 可以看到不同语言的代码实现分别放在不同的目录下。

刚才提到, WebDriver 的不同浏览器支持,以及不同编程语言下的封装,都可能有一些差异,而他们之间也是有标准要遵循的: https://www.w3.org/TR/webdriver/

SELENIUM DOCUMENTATION https://seleniumhq.github.io/docs/

Selenium 1.0 + WebDriver = Selenium 2.0 https://seleniumhq.github.io/docs/wd.html

什么时候不建议使用 WebDriver

个人感觉,如果你在考虑使用 WebDriver 技术做自动化测试,不妨先了解几类不适合使用 WebDriver 的场合 https://seleniumhq.github.io/docs/worst.html

  1. 验证码
  2. 文件下载
  3. Http Response Code

    利用 WebDriver 做自动化测试,http 返回值并不是必须的,针对 404 或者 500 的检查可以利用其他方式代替。比如,我们可以去检查该网页中的标题或者某一固定的元素值是否存在来判断该网页是否正常加载。 事实上, webdriver 更倾向于从真实用户的视角去检查网页是不是正常展示(比如通过检查元素是否存在)。另外,如果坚持需要检查 response code, 有些浏览器中 webdriver是可以做到的。

    原文:Selenium WebDriver is to browser automation, preferring to act more like a user and this is represented in the way you write tests with WebDriver. In automated functional testing, checking the status code is not a particularly important detail of a test’s failure; the steps that preceded it are more important.The browser will always represent the HTTP status code, imagine for example a 404 or a 500 error page. A simple way to “fail fast” when you encounter one of these error pages is to check the page title or content of a reliable point (e.g. the h1 tag) after every page load. If you are using the page object model you can include this check in your class constructor or similar point where the page load is expected. Occasionally the HTTP code may even be represented in the browser’s error page and you could use WebDriver to read this and improve your debugging output.

    Checking the webpage itself is inline with WebDriver’s ideal practice of representing and asserting upon the user’s view of the website.

  4. GMAIL, EMAIL, AND FACEBOOK 登录

    不要使用 webdriver 去登录第三方的网站,一方面可能会被封号,亦或是不稳定。 推荐的做法是,利用第三方网站提供的 APIs 去做认证和登录验证,尽管这实现起来可能会更麻烦一点,但是公开发布的 API 一般不会发生变化。另一方面,第三方网站的布局有可能发生变化,所以webdriver的实现也需要变化。

    原文:For multiple reasons logging into sites like Gmail and Facebook using WebDriver is not recommended. Aside from being against the usage terms for these sites (where you risk having the account shut down), it is slow and unreliable. Not what we want where test stability is important.

    The ideal practice is to use the APIs that email providers offer, or in the case of facebook the developer tools service which exposes an API for creating test accounts, friends and so forth. Although using an API might seem like a bit extra hard work you will be paid back in speed, reliabilty and stability. The API is also unlikely to change whereas webpages and HTML locators change often and require you to update your test framework.

    Logging in to 3rd-party sites using WebDriver at any point of your test increases the risk of your test failing because it makes your test longer. A general rule of thumb is that longer tests are more fragile and unreliable.

  5. 测试之间有依赖

    A common idea and misconception about automated testing is regarding a specific test order. Your tests should be able to run in any order, and not rely on other tests to complete in order to be successful.

  6. 性能测试

    由于 webdriver 测试用例在运行时可能会受到浏览器启动速度、http 服务器速度、第三方服务器的响应时间等等影响,所以不建议在做性能测试时使用这种技术。

    It may seem ideal to performance test in the context of the user but a suite of WebDriver tests are subjected to lots of points of external fragility which is beyond your control; for example Browser startup speed, speed of HTTP servers, response of 3rd party servers that host Javascript or CSS. Variation at these points will cause variation in your results. It is very difficult to separate the difference between the performance of your website and the performance of external resources. As WebDriver is only an API you will need to develop this reporting yourself.

  7. 链接爬虫

    利用 webdriver 方式效率并不高,因为它本身并不擅长做这个,完全可以利用其他的工具更高效地做到这些。

Leave a Reply

Your email address will not be published. Required fields are marked *