曾被很多次问到,怎样提高测试工作的效率?实话实说,我自己也是只有一些零零散散的思路,并没有一个可以解释的很完善的方法论。所以每次回答的时候,都是答的特零碎,比较认真回答的一次是在知乎上,我也把答案搬运到公众号里了,有兴趣的小伙伴可以查看6月13号公众号的文章《知乎上回答的3个问题》。
  即便是认真回答,发现还是会遗漏一些内容,比如我们聊的测试过程的优化问题,即可以看作是提升测试效率的一个零散的点。
  想到这个问题,还是因为这两天抽时间优化前段时间用python写的一个分析统计项目工作量的脚本时想到的。
  初的这个python脚本,我只是按照想法直接实现了一版,并没考虑太多结构上的东西,能跑出结果来挺满意,中间还解决了邮件发送图片的问题,当时觉得还是挺有意思的一件事。
  But, 在实际使用的这段时间,我发现项目每进一个新人,我都要改动代码中非常多的地方,痛苦不堪。于是被迫重新优化一下原来的脚本,当我回过头去看我初写的那个版本,代码烂的简直是一坨屎。
  于是花了一些时间,重新调整结构,把人员变量抽离出来,这样项目新加人的时候,只需要增加新的变量好了,不用调整太多代码。完成这个版本后,觉得已经很好了。
  但是,又过了几天,我回过头再去看调整后的代码时,发现,还是一坨屎。。。
  虽然添加人员方便了很多,但是代码明显存在很多冗余的地方,这样当我们查看具体逻辑时,还是显得很混乱。于是,我又抽时间优化了一版,把可复用的内容都抽象出来,让代码逻辑上更清晰一些。
  整个过程,脚本代码从一千多行优化到只有六百多行,可见,初版本的代码简直不忍直视。
  通过修改这个脚本的过程,带给我的感触是,很多事情,做完了并不意味着是一种良好的状态。当我们在过程之中遇到问题时,还是要尝试去优化以前的内容。优化也并不意味着是一次完结的事情,可能要反复很多次,总会有更优的解决方案出现。
  实例化到我们日常的测试过中,会有很多类似的问题。
  比如我们测试一个功能时,发现了很多bug,以为测试全面了。但是当我们静下心来再次回顾这个功能时,往往还是能够发现很多以前没有测试到的地方。
  同样写用例也是如此,哪怕功能需求没变更,等我们写完之后,再去回顾通篇用例时,还是能够发现遗漏或冗余的地方。
  同样的情况可能会出现在我们日常工作中的很多地方,测试的过程是个持续优化的过程,通过不断的优化和迭代,可以使得我们的测试工作越来越。
  后,补充说明一点,有些事情需要慎重考虑,三思而后行,不适用迭代方式,比如某些决策类行为。有些事情可以通过不断的迭代来做好,先把事情做完,解决当前面对的问题,再考虑后续的优化,比如日常具体的执行类事务。大家还是要根据实际情况来权衡。