草庐IT

WEB自动化-03-Cypress 测试框架概述

Surpassme 2023-03-28 原文

3 Cypress 测试框架概述

3.1 Cypress 默认文件结构

    在Cypress安装完成后,其生成的默认文件目录如下所示:

3.1.1 Fixtures

    Fixture又称之为测试夹具,通常配合cy.fixture命令使用,主要用于存储测试用例的外部静态数据。其默认位置位于cypress\fixtures中,也可以根据需要配置到其他目录。 Fixtures里面的静态数据通常存储在json文件中,而这部分数据通常是某个网络请求对应的响应部分,如HTTP状态码和返回值等。Fixture的应用场景通常为,当测试需要对某些外部接口进行访问并依赖于其返回值时,可以使用fixture而无需访问这些接口。

3.1.2 测试文件

    测试文件就是对应的测试用例,一般位于cypress\integration中,也可以根据需要配置到另一个目录中,通常为js文件,在Cypress中其他命令格式为:fileName.spec.js,支持的文件类型如下所示:

  • .js
  • .jsx
  • .coffee
  • .cjsx

3.1.3 Plugins

    在Cypress中,测试代码是运行浏览器里面,提供了更加可靠的测试体验,但也存在明显的缺点,使得与浏览器之外进行通信更加困难。为解决这个问题,Cypress提供了一些插件,可以修改或扩展Cypress的内部行为。插件一般位于cypress\plugins,在每个测试文件运行之前,Cypress会自动加载该目录中的index.js文件。

3.1.4 Support

    支持文件一般位于目录cypress\support中,可以根据需要放置在其他目录中,其主要功能是放置可复用配置项,如底层通用方法、全局默认配置等。在每个测试文件运行前,Cypress会自动加载该目录中的index.js文件。

    使用方法也非常简单,仅需要在cypress\support\index.js文件中添加beforeEach()函数即可。示例如下所示:

beforeEach( function (){
  cy.log(`Current Enviroment is ${JSON.stringfy(Cypress.env())}`)
 }
)

3.2 核心概念

3.2.1 核心参数配置

    在第一次打开Cypress Test Runner后,cypress.json将会创建,目录与Cypress同级。该文件主要用于保存所有支持的自定义配置,在配置了录制和测试项目后,则projectId将会被保存至cypress.json文件中。

用户可以通过参数来定义所使用的配置文件,参数为--config-file

3.2.1.1 全局配置项

    以下为Cypress支持的常用自定义的全局配置及其默认值,如下所示:

配置项 默认值 描述
baseUrl null URL前缀,通常与命令cy.visit()/cy.request()结合使用
clientCertificates [] 客户端证书选项数组
env {} 环境变量设置选项,任何支持的值均可
numTestsKeptInMemory 50 在内存中保存的快照和命令数据等数量,在运行测试时,若内存占用太高,可以减少该值
port null Cypress使用的端口号,默认随机产生
redirectionLimit 20 在出现错误前,允许应用程序在测试运行时重定向的数量
reporter spec 在Cypress运行时使用的的reporter
reporterOptions null reporter支持的配置选项
watchForFileChanges true 用于监测文件变化,若有变化,则自动重新运行该用例

3.2.1.2 超时

    超时是Cypress中的核心概念,所以必须了解,常见的超时参数如下所示:

配置项 默认值 描述
defaultCommandTimeout 4000 命令默认超时时间,单位为ms
execTimeout 60000 在cy.exec()执行期间,等待系统命令完成执行的超时时间,单位为ms
taskTimeout 60000 在cy.task()执行期间,等待任务完成执行的超时时间,单位为ms
pageLoadTimeout 60000 在等待页面加载或cy.visit()/cy.go()/cy.reload()等命令触发其他页面加载事件的超时时间,单位为ms,网络请求受限于操作系统
requestTimeout 5000 在执行cy.wait()命令时,请求超时时间,单位为ms
responseTimeout 30000 在执行命令cy.request()/cy.wait()/cy.fixture()/cy.getCookie()/cy.getCookies()/cy.setCookie()/ cy.clearCookie()/ cy.clearCookies/cy.screenshot()时的响应超时时间,单位为ms
slowTestThreshold 10000 | 250 在Cypress run期间,运行较慢的测试用例在reporter中将会以桔黄色显示,通过该参数可进行单独设置E2E和组件测试超时时间,E2E默认超时时间为 10000ms,而组件测试为250ms,单位为ms

