测试效率倍增！2026年5大自动生成语句覆盖测试用例工具精选推荐

自动生成语句覆盖测试用例，最容易制造的一种错觉是：覆盖率从 42% 升到 85%，测试质量就同步提高了。实际项目里，工具可能只是让代码“跑过”了更多语句，却没有检查返回值是否正确，也没验证异常、边界和状态变化。本文按适用语言、生成方式、接入成本和人工复核负担，比较 EvoSuite、Randoop、Diffblue Cover、IntelliTest 与 Parasoft Jtest，并给出一套可复现的评估方法。

文中的量化案例均明确标注为情景模拟，不冒充厂商实测；选型时，我更建议先看新增覆盖是否转化为有效断言，再决定是否扩大自动生成范围。

一、先讲结论：工具的价值不等于覆盖率数字

1. 五款工具各自适合什么团队

如果只想快速得到结论：Java 项目可以优先在 EvoSuite、Randoop、Diffblue Cover 和 Parasoft Jtest 中做小范围验证；C# 项目则重点看 IntelliTest。它们的生成机制不同，不能只按“谁生成得多”排序，更不适合脱离语言、构建方式和维护能力评出唯一赢家。

这张表不是工具排名，而是初筛入口。最终选择应由真实仓库的一个代表性模块决定：同一款工具在纯函数、遗留代码、数据库访问层和依赖繁重的服务中，表现可能完全不同。

2. 我会先看四个结果，而不是生成了多少条用例

我评估自动生成工具时，会把结果拆成四层：新增语句覆盖、断言有效率、测试稳定性、维护成本。覆盖率衡量代码是否被执行；断言衡量测试是否能识别错误；稳定性看重复运行是否一致；维护成本则包括阅读、修复、去重和 CI 运行时间。只报告第一项，通常不足以支持采购或推广决定。

可执行但没有有效断言的测试，只能证明代码路径被走过，不能证明行为符合预期。因此，语句覆盖适合做“盲区定位”，不该单独充当测试质量的代理指标。

3. 选型结论按项目类型分流

• Java、已有 JUnit 测试基础：先用 EvoSuite 或 Randoop 做可控样本对照；如果需要商业支持、团队级治理或集成能力，再验证 Diffblue Cover、Parasoft Jtest。
• C#、使用 Visual Studio 的团队：先确认 IntelliTest 对当前版本、目标框架和项目结构的支持，再用一个业务逻辑清晰的类进行验证。
• 代码量大、测试缺口广：优先选能批量处理、便于审查和持续集成的方案；不要一次性让工具生成整个仓库的测试。
• 代码具有大量外部依赖：先梳理可替换依赖和测试边界。工具无法替团队决定数据库、消息队列或支付接口在单元测试中的正确替身行为。

如果项目语言不在这些工具的主要支持范围内，或者团队真正缺少的是需求验收场景，而不是低层单元测试，不要因为“自动生成”这个标签强行套用。此时更应评估适配该语言的测试框架、静态分析和基于需求的测试设计流程。

二、背景与真实场景：为什么自动生成用例会被误用

1. 覆盖率缺口常常来自“难以进入”，不只是没人写测试

在遗留项目中，低覆盖区域经常出现在构造过程复杂、依赖无法替换、全局状态难以重置的代码里。测试人员并非不知道那里需要测试，而是要搭建一套与生产环境相似的前置条件，才能让目标方法跑起来。自动生成工具能够减少一部分输入探索工作，但它不会自动消除架构耦合。

例如，一个订单计算类如果只接受金额、折扣和税率，工具较容易生成边界输入；如果它在构造时就读取数据库、系统时间、环境变量和远程配置，那么生成器面对的不是一个简单函数，而是一串需要处理的副作用。它可能不断尝试不同调用序列，却因为初始化失败而无法触达真正的业务逻辑。

2. 语句覆盖的“覆盖”有明确但有限的含义

语句覆盖通常关注测试运行时是否执行了可计数的语句。分母如何计算，会受语言、编译器插桩、工具定义和排除规则影响。它也不等同于分支覆盖、条件覆盖、路径覆盖或变异测试得分。一个包含多个条件的判断语句，可能在被执行后仍未检查所有真假组合。

