无论你跑步有多快，我一踩油门就让你望尘莫及。
A 团队引入了自动化测试工具
M 团队奉行手工测试
两个团队做同一个系统，下面是版本历程
- 第 1 个版本
第一个版本有 5 个对外服务的接口。
A 团队针对每个接口编写了尽可能全面的测试案例，并全都用代码实现，1 分钟内可以进行全部接口测试。
M 团队也很快实现了 5 个接口，并且手工测试了能想到的案例。全部接口全部案例测试一遍 10 分钟。
- 第 2 个版本
第二个版本新增 5 个对外服务的接口。
A 团队针对每个新增接口编写了尽可能全面的测试案例，并全都用代码实现，1 分钟内可以进行全部接口测试。
M 团队也很快实现了 5 个接口，并且手工测试了能想到的案例。部署前要做回归测试（即确保修改的代码不会影响存量代码），全部接口全部案例测试一遍 20 分钟。
- 第 3 个版本
第三个版本修改 3 个对外服务的接口，新增 3 个接口，有些接口要共用一些代码块。
A 团队为新增接口编写了尽可能全面的测试案例，并全都用代码实现，1 分钟内可以进行全部接口测试。
M 团队为每个改动或新增接口手工测试了能想到的案例。部署前要做回归测试（即确保修改的代码不会影响存量代码），全部接口全部案例测试一遍 30 分钟。
- 第 4 个版本
第四个版本修改 5 个对外服务的接口。
A 团队修改完代码后，1 分钟内可以进行全部接口测试，以检查是否有问题。
M 团队为每个改动接口手工测试了能想到的案例。部署前要做回归测试（即确保修改的代码不会影响存量代码），全部接口全部案例测试一遍 30 分钟。
……
- 第 N 个版本（系统变得很复杂与很庞大了）
第 N 个版本修改一些地放，新增几个接口。
A 团队修改完代码后，15 分钟内可以进行全部接口测试，以检查是否有问题。（想像一下，计算机要跑 15 分钟的代码，是要干多少活）
M 团队开发完成后，手工测试了能想到的案例。部署前要做回归测试（即确保修改的代码不会影响存量代码），全部接口全部案例测试花一天。
- 第 K 个版本
只用修改一个小地方。
A 团队修改完代码后，15 分钟内可以进行全部接口测试，以检查是否有问题。（想像一下，计算机要跑 15 分钟的代码，是要干多少活）
M 团队开发完成后，只测试了修改处的某些案例，没有做回归测试（因为没时间）
上线后，M 团队出现生产问题，因为修改的代码影响了别的逻辑，测试没有覆盖到。花了两天时间处理生产问题的手尾，代码重新修改，花至少一天时间测试（怕了），上线。
越到后期，A 团队与 M 团队花在测试上的时间相差会越来越大，如果加上因为测试不全面导致上线后的返工时间，相差就更加大了。
从长远来看，A 团队拥有更多的自主时间，或者投入到产品研发中，或者投入到技术研究中，或者投入到其它可以改善团队绩效的建设中，更容易得到持续的进步，从此走上自动化测试这条不归路（还没出现尝过自动化测试的甜头后再变回手工测试的情况）。
反观 M 团队，后期随着人员更替，系统的规模变大，有效的测试工作展开的非常艰难。有效是指，每次上线前系统每个可以测试的地方都测试过并且都符合预期，而不是靠着“我只改了这个地方，其它地方应该没问题”这种心态去对待测试，有个成语叫自欺欺人请了解一下。
当然，自动化测试不是要求绝对百分百的覆盖率，90% 以上没问题，至少一定要覆盖核心功能。
真正优秀的产品离不开自动化测试，oracle 数据库的自动化测试就要跑一个晚上。