前端测试回顾及我们为什么选择Karma

前端测试,或者UI测试一直是业界一大难题。最近Q.js使用Karma作为测试任务管理工具,本文在回顾前端测试方案的同时,也分析下为什么Q.js选用Karma而不是其他测试框架。

像素级全站对比

曾今有一批人做过这样的UI测试,即最终页面图像是否符合预期,通过图片差异对比来找出可能的问题。

如图所示,所谓像素级站点对比,即利用截屏图像前后对比来找出,站点前后差异,从而发现问题。

Q: 为什么需要这种测试呢?

A: CSS容易被破坏,在大型响应式重构案例中,像素级全站对比是一个比较好的测试方案。

目前常用的两大工具:

录制型测试

比较经典的有Selenium,本质上提供了编码型测试,但是因为提供了录制功能,所以广泛被用于录制测试。

编码测试

即通过编写代码来测试UI,但由于各种兼容性问题,这里出现了各种方案。

JsTestDriver式

即启用一个服务器,然后让测试浏览器链接该服务器,便可自动运行测试任务,下面是BusterJS中的一个演示:

  • 启动服务器

  • 打开测试浏览器,并连上服务器,按下按钮使得服务器捕获该浏览器

  • 在服务器发起一次测试,则每个被捕获的浏览器都会跑一次测试用例

静态测试

即通常的打开一个页面进行测试,下面是Mocha的静态测试页面例子:

无头浏览器测试

即通过无头浏览器,如:PhantomJSSlimerJS来进行测试

持续集成测试

这个就需要看持续集成系统能提供什么浏览器支持了,一般至少可以提供PhantomJS来进行测试,比较优秀的持续集成系统有:

下面是Backbone在Sauce Labs里的测试,可见,可使用各种浏览器进行测试:

Karma

Karma是一个测试任务管理工具,可以很容易和Jasmine、Mocha等市面上常用的测试框架打通,通过其插件可以快速集成到各种环境中。例如:本地环境、持续集成环境。

她可以使我们只需输入一行命令就就行测试,并在文件进行修改后,重跑一次用例,过程就像用NodeJS进行测试一样一样的。

所以目前在各大开源项目中使用,下面是使用Q.js进行测试的完整输出:

bogon:Q.js miniflycn$ gulp test
[23:58:30] Using gulpfile ~/github/Q.js/gulpfile.js
[23:58:30] Starting ‘test‘...
INFO [framework.browserify]: 70617 bytes written (0.30 seconds)
INFO [framework.browserify]: bundle built
INFO [karma]: Karma v0.12.35 server started at http://localhost:9876/
INFO [launcher]: Starting browser Chrome
INFO [launcher]: Starting browser PhantomJS
INFO [Chrome 41.0.2272 (Mac OS X 10.10.2)]: Connected on socket YFLQOvttbrfH9Mmxvqeu with id 10368837
WARN [web-server]: 404: /favicon.ico
INFO [PhantomJS 1.9.8 (Mac OS X 0.0.0)]: Connected on socket E1mb7b7zs7Ugi4u-vqev with id 68559341

Start:
  data
    ? should able to get a vm data
    ? should able to set a vm data
    ? should able to pop a vm data
    ? should able to unshift a vm data
    ? should able to shift a vm data
    ? should able to call indexOf for a DataArray
    ? should able to call splice for a DataArray
    ? should return itself when key is undefined
    ? should able to watch vm change
    ? should able traversing a array which has some property
    ? should able to watch push method
  class
    ? should able to define & require a hello component
    ? should able to create a child component
    ? should able to set the data of a children component
  custom
    ? should able to create a custom filter
    ? should able to toggle class
    ? should able to set a class
  if
    ? should able to use if directive
  attrbute
    ? should able to set src
    ? should able to set attribute
  on
    ? should able bind event
  repeat
    ? should able repeat
    ? should able push a data
    ? should able splice a data
    ? should able multiple repeat
    ? should not throw a error when repeat element has been modified
    ? should throw a error when a filter hasn‘t implemented
    ? should able to use double repeat
  utils
    ? should find a element
    ? should able to copy a array use slice
    ? should able check contains
    ? should able to set and get data
    ? should able to add & remove event
    ? should able to extend objects
    ? should able to extend from multiple srouces
    ? should able to add & remove class
    ? should able to check a object

Finished in 2.447 secs / 2.318 secs

SUMMARY:
? 78 tests completed

在这个构成中,Karma会根据我们设定的配置,自动在本地启动ChromePhantomJS进行测试。

那么我们为什么选择用Karma来测试呢?

  • 方便集成测试
  • 较为通用的开源解决方案,google出品
  • Q.js 是一个js库,不需要像素级测试,由于是程序员我们也不需要录制测试,我们需要的是静态测试(开发阶段)、以及持续集成测试(集成阶段)
  • 可以根据不同环境,选择不同浏览器进行测试。例如原来我们只能使用PhantomJS进行测试,现在我们可以在集成系统中使用FirefoxPhantomJS进行测试,在本地环境我们还可以ChromeIE进行自动化测试。如果有钱,我们更可以购买Sauce Labs(关键没钱= =)的服务来得到更多浏览器支持。
