此篇博客是Cypress框架部分的最后一篇。首先，会回顾cypress框架特点，接着会介绍cypress框架的局限性，通过这些信息让大家更好的选择适合项目的测试框架。为了完成此次课程目标拆分了2个task。
- 回顾Cypress框架特点
- 使用Cypress框架时的局限性
回顾Cypress框架特点
通过前面的博客，可以发现如果选用Cypress框架，调试脚本即高效又方便。另外，框架内置的自动等待算法让定位和操作页面元素成功率非常高，基本无需用户增加额外的等待处理语句。调用接口或者查询数据库准备测试数据方面也支持的很好。故如果被测应用只需测试chrome或者firfox浏览器，那么Cypress是一个不错的选择。
上面重点列举了Cypress框架的突出优势，那么此框架有局限性么？当然有，比如不支持IE浏览器就是局限性之一，下面让我们看看如果选用Cypress框架还会存在哪些局限性。
使用Cypress框架时的局限性
- 1.不支持浏览器多个Tab页面间操作，即便提供了workround方式，但有局限性，前面章节专门做过介绍，这里不再重复说明。
- 2.不支持同时操作多个浏览器，例如打开了两个chrome浏览器，并发执行测试案例。此局限性影响不大，因为可以通过在CICD平台上配置多条流水线并发运行测试案例，缩短反馈时间。例如jenkins上配置多个job并发运行自动化案例。
- 3.同一个测试用例中不支持跨域操作，如果被测应用中存在大量点击某个连接或者按钮后会跳转到新的域页面，那么需要考虑是否选择该框架。
- 4.不支持hover操作。对于hover操作，官网提供了三种workaround方式：通过trigger('mouseEvent')模拟hover操作；通过click({froce:true})跳过校验直接点击目标元素；将需要hover才能显示的目标元素调用invoke('show')方法强行显示后再进行点击。下面是使用第一种和第三种workaround方式模拟hover操作的脚本。Test Runner上选择“hover_spec.js”即可运行下面的脚本。
describe("hover demo", () => {
it("should click successfully", () => {
Cypress.on('uncaught:exception', (err, runnable) => {
return false
});
cy.visit('https://chercher.tech/practice/popups');
cy.get('a[href="https://google.com"]').click({force: true})
//跳过校验点击需要hover操作后才显示的跳转菜单
})
it.only("should hover successfully", () => {
Cypress.on('uncaught:exception', (err, runnable) => {
return false
});
cy.visit('https://chercher.tech/practice/popups');
cy.get('#sub-menu').focus();
['mouseover', 'mouseout', 'mouseenter', 'mouseleave'].forEach((event) => {
cy.get('#sub-menu').trigger(`${event}`)
//模拟hover操作，但发现未生效
});
cy.wait(3000);
cy.get('a[href="https://google.com"]').click()
//因为前面hover操作未生效，故点击此元素时会失败，提示目标元素不是visible状态
});
});执行脚本发现，第一个测试脚本通过强制点击方式确实能点击到目标元素，但第一种方式无法check hover操作本身。第二个脚本通过调用trigger(eventname)方式模拟hover操作，但未生效，即页面上没有真正进行hover操作。执行结果如下图所示。总结而言，Cypress框架目前对hover操作支持有限，但官网上有说明未来会支持hover操作。
虽然Cypress框架有一些局限性，但相比后面介绍的Puppeteer框架和TestCafe框架，Cypress框架的明显优势是提供了Test Runner，通过Test Runner可快速修复失败的案例。提升了调试效率，就等于极大程度降低了自动化脚本维护成本。故如果被测应用中只有极少量的多tab页间切换场景或者跨域访问业务场景，那么是可以考虑牺牲掉自动化测试覆盖率的。即选用Cypress框架，少量场景不添加到UI层自动化案例中，从而避免遇到框架不支持的测试场景。
