什么是测试

在编写软件时,您可以通过测试来确认其能否正常运行。 测试可以广泛地定义为在特定环境中运行软件的过程 以确保其按预期运行。

测试成功后,就可以信心十足地 在添加新代码、新功能或 甚至升级依赖项,你已经编写的软件也会 继续按您预期的方式运作。测试还有助于保护您 避免意外的场景或意外的输入。

下面列举了一些您可能希望测试的网上行为示例:

  • 确保网站功能在用户点击按钮后正常运行。
  • 确认复杂函数能否生成正确的结果。
  • 完成需要用户登录的操作。
  • 在输入格式错误的数据时,检查表单是否正确报告错误。
  • 确保复杂的 Web 应用在用户使用 带宽较低或断网。

自动测试与手动测试

您可以通过两种常规方式测试软件:自动测试和手动测试 测试。

手动测试需要由人工直接运行软件,例如 确认其行为符合预期。手动 测试可以轻松创建或定义。例如,您的网站能否加载?你能不能 执行这些操作呢?但每次穿越都消耗了大量的 人类的时间。虽然人类极具创造力,但可以进行某种类型的测试 称为探索性测试,我们仍然难以发现故障或 特别是在多次执行同一任务时。

自动化测试是指任何允许编写测试代码并运行测试的流程 以确认软件的预期行为,而无需 让人工执行所有重复步骤,例如设置或检查结果。 重要的是,自动测试一旦配置完成,就可以频繁运行。 这仍然是一个非常宽泛的定义,值得注意的是, 都采用各种形状和形式本课程的大部分内容 作为一种实践,将自动化测试纳入测试范围。

手动测试确实有一定的作用,通常是编写自动化测试的前兆 但如果自动化测试变得不可靠、范围太广, 或难以编写

通过示例了解基础知识

对于编写 JavaScript 或相关语言的 Web 开发者来说,简洁的 可以像这样每天运行的脚本 或者在浏览器中加载:

import { fibonacci } from "../src/math.js";

if (fibonacci(0) !== 0) {
  throw new Error("Invalid 0th fibonacci result");
}
const fib13 = fibonacci(13);
if (fib13 !== 233) {
  throw new Error("Invalid 13th fibonacci result, was=${fib13} wanted=233");
}

这是一个简化示例,可提供以下数据分析:

  • 这是一个测试,因为它会运行一些软件(斐波那契 函数),并确保其 行为的预期方式, 预期值。如果行为不正确,则会引发错误, JavaScript 通过抛出 Error 来表达。

  • 即使您可能在终端或 因此这仍是一项自动测试,因为它可以反复运行 而无需执行任何单独的步骤下一页, 详细说明了

  • 尽管此测试不使用任何库,但还是可以 它仍然可以在任何地方运行 - 它仍然是一个测试有很多工具可以帮助您 您可以编写测试,包括本课程稍后介绍的测试, 但它们仍然遵循着导致错误的基本原则, 出现问题。

实际测试库

大多数库或内置测试框架都提供两个主要基元, 让测试更易于编写:断言和一种定义独立测试的方法。 我们将在下一部分(断言和 其他基元。不过,概括来讲 需要注意的是,您看到或编写的几乎所有测试 使用这些基元进行构建。

断言是一种合并检查结果和在发生以下情况时导致错误的方法: 出现问题。例如,您可以让上一个测试更简洁 引入 assert

import { fibonacci } from "../src/math.js";
import { assert } from "a-made-up-testing-library";

assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");

您可以通过定义独立的测试(可选)来进一步改进此测试 套件。以下套件会单独测试 Fibonacci 函数和 Catalan 函数

import { fibonacci, catalan } from "../src/math.js";
import { assert, test, suite } from "a-made-up-testing-library";

suite("math tests", () => {
  test("fibonacci function", () => {
    assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
    assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");
  });
  test("relationship between sequences", () => {
    const numberToCheck = 4;
    const fib = fibonacci(numberToCheck);
    const cat = catalan(numberToCheck);
    assert.isAbove(fib, cat);
  });
});

在软件测试环境中,“测试”作为名词是指“测试用例”: 单一、独立、可行的场景,例如“组织之间的 序列”上一个示例中的测试用例。

单独命名的测试可用于完成以下任务及其他任务:

  • 确定测试在一段时间内成功或失败的情况。
  • 按名称突出显示某个 bug 或场景,以便您更轻松地测试 场景处理完成。
  • 有些测试独立于其他测试,例如通过 glob 过滤器运行。

可以采用“三个 A”来理解测试用例单元测试: 安排、行事和主张每个测试用例的核心如下:

  • 排列一些值或状态(这可能只是硬编码的输入数据)。
  • 执行操作,例如调用方法。
  • 断言输出值或更新状态(使用 assert)。

测试的规模

上一部分中的代码示例描述了单元测试,因为它们 测试软件的一小部分,通常集中在单个文件上 一个函数的输出。测试复杂性会随着您的 考虑来自多个文件、组件甚至是不同互连的 系统(有时不受您控制,例如网络服务或 外部依赖项的行为)。因此,测试类型通常被命名为 基于其范围规模

除了单元测试以外,其他测试类型示例还包括组件测试 测试视觉测试集成测试。这些名称都没有 不同的标准,而且它们的含义可能也不尽相同, 因此请务必以这些代码为指导,并想出一些定义 您的工作。例如,您系统中正在测试的组件是什么?对于 React 开发者,这可能会从字面上映射到“React 组件”, 在其他情境中对开发者而言具有不同的含义。

单个测试的规模可将其置于通常称为 作为“测试金字塔”,这是判断 及其运行方式

<ph type="x-smartling-placeholder">
</ph> 测试金字塔
    在顶部进行端到端 (E2E) 测试,在中间进行集成测试,
    单元测试
测试金字塔

经过反复改进,这一理念已形成其他各种形式 例如测试菱形或 测试冰锥你的测试写作优先级可能因你而异 代码库。不过,一个常见的功能是,较简单的测试(例如单元测试) 往往运行更快、更容易编写(因此你会用到更多代码),并且 可以在有限的范围内进行测试,而像端到端测试这样的复杂测试 难以编写,但可以测试更广泛的范围。事实上,许多堆栈中的顶层 测试“形状”通常是手动测试 过于复杂,无法编码为自动化测试。

我们将在自动化技术分类中 测试

检查您的理解情况

大多数测试库和框架都提供哪些基元?

如果未得到满足,会导致异常的断言。
能够按函数定义独立测试。
一种将测试归类到测试金字塔中的方法。
使用云提供程序的运行程序服务。