人在江湖飘,哪能不挨刀. 我挨了重重一bug.严格来讲这可能是我职业生涯以来的首个悲惨经历,因为凭我的知识储备和经验,基本上任何可重现的bug都是可解的.然而这个bug却困扰了我三个月之久,它具有以下生理特征: 后台日志能统计到异常,偶发.低频 报异常的用户设备不具有规律性,什么手机都有 我们自己无法复现,任何设备.任何环境都没复现 打电话回访报异常的用户,确实存在问题 客服未接到用户主动反馈这个异常 此bug并不是js报错,而是一个业务逻辑的错误.表现是,用户提交的数据莫名缺失.场景是以下这个

写在前面: 随着互联网日新月异的发展,用户对于页面的美观度,流畅度以及各方面的体验有了更高的要求,我们的网页不再是简单的承载文字,图片等简单的信息传递给用户,我们需要的是更加美观的页面展示,更快的浏览速度,更加的丰富的用户交互效果.好的用户体验必要需要优秀的前端技术支撑,这使得我们的前端技术发生了翻天覆地的变化,前端的项目架构也越来越复杂,已经逐渐的演变成重量级的前端.从软件开发的角度来说项目技术的复杂度会带来开发,测试,交付流程等的复杂度的成倍提升,而我们知道测试是整个软件交付流程中非常重要的

写在前面: 匹配器(Matchers)是Jest中非常重要的一个概念,它可以提供很多种方式来让你去验证你所测试的返回值,本文重点介绍几种常用的Matcher,其他的可以通过官网api文档查看. 常用的匹配方式: 第一种:相等匹配,这是我们最常用的匹配规则 test('two plus two is four', () => { expect(2 + 2).toBe(4); }); 在这段代码中 expact(2 + 2) 将返回我们期望的结果,通常情况下我们只需要调用expect就可以,括号中的

写在前面: Jest中定义了很多全局性的Function供我们使用,我们不必再去引用别的包来去实现类似的功能,下面将列举Jest中实现的全局函数. Jest Global Functions afterAll(fn, timeout) 从字面意思就可以理解到它是在所有测试运行完之后才会执行的,如果你的测试中包含promise,则将会等待promise被验证之后被执行. 你还可以提供一个timeout的参数(以毫秒为单位),用于指定在终止前等待的时间.注意:默认的超时是5秒. 如果您想要清理一些跨

前端测试框架对比(js单元测试框架对比) 本文主要目的在于横评业界主流的几款前端框架,顺带说下相关的一些内容. 测试分类 通常应用会有 单元测试(Unit tests) 和 功能测试(Functional tests),复杂大型应用可能会有整合测试(Integration tests). 其中: 单元测试:关注应用中每个零部件的正常运转,防止后续修改影响之前的组件. 功能测试:确保其整体表现符合预期,关注能否让用户正常使用. 整合测试:确保单独运行正常的零部件整合到一起之后依然能正常运行. 详细

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

转自: https://www.cnblogs.com/Wolfmanlq/p/8012847.html 作者:Ken Wang 出处:http://www.cnblogs.com/Wolfmanlq/ 前端测试框架Jest系列教程 -- 简介   系列教程:   1. 前端测试框架Jest系列教程 -- Matchers(匹配器)   2.前端测试框架Jest系列教程 -- Asynchronous(测试异步代码)   3.前端测试框架Jest系列教程 -- Mock Functions(模拟

Web前端测试维度: 功能性:功能准确性.兼容性 易用性:易学性.易理解性.易操作性.吸引性 可靠性:成熟性.容错性.稳定性.可恢复性.安全性 可移植性:适应性.易安装性.兼容性 可维护性:易分析性.易测试性 效率:时间特性.资源利用性 调优点: 1. 减少http请求的数量 2. 用好浏览器缓存机制 3. 利用GZIP压缩机制:只针对文本类资源有效 4. 把CSS文件放在HTML的开头 5. 把JavaScript文件放到HTML的结尾 6. 避免CSS表达式 7. 减少DNS查找:把域名解析

