RoleTang's Blog

测试基础

7/10/2022

# 测试基础概念

什么是应用程序测试？简单的说就是检查程序在运行过程中是否正确。

# 手动测试

编码完成后开发人员自己进行手动的检查它，包括逻辑性和正确性。 但是它

  • 不适合大型项目
  • 容易忽略测试某些功能
  • 大部分时间在做回归测试（即对之前的功能做测试）

# 自动化测试

利用程序检查软件是否正常运行，及是利用额外的代码检查被测试的软件、程序。 可使用许多种不同的方法来编写自动化测试脚本。

  • 可以编写通过浏览器自动执行的程序
  • 可以直接调用源代码里的函数
  • 也可以直接对比程序渲染之后的截图

总之，它更快，覆盖率能够做到更高，能够快速反馈，促进重构。但是也不同保证一个程序是真正完全正确的。

# 单元测试

验证独立的单元是否正常工作

单元测试是对应用程序最小的部分（单元)运行测试的过程。通常，测试的单元是函数，但在前端应用中，组件也是被测单元。 单元测试可以单独调用源代码中的函数并断言其行为是否正确。

image-20220708140506991

但同时由于单元测试是独立的，也无法保证多个独立的模块在一起是否能正确工作。

# 集成测试

验证多个单元协同工作

集成测试简单来说就是测试多个单元或者组件一起时候能否正常工作。

优点∶

  • 由于是从用户使用角度出发，更容易获得软件使用过程中的正确性

  • 集成测试相对于写了软件的说明文档

  • 由于不关注底层代码实现细节，所以更有利于快速重构

  • 相比单元测试，集成测试的开发速度要更快一些

缺点：

  • 难以定位出错位置及原因
  • 代码覆盖率较低

# 端到端测试

从用户角度以机器的方式在真实浏览器环境验证应用交互

E2E(end to end）端到端测试是最直观可以理解的测试类型。在前端应用程序中，端到端测试可以从用户的视角通过浏览器自动检查应用程序是否正常工作。

端到端测试的重点是多页面的应用表现，针对你的应用在生产环境下进行网络请求。他们通常需要建立一个数据库或其他形式的后端，甚至可能针对一个预备上线的环境运行。

端到端测试通常会捕捉到路由、状态管理库、顶级组件（常见为 App 或 Layout）、公共资源或任何请求处理方面的问题。如上所述，它们可以捕捉到单元测试或组件测试无法捕捉的关键问题。

# 快照测试

验证程序的 UI 变化

在程序稳定时候保证UI界面不发生变化。是将你的程序代码作为字符串写进一个文件中。下一次快照测试的时候就会将其进行比较，测试是否有不同。流行的组件库常用。

如果你是开发组件库，建议写更多的单元测试、为每个组件编写快照测试、写少量的集成测试＋端到端测试

# 测试开发方式

TDD:测试驱动开发，先写测试后实现功能

BDD:行为驱动开发,先实现功能后写测试

# TDD

TDD (Test-driven development)，测试驱动开发，是敏捷开发中的一项核心实践和技术，也是一种软件设计方法论。

  • 它的原理就是在编写代码之前先编写测试用例，由测试来决定我们的代码;
  • 而且TDD更多的需要编写独立的测试用例，比如只测试一个组件的某个功能点，某个工具函数等;

大致流程

image-20220708145926119

  • 编写测试用例
  • 运行测试
  • 编写代码使测试通过
  • 重构/优化代码
  • 新增功能,重复上述步骤

TDD的模式适合于对系统代码质量和测试覆盖率有要求的开发主体，比如函数和组件库。但通常在代码发生变化的时候，测试用例也要进行相应的调整。

它的缺点是

  • 代码量增多，大多数情况下测试代码是功能代码的两倍甚至更多；
  • 业务耦合度高，测试用例中使用了业务中一些模拟的数据，当业务代码变更的时候，要去重新组织测试用例；
  • 关注点过于独立，由于单元测试只关注这一个单元的健康状况，无法保证多个单元组成的整体是否正常；

# BDD

BDD (Behaviour-driven development)。测试用例模拟用户的操作行为，通常在完成业务代码开发之后，以用户的操作为指导编写测试代码。当测试用例跑通之后，就可以认为系统的整体流程已经流畅。BDD的模式适用于平时的业务代码开发，因为业务的需求有可能变更频繁，但操作流程有可能不会变化，当业务代码发生变化的时候，可以使用原来的测试用例继续跑代码，节省了开发时间。

BDD通常负责整体业务模块的测试。

img

1、开发人员和非开发人员一起讨论确认需求

2、以一种自动化的方式将需求建立起来，并确认是否一致

3、最后，实现每个文档示例描述的行为，并从自动化测试开始以指导代码的开发

# 前端自动化测试的权衡利弊

当我们开始编写自动化测试时，可能想要测试所有的东西。每个搬砖仔可能都体会过未经测试的应用程序带来的痛苦，但在测试过程中，很快我又学到了另一课——测试会减缓开发速度。

在编写测试时，请务必牢记编写测试的目的。通常，测试的目的是为了节省时间。如果你正在进行的项目是稳定的并且会长期开发，那么测试是可以带来收益的。

但是如果测试编写与维护的时间长于它们可以节省的时间，那么你根本不应该编写测试。当然，在编写代码之前你很难知道通过测试可以节省多少时间。但是，假设你正在一个短期项目中创建原型，或者是在一个创业公司迭代一个想法，那你可能不会从编写测试中获得收益。

凡事都有两面性，软件测试也不是银弹，好处虽然明显，却并不是所有的项目都值得引入测试框架，毕竟维护测试用例也是需要成本的。对于一些需求频繁变更、复用性较低的内容，比如活动页面，让开发专门抽出人力来写测试用例确实得不偿失。

而适合引入测试场景大概有这么几个：

  • 需要长期维护的项目。它们需要测试来保障代码可维护性、功能的稳定性。
  • 较为稳定的项目、或项目中较为稳定的部分。给它们写测试用例，维护成本低。
  • 被多次复用的部分，比如一些通用组件和库函数。因为多处复用，更要保障质量。

测试确实会带给我们相当多的好处，但不是立刻就能够体会到。测试就像保险，如果身体健康顺顺利利，几十年可能都用不上。测试也一样，写了可以买个放心，这就是对代码的一种保障，有 bug 可以尽快测出来，没 bug 最好，但不能说“写那么多测试，结果测不出 bug，是浪费时间”。。

Jest入门