因此，我不会跨不同覆盖工具直接比较一个百分比，也不会把测试执行覆盖与生产代码缺陷率建立未经验证的因果关系。团队应固定覆盖工具、版本、排除规则和构建方式，先建立同口径基线，再讨论变化。

3. 自动化最有价值的环节是把“探索”变得便宜

生成器的优势不是替代测试设计，而是更快尝试输入、对象状态和方法序列。它可以帮助团队发现过去没触发过的语句，也可能暴露空指针、数组越界、非法状态转换等意外行为。但“触发了异常”不自动意味着“发现了业务缺陷”：有些异常是输入契约允许的，有些则反映了系统对非法输入缺乏防护。

我的判断是：自动生成最适合用在两类地方。第一类是逻辑边界明确、输入输出可观察的纯业务代码；第二类是测试债务很高、人工补齐基础回归用例成本过大的稳定模块。对强依赖外部服务、并发时序或业务规则频繁变化的代码，自动生成适合作为辅助探索，不应直接接管验收责任。

4. 生成器的实际流程包含多个损耗点

从工具启动到用例合入，中间会经过编译、依赖解析、目标类选择、输入搜索、测试代码生成、格式化、人工审查和重复运行。每个环节都会损耗效率。比如一次生成耗时很短，但生成结果大量依赖私有实现细节，开发者每次重构都要改测试，长期总成本仍可能很高。

三、五款工具拆解：生成机制比功能宣传更重要

1. EvoSuite：适合用覆盖目标驱动探索 Java 类

EvoSuite 是 Java 自动单元测试生成领域常被评估的工具之一。它的典型思路是围绕目标覆盖进行搜索，生成一组测试来触达目标类中的行为，并可对测试套件进行压缩。对输入有限、依赖相对简单的类，这种方式适合快速建立初始测试骨架。

我会优先把它放在纯计算类、集合处理、格式转换、参数校验和具有明确对象状态的代码上试用。若一个类的方法能在隔离环境中运行，输入边界可枚举或可变异，生成器往往比较容易找到新的执行路径。评估时要检查测试是否只固化当前实现细节，尤其是集合顺序、异常文本和私有状态相关的断言。

适用边界：依赖反射、线程调度、网络响应、文件系统状态或不可控时间的类，需要先处理环境隔离。不要把测试生成器难以稳定覆盖这类代码，简单归因于工具能力不足；也可能是测试边界本身没有设计好。

2. Randoop：适合探索对象方法组合与意外行为

Randoop 采用反馈式随机测试生成思路，通过尝试方法调用序列并观察执行结果，逐步探索可用的对象状态和交互。它的独特价值在于，有些问题不是单个方法的参数边界，而是对象经过一系列合法或非法调用后进入了不一致状态。

例如，集合先加入元素、再清空、再读取；或者一个状态对象经历初始化、更新、关闭后再次操作。手写测试通常会覆盖团队熟悉的调用路径，随机序列则可能找到开发者没有主动想到的组合。生成结果因此常带有“探索性”，需要团队判断异常究竟是合法行为、契约缺失，还是实际缺陷。

评估重点：重复执行同一批结果是否稳定、生成序列是否可读、失败是否能缩减为简单复现步骤。若失败序列很长，定位成本可能抵消发现问题的收益。还要设定明确运行时长和目标包范围，避免随机探索占用构建资源。

3. Diffblue Cover：重点评估测试可读性与团队工作流

Diffblue Cover 面向 Java 单元测试生成场景，团队评估时通常会同时关注生成结果、开发环境集成方式和批量应用的实际成本。与开源工具一样，判断它是否合适不能只看演示生成了多少测试，而要看生成代码是否符合项目测试规范、能否进入代码评审、是否便于开发者修改。

我会拿同一组 Java 类与其他候选方案做盲评：隐藏生成来源，让熟悉项目的开发者判断每个测试在验证什么、失败时能否快速定位，以及改动业务实现后测试是否容易维护。这种方式能减少“因为看起来自动化程度高，就默认结果更先进”的认知偏差。

采购或扩大部署前，应向供应方确认当前版本对 JDK、构建系统、IDE、CI 环境和项目结构的支持，以及授权、数据处理和离线使用要求。产品能力与许可条款可能随版本变化，本文不把某一版本的功能承诺当作永久事实。

4. IntelliTest：适合 .NET 项目探索输入与边界条件

