前端自动化测试

[zzkkui]

前端自动化测试

优点：

• 可以保障项目的可靠性
• 提升开发者编写容易被测试的代码，提高代码质量
• 编写的测试有文档的作用，方便维护
• 提升项目架构思维
• 驱动开发，指导设计

缺点：

• 会导致开发项目周期延长
• 额外的知识结构，额外的学习成本

考虑投入产出比来做测试

编写维护自动化测试用例是很费时间的，所以不代表一上来就写出 100% 场景覆盖的测试用例，要 基于投入产出比来做测试。我们首先可以对基础组件、公共方法之类的不常变更且复用较多的部分，优先考虑变编写测试用例来保障代码质量。其他业务模块的组件及方法，我们可以在提测阶段，或者后期迭代阶段形成测试用例进行沉淀。

黑盒测试和白盒测试

• 黑盒测试一般也被称为功能测试，黑盒测试要求测试人员将程序看作一个整体，不考虑其内部结构和特性，只是按照期望验证程序是否能正常工作
• 白盒测试是基于代码本身的测试，一般指对代码逻辑结构的测试。

单元测试

特点：测试对象的细颗粒度性，即被测对象独立性高、复杂度低。测试覆盖率大

单元测试是指对程序中最小可测试单元进行的测试，例如测试一个函数、一个模块、一个组件。

单元测试混合了编程和测试，由于是对代码内部逻辑进行测试，因此更多的使用白盒的测试方式。

不足：

1. 业务耦合度高
2. 代码量大
3. 过于独立

工具类方法、高复用组件等适合使用单元测试，业务组件因为单元组件和业务耦合度很高，组件业务逻辑修改，测试用例就要修改（不确定性修改多），不太适用单元测试

集成测试

将已测试过的单元测试函数进行组合集成暴露出的高层函数或类的封装，对这些函数或类进行的测试。（多个模块测试）

项目业务逻辑（业务组件）等适合使用继承测试，业务耦合度高，单元测试安全性不够高，需要对整个业务逻辑（用户使用场景）的一个模拟，需要集成测试来完成业务逻辑的测试

端到端测试

打开应用程序模拟输入，检查功能以及界面是否正确

TDD & BDD

TDD

测试驱动开发

流程

1. 先编写测试用例，然后运行
2. 编写代码，使之前的测试用例通过测试
3. 优化代码，完成开发

优势

1. 长期减少回归 bug
2. 代码质量更好（组织，可维护性）
3. 测试覆盖率高
4. 错误的测试代码不容易出现

特点

1. 先写测试再写代码
2. 一般结合单元测试使用，是白盒测试
3. 测试重点是代码（数据）
4. 安全感低（没法保证整个项目工程是通过的）
5. 速度快
6. 测试覆盖率高

BDD

行为驱动开发

流程

1. 先写代码再写测试
2. 使测试用例通过
3. 优化代码，完成开发

特点

1. 先写代码再写测试
2. 一般结合集成测试使用，是黑盒测试
3. 测试重点是UI（DOM）
4. 安全感高
5. 速度慢
6. 测试覆盖率低

e2e

端到端测试

测试工具

Jest

Jest 用法

Mocha

Mocha 用法（待）

测试运行环境分类

基于JSDOM

优点：快，执行速度最快，因为不需要浏览器启动

缺点：无法测试如seesion或cookie等相关操作，并且由于不是真实浏览器环境因此无法保证一些如Dom相关和BOM相关的操作的正确性，并且JSDOM未实现localStorage，如果需要进行覆盖，只能使用第三方库如node-localStorage （这个库本身对与执行环境的判断有一些问题）进行模拟。

基于 PhantomJs 等无头浏览器

优点：相对较快，并且具有真实的DOM环境

缺点: 同样不在真实浏览器中运行，难以调试

使用Karma等工具，调用真实的浏览器环境进行测试

优点：配置简单，能在真实的浏览器中运行测试，并且karma能将测试代码在多个浏览器中运行,同时方便调试

缺点: 唯一的缺点就是相对前两者运行稍慢，但是在单元测试可接受范围内