时间: 2024-10-05 21:38:57

前端测试回顾及我们为什么选择Karma的相关文章

前端测试代码测试

一:前端测试的背景.为什么做测试 1.测试分类 (1).TDD(Test-Driven Development) 测试驱动开发(2).BDD(Behavior Drive Development) 行为驱动开发 它通过用自然语言书写非程序员可读的测试用例扩展了测试驱动开发方法 这让开发者得以把精力集中在代码应该怎么写,而不是技术细节上 - 伪代码(3).DDD(Domain Drive Design) 领域驱动开发 各个层次之间的调用问题 DDD是告诉我们如何做好业务层!并以领域驱动设计思想来选

前端测试框架

一.为什么要进行测试? 一个 bug 被隐藏的时间越长,修复这个 bug 的代价就越大.大量的研究数据指出:最后才修改一个 bug 的代价是在 bug 产生时修改它的代价的10倍.所以要防患于未然. 从语言的角度讲 JavaScript 作为 web 端使用最广泛的编程语言,它是动态语言,缺乏静态类型检查,所以在代码编译期间,很难发现像变量名写错,调用不存在的方法, 赋值或传值的类型错误等错误. 例如下面的例子, 这种类型不符的情况在代码中非常容易发生 function foo(x) { ret

WEB前端测试浏览器兼容性的娃有福了!

今天调试前端的一个js效果,在其它浏览器上都正常,本人的IE11也正常,但是同事的IE8下就不正常,于是楼主只能去找第三方软件了.先用的微软的Microsoft Expression SuperPreview4,但是它只能看静态页面,运行不了JS,于是只能去用IETester(楼主以前用过IETester,不太好用,经常崩溃).在IETester下试了,居然还是正常的,楼主瞬间凌乱了,不只如何下手了,只能再去找度娘了.在一篇帖子中看到一个好办法,真心好啊,楼主以前居然都没发现,贴图如下: 在IE

可视化前端测试

背景 相信进行过前端开发的同学都知道,前端测试不仅仅涉及到功能的测试,而且也需要考虑到界面样式测试.多浏览器兼容性测试.性能测试.本文主要讨论分析目前前端测试的现状,并讨论目前流行的测试工具,下篇文章将会介绍工具的使用方法 前端测试分类 前端测试主要分三大方向测试,而这三大方向也分很多小方向测试,首先简单的介绍每个方向的概念 界面样式测试 固定界面样式测试:主要针对文字内容不变的区域,例如页面的页头,页脚这类结构.内容不变的区域,而测试一般通过截图对比解决. 结构不变界面样式测试:主要针对结构不

前端测试框架Jest系列教程 -- Expect(验证)

写在前面 在编写测试时,我们通常需要检查值是否满足某些条件,Jest中提供的expect允许你访问很多“Matchers”,这些“匹配器”允许您验证不同的东西. Expect 可以验证什么 Jest中提供了如下的验证方法: expect(value) expect.extend(matchers) expect.anything() expect.any(constructor) expect.arrayContaining(array) expect.assertions(number) ex

web前端测试(二)

web前端测试(二)   HTML 语言中,设置表格中文字与边框距离的标签是() * [单选题] * A.<table boder=””> B.<table cellspacing=””> C.<table cellpadding=””>(正确答案) D.<table width=””> 以下说法,错误的是() * [单选题] * A.mark用于显示变粗的文字(正确答案) B.<del>用于显示删除的文本 C.<ins>的文字会带下

现代化前端测试

mu --> 目录 1.现代化前端测试模型2.nodejs的断言模块assert3.单元测试断言库 chai4.mocha--JavaScript test framework5.测试的覆盖率--Istanbul, a JavaScript test coverage tool 1.现代化前端测试模型  <--返回目录 前端测试中有两种模型, 金字塔模型与奖杯模型. 1.1 金字塔模型 金字塔模型摘自 Martin Fowler's blog: 金字塔模型自下而上分为单元测试.集成测试.UI

前端测试 karma mocha should 都是什么鬼?

测试TDD和BDD的区别 TDD是测试驱动开发,通过用测试用例来规范约束开发者,编写出质量更高的代码 BDD是行为驱动开发,描述行为路径,就像描述故事,产品和前线业务人员可参与到开发流程中,减轻测试和开发写测试用例的成本.用通用的语言形式尽可能避免沟通上的障碍,实现产品和开发者同时定义系统的需求. karma  mocha  should  这些都是什么鬼? karma 是驱动测试的runner,可以执行Javascript代码在多个真实的浏览器中测试.并生成测试报告 安装 Karma :  $

前端测试框架学习

做了一年多的前端,从没有认真写过单元测试,对于常说的各种框架并不能彻底的分清,这次做了一个认真的学习与总结. 单元测试框架:Mocha, Jasmine等,因测试框架不包含断言库,因此需要引入断言库,Jasmine带有断言库assertions(未使用过).断言库 assert, shouldjs, chai等,具体的单元测试用例中使用karma是一款自动化测试工具,通过使用配置文件自动检测单元测试文件并进行测试,输出测试结果travis ci 持续集成服务,实现对代码库的代码的检测,编译,发布