前端自动化测试(一)：揭秘自动化测试秘诀

news2024/9/21 10:40:28

目录

@[TOC](目录)
前言
自动化测试 VS 手动测试
测试分类
何为单元测试
单元测试的优缺点
优点
缺点

测试案例
测试代码

测试函数的封装
实现 `expect` 方法
实现 `test` 函数
结语

在这里插入图片描述

正文开始 ， 如果觉得文章对您有帮助，请帮我三连+订阅，谢谢💖💖💖

前言

在日常开发中，我们常会遇到下面的问题：

每次在版本发布上线之前，需要在电脑前蹲上好几个小时甚至更长时间对你的应用进行测试，这个过程非常枯燥而痛苦。
当代码的复杂度达到一定级别，且维护者的数量不止你一个时，你会逐渐察觉到在开发新功能或修复 bug 时会变得越发小心翼翼。即使代码看起来没问题，你心里还是会犯嘀咕：这个 Feature 会不会带来其他 Bug？这个 Fix 会不会引入其他 “Feature”？
当你想要对项目中的代码进行重构时，会花费大量时间进行回归测试。

以上这些问题大多源于开发者使用的最基本的手动测试方式。解决这些问题的根本在于引入自动化测试方案。

自动化测试 VS 手动测试

特性	自动化测试	手动测试
速度	快速，可以连续运行多个测试用例。	慢，需要逐个测试用例手动执行。
一致性	高，每次执行结果一致。	低，可能因人为因素导致结果不一致。
覆盖率	高，可以覆盖大量测试用例。	低，可能遗漏一些测试用例。
成本	初始成本高，需要编写和维护测试脚本。	初始成本低，但随着测试用例增加，成本可能增加。
维护	需要维护测试脚本，但一旦建立，维护成本较低。	每次更改需求或功能时，需要重新执行所有测试用例。
灵活性	低，测试用例需要预先定义。	高，可以根据需要随时调整测试用例。
准确性	高，可以精确执行测试用例。	低，可能因人为因素导致测试结果不准确。
重复性	高，可以重复执行测试用例。	低，重复执行测试用例可能会出错。
资源	需要专门的测试工具和环境。	需要测试人员和测试设备。
发现问题	可以发现一些手动测试难以发现的问题。	可以发现一些自动化测试难以发现的问题。
适用场景	适用于回归测试、持续集成等场景。	适用于探索性测试、用户验收测试等场景。
可扩展性	随着测试用例的增加，可以扩展测试范围。	随着测试用例的增加，执行时间可能显著增加。
风险	测试脚本可能存在缺陷，导致测试结果不准确。	测试人员可能因疲劳或疏忽导致测试结果不准确。

测试分类

前端开发最常见的测试主要是以下几种：

单元测试：验证独立的单元是否正常工作。
集成测试：验证多个单元协同工作。
端到端测试：从用户角度以机器的方式在真实浏览器环境验证应用交互。
快照测试：验证程序的 UI 变化。

何为单元测试

单元测试是对应用程序最小的部分（单元）运行测试的过程。通常，测试的单元是函数，但在前端应用中，组件也是被测单元。
单元测试可以单独调用源代码中的函数并断言其行为是否正确。
与端到端测试不同，单元测试运行速度很快，只需几秒钟即可完成，因此你可以在每次代码变更后运行单元测试，从而快速得到变更是否破坏现有功能的反馈。
单元测试应该避免依赖性问题，比如不存取数据库、不访问网络等，而是使用工具虚拟出运行环境。这样可以最小化测试成本，不需花大力气搭建各种测试环境。

单元测试的优缺点

优点

提升代码质量，减少 Bug。
快速反馈，减少调试时间。
让代码维护更容易。
有助于代码的模块化设计。
代码覆盖率高。

缺点

由于单元测试是独立的，无法保证多个单元一起运行时是否正确。

测试案例

上面提到单元测试的单元是函数，我们可以写两个函数，然后进行测试。看下面的例子：

// math.js
function sum (a, b) {
  return a + b; 
}

function subtract (x, y) {
  return x - y;
}

module.exports = {
  sum,
  subtract
};

测试代码

通过测试代码可以很方便地帮助验证代码的正确性。

const { sum, subtract } = require('./math');

const result = sum(1, 2);
const expected = 3;

if (result !== expected) {
  throw new Error(`1 + 2 应该等于 ${expected}，但是结果却是 ${result}`);
}

const result2 = subtract(2, 1);
const expected2 = 1;

if (result2 !== expected2) {
  throw new Error(`2 - 1 应该等于 ${expected2}，但是结果却是 ${result2}`);
}

测试函数的封装

之前示例的测试代码太过繁琐，可以思考如何封装得更简便一些，例如：

expect(sum(1, 2)).toBe(3);
expect(subtract(2, 1)).toBe(1);

这样的测试代码就像自然语言说话一样，很舒服。

实现 `expect` 方法

function expect (result) {
  return {
    toBe (actual) {
      if (result !== actual) {
        throw new Error(`预期值和实际值不相等，预期 ${result}，实际 ${actual}`);
      }
    }
  };
}

实现 `test` 函数

增加错误提示信息：

const { sum, subtract } = require('./math');

test('测试加法', () => {
  expect(sum(1, 2)).toBe(3);
});

test('测试减法', () => {
  expect(subtract(2, 1)).toBe(1);
});

function test (description, callback) {
  try {
    callback();
    console.log(`${description} 通过测试`);
  } catch (err) {
    console.error(`${description} 没有通过测试：${err}`);
  }
}

function expect (result) {
  return {
    toBe (actual) {
      if (result !== actual) {
        throw new Error(`预期值和实际值不相等，预期 ${result}，实际 ${actual}`);
      }
    }
  };
}