3.2.1.3 目录和文件

    Cypress支持自定义目录和文件,如下所示:

配置项 默认值 描述
downloadsFolder cypress/downloads 在测试期间,默认的文件下载目录
fileServerFolder root project folder 向服务器发送的应用程序文件目录
fixturesFolder cypress/fixtures fixture默认目录,可更改默认值为false来禁用
ignoreTestFiles *.hot-update.js 在运行期间,需要忽略的测试用例
integrationFolder cypress/integration 测试用例所在目录
pluginsFile cypress/plugins/index.js Plugins所在目录,可更改默认值为false来禁用
screenshotsFolder cypress/screenshots 在测试用例运行失败或cy.screenshot()命令触发截图,用于保存这些截图的目录
supportFile cypress/support/index.js 在测试加载之前要加载的文件
testFiles **/. 要加载的测试文件
videosFolder cypress/videos 在Cypress run运行期间,用于保存video的目录

3.2.1.4 截图

配置项 默认值 描述
screenshotOnRunFailure true 测试用例运行失败后将进行截图
screenshotsFolder cypress/screenshots 在测试用例运行失败或cy.screenshot()命令触发截图,用于保存这些截图的目录

3.2.1.5 视频

配置项 默认值 描述
videoCompression 32 设置视频的压缩比,设置为false关闭压缩或0~51,数字越低,视频质量越好,文件越大
videosFolder cypress/videos 在Cypress run运行期间,用于保存video的目录
video true 是否启用视频功能
videoUploadOnPasses true 是否启用在用例运行通过后,上传视频至Dashboard,仅适用于录制项目,如果关闭该功能,则仅上传运行失败的视频

3.2.1.6 视图

配置项 默认值 描述
viewportHeight 660 测试视图下待测试应用程序的默认高度,单位为pixels,可使用cy.viewport()命令覆盖
viewportWidth 1000 测试视图下待测试应用程序的默认宽度,单位为pixels,可使用cy.viewport()命令覆盖

更多自定义选项,可查阅官方文档,地址为:https://docs.cypress.io/guides/references/configuration

3.2.1.7 命令行

    除了使用配置文件进行配置以外,也可以使用命令行进行设置以下各个参数,如下所示:

cypress open --config pageLoadTimeout=30000,baseUrl=https://www.surpass.com
cypress run --config integrationFolder=tests,videoUploadOnPasses=false

3.2.1.8 Cypress.config()

    除了直接在cypress.json文件中更改配置之外,也可以通过Cypress.config()去获取或覆盖某些配置项。其基本使用方法如下所示:

// 获取所有config信息
Cypress.config()
// 获取指定config信息
Cypress.config(name)
// 更改指定config信息
Cypress.config(name,value)
// 设置多个config项
Cypress.config(object)

    示例代码如下所示:

describe("测试Cypress.config",function(){
   it("获取defaultCommandTimeout",function(){
       cy.log(`defaultCommandTimeout value is:${Cypress.config("defaultCommandTimeout")}`)
       // 设置参数选项值
       Cypress.config("defaultCommandTimeout",99999)
       cy.log(`defaultCommandTimeout value is:${Cypress.config("defaultCommandTimeout")}`)
   })
})

    运行结果如下所示:

3.2.2 用例结构

    Cypress是建立在MochaChai之上,因此同时支持Chai的BDDTDD两种风格。如果你熟悉JavaScript风格的代码,那么在Cypress中写测试用例是很容易上手的。

Mocha是一款适用于Node.js和浏览器的测试框架,可使用异步测试变得简单灵活。

    Cypress的测试风格继承于Mocha,提供了describe()context()it()specify()四个关键字,对于一条可执行的测试而言,必须包含以下两个组成部分:

  • describe()context()等效,均表示一个测试套件或测试集
  • it()specify()等效,均表示一个测试用例

    示例如下所示:

describe('我是一个测试集', () => {
    it('测试用例-1', () => {
        expect(1+2).to.eq(3)
    });
    it('测试用例-2', () => {
        expect(3-2).to.eq(1)
    });
    it('测试用例-3', () => {
        expect(3*2).to.eq(5)
    });
});

    最终的运行结果如下所示:

