JavaScript 测试?单元vs功能vs集成测试
作者:wildflame 发布时间:[ 2017/1/19 15:15:12 ] 推荐标签:软件测试 单元测试 集成测试
单元测试、集成测试、功能测试这些自动化测试方法,是项目持续部署的基础。作为一种研发方式,它能帮助你在短时间内安全的发布新特性,而不用等上几个月甚至几年。
自动测试通过捕捉更多的错误,增强了软件到达用户之前的稳定性。好比是一张防护网一样,使开发者们在做更改的时候不必担心引发未知的错误。
忽略测试的代价
与直觉相反,维护一个高质量的测试套件能够极大地提高开发人员的效率,因为它使得开发人员能够立即发现开发中的错误。反过来说,如果没有这些套件,终端用户会遇到更多的 Bug,从而导致需要在用户服务,质量保证和错误报告上面投入更多的资源。
测试驱动开发(TDD)在前期需要更多的时间,但是一旦 Bug 到了用户那里,你会付出更多的代价:
· 它们会影响用户体验,而这会导致你销量下降,用户减少,甚至赶走潜在的客户。
· 所有的错误报告都必须被 QA 或者开发者亲自验证。
· 修补这些 Bug 会耗费你大量的时间,因为它导致你必须停下手头的工作。粗略估计每一个 Bug 都将浪费你 20 分钟的时间,而这还没有算你修补它们的时间。
· 有时候,诊断这些 Bug 的人并不是开发它们的人,这导致了开发人员对代码的不熟悉。
· 机会成本:开发团队必须等到 Bug 被修补以后,才能继续按照计划开发。
在生产环境里的 Bug 使你付出的代价往往要数倍于在自动化测试时发现的 Bug。换句话说,如果你计算投资与回报的话,测试驱动开发(TDD)将具有压倒性的优势。
不同类型的测试
你需要了解的第一件事情是,每一种测试都有它自己的作用。他们都在软件的持续发布中起了扮演着重要的角色。
前阵子,我为一个野心勃勃的项目做了咨询,这个团队费尽心机的希望搭建一个可靠的测试套件。但因其难以使用和理解,很少派上用场,更无法继续维护。
我观察到的其中一个问题是,现有套件混淆了单元,功能和集成测试。以至于不同类型的测试之间没有明显的区别。
其结果是现有测试套件不适合任何一个测试套件。
在持续发布中这些测试所扮演的角色
每种类型的测试可以发挥其独特的作用。你不用在单元测试、功能测试和集成测试中做选择。因为你会使用全部的这三种测试,并确保可以独立的运行这三种类型的测试套件。
大多数应用程序都需要单元测试和功能测试,而许多复杂的应用程序在此基础上,还需要集成测试。
· 单元测试 用来确保每个组件正常工作 —— 测试组件的 API 。
· 集成测试 用来确保不同组件互相合作 —— 测试组件的 API, UI, 或者边缘情况(比如数据库I/O,登陆等等)。
· 功能测试 用来确保整个应用会按照用户期望的那样运行 —— 主要测试界面
你应该把单元,集成和功能测试互相隔离开来,这样你可以在开发时分别的运行它们。在持续的集成过程中,测试一般会出现在下面三个阶段。
· 开发阶段 ,主要是程序员反馈。这时单元测试很有用。
· 在中间阶段 ,主要是能够在发现问题时立刻停下来。这时各种测试都很有用。
· 在生产环境 ,主要是运行功能测试套件中一个叫做「冒烟测试」的子集,确保部署的时候没有弄坏什么东西。
如果你问我该使用那个测试? 所有的。
为了了解如何在您的软件开发过程选择不同测试,你需要了解每种测试所扮演的角色,那些测试大致可分为三大类?
· 开发 API 测试(针对开发人员)用户体验测试(针对终用户)
· 开发 API 测试(针对开发人员)
· 开发 API 测试(针对开发人员)基础设施测试(负载测试、 网络集成测试等……)
用户体验测试从用户的角度来测试,使用实际的用户界面,通常是在目标平台或设备上。
API 测试则从开发者的角度来做测试。我说的可不是 Http API。我说的是一个 Unit 的 API,而一个 Unit 指开发者创建出来用来和其他模块或者类交互的一整个部分。
单元测试:实时的开发者反馈
单元测试是确保单个组件的工作彼此隔绝。一个单元,通常是一个模块、 功能等等…
比方说,您的应用程序可能需要路由一个 URL 到路由处理程序。一个单元测试用来确保此 URL 解析器正确的解析 URL。而另一个单元测试可能确保路由器为给定的 URL 调用了正确的处理程序。
然而,如果你想测试在接收到特定的 post 请求以后,数据库会添加对应的记录,那么这是集成测试,而不是单元测试。
单元测试常常被用来开发者的反馈机制。比方说,我在工作时,会在我每一次更改之后运行 lint 和单元测试,在 console 里检测运行的结果。
为了实现这个目的,单元测试必须很快,也是说,在单元测试里,一切异步的操作都应该被避免。
自集成测试和功能测试非常频繁地依赖于网络连接和文件 I/O,他们会显著减慢测试的速度。当有很多的测试的时候,可以运行的时间可以从毫秒数到几分钟。对于非常大的应用程序,运行完整的测试可以用一个多小时。
一个好的单元测试应该包括以下三点:
· 开发 API 测试(针对开发人员)非常简单
· 开发 API 测试(针对开发人员)速度很快 - 以迅雷不及掩耳之势
· 开发 API 测试(针对开发人员)生成一个「好的报告」
什么是「好的报告」呢?
「好的报告」是能够一眼告诉你,
1、什么组件正在被测试
2、你期望什么行为
3、实际是什么结果
4、你期望什么结果
5、如何重现
前四个问题应在故障报告中清晰可见,而后的那个问题应该从测试的执行很清楚的中找到。当然,在一份不合格的报告中有一些 assertion 的类型是不能回答所有问题的,但大部分的问题 ‘equal’、 ’same’,或者 ‘deepEqual’ 都应该可以做到。事实上,如果那些断言是现有断言库里的断言,现存的大多数测试套件可能会更好。大道至简!
下面这个是我在实际项目中使用 Tape 的做单元测试的例子:
// Ensure that the initial state of the "hello" reducer gets set correctly
import test from 'tape';
import hello from 'store/reducers/hello';
test('...initial', assert => {
const message = `should set { mode: 'display', subject: 'world' }`;
const expected = {
mode: 'display',
subject: 'World'
};
const actual = hello();
assert.deepEqual(actual, expected, message);
assert.end();
});
// Asynchronous test to ensure that a password hash is created as expected.
import test from 'tape',
import credential from '../credential';
test('hash', function (t) {
// Create a password record
const pw = credential();
// Asynchronously create the password hash
pw.hash('foo', function (err, hash) {
t.error(err, 'should not throw an error');
t.ok(JSON.parse(hash).hash,
'should be a json string representing the hash.');
t.end();
});
});
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11