前端测试之自动化测试 古城微笑少年丶 2022-11-29 03:02 158阅读 0赞 [前端测试之E2E测试][E2E] 前端界, 浏览器兼容性是很头疼的wenti , 对于经验丰富的人来说, 很清楚浏览器有哪些坑, 但是对于大部分砖工, 最可怕的是代码明明在自己浏览器上运行很好, 但是到另一个浏览器就不行了, 因此保障代码能正常运行的方法便是能尽早发现问题然后解决 ## 1. 为什么需要自动化测试? ## 项目迭代趋于稳定, 引入自动化测试能尽早发现问题, 保证产品质量. 测试作为完整的开发流程中最后一环, 而前端测试一般在产品开发流程中属于偏后的环节, 在整个开发架构中属于较高层次, 前端测试更偏向于GUI的特性, 因此前端的测试难度很大. 测试的目的: * 有利于写出高质量代码, 尽早发现问题 * 有利于代码的扩展和维护 ## 2. 前端自动化测试 ## **1. 测试的分类** 黑盒测试: 不知道盒子里的东西, 只输入得到输出, 盒子外部进行测试 白盒测试: 知道盒子的功能代码和逻辑进行测试 灰盒测试: 黑白之间 **2. 前端测试一般分为:** * 单元测试 Unit Testing: 函数级别, 根据代码单元的公共API运行. 需要创建一个类的实例, 使用特定的输入调用它的方法, 断言被调用的方法达到了预期的效果。 * E2E测试:模拟用户行为, 断言浏览器发生特定事情或得到了期待的结果 * 集成测试 Integration Testing **3. 测试工具对比:** 选择框架会考虑下面的点: * 测试框架是否有简明的语法和文档. Mocha, Jasmine, Jest, AVA, Karma, Nightmare * 断言(Assertions): 用于判断结果是否符合预期, 有些框架需要单独的断言库。 should.js, chai, expect.js等等, 断言库提供了很多语义化的方法来对值做各种各样的判断, 当然也可以不用断言库, Node.js中也可以直接使用原生asset库 * 适合TDD/BDD: 是否适合测试驱动型 (Testing Driven Development)/ 行为驱动型的 测试风格 (BDD(Behavior Driven Development)) BDD和TDD均有各自的适用场景, BDD一般更偏向于系统功能和业务逻辑的自动化测试设计, 而TDD在快速开发并测试功能模块的过程中更加高效, 以快速完成开发为目的. > BDD特点: > 系统层面全局统筹 > 从业务逻辑的角度定义具体的输入与预期输出, 以及可衡量的目标 > 尽可能覆盖所有的测试用例情况 > 描述一系列可执行的行为, 根据业务的分析来定义预期输出, 例如, expect, should, assert > 设定关键的测试通过节点输出提示, 便于测试人员理解 > 最大程度的交付出符合用户期望的产品, 避免输出不一致带来的问题 > TDD特点: > 更快开发 > 需求分析, 快速编写对应的输入输出测试脚本 > 实现代码让测试更成功 > 重构, 然后重复测试, 最终让程序符合所有要求 * 异步测试: 是否良好支持异步测试 **4. 单元测试类工具:** mocha, jest,ava, jasmine-core, karma 大型项目选Jest吧, 懒得写了 需要测试快照, 选Jest或者Ava 对于配置型要求高, 对测试框架性能有要求的选mocha 对模拟还原浏览器业务操作有很大的需求的, 可以选nightmare 复杂场景, 可以先写一些测试用例, 覆盖到80%的场景, 保证主要流程。在场景中出现bug的时候可以在迭代中形成测试用例沉淀, 场景覆盖逐渐趋近100% **5. 单元测试类工具:** cypress,nightmare,nightwatch,testcafe 选Cypress吧, 懒得写了 [E2E]: https://blog.csdn.net/m0_48446542/article/details/108084401
还没有评论,来说两句吧...