前端测试工具一览 前端测试工具也和前端的框架一样纷繁复杂,其中常见的测试工具,大致可分为测试框架.断言库.测试覆盖率工具等几类.在正式开始本文之前,我们先来大致了解下它们: 测试框架 测试框架的作用是提供一些方便的语法来描述测试用例,以及对用例进行分组.测试框架可分为两种: TDD (测试驱动开发)和 BDD (行为驱动开发)常见的测试框架有 Jasmine, Mocha以及本文要介绍的 Jest. 断言库 断言库主要提供语义化方法,用于对参与测试的值做各种各样的判断.这些语义化方法会返回测试的

互联网人罪状系列 1.上班第一天,前端把后端告上县衙,还列了 5 宗罪 2. 程序员状告产品经理八大罪状 (上) 3.程序员状告产品经理八大罪状(下) 开发人员与测试人员的关系,就如同程序员与产品经理的关系一样,开发没了测试,项目没有办法保质上线,产品经理离了程序员,再牛的产品,也只是纸上谈兵. 所以两者之间,就像鱼跟水,谁能离不开谁,却又相互看对方不爽,这不,公司的开发与测试人员,又吵起来了,这次玩的还有点大,直接对簿公堂了- 本期漫画情节纯属虚构,切勿对号入座 如有雷同,纯属巧合. 这是苏南

前端测试,或者UI测试一直是业界一大难题.最近Q.js使用Karma作为测试任务管理工具,本文在回顾前端测试方案的同时,也分析下为什么Q.js选用Karma而不是其他测试框架. 像素级全站对比 曾今有一批人做过这样的UI测试,即最终页面图像是否符合预期,通过图片差异对比来找出可能的问题. 如图所示,所谓像素级站点对比,即利用截屏图像前后对比来找出,站点前后差异,从而发现问题. Q: 为什么需要这种测试呢? A: CSS容易被破坏,在大型响应式重构案例中,像素级全站对比是一个比较好的测试方案. 目

写在前面: 在JavaScript代码中,异步运行是很常见的.当你有异步运行的代码时,Jest需要知道它测试的代码何时完成,然后才能继续进行另一个测试.Jest提供了几种方法来处理这个问题. 测试异步代码的三种实现方式: 方法一:回调函数 这是非常常见的通用处理方式,比如你有一个fetchData(callback)的function用来获取数据,并且在获取完成的时候调用callback 函数,你想测试返回的数据是“peanut butter” ,默认情况下当fetchData执行完成的时候Je

写在前面: 在写单元测试的时候有一个最重要的步骤就是Mock,我们通常会根据接口来Mock接口的实现,比如你要测试某个class中的某个方法,而这个方法又依赖了外部的一些接口的实现,从单元测试的角度来说我只关心我测试的方法的内部逻辑,我并不关注与当前class本身依赖的实现,所以我们通常会Mock掉依赖接口的返回,因为我们的测试重点在于特定的方法,所以在Jest中同样提供了Mock的功能,本节主要介绍Jest的Mock Function的功能. Jest中的Mock Function Mock

写在前面: 在写单元测试的时候有一个最重要的步骤就是Mock,我们通常会根据接口来Mock接口的实现,比如你要测试某个class中的某个方法,而这个方法又依赖了外部的一些接口的实现,从单元测试的角度来说我只关心我测试的方法的内部逻辑,我并不关注与当前class本身依赖的实现,所以我们通常会Mock掉依赖接口的返回,因为我们的测试重点在于特定的方法,所以在Jest中同样提供了Mock的功能,本节主要介绍Jest的Mock Function的功能. Jest中的Mock Function Mock

