Test Talking

Table of Contents

TODO Index

Learn the difference between Unit, Integration and Functional tests and learn how to write them with the tools listed on the followwing.

You can fill all your testing needs with just these:

  • [X] *R → Jest
  • [ ] *R → react-testing-library
  • [X] *R → vue testing library
  • [X] *R → Cypress
  • [ ] *R → Enzyme

and

  • [ ] *X → Mocha
  • [ ] *X → Chai
  • [ ] *X → Ava
  • [ ] *X → Jasmine

or

Type Checkers:

  • [ ] *R → TypeScript
  • [ ] *X → Flow

Jest1

1. 安装

1: yarn add --dev jest
2: # or
3: npm install --save-dev jest

2. 测试文件

下面我们开始给一个假定的函数写测试,这个函数的功能是两数相加。首先创建 sum.js 文件:

1: function sum(a, b) {
2:   return a + b;
3: }
4: module.exports = sum;

接下来,创建名为 sum.test.js 的文件。这个文件包含了实际测试内容:

1: const sum = require('./sum');
2: 
3: test('adds 1 + 2 to equal 3', () => {
4:   expect(sum(1, 2)).toBe(3);
5: });

将如下代码添加到 package.json 中:

1: {
2:   "scripts": {
3:     "test": "jest"
4:   }
5: }

最后,运行 yarn test 或者 npm run test ,Jest 将输出如下信息:

1: PASS  ./sum.test.js
2: ✓ adds 1 + 2 to equal 3 (5ms)

在此测试中,使用了 expect 和 toBe 来检测两个值是否完全相同。若要了解其它使用 Jest 可以测试的内容,请参阅使用匹配器(Matcher)

Vue Testing Librart2

Vue Testing Library builds on top of DOM Testing Library by adding APIs for working with Vue components. It is built on top of @vue/test-utils , the official testing library for Vue.

In short, Vue Testing Library does three things:

  • Re-exports query utilities and helpers from DOM Testing Library;
  • Hides @vue/test-utils methods that are in conflict with Testing Library Guiding Priinciple;
  • Tweaks some methods from both sources.
1: npm install --save-dev @testing-library/vue

You can now use all of DOM Testing Library's getBy, getAllBy, queryBy and queryAllBy commands. See here the full list of queries.

Cypress3

Our users are typically developers or QA engineers building web applications using modern JavaScript frameworks.

Cypress enables you to write all types of tests:

  • End-to-end tests
  • Integration tests
  • tests

Cypress can test anything that runs in a browser.

*Vue 中的测试4

该章节是个引子,先以 Vue 中的测试为切入点,在这个应用场景下引入一些测试相关的概念。

当构建可靠的应用时,测试在个人或团队构建新特性、重构代码、修复 bug 等工作中扮演了关键的角色。尽管测试的流派有很多,它们在 web 应用这个领域里主要有三大类:

- 单元测试
- 组件测试
- 端到端(E2E)测试

本章节致力于引导大家了解测试的生态系统并为 Vue 应用或组件库选择适合的工具。

单元测试

单元测试允许你将独立单元的代码进行隔离测试,其目的是为开发者提供对代码的信心。通过编写细致且有意义的测试,你能够有信心在构建新特性或重构已有代码的同时,保持应用的功能和稳定。

为一个 Vue 应用做单元测试并没有和其它类型和应用做测试有什么明显的区别。

1. 选择框架

因为单元测试的建议通常是框架无关的,所以下面只是当你在评估应用的单元测试工具时需要的一些基本指引。

(1)一流的错误报告

当测试失败时,提供有用的错误信息对于单元测试框架来说至关重要,这是断言库应尽的职责。

一个具有高质量错误信息的断言能够最小化调试问题所需的时间,除了简单地告诉你什么测试失败了,断言库还应额外提供上下文及测试失败的原因,例如预期结果 vs. 实际得到的结果。

一些诸如 Jest 这样的单元测试框架会包含断言库,另一些诸如 Mocha 需要你单独安装断言库(通常会用 Chai)。

(2)活跃和社区和团队

因为主流的单元测试框架都是开源的,所以对于一些旨在长期维护其测试且布尔什确保项目本身保持活跃的团队来说,拥有一个活跃的社区是至关重要的。额外的好处是,在任何时候遇到问题时,一个活跃的社区会为你提供更多的支持。

2. 框架

