Joyine 2019-09-19
无论你跑步有多快,我一踩油门就让你望尘莫及。
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数据库的自动化测试就要跑一个晚上。
4.启动命令windows:chrome --remote-debugging-port=9222启动命令mac:Google\ Chrome --remote-debugging-port=9222