第八章 测试执行/报告BUG QQ群交流:585499566 把他们放到一起,是因为报告bug是在执行的过程中同步进行的——即执行用例的过程中一旦发现bug我们需要立即把其报告到我们的bug管理系统redmine中去. 执行测试以前,需要为每个测试计划创建一个build版本,一个测试计划可以创建多个构建——我们可以这样,用每次发布的版本号来标识,表明我们执行测试计划的版本是哪个,并且可以和redmine对应.   当然了,也可以用其他含义的标题,诸如本次测试执行的侧重点什么的. 创建好构建后,将

一.作为测试人员,你应该这样报BUG: 不要对程序员说,你的代码有BUG. 他的第一反应是:1.你的环境有问题吧:2.你踏马到底会不会用? 如果你委婉的说:你这个程序和预期的不一样,你看看是不是我的方法不一样. 他本能的会想:是不是程序出BUG了. 二.和程序员聊BUG是个技术活 1. BUG存在性 测试员在遇到问题,第一反应不要着急确认是否为BUG.追踪分析所遇问题,验证环境配置.实际操作没有错误的前提下,确认BUG并将其提给开发. 2. BUG随机性 在确认BUG存在的情况下, 确认BUG是

质量控制 大多数测试人员认为测试工作是发现bug,虽然这是测试的主要任务,但其实测试最重要的任务是质量控制,而发现bug和验证bug只是质量控制的一个重要环节而已. 我想很多测试人员都经历过这样的场景,就是测试环境全部都能测试通过,但正式上线之后就会有各种各样的bug,到底是哪里出了问题呢?   在测试工作中,常见的问题原因分为以下几类: ●不同版本的数据兼容 这是最常见的问题,一般新版本的迭代不仅仅是代码层面的,还有数据库的改动,而对于线上原有的数据来说改动了数据库有可能会受到影响. 举个例子

质量控制 大多数测试人员认为测试工作是发现bug,虽然这是测试的主要任务,但其实测试最重要的任务是质量控制,而发现bug和验证bug只是质量控制的一个重要环节而已. 我想很多测试人员都经历过这样的场景,就是测试环境全部都能测试通过,但正式上线之后就会有各种各样的bug,到底是哪里出了问题呢? 在测试工作中,常见的问题原因分为以下几类: 不同版本的数据兼容 这是最常见的问题,一般新版本的迭代不仅仅是代码层面的,还有数据库的改动,而对于线上原有的数据来说改动了数据库有可能会受到影响. 举个例子: 如

在web测试过程中,经常会遇到页面中内容或数据显示错误,甚至不显示,第一反应就是BUG,进一步了解这个BUG的问题出在那里,是测试人员需要掌握的,可以简单的使用浏览器自带开发者工具.数据库工具配合去排查. bug定位常用工具 Firefox——firebug.web developer.live http headers.http fox IE插件——httpwatch 第三方工具——fiddler 慢速网模拟工具——firefox throttle 前台错误 前台的bug通常是功能.界面和兼容

相信有很多前端的朋友再布局的时候经常面对IE6咬牙切齿,尤其是刚刚入行的朋友,在这里给大家一点常见问题的解决方案,希望对大家有所帮助 1)png24位的图片在iE6浏览器上出现背景,解决方案是做成PNG8.也可以引用一段脚本处理. 2)IE6双倍边距bug:在该元素中加入display:inline 或 display:block   3)像素问题 使用多个float和注释引起的 使用dislpay:inline -3px     4)超链接hover 点击后失效  使用正确的书写顺序 link

在web测试过程中,经常会遇到页面中内容或数据显示错误,甚至不显示,第一反应就是BUG,没错,确实是BUG.进一步了解这个BUG的问题出在那里,是测试人员需要掌握的,可以简单的使用浏览器自带开发者工具.数据库工具配合去排查. 1.开发者工具的使用 (1)打开开发者工具,在浏览器菜单栏选择工具-开发者工具,快捷键是F12 (2)打开之后切换到Network页签,操作就可以看到请求响应 (3)在选择响应的链接,切换到Preview页签,可以看到响应的结果数据 (4)结果中可以看到数据字段.值 2.可