前端测试之自动化测试

前端测试之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吧, 懒得写了