IntelliTest 面向 .NET 开发环境，可围绕参数化测试探索输入空间，并生成用于后续验证的测试。对 C# 中参数类型明确、分支逻辑集中、依赖较少的方法，它有机会快速暴露边界输入和异常路径，帮助开发者把探索结果转成可维护测试。

使用前要确认 Visual Studio 版本、目标框架、项目格式以及团队当前的测试框架是否兼容。功能在特定开发环境中可用，不代表所有仓库结构和构建代理都能无差别使用。建议先在开发机生成，再验证生成的测试是否能在命令行和 CI 中独立运行。

需要特别审查生成的输入数据是否有业务意义。一个整数参数的极大值、负值和零值是有用候选，但是否应该被接受，需要由产品契约决定。否则，测试可能只是在固定一个从未承诺的实现行为。

5. Parasoft Jtest：适合看重企业质量流程的 Java 团队

Parasoft Jtest 面向 Java 代码质量与测试相关工作流。对大型团队而言，评估重点不应只限于测试生成，还包括与现有构建、质量门禁、覆盖率分析和团队规范的衔接程度。平台型工具的价值可能来自流程整合，但也意味着需要明确实际使用范围，避免为未采用的功能支付实施和维护成本。

试点时应把“生成效果”和“平台落地成本”分开记录：前者包括新触达语句、有效断言比例和用例稳定性；后者包括环境配置、规则定制、CI 执行时间、培训与版本管理。若团队真正需求只是补齐少数核心类的单元测试，完整平台未必是最经济的路径。

6. 不要把工具清单误读成同一赛道的等价比较

这五款工具的生态、语言和定位并不相同。EvoSuite、Randoop 和 Diffblue Cover 面向 Java，但生成机制和工作流侧重点不同；IntelliTest 的目标是 .NET 环境；Parasoft Jtest 更适合结合企业流程评估。实际对比应先按语言与项目边界筛掉不适用项，再比较同一模块上的结果。

四、常见误区：覆盖提高，不代表测试可信

1. 误区一：语句覆盖达到目标，就可以停止补测

语句覆盖是一个视角，不是质量合格证。假设代码中有一条退款分支被执行过，但测试没有验证退款金额、状态变化和重复退款防护，那么覆盖率上升并不能说明核心风险已经受控。对关键业务逻辑，至少还要看分支条件、异常行为、状态转换和关键不变量。

我会把覆盖率当成“还有哪些代码没有被测试触及”的导航图，而不是“测试已经足够”的裁决书。覆盖工具指出空白后，团队再判断该区域需要自动生成、手写用例、集成测试，还是明确排除。

2. 误区二：生成的断言越多，测试越强

大量断言可能只是把当前输出完整拍照保存下来。例如，复杂对象的所有字段都被断言，但其中不少字段属于实现细节，业务上并无稳定承诺。未来重构只改变内部表达方式，测试就会大面积失败，团队随后可能习惯性删除断言，反而削弱保护能力。

审查断言时，我会逐条问：它对应什么业务规则？如果该规则被破坏，断言是否会失败？如果只是内部字段变化，是否应该仍然通过？这比数断言条数更能判断测试是否有价值。

3. 误区三：生成器发现的异常一定是产品缺陷

工具探索出的非法参数、对象调用顺序或异常输入，必须结合公开契约判断。有的输入依法应被拒绝，有的行为是内部实现细节；另一些看似罕见的输入，可能暴露了真实的安全、稳定性或数据一致性问题。没有契约和业务解释，生成器只会给出“这里发生了什么”，不能替团队给出“这是否错误”。

4. 误区四：覆盖率增加就是效率增加

需要把运行时间和人工时间一起算。某工具 10 分钟生成 200 个用例，但开发者要花一天理解、修复和删除其中的大部分，这不是效率提升。相反，工具只生成 20 个高质量候选，经过半小时审查后稳定进入回归，可能有更高的投入产出比。

团队应记录净节省工时，而不只是生成时长。至少统计配置耗时、用例审查耗时、失败定位耗时、维护耗时和 CI 增量耗时，并用同一周期计算。

5. 误区五：把生成测试直接合并进主分支

生成代码也需要像其他代码一样经过评审。批量生成的测试可能含有难以解释的对象构造、冗余序列、与平台相关的输出，或将偶然结果固定为期望值。先分批生成、按类审查、重复运行，再逐步纳入主分支，更容易发现问题来源，也便于回滚。

