自动化测试拉开的距离

无论你跑步有多快，我一踩油门就让你望尘莫及。

A团队引入了自动化测试工具
M团队奉行手工测试

两个团队做同一个系统，下面是版本历程

第一个版本有5个对外服务的接口。

A团队针对每个接口编写了尽可能全面的测试案例，并全都用代码实现，1分钟内可以进行全部接口测试。

M团队也很快实现了5个接口，并且手工测试了能想到的案例。全部接口全部案例测试一遍10分钟。

第二个版本新增5个对外服务的接口。

A团队针对每个新增接口编写了尽可能全面的测试案例，并全都用代码实现，1分钟内可以进行全部接口测试。

M团队也很快实现了5个接口，并且手工测试了能想到的案例。部署前要做回归测试（即确保修改的代码不会影响存量代码），全部接口全部案例测试一遍20分钟。

第三个版本修改3个对外服务的接口，新增3个接口，有些接口要共用一些代码块。

A团队为新增接口编写了尽可能全面的测试案例，并全都用代码实现，1分钟内可以进行全部接口测试。

M团队为每个改动或新增接口手工测试了能想到的案例。部署前要做回归测试（即确保修改的代码不会影响存量代码），全部接口全部案例测试一遍30分钟。

第四个版本修改5个对外服务的接口。

A团队修改完代码后，1分钟内可以进行全部接口测试，以检查是否有问题。

M团队为每个改动接口手工测试了能想到的案例。部署前要做回归测试（即确保修改的代码不会影响存量代码），全部接口全部案例测试一遍30分钟。

……

第N个版本修改一些地放，新增几个接口。

A团队修改完代码后，15分钟内可以进行全部接口测试，以检查是否有问题。（想像一下，计算机要跑15分钟的代码，是要干多少活）

M团队开发完成后，手工测试了能想到的案例。部署前要做回归测试（即确保修改的代码不会影响存量代码），全部接口全部案例测试花一天。

只用修改一个小地方。

A团队修改完代码后，15分钟内可以进行全部接口测试，以检查是否有问题。（想像一下，计算机要跑15分钟的代码，是要干多少活）

M团队开发完成后，只测试了修改处的某些案例，没有做回归测试（因为没时间）

上线后，M团队出现生产问题，因为修改的代码影响了别的逻辑，测试没有覆盖到。花了两天时间处理生产问题的手尾，代码重新修改，花至少一天时间测试（怕了），上线。

越到后期，A团队与M团队花在测试上的时间相差会越来越大，如果加上因为测试不全面导致上线后的返工时间，相差就更加大了。

从长远来看，A团队拥有更多的自主时间，或者投入到产品研发中，或者投入到技术研究中，或者投入到其它可以改善团队绩效的建设中，更容易得到持续的进步，从此走上自动化测试这条不归路（还没出现尝过自动化测试的甜头后再变回手工测试的情况）。

反观M团队，后期随着人员更替，系统的规模变大，有效的测试工作展开的非常艰难。有效是指，每次上线前系统每个可以测试的地方都测试过并且都符合预期，而不是靠着“我只改了这个地方，其它地方应该没问题”这种心态去对待测试，有个成语叫自欺欺人请了解一下。

当然，自动化测试不是要求绝对百分百的覆盖率，90%以上没问题，至少一定要覆盖核心功能。

真正优秀的产品离不开自动化测试，oracle数据库的自动化测试就要跑一个晚上。