尽管生态系统里有很多工具,这里我们列出一些在 Vue 生态系统中常用的单元测试工具。

(1)Jest

Jest 是一个专注于简易性的 JavaScript 测试框架,一个其独特的功能是可以为测试生成快照(snapshot),以提供另一种验证应用单元的方法。

更多资料: Jest 官网Vue CLI 官方插件 - Jest

(2)Mocha

Mocha 一个专注于灵活性的 JavaScript 测试框架。因为其灵活性,它允许你选择不同的库来满足诸如侦听(如 Sinon)和断言(如 Chai)等其它常见的功能。另一个 Mocha 的独特功能是它不止可以在 NodeJS 里运行测试,还可以在浏览器里运行测试。

更多资料: Mocha 官网Vue CLI 官方插件 - Mocha

组件测试

测试大多数 Vue 组件时都必须将它们挂载到 DOM (虚拟或真实)上,才能完全断言它们在工作。这是另一个与框架无头的概念。因此组件测试框架的诞生,是为了让用户能够以可靠的方式完成这项工作,同时还提供了 Vue 特有的诸如对 Vuex、Vue Router 和其他 Vue 插件的集成的便利性。

1. 选择框架

以下章节提供了在评估最适合你的应用的组件测试框架时需要记住的事项。

(1)与 Vue 生态系统的最佳兼容性

毋容置疑,最重要的标准之一就是组件测试库应该尽可能与 Vue 生态系统兼容。

虽然这看起来很全面,但需要记住的一些关键集成领域包括单文件组件(SFC)、Vuex、Vue Router 以及应用所依赖的任何其他特定于 Vue 的插件。

(2)一流的错误报告

当测试失败时,提供有用的错误日志以最小化调试问题所需的时间对于组件测试框架来说至关重要。除了简单地告诉你什么测试失败了,他们还应额外提供上下文以及测试失败的原因,例如预期结果 vs. 实际得到的结果。

2. 推荐

(1)Vue Testing Library (@testing-library/vue)

Vue Testing Library 是一组专注于测试组件而不依赖实现细节的工具。由于在设计时就充分考虑了可访问性,它采用的方案也使重构变得轻而易举。

它的指导原则是,与软件使用方式相似的测试越多,它们提供的可信度就越高。

更多资料: Vue Testing Library 官网

(2)Vue Test Utils

Vue Test Utils 是官方的偏底层的组件测试库,它是为用户提供对 Vue 特定 API 的访问而编写的。如果你对测试 Vue 应用不熟悉,我们建议你使用 Vue Testing Library ,它是 Vue Test Utils 的抽象。

更多资料: Vue Test Utils 官方文档Vue 测试指南 by Lachlan Miller

端到端(E2E)测试

虽然单元测试为开发者提供了一定程度的信心,但是单元测试和组件测试在部署到生产环境时提供应用整体覆盖的能力是有限的。因此,端到端测试可以说从应用最重要的方面进行测试覆盖:当用户实际使用应用时会发生什么。

换句话说,端到端测试验证应用中的所有层。这不仅包括你的前端代码,还包括所有相关的后端服务和基础设施,它们更能代表你的用户所处的环境。通过测试用户操作如何影响应用,端到端测试通常是提高应用是否正常运行的信心的关键。

1. 选择框架

虽然 web 上的端到端测试因不可信赖(片面的)测试和减慢开发过程而得到负面的声誉,但现代端到端工具在创建更可靠的、交互的和实用的测试方面取得了长足进步。在选择端到端测试框架时,以下章节在为应用选择测试框架时提供了一些指导。

(1)跨浏览器测试

端到端测试的一个主要优点是它能够跨浏览器测试应用。尽管 100% 的跨浏览器覆盖看上支很诱人,但需要注意的是,因为持续运行这些跨浏览器测试需要额外的时间和机器消耗,它会降低团队的资源回报。因此,在选择应用需要的跨浏览器测试数量时,必须注意这种权衡。

针对浏览器特定问题的一个最新进展是,针对还常用的浏览器(如:<IE11、旧版 Safari 等)使用应用监视和错误报告工具(如: Sentry、LogRocket 等)。

(2)更快的反馈路径

端到端测试和开发的主要问题之一是运行整个套件需要很长时间。通常,这只在持续集成和部署(CI/CD)管道中完成。现代的端到端测试框架通过添加类似并行化的特性来帮助解决这个问题,这使用 CI/CD 管道的运行速度通常比以前快。此外,在本地开发时,有选择地为正在处理的页面运行单个测试的能力,同时还提供测试的热重载,将有助于提高开发者的工作流程和工作效率。

