前端测试之自动化测试

古城微笑少年丶 2022-11-29 03:02 218阅读 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