测试驱动开发

预期结果：用 测试驱动开发 (Test-driven Development) 收集可重复验证这项行为或质量风险的证据。 用户场景：开发人员先为新的金额四舍五入规则，写一个会失败的示例测试。接着用最少的代码让测试通过，再在所有测试都成功时整理重复代码；功能写完后才补测试仍有帮助，但不算 TDD 的先测试流程。 验证方式：测试驱动开发 (Test-driven Development)。 适用理由：每个小设计步骤都由失败测试带动，通过后再安全整理代码时，可以使用这个词。 不应使用的情况：不要只因为项目有很多测试，就称它采用 TDD；实现必须遵循先写测试的循环。 测试要求：说明要测的系统与环境。定义预先准备的测试数据（Fixture）、其他输入，以及看得到的预期结果。加入预期失败、边界案例、容差、隔离方式及清理流程。 测试维护：让失败原因容易查找，并控制随机或会变化的输入。指定负责人。测试速度与维护成本要符合发布前检查的需要。 验收标准：已知缺陷存在时测试会失败，修复后通过。测试能在目标环境重复执行，提供可采取行动的证据，且不泄露或改动无关数据。 证据与限制（证据边界）：没有一份官方标准能涵盖全部内容。不同团队、平台或框架的用法可能不同。 待确认：发布前必过的检查、环境、测试数据、容差、执行时间预算、负责人，以及不稳定测试的处理规则。