(3)一流的调试经验

虽然开发者传统上依赖玩耍终端窗口中扫描日志来帮助确定测试中出了什么问题,但现代端到端测试框架允许开发者利用他们已经熟悉的工具,例如浏览器开发工具。

2. 推荐

虽然生态系统中有许多工具,但以下是一些 Vue.je 生态系统中常用的端到端测试框架。

(1)Cypress.io

Cypress.io 是一个测试框架,旨在通过使开发者能够可靠地测试他们的应用,同时提供一流的开发者体验,来提高开发者的生产率。

更多资料: Cypress 官网Vue CLI 官方插件 - CypressCypress Testing Library

(2)Nightwatch.js

Nightwatch.js 是一个端到端框架,可用于测试 web 应用网站,以及 NodeJS 单元测试和集成测试。

更多资料: Nightwatch 官网Vue CLI 官方插件 - Nightwatch

(3)Puppeteer

Puppeteer 是一个 NodeJS 库,它提供高阶 API 来控制浏览器,并可以与其他测试运行程序(例如 Jest)配对来测试应用。

更多资料: Puppeteer 官网

(4)TestCafe

TestCafe 是一个基于端到端的 NodeJS 框架,旨在提供简单的设置,以便开发者能够专注于创建易于编写和可靠的测试。

更多资料: TestCafe 官网

不难看出,所谓测试的最终目的是为保证程序在整个开发及交付周期中的正确性,以满足用户需求,是多种因素和限制的折衷和妥协。

简介

单元测试5

单元测试(Unit Testing),是指对软件中的最小可测试单元进行检查和验证。

对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如 C 语言中单元指一个函数,Java 里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。

总是来说,单元就是人为规定的最小的被测功能模块。

单元测试是在软件开发中要进行的最低级别的测试活动,软件的独立单元将与程序的其他部分相隔离的情况下进行测试。

经常与单元测试联系起来的另外一些开发活动包括代码走读(Code review),静态分析(Static analysis)和动态分析(Dynamic analysis)。

_静态分析_ 就是对软件的源代码进行研读,查找错误或收集一些度量数据,并不需要对代码进行编译和执行; _动态分析_ 就是通过观察软件运行时的动作,来提供执行跟踪,时间分析,以及测试覆盖度方面的信息。

详解

单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。

单元测试是由程序员自己来完成,最终受益的也是程序员自己。

其实我们每天都在做单元测试。你写了一个函数,除了极简单的外,总是要执行一下,看看功能是否正常,有时还要想办法输出些数据,如弹出信息窗口什么的,这也是单元测试,我们通常把这种单元测试称为 临时单元测试

只进行了临时单元测试的软件,针对代码的测试很不完整,代码覆盖率要超过 70% 都很困难,未覆盖的代码可能遗留大量的细小的错误,这些错误还会互相影响,当 Bug 暴露出来的时候难于调试,大幅度提高后期测试和维护成本,也降低了开发商的竞争力。

对程序员来说,如果养成了对自己写的代码进行单元测试的习惯,不但可以写出高质量的代码,而且还能提高编程水平。

要进行充分的单元测试,应专门编写测试代码,并与产品代码隔离。比较简单的办法是为产品工程建立对应的测试工程,为每个类建立对应的测试类,为每个函数(很简单的除外)建立测试函数。

其实,永远都是一种折衷。

使用效果

我们编写代码时,一定会反复调试保证它能够编译通过。但代码通过编译,只是说明了它的语法正确,我们却无法保证它的语义也一定正确。

幸运的是,单元测试会为我们的承诺做保证,编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。

什么时候测试?单元测试越早越好,早到什么程度?

极限编程(Extreme Programming,XP)讲究 TDD,即测试驱动开发,先编写测试代码,再进行开发。在实际的工作中,可以不必过分强调先什么后什么,重要的是高效和感觉舒适。从经验来看,

1. 先编写产品函数的框架,
2. 然后编写测试函数,针对产品函数的功能编写测试用例,
3. 然后编写产品函数的代码,每写一个功能点都运行测试,随时补充测试用例。

