当你编码时，目标是使程序正常工作。但作为测试设计者，你希望让它失败。这是一个微妙但重要的区别。

为什么软件测试很难？

做不到十分详尽：测试一个 32 位浮点乘法运算。有 2^64 个测试用例！
随机或统计测试效果差：其他工程学科可以测试小的随机样本（例如制造的硬盘驱动器的 1%）并推断整个生产批次的缺陷率。但是对于软件来说并非如此。软件行为在可能输入的空间内不连续且离散地变化，系统可能在广泛的输入范围内似乎工作正常，然后在单个边界点突然失效，堆栈溢出、内存不足错误和数字溢出错误往往会突然发生。

Test-first programming

顺序：

测试优先编程的最大好处是防止错误。不要将测试留到开发结束，因为此时有一大堆未经验证的代码。将测试留到最后只会使调试时间更长、更痛苦，因为错误可能存在于代码中的任何位置。

我们希望进行系统测试，而不是详尽、随意或随机的测试。系统测试意味着我们以有原则的方式选择测试用例，目标是设计一个具有三个理想属性的测试套件：

我们希望选择一组足够小的测试用例，以便于编写和维护并快速运行，但又足够彻底以发现程序中的错误。

为此，我们将程序的输入空间划分为多个子域，每个子域由一组输入组成。我们只需要为每个集合测试一个代表。这种方法通过选择不同的测试用例，并强制测试探索随意或随机测试可能无法到达的输入空间区域，从而充分利用了有限的测试资源。

例:

Math.abs()

测试用例：

Math.max()

测试用例：

子域应具有三个理想的属性：

单元测试 (Unit Test)：测试单个模块（如函数）的测试。
自动化：使用测试框架（如Mocha for JS/TS）编写测试代码，自动运行并检查结果（使用assert.strictEqual, assert.deepStrictEqual等断言），输出通过/失败报告。
文档化测试策略 (Documenting Strategy)：在测试代码中以注释形式记录所采用的分区策略，并为每个测试用例命名其所覆盖的子域（如it("covers a < b", ...)），这极大地增强了测试套件的可理解性。

衡量测试套件对代码的覆盖程度，常用指标：

Statement coverage (语句覆盖)：是否每条语句都被至少一个测试执行过？（常见目标）
Branch coverage (分支覆盖)：是否每个控制分支（如if/else的两边）都被至少一个测试执行过？
Path coverage (路径覆盖)：是否所有可能的执行路径都被覆盖？使用工具（如Istanbul/nyc）测量覆盖率，并补充测试用例以提高覆盖率。

回归测试 (Regression Testing)：在每次修改代码后（修复bug、添加功能、优化性能）运行完整的测试套件，防止修改引入新的错误。
测试优先调试 ：发现bug时，立即编写一个能重现该bug的测试用例，并将其加入测试套件。修复bug后，该测试用例就成为防止未来回归的回归测试。
自动化是回归测试可行的关键。