更多测试用例的组织和编写会在后续详细讲解

3.2.3 重试机制

    重试是Cypress一个非常重要的功能,在了解重试的概念后,有助于写出更加健壮的测试。

3.2.3.1 命令和断言

    命令断言是两种在Cypress中测试常用的两种方法,示例如下所示:

/// <reference types="cypress" />

describe('', () => {
    let baseUrl="https://example.cypress.io/todo"
    it('测试用例-1', () => {
        // 一个命令 visit
       cy.visit(baseUrl);
       // 一个命令 get,一个断言 should
       cy.get(".header input").should("have.class","new-todo");
       // 三个命令 get 和 type
       cy.get('.new-todo').type('todo A{enter}').type('todo B{enter}');
        // 一个命令 get,一个断言 should
       cy.get('.todo-list li').should('have.length', 4);
    });

});

    最终的运行结果如下所示:

    让我们一起来看看最后一行的命令和断言,如下所示:

 cy.get('.todo-list li').should('have.length', 4);

    以上命令和断言,是通过cy.get()命令查找页面的DOM,在找到与选择器匹配的元素,然后进行断言尝试,而现在很多WEB应用几乎都是异步的。以最后一行代码为例,Cypress不能在查询DOM元素(todo-list)的同时又去检查其元素个数是否为4个。因此在出现以下情况,就会出现问题,如下所示:

  • 1.当运行命令或断言时,应用程序没有更新DOM时,怎么办?
  • 2.当运行命令或断言时,应用程序正在等待后端返回响应,而页面暂时没有结果时,怎么办?
  • 3.当运行命令或断言时,应用程序正在进行密集计算,而导致页面显示未及时更新时,怎么办?

    以上几种情况,在测试过程中非常常见,一般处理办法在断言前,设置一个等待时间,但这个等待时间,在不同环境中还不能完全统一,还是会导致经常出错。而Cypress处理这种问题,则非常智能,如下所示:

在实际运行时,如果cy.get()命令之后的断言通过,则认为该命令成功执行。如果失败,则cy.get()命令将重新查询应用程序的DOM,再进行断言。如果失败,则再次执行cy.get()命令查询DOM,再进行断言。依此类推,直至断言成功或cy.get()命令超时为止。

    正是因为Cypress的这种自动重试功能避免了在测试代码中出现硬编码的等待。使测试代码更加健壮。

3.2.3.2 多重断言

    在日常测试中,有时候需要对一个数据进行多次断言,Cypress提供一种方法叫多重断言,其定义为:单个命令后跟多个断言。在断言时,Cypress将按顺序重试每个命令,即当第一个断言通过后,在进行第二个断言时仍会重试第一个断言。当第一和第二个断言都通过后,在进行第三个断言,仍然会重试第一和第二个断言,依此类推。来看看以下示例:

/// <reference types="cypress" />

describe('多重断言示例', () => {
    let baseUrl="https://example.cypress.io/todo";
    it('演示用例-1', () => {
        cy.visit(baseUrl);
        cy.get('.new-todo').type('todo A{enter}').type('todo B{enter}');
        cy.get('.todo-list li')
        .should('have.length',4)
        .and(($li) => {
            expect($li.get(2).textContent,'first item').to.equal('todo A')
            expect($li.get(3).textContent,'second item').to.equal('todo B')
           });
    });
});

.and()断言是.should()的别名,它是.should()的自定义回调函数,包含两个expect()断言。

    最终的运行结果如下所示:

    上面代码共有三个断言,分别是should和两个expect。在测试过程中,如果第二个断言失败了,则第三个断言不会执行,如果第二个断言执行通过,整个命令还未超时,在执行第三个断言前,会再次重试第一个和第二个断言。

    修改代码使得第二个断言出现失败,代码如下所示:

/// <reference types="cypress" />

describe('多重断言示例', () => {
    let baseUrl="https://example.cypress.io/todo";
    it('演示用例-1', () => {
        cy.visit(baseUrl);
        cy.get('.new-todo').type('todo A{enter}').type('todo B{enter}');
        cy.get('.todo-list li')
        .should('have.length',4)
        .and(($li) => {
            expect($li.get(2).textContent,'first item').to.equal('toda A')
            expect($li.get(3).textContent,'second item').to.equal('todo B')
           });
    });
});

    在第二个断言运行失败后,第三个断言则不会被执行。在执行命令超时后,会在运行页面显示第一个断言执行成功,第二个断言执行失败,如下图所示:

3.2.3.3 重试条件

    Cypress并不会重试所有命令。当命令可能改变待测应用程序的状态时,则将不会进行重试操作(例如.click()命令)。Cypress仅会重试查询DOM的命令,例如cy.get()、.find()、.contains()等等。

如果需要查询更多重试的命令,可查阅API文档中Assertions文档https://docs.cypress.io/guides/references/assertions

    重试的超时时间默认为4s,也可通过defaultCommandTimeout进行设置。

3.2.3.3.1 增加超时时间

    我们也可以通过修改所有命令的超时时间,例如,将全局的默认超时时间设置为10s,如下所示:

cypress run --config defaultCommandTimeout=10000

    以上这种方式可以修改全局的超时时间,但不推荐。相反,我们可以通过设置单个命令的超时时间{ timeout: ms },而更加灵活的控制各个命令的超时时间,示例如下所示:

/// <reference types="cypress" />

describe('多重断言示例', () => {
    let baseUrl="https://example.cypress.io/todo";
    it('演示用例-1', () => {
        cy.visit(baseUrl,{timeout:1000});
        cy.get('.new-todo').type('todo A{enter}').type('todo B{enter}');
        cy.get('.todo-list li')
        .should('have.length',4)
        .and(($li) => {
            expect($li.get(2).textContent,'first item').to.equal('toda A')
            expect($li.get(3).textContent,'second item').to.equal('todo B')
           });
    });
});

    以上代码,设置访问网站的超时时间为1s,运行结果如下所示:

3.2.3.3.2 禁用重试

    如果将超时时间设置为0,其本质上是禁用重试机制,示例如下所示:

cy.get('.new-todo',,{timeout:0}).type('todo A{enter}').type('todo B{enter}');

原文地址:https://www.jianshu.com/p/55819e173a5d

本文同步在微信订阅号上发布,如各位小伙伴们喜欢我的文章,也可以关注我的微信订阅号:woaitest,或扫描下面的二维码添加关注:

有关WEB自动化-03-Cypress 测试框架概述的更多相关文章

  1. ruby-on-rails - 使用 Ruby on Rails 进行自动化测试 - 最佳实践 - 2

    很好奇,就使用ruby​​onrails自动化单元测试而言,你们正在做什么?您是否创建了一个脚本来在cron中运行rake作业并将结果邮寄给您?git中的预提交Hook?只是手动调用?我完全理解测试,但想知道在错误发生之前捕获错误的最佳实践是什么。让我们理所当然地认为测试本身是完美无缺的,并且可以正常工作。下一步是什么以确保他们在正确的时间将可能有害的结果传达给您? 最佳答案 不确定您到底想听什么,但是有几个级别的自动代码库控制:在处理某项功能时,您可以使用类似autotest的内容获得关于哪些有效,哪些无效的即时反馈。要确保您的提

  2. ruby - 使用 C 扩展开发 ruby​​gem 时,如何使用 Rspec 在本地进行测试? - 2

    我正在编写一个包含C扩展的gem。通常当我写一个gem时,我会遵循TDD的过程,我会写一个失败的规范,然后处理代码直到它通过,等等......在“ext/mygem/mygem.c”中我的C扩展和在gemspec的“扩展”中配置的有效extconf.rb,如何运行我的规范并仍然加载我的C扩展?当我更改C代码时,我需要采取哪些步骤来重新编译代码?这可能是个愚蠢的问题,但是从我的gem的开发源代码树中输入“bundleinstall”不会构建任何native扩展。当我手动运行rubyext/mygem/extconf.rb时,我确实得到了一个Makefile(在整个项目的根目录中),然后当

  3. ruby - Ruby 的 Hash 在比较键时使用哪种相等性测试? - 2

    我有一个围绕一些对象的包装类,我想将这些对象用作散列中的键。包装对象和解包装对象应映射到相同的键。一个简单的例子是这样的:classAattr_reader:xdefinitialize(inner)@inner=innerenddefx;@inner.x;enddef==(other)@inner.x==other.xendenda=A.new(o)#oisjustanyobjectthatallowso.xb=A.new(o)h={a=>5}ph[a]#5ph[b]#nil,shouldbe5ph[o]#nil,shouldbe5我试过==、===、eq?并散列所有无济于事。

  4. ruby - RSpec - 使用测试替身作为 block 参数 - 2

    我有一些Ruby代码,如下所示:Something.createdo|x|x.foo=barend我想编写一个测试,它使用double代替block参数x,这样我就可以调用:x_double.should_receive(:foo).with("whatever").这可能吗? 最佳答案 specify'something'dox=doublex.should_receive(:foo=).with("whatever")Something.should_receive(:create).and_yield(x)#callthere

  5. ruby - Sinatra:运行 rspec 测试时记录噪音 - 2

    Sinatra新手;我正在运行一些rspec测试,但在日志中收到了一堆不需要的噪音。如何消除日志中过多的噪音?我仔细检查了环境是否设置为:test,这意味着记录器级别应设置为WARN而不是DEBUG。spec_helper:require"./app"require"sinatra"require"rspec"require"rack/test"require"database_cleaner"require"factory_girl"set:environment,:testFactoryGirl.definition_file_paths=%w{./factories./test/

  6. ruby-on-rails - 迷你测试错误 : "NameError: uninitialized constant" - 2

    我遵循MichaelHartl的“RubyonRails教程:学习Web开发”,并创建了检查用户名和电子邮件长度有效性的测试(名称最多50个字符,电子邮件最多255个字符)。test/helpers/application_helper_test.rb的内容是:require'test_helper'classApplicationHelperTest在运行bundleexecraketest时,所有测试都通过了,但我看到以下消息在最后被标记为错误:ERROR["test_full_title_helper",ApplicationHelperTest,1.820016791]test

  7. ruby - RuntimeError(自动加载常量 Apps 多线程时检测到循环依赖 - 2

    我收到这个错误:RuntimeError(自动加载常量Apps时检测到循环依赖当我使用多线程时。下面是我的代码。为什么会这样?我尝试多线程的原因是因为我正在编写一个HTML抓取应用程序。对Nokogiri::HTML(open())的调用是一个同步阻塞调用,需要1秒才能返回,我有100,000多个页面要访问,所以我试图运行多个线程来解决这个问题。有更好的方法吗?classToolsController0)app.website=array.join(',')putsapp.websiteelseapp.website="NONE"endapp.saveapps=Apps.order("

  8. ruby - 即使失败也继续进行多主机测试 - 2

    我已经构建了一些serverspec代码来在多个主机上运行一组测试。问题是当任何测试失败时,测试会在当前主机停止。即使测试失败,我也希望它继续在所有主机上运行。Rakefile:namespace:specdotask:all=>hosts.map{|h|'spec:'+h.split('.')[0]}hosts.eachdo|host|begindesc"Runserverspecto#{host}"RSpec::Core::RakeTask.new(host)do|t|ENV['TARGET_HOST']=hostt.pattern="spec/cfengine3/*_spec.r

  9. ruby-on-rails - 如何使辅助方法在 Rails 集成测试中可用? - 2

    我在app/helpers/sessions_helper.rb中有一个帮助程序文件,其中包含一个方法my_preference,它返回当前登录用户的首选项。我想在集成测试中访问该方法。例如,这样我就可以在测试中使用getuser_path(my_preference)。在其他帖子中,我读到这可以通过在测试文件中包含requiresessions_helper来实现,但我仍然收到错误NameError:undefinedlocalvariableormethod'my_preference'.我做错了什么?require'test_helper'require'sessions_hel

  10. ruby-on-rails - Cucumber 是否只是 rspec 的包装器以帮助将测试组织成功能? - 2

    只是想确保我理解了事情。据我目前收集到的信息,Cucumber只是一个“包装器”,或者是一种通过将事物分类为功能和步骤来组织测试的好方法,其中实际的单元测试处于步骤阶段。它允许您根据事物的工作方式组织您的测试。对吗? 最佳答案 有点。它是一种组织测试的方式,但不仅如此。它的行为就像最初的Rails集成测试一样,但更易于使用。这里最大的好处是您的session在整个Scenario中保持透明。关于Cucumber的另一件事是您(应该)从使用您的代码的浏览器或客户端的角度进行测试。如果您愿意,您可以使用步骤来构建对象和设置状态,但通常您

随机推荐