自动化测试
# 自动化测试
# 自动化测试有没有了解过? 自动化测试有什么好处?
# 自动化测试的流程
输入 - 断言 - 验证
不管是单测还是 E2E 都可以遵循这个原则,如果不知道如何开始,可以考虑我们的预期结果是什么,以终为始,再去慢慢实现函数或组件的具体功能,这就是 TDD 的一种模式
自动化这种方案基本上能做到不漏测一个功能,而且不需要我们手动去输入数据和点击页面去验证了,提升了代码的质量
人工测试:通过开发人员或测试人员与程序的交互来完成,即手动操作验证。
自动化测试:通过自动化脚本与程序的交互来完成,除了刚开始编写的自动化脚本时间,基本上无需手动操作
# 自动化测试解决了什么问题?
- 解决了耗时时间和人力成本
 
# 自动化测试的应用场景
- 白盒测试:说白了就是代码的逻辑是否正确,流程逻辑,函数调用,异常处理等等,比如常见的单元测试。
 - 黑盒测试:主要是对一个功能的验证,不关心代码的具体实现,比如端到端测试(E2E,也是集成测试的一种类别)
 
# 单元测试
一般是对程序最小单元运行测试的过程
- 单元测试的场景
- 组件的单元测试:UI 组件、无状态组件、基础组件
 - 纯函数的单元测试
 - 我们可能会封装一些 util 工具等等,但是要保证我们写的函数是易于测试的,即没有副作用,函数的输入和输出是稳定的
 
 
# 优点
- 测试速度很快。
 - 代码覆盖率较高。
 - 有助于模块的设计。
 - 易于代码维护
 
# 缺点
- 无法验证多个单元运行到一起是否正确,能做到这一点的是我们要介绍的集成测试。
 
# 集成测试/端到端测试(E2E)
集成测试是把不同的模块集成在一起,来测试模块与模块之前的配合是否正常工作。
在前端我们点击一个按钮会进行表单提交,而这涉及到按钮的点击事件是否正常,表单的校验或者发送请求是否正常触发。
而 E2E的定义和集成测试是差不多的,它们通常都是站在用户视角并且以真正的运行环境来测试整个流程和功能的。集成测试和端到端的定义的边界是较模糊的,所以我们可以放在一起介绍。下面是一个用户使用某个系统的简单场景
- 访问某个系统主页
 - 点击某个元素,然后进入另外一个页面
 
那么它的测试代码可以这么写(以 Cypress 为例):
describe('My First Test', () => {
  it('clicking "type" navigates to a new url', () => {
    // 1.访问 https://example.cypress.io -> 模拟用户输入 URL
    cy.visit('https://example.cypress.io')
    // 2.点击某个元素 -> 模拟用户点击
    cy.contains('type').click()
    // 3.跳转新页面的断言
    // includes '/commands/actions'
    cy.url().should('include', '/commands/actions')
  })
})
 1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
# 测试模式
- TDD(测试驱动开发):测试驱动开发,先写测试后实现功能
 - BDD(行为驱动开发):行为驱动开发,先实现功能后写测试
 
# TDD开发流程
- 编写测试用例
 - 运行测试
 - 编码使测试用例通过
 - 重构/优化代码
 - 新增功能,重复流程
 
# TDD优点
- 功能代码未动,测试先行,能够用 “以终为始” 的开发思路来保证代码的质量。
 - 可以促进开发人员去思考模块设计和重构代码。
 - 测试的覆盖率较高,因为编写的代码需要按照测试的用例去跑,基本上每个用例都要考虑到
 
# TDD缺点
- 测试代码量增多,比如 Vue 2.x 中 的 keep-alive 源码实现只有 100 多行,而单元测试代码有 800 多行
 - 当代码调整时,测试代码也要调整,比如函数加了参数,函数里面加了 if 语句(这说明代码的设计不好)
 - 最终做出来的东西和实际功能需求可能相偏离。
 
# BDD开发流程
- 需求确认(一般是从 PM 那获取需求)
 - 以自动化的方式将需求建立起来(比如将需求录入某个迭代系统)。
 - 实现每个文档示例描述的行为,并从自动化测试开始以指导代码的开发。
 - 特点
- 解决 TDD 模式下开发和实际功能需求不一致而诞生。
 - 不需要面向细节设计测试,而是面向行为测试。
 - 从产品的角度出发,鼓励开发与非开发人员之间的协作。
 - 注重功能测试,所以 BDD 更多结合的是集成测试,是黑盒的。
 
 
# BDD优点
- 由于侧重于需求功能的完整度,所以能给开发人员增加更多对程序的信心。
 - 由于仅关注功能,不关注实现细节,有利于测试代码和实际代码解耦。
 - 由于大多数为编写集成测试,相比 TDD 有更好的开发效率。
 
# BDD缺点
- 以功能性的集成测试为主,因此不是那么关注每个函数功能,测试覆盖率比较低。
 - 没有 TDD 那么严格的保证代码质量。