所谓,先编写产品函数的框架,是指先编写函数空的实现,有返回值的直接返回一个合适值,编译通过后再编写测试代码,这时,函数名、参数表、返回类型都应该确定下来了,所编写的测试代码以后需修改的可能性比较小。

关于桩代码,单元测试应避免编写桩代码。

桩代码 就是用来代替某些代码的代码,例如,产品函数或测试函数调用了一个未编写的函数,可以编写桩函数来代替该被调用的函数,桩代码也用于实现测试隔离。采用由底向上的方式进行开发,底层的代码先开发并先测试,可以避免编写桩代码,这样做的好处有:

  • 减少了工作量;
  • 测试上层函数时,也是对下层函数的间接测试;
  • 当下层函数修改时,通过回归测试6可以确认修改是否导致上层函数产生错误。
回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁,而在极端编程方法中,更是要求每天都进行若干次回归测试。因此,通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

Hmm... 公司目前的项目,好像没有人写测试...

1. 误解

在明确了什么是单元测试后,我们可以进行“反调论证”了。

(1)它浪费了太多的时间

一旦编码完成,开发人员总是会迫切希望进行软件的集成工作,这样就能够看到实际的系统开始启动工作了,而像单元测试这样的活动则往往被认为推迟了对整个进行联调的时间。

然而,系统能够正常工作的可能性是小的,更多的情况是充满了各式各样的 Bug 。

在实践中,这样一种开发步骤常常会导致这样的结果:软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的 Bug 上面,在个别情况下,这些 Bug 也许是琐碎和微不足道的,但是总的来说,他们会导致在软件集成为一个系统时增加额外的工期, 而且当这个系统投入使用时也无法确保它能够可靠运行。

在实践工作中,进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作,很多 Bug 将被纠正,在确信他们手头拥有稳定可靠的部件的情况下,开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步,所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。

使用 AdaTEST 和 Cantata 这样的支持工具可以使单元测试更加简单和有效。但这不是必须的,单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。

<实用软件度量>一书中列出了准备测试,执行测试,和修改缺陷所花费的时间(以一个功能点为基准),这些数据显示单元测试的成本效率大约是集成测试的两倍系统测试的三倍.

(2)它仅仅是证明这些代码做了什么

(3)我是个很棒的程序员,是不是可以不进行单元测试

在真实世界里,每个人都会犯错误。即使某个开发人员可以抱着这种态度在很少的一些简单的程序中应付过去。但真正的软件系统是非常复杂的,真正的软件系统不可以寄希望于没有进行广泛的测试和 Bug 修改过程就可以正常工作。

(4)不管怎样,集成测试将会抓住所有的 Bug

这个论点不成立的原因在于规模越大的代码集成意味着复杂性就越高。如果软件的单元没有事先进行测试,开发人员很可能会花费大量的时间仅仅是为了使软件能够运行,而任何实际的测试方案都无法执行。

一旦软件可以运行了,开发人员又要面对这样的问题:在考虑软件全局复杂性的前提下对每个单元进行全面的测试。这是一件非常困难的事情,甚至在创造一种单元调用的测试条件的时候,要全面的考虑单元的被调用时的各种入口参数。在软件集成阶段,对单元功能全面测试的复杂程度远远的超过独立进行的单元测试过程。

最后的结果是测试将无法达到它所应该有的全面性。一些缺陷将被遗漏,并且很多 Bug 将被忽略过去。

2. 成本效率

很多研究成果表明,无论什么时候作出修改都需要进行完整的回归测试,在生命周期中尽早地对软件产品进行测试将使效率和质量都得到最好的保证。Bug 发现的越晚,修改它所需的费用就越高,因此从经济角度来看, 应该尽可能早的查找和修改 Bug。在修改费用变的过高之前,单元测试是一个在早期抓住 Bug 的机会。

相比后阶段的测试,单元测试的创建更简单,维护更容易,并且可以更方便的进行重复。从全程的费用来考虑, 相比起那些复杂且旷日持久的集成测试,或是不稳定的软件系统来说,单元测试所需的费用是很低的。

结论

经验表明一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的 Bug,并且修改它们的成本很低。在软件开发的后期阶段,Bug 的发现并修改将会变得更加困难,并要消耗大量的时间和开发费用。

无论什么时候作出修改都要进行完整的回归测试,在生命周期中尽早地对软件产品进行测试将使效率和质量都得到最好的保证。

