前端自动化测试(一):揭秘自动化测试秘诀
子羽bro 2024-08-16 10:03:12 阅读 68
目录
@[TOC](目录)前言自动化测试 VS 手动测试测试分类何为单元测试单元测试的优缺点优点缺点
测试案例测试代码
测试函数的封装实现 `expect` 方法实现 `test` 函数结语
<code>正文开始 ,
如果觉得文章对您有帮助,请帮我三连+订阅,谢谢
💖💖💖
前言
在日常开发中,我们常会遇到下面的问题:
每次在版本发布上线之前,需要在电脑前蹲上好几个小时甚至更长时间对你的应用进行测试,这个过程非常枯燥而痛苦。当代码的复杂度达到一定级别,且维护者的数量不止你一个时,你会逐渐察觉到在开发新功能或修复 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}`);
}
}
};
}
结语
自动化测试是前端开发中提升效率、保证质量的利器。它不仅能够减轻手动测试的繁重工作,还能在代码发生变动时迅速提供反馈,确保代码的稳定性和可靠性。通过本文的介绍,相信你已经对自动化测试有了简单理解,后面我会继续介绍更多使用的测试工具
在实际项目中,合理地引入自动化测试,不仅能够大幅度提升开发效率,还能让你在面对复杂的项目需求和频繁的代码变更时更加从容。
声明
本文内容仅代表作者观点,或转载于其他网站,本站不以此文作为商业用途
如有涉及侵权,请联系本站进行删除
转载本站原创文章,请注明来源及作者。