什么是测试

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

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

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

确保网站功能在用户点击按钮后正常运行。
确认复杂函数能否生成正确的结果。
完成需要用户登录的操作。
在输入格式错误的数据时，检查表单是否正确报告错误。
确保复杂的 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 组件”，在其他情境中对开发者而言具有不同的含义。

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

测试金字塔
在顶部进行端到端 (E2E) 测试，在中间进行集成测试，
单元测试 — 测试金字塔

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

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

检查您的理解情况

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

使用云提供程序的运行程序服务。

一些基于浏览器的运行程序提供了一种将测试外包出去的方法，但是这并不是测试库的常规功能

如果未得到满足，会导致异常的断言。

虽然您可以通过抛出错误来使测试失败，但 assert() 及其变体往往会被包括在内，因为它们数据。

一种将测试归类到测试金字塔中的方法。

实际上，并没有标准方法可以做到这一点。您可以将或者将它们放在不同的文件中但大部分测试框架并未真正内置分类功能。

能够按函数定义独立测试。

几乎所有测试中都包含 test() 方法跑步者。测试代码并非在顶级运行，因此这一点很重要文件的名称，这样测试运行程序便可将每个测试用例视为独立单元。