在提供了经过测试的单元的情况下,系统集成过程将会大大地简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上,而不是陷入充满很多 Bug 的单元之中不能自拔。

优点

1. 它是一种验证行为

程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支援,就算是开发后期,我们也可以轻松的增加功能或更改程序结构,而不用担心这个过程中会破坏重要的东西,而且它为代码的重构提供了保障。这样,我们就可以更自由的对程序进行改进。

2. 它的一种设计行为

编写单元测试将使我们从调用者观察、思考。特别是先写测试(test-first),迫使我们把程序设计成易于调用和可测试的,即迫使我们解除软件中的耦合。

3. 它是一种编写文档的行为

单元测试是一种无价的文档,它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的,并且它保持最新,永远与代码同步。

4. 它具有回归性

自动化的单元测试避免了代码出现回归,编写完成之后,可以随时随地的快速运行测试。

范畴

如果要给单元测试一个明确的范畴,指出哪些功能是属于单元测试,这似乎很难。我们下面讨论四个问题,基本上可以说明单元测试的范畴,单元测试所要做的工作。

1. 它的行为和我期望的一致吗?

这是单元测试最根本的目的,我们就是用单元测试的代码来证明它所做的就是我们期望的。

2. 它的行为一直和我期望的一致吗?

编写单元测试,如果只测试代码的一条正确路径,让它正确走一遍,并不算是真正的完成。

软件开发是一项复杂的工程,在测试某段代码的行为是否和你的期望一致时,你需要确认:在任何情况下,这段代码是否都和你的期望一致,如参数很可疑、缓冲区溢出、网络掉线等。

3. 我可以依赖单元测试吗?

不能依赖的代码是没有多大用处的,既然单元测试是用来保证代码的正确性,那么单元测试也一定要值得依赖。

4. 单元测试说明我的意图了吗?

单元测试能够帮我们充分了解代码的用法,从效果上而言,单元测试就像是能执行的文档,说明了在你用各种条件调用代码时,你所期望这段代码完成的功能。

测试用例

下面说说测试用例,输入数据及预期输出。

输入数据是测试用例的核心,对 输入数据 的定义是:被测试函数所读取的外部数据及这些数据的初始值。

外部数据 是对于被测试函数来说的,实际上就是除了局部变量以外的其他数据,这些数据分为几类:参数、成员变量、全局变量、IO 媒体(指文件、数据库其其他储存或传输数据的媒体)。

一个函数无论多复杂,都无非是对这几类数据的读取、计算和写入。

预期输出 是指:返回值及被测试函数所写入的外部数据的结果值。

一个 测试用例 ,就是设定输入数据,运行被测试函数,然后判断实际输出是否符合预期。

如何设计测试用例呢?

前面已经说了,测试用例的核心是输入数据,预期输出是依据输入数据和程序功能来确定的。也就是说,对于某一程序,输入数据确定了,预期输出也就可以确定了,至于生成/销毁被测试对象和运行测试的语句,是所有测试用例都大同小异的,因此,我们讨论测试用例时,只讨论输入数据。

输入数据包括:参数、成员变量、全局变量、IO 媒体。这四类数据中,只要所测试程序需要执行读操作的,就要设定其初始值,其中,前两类比较常用,后两类较少用。

显然,把输入数据的所有可能值都进行测试,是不可能也是无意义的,我们应该用一定的规则选择有代表性的数据作为输入数据,主要有三种:

- 正常输入
- 边界输入
- 非法输入

每种输入还可以分类,也就是平常说的等价类法,每类取一个数据作为输入数据,如果测试通过,可以肯定同类的其他输入也是可以通过的。

如果函数使用了外部数据,则正常输入是肯定会有的,而边界输入和非法输入不是所有函数都有。一般情况下,即使没有设计文档,考虑以上三种输入也可以找出函数的基本功能点。实际上,单元测试与代码编写是“一体两面”的关系,编码时对上述三种输入都是必须考虑的,否则代码的健壮性就会成问题。

上面所说的测试数据都是针对程序功能来设计的,就是所谓的 黑盒测试

单元测试还需要从另一个角度来设计测试数据 – 白盒测试 ,即针对程序的逻辑结构设计测试用例,用逻辑覆盖率来衡量测试的完整性。

逻辑单位主要有:语句、分支、条件、条件值、条件值组合,路径。

