在编写软件时,您可以通过测试来确认其能否正常运行。 测试可以广泛地定义为在特定环境中运行软件的过程 以确保其按预期运行。
测试成功后,就可以信心十足地 在添加新代码、新功能或 甚至升级依赖项,你已经编写的软件也会 继续按您预期的方式运作。测试还有助于保护您 避免意外的场景或意外的输入。
下面列举了一些您可能希望测试的网上行为示例:
- 确保网站功能在用户点击按钮后正常运行。
- 确认复杂函数能否生成正确的结果。
- 完成需要用户登录的操作。
- 在输入格式错误的数据时,检查表单是否正确报告错误。
- 确保复杂的 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">经过反复改进,这一理念已形成其他各种形式 例如测试菱形或 测试冰锥你的测试写作优先级可能因你而异 代码库。不过,一个常见的功能是,较简单的测试(例如单元测试) 往往运行更快、更容易编写(因此你会用到更多代码),并且 可以在有限的范围内进行测试,而像端到端测试这样的复杂测试 难以编写,但可以测试更广泛的范围。事实上,许多堆栈中的顶层 测试“形状”通常是手动测试 过于复杂,无法编码为自动化测试。
我们将在自动化技术分类中 测试。
检查您的理解情况
大多数测试库和框架都提供哪些基元?