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