自动化测试拉开的距离

不管你跑步有多快，我一踩油门就让你可望不可即。

---

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数据库的自动化测试就要跑一个晚上。