关于白盒测试用例的设计,程序测试领域的书籍,普通方法是画出程序的逻辑结构图,如 程序流程图控制流图 ,根据逻辑结构图设计测试用例,这些是纯粹的白盒测试。

推荐的方法是:先完成黑盒测试,然后统计白盒覆盖率,针对未覆盖的逻辑单位设计测试用例覆盖它。

应用

1. 极限编程

单元测试是极限编程的基础,依赖于自动化的单元测试框架。自动化的单元测试框架可以来源于第三方,如 xUnit,也可以由开发组自己创建。

极限编程创建单元测试用于测试驱动开发。首先,开发人员编写单元测试用于展示软件需求或者软件缺陷。因为需求尚未实现或者现有代码中存在软件缺陷,这些测试会失败。然后,开发人员遵循测试要求编写最简单的代码去满足它,直到测试得以通过。

至关重要的,测试代码应视为第一个项目成品,与实现代码维持同等级别的质量要求,没有重复。

还是部分测试好一点,Hmm... 虽然不完全编写等于没有编写...

2. 技术

单元测试通常情况下自动进行,但也可被手动执行,IEEE 没有偏爱某一种形式。

在自动化测试时,为了实现隔离的效果,测试将脱离待测程序单元(或代码主体)本身固有的运行环境之外,在测试框架中运行。以隔离方式运行有利于充分显露待测试代码与其它单元或者产品数据空间的依赖关系,这些依赖关系中单元测试中可以消除。

总体来说,单元测试会激发程序员创造解耦的和内聚的代码体。

单元测试实践有利于促进健康的软件开发习惯。设计模式、单元测试和重构经常一起出现在工作中,借助于它们,开发人员可以生产出最为完美的解决方案。

3. 单元测试框架

单元测试框架通常是没有作为编译器的第三方产品,它们帮助简化单元测试的过程,并且已经为各种编程语言开发。

通常在没有特定框架支持下,通过撰写在测试中的运行单元,并使用判定、异常处理、或其他控制流程机制来表示失败的用户代码运行单元测试是可行的。不通过框架的单元测试有用之处在于进行单元测试时会有一个参进障碍(barrier to entry),进行一点单元测试几乎不比没做好多少,但是一旦使用了框架,加入单元测试相对来说就会简单许多。

集成测试7

集成测试,也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成为子系统或系统,进行集成测试。

实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题,在全局上很可能暴露出来。

详解

集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它最简单的形式是:把两个已经测试过的单元组合成一个组件,测试它们之间的接口。

从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合为程序的更大部分。方法是测试片段的组合,并最终扩展成进程,将模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。此外,如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进程。

集成测试是在单元测试的基础上,测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说,在集成测试之前,单元测试应该已经完成,集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要,因为如果不经过单元测试,那么集成测试的效果将会受到很大影响,并且会大幅增加软件单元代码纠错的代价。

集成测试是单元测试的逻辑扩展。在现实方案中,集成是指多个单元的聚合,许多单元组合成模块,而这些模块又聚合成程序的更大部分,如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作,以及与其他组的模块能否集成起来工作。最后,还要测试构成系统的所有模块组合能否正常工作。

所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式,具体的开发工作总得从一个一个的软件单元做起,软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成,总是会出现一些常见问题,工程实践中 ,几乎不存在软件单元组装过程中不出任何问题的情况。

*注:集成测试需要花费的时间远远超过单元测试,直接从单元测试过渡到系统测试是极不妥当的做法。

目标

集成测试的目标是按照设计要求使用那些通过单元测试的构件来构造程序结构。单个模块具有高质量但不足以保证整个系统的质量。有许多隐蔽的失效是高质量模块间发生非预期交互而产生的。

以下两种测试技术是用于集成测试:

- 功能性测试,使用黑盒测试技术针对被测模块的接口规格说明进行测试;
- 非功能性测试,对模块的性能或可靠性进行测试。

另外,集成测试的必要性还在于一些模块虽然能够单独地工作,但并不能保证连接起来也能正常工作。此外,在某些开发模式中,如迭代式开发,设计和实现是迭代进行的。在这种情况下,集成测试的意义还在于它能间接地验证概要设计是否具有可行性。

集成测试是确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能,使用黑盒测试方法测试集成的功能,并且对以前的集成进行回归测试。

功能测试8

功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。

Footnotes:

Date: 2020-12-15 Tue 10:17

Author: Jack Liu

Created: 2021-01-01 Fri 14:37

Validate