五、专业评估方法：怎样判断工具值不值得留下

1. 先定义测试对象，不要拿整仓库做首轮试验

试点样本要足够代表真实复杂度，又能在有限时间内分析。通常可以选 8 至 15 个类，覆盖纯逻辑、集合处理、边界校验、遗留代码和轻度依赖等不同类型。避免只挑最容易生成的类，否则结果会过于乐观；也不要只挑无法构建的历史遗留类，否则会误判工具无效。

对照组与工具组应使用相同代码版本、构建命令、覆盖工具和排除规则。若团队已有手写测试，不要先删掉再比较；应明确哪些结果来自既有测试，哪些是工具新增，避免把基线能力算到工具头上。

2. 建立一张可复现的评估记录表

• 记录仓库提交版本、运行环境、工具版本和关键配置。
• 记录目标类数量、目标方法数量，以及排除项和排除理由。
• 记录运行前后的语句覆盖与分支覆盖，但不把两者混成一个分数。
• 随机抽取生成结果，评估断言是否验证业务契约，标注无断言、弱断言和有效断言。
• 将同一批测试独立执行至少数轮，并尝试变更执行顺序，观察间歇失败。
• 记录审查、修复、去重、故障排查和后续维护的实际工时。

这套记录的目的不是制造复杂的评分体系，而是让选择可复核。如果工具 A 生成覆盖更多，工具 B 的测试更容易维护，团队可以依据自己的风险和资源做明确取舍，而不是凭演示印象决定。

3. 用“有效新增覆盖”替代单纯的新增覆盖

可以把新增语句分成三类：有有效断言保护的新增覆盖、仅触达但没有有效断言的新增覆盖、与业务无关或不适合单元测试的新增覆盖。只有第一类可以直接记为“高价值新增覆盖”；第二类更像待完善的候选，第三类则应说明排除原因。

这并不意味着没有断言的测试毫无意义。有些测试能触发初始化故障、崩溃或资源泄漏，依然可能有价值。但其价值应单独描述，不能与验证功能正确性的断言测试混为一谈。

4. 用变异思路检查断言是否真的能发现错误

若一个测试断言看起来合理，却在实现被轻微改错后依然通过，它就未必保护了想要保护的行为。团队可以在关键逻辑上做简单变更试验：把边界比较符改错、移除必要校验、替换关键返回值，观察测试是否失败。正式的大规模变异测试工具不是本文推荐工具的替代品，但这种思路能帮助审查测试是否有检测力。

例如，原逻辑要求金额大于零才允许提交，可以尝试让条件改为大于等于零。若生成测试仍全部通过，说明用例没有真正验证零值边界。此时补一条有明确业务意图的测试，通常比再生成几十条普通输入更有价值。

5. 建议使用项目自己的权重，不设通用冠军分数

团队可以按风险设权重。对金融计算，边界检测和断言有效性权重更高；对遗留系统补测，生成速度和覆盖盲区发现能力可能更重要；对高频重构模块，可读性和维护成本应占更大比重。评分只用于结构化讨论，不能伪装成客观真理。

六、案例与数据观察：一个订单计算模块如何试点

1. 案例边界与数据口径

下面用一个订单折扣与退款计算模块说明评估方式。它包含金额校验、折扣上限、状态判断和退款金额计算。为避免把模拟数据误读为产品实测，以下数字均为情景模拟，只展示如何分析结果，不代表五款工具的性能排名。

假设模块有 24 个可测试方法、约 310 条可计数语句，原有自动化测试覆盖 46%。团队从 12 个具有代表性的类中选出样本，对每款候选工具分别评估；实际执行时应使用独立工作区，避免前一款工具生成的测试污染后一款结果。

2. 先把业务规则写成可验证条件

测试生成前，团队先确认三项规则：优惠不得超过订单可折扣金额；已完成退款的订单不能重复退款；退款金额不能大于可退余额。这些规则让评审人员能判断生成用例是否有意义，而不是看到断言就默认正确。

其中一项规则可以在测试里表达为：退款成功后，订单状态进入已退款，且剩余可退金额归零。另一个用例则验证重复退款应被拒绝，并确保拒绝操作没有产生第二次资金变更。断言针对的是外部可观察行为，而不是私有字段的具体名称。

