测试过程的优化问题

测试过程的优化问题

想到这个问题，还是因为这两天抽时间优化前段时间用python写的一个分析统计项目工作量的脚本时想到的。

最初的这个python脚本，我只是按照想法直接实现了一版，并没考虑太多结构上的东西，能跑出结果来就挺满意，中间还解决了邮件发送图片的问题，当时觉得还是挺有意思的一件事。

But, 在实际使用的这段时间，我发现项目每进一个新人，我都要改动代码中非常多的地方，痛苦不堪。于是被迫重新优化一下原来的脚本，当我回过头去看我最初写的那个版本，代码烂的简直是一坨屎。

于是花了一些时间，重新调整结构，把人员变量抽离出来，这样项目新加人的时候，只需要增加新的变量就好了，不用调整太多代码。完成这个版本后，觉得已经很好了。

但是，又过了几天，我回过头再去看调整后的代码时，发现，还是很糟糕。。。

虽然添加人员方便了很多，但是代码明显存在很多冗余的地方，这样当我们查看具体逻辑时，还是显得很混乱。于是，我又抽时间优化了一版，把可复用的内容都抽象出来，让代码逻辑上更清晰一些。

整个过程，脚本代码从一千多行优化到只有六百多行，可见，最初版本的代码简直不忍直视。

通过修改这个脚本的过程，带给我的感触就是，很多事情，做完了并不意味着是一种良好的状态。当我们在过程之中遇到问题时，还是要尝试去优化以前的内容。优化也并不意味着是一次完结的事情，可能要反复很多次，总会有更优的解决方案出现。

实例化到我们日常的测试过中，会有很多类似的问题。

比如我们测试一个功能时，发现了很多bug，以为测试全面了。但是当我们静下心来再次回顾这个功能时，往往还是能够发现很多以前没有测试到的地方。

同样写用例也是如此，哪怕功能需求没变更，等我们写完之后，再去回顾通篇用例时，还是能够发现遗漏或冗余的地方。

同样的情况可能会出现在我们日常工作中的很多地方，测试的过程是个持续优化的过程，通过不断的优化和迭代，可以使得我们的测试工作越来越优秀。

最后，补充说明一点，有些事情需要慎重考虑，三思而后行，不适用迭代方式，比如某些决策类行为。有些事情可以通过不断的迭代来做好，先把事情做完，解决当前面对的问题，再考虑后续的优化，比如日常具体的执行类事务。大家还是要根据实际情况来权衡。