什么是测试

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

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

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

• 确保网站功能在用户点击按钮后正常运行。
• 确认复杂函数能否生成正确的结果。
• 完成需要用户登录的操作。
• 在输入格式错误的数据时，检查表单是否正确报告错误。
• 确保复杂的 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> 。

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

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

检查您的理解情况