3. 模拟结果显示，候选数量不等于有效产出

在这个情景里，工具生成结果数量从 43 到 126 不等；生成数量较多的方案并没有自动成为首选。经过编译、去重、断言审查和稳定性检查后，最终可进入回归的测试数量差距缩小。试点最终要回答的不是“谁给了最多代码”，而是“谁以最低总成本补上了可解释的风险保护”。

4. 重点观察新增覆盖来自哪里

情景模拟中，新增覆盖主要分布在金额边界校验、空集合处理和状态转换前置判断。团队发现，容易生成的输入检查为覆盖率贡献明显；真正高风险的“重复退款”路径，则需要把状态变化和副作用纳入断言。这个差异说明，覆盖盲区并不都具有相同业务价值。

评审时，我会把新增语句映射回规则和风险：它是在保护核心不变量，还是仅触达了错误处理分支？若生成器命中了异常路径，团队是否确认了异常类型和状态回滚要求？这些问题能把覆盖数字转化成具体的测试决策。

5. 数据观察的边界不能省略

模拟项目没有控制语言版本、仓库规模、人员熟练度和工具配置，因此不能推出普遍性能结论。真正试点应至少保留一份工具原始输出、一份筛选后的测试集、一份手工工时记录和一份重复运行结果。任何“效率提升百分比”都应写清比较基线、样本范围和统计方法。

如果团队打算把结果用于预算或采购决策，还应把许可费用、培训成本、环境维护和长期测试修复纳入总拥有成本。单轮试点省下的几个小时，不能直接外推成全年节省工时，除非项目规模、使用频率和质量收益都有合理估算。

七、落地步骤：从一个类开始，而不是一次性铺满仓库

1. 第一步：挑一个高价值且可隔离的模块

优先选择有明确输入输出、近期没有大规模重构计划、手工测试明显不足的模块。不要从全仓库启动，也不要先从依赖最复杂的服务入口开始。小范围试点能缩短定位路径，出现失败时也更容易判断是构建配置、代码结构还是生成结果的问题。

2. 第二步：固定环境与基线

记录代码提交、编译版本、依赖锁定文件、测试命令、覆盖率工具和排除规则。试点前至少跑一次基线构建，确认原有测试稳定。若现有测试已经间歇失败，先处理噪声，否则自动生成结果会混入难以区分的失败来源。

3. 第三步：划定生成范围与时间预算

按包、类或方法限定目标，并设置合理的生成时长和最大候选量。运行越久不一定越好；搜索空间扩大后，结果数量和噪声也可能同步增长。建议先从短时运行开始，分析新增覆盖的边际变化，再判断是否值得增加时间。

4. 第四步：按行为意图分批审查

• 先检查新增覆盖落在哪些方法和代码段。
• 再检查每个测试的输入、调用序列和断言。
• 对异常类测试，确认异常是否符合公开契约。
• 对依赖外部状态的测试，确认替身、时间和随机性处理方式。
• 对重复或难以解释的测试，优先删除或改写，不为了保留生成数量而合入。

审查时可将测试分成“直接合入”“人工改写后合入”“保留为缺陷线索”“拒绝合入”四类。这样既不会把所有生成结果一刀切，也能让团队沉淀哪些代码结构不适合当前生成方式。

5. 第五步：重复运行并接入 CI

合入前要在干净环境中重复执行，并尝试单独运行与全量运行。测试若仅在某个顺序下通过，就可能依赖共享状态；若本地通过、CI 失败，则要检查时区、文件路径、并发、环境变量和依赖差异。确认稳定后，再逐步纳入持续集成。

6. 第六步：用真实维护周期复核收益

一次生成成功只是短期信号。经过一次正常重构或业务变更后，观察测试是否容易更新、是否频繁出现与需求无关的失败，以及开发者是否愿意阅读和维护它们。若测试很快被绕过或删除，最初的覆盖提升可能只是短期数字收益。

八、不同团队的行动建议与取舍

1. 小团队：优先降低部署和审查负担

小团队通常没有专职测试平台人员，适合从一个依赖少、业务规则清晰的模块开始。重点看工具能否沿用现有构建命令、生成结果能否被开发者快速理解，以及失败时是否容易复现。若配置和维护成本过高，少量手写高价值测试可能更划算。

