自动化测试拉开的距离

Joyine 2019-09-19

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


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

相关推荐