取舍上，小团队不必追求覆盖率目标看起来漂亮。应优先保护支付、权限、状态转换、数据校验等关键路径；对低风险、频繁变化且缺乏清晰契约的区域，可以先补测试设计和代码隔离，再考虑自动生成。

2. 中大型团队：重视标准化、权限与结果治理

多团队组织需要先统一工具版本、运行方式、覆盖口径、生成代码规范和审查责任。若各团队使用不同设置，覆盖率横向比较会失去意义；如果生成测试没有明确所有者，后续失败容易被当成“工具产生的噪声”而无人维护。

这类组织更适合建立试点模板和准入清单：什么代码可以生成、哪些测试必须人工复核、失败如何升级、测试如何标记生成来源、更新时谁负责。涉及源代码或构建信息交给外部服务处理时，还需由安全与法务团队确认数据处理边界和授权条款。

3. 遗留系统团队：先改善可测试性，再扩大生成

若测试生成器长期卡在构造阶段、数据库连接或全局状态，先检查依赖注入、接口边界和环境隔离。对可拆分的业务逻辑，可以把计算规则提取到无副作用组件，再在该边界生成测试。自动化工具可以暴露结构问题，却不应被要求替代架构重构。

取舍上，遗留系统的短期目标可以是“减少关键模块盲区”，不必一次性达到高覆盖率。先保护改动最频繁、故障代价最高的代码，再逐渐扩展，通常比对全仓库追数字更稳妥。

4. 安全或高可靠团队：覆盖率之外还需独立证据

对安全、资金或高可靠系统，自动生成测试可以补充边界探索，但不能代替威胁建模、代码审查、接口契约验证、故障注入和人工设计的关键场景。要验证的不只是“语句走到了”，还包括授权边界、数据一致性、幂等性、回滚和异常恢复。

此类团队应把生成测试定位为补充证据，并对高风险行为保留人工定义的预期。工具生成的测试如果不能明确对应安全属性或业务不变量，不宜作为重要控制的唯一证明。

5. 不同目标下的取舍清单

九、常见问题与最后的决策建议

1. 自动生成测试能不能替代手写单元测试

不能完全替代。自动生成适合扩大输入探索、发现未触达路径和补齐部分基础回归；手写测试更适合表达业务意图、关键不变量和产品约定。比较有效的组合是让工具提供候选，再由熟悉业务的人保留、修订或拒绝。

2. 语句覆盖和分支覆盖应该优先看哪个

两者回答的问题不同。语句覆盖回答哪些语句执行过，分支覆盖更关注判断结果的不同方向是否发生。对于复杂条件，分支覆盖也不一定证明所有条件组合都被充分测试。应根据风险选择指标，并将覆盖数据与断言质量、失败检测能力结合起来看。

3. 自动生成测试不稳定，应该立即换工具吗

先定位不稳定来源：是时间、随机数、系统环境、测试顺序、共享状态、并发，还是生成器本身的搜索结果变化。若问题来自代码无法隔离的副作用，换工具未必解决根因；若结果难以重现、无法控制随机种子或不适配现有构建环境，再把稳定性作为工具淘汰依据。

4. 什么时候适合增加自动生成范围

当试点中的新增覆盖可解释、有效断言比例达到团队设定标准、测试能在 CI 稳定运行，而且审查与维护成本可接受时，可以扩大到相邻模块。若其中任何一项明显不达标，先修正流程或代码边界，不要单靠增加生成时长掩盖问题。

5. 选型的最终判断

我的最终判断不是“哪款工具生成得最多”，而是“哪款工具能在当前代码结构和团队能力下，持续产生可理解、可重复、维护得起的测试”。Java 项目可以把 EvoSuite、Randoop、Diffblue Cover 和 Parasoft Jtest 纳入同仓库小样本评估；.NET 项目则先验证 IntelliTest 与当前开发环境的兼容性。工具名单只是起点，真实代码上的对照实验才是决策依据。

下一步建议：选一个覆盖不足但边界清楚的模块，冻结代码版本和测量口径；运行一款候选工具，抽样审查断言，重复执行并记录全部人工耗时。只有当新增覆盖能够转化为可解释的行为保护，且长期维护成本低于团队获得的回归价值时，才值得把自动生成纳入常态流程。测试效率真正的倍增，不是写出更多测试，而是更快找到风险、保留有效验证，并让这些验证在下一次改动时仍然可信。