自动化测试原因分析

无论你是软件测试人员还是程序猿， 自动化测试学习 都是必要的，首先，你想想下面的场景：
你利用重构之术让代码更简洁， 可读性更好，更高效，修改完成后，你泡上一杯清茶，躺在你的人体工学座椅上还在沉浸在刚才的美好之中， 这时QA找到你，
QA：请问你刚才提交代码了吗，
答曰：是的
QA: 你修改的那部分功能跑不通了，你没有测试吗
答曰：是吗， 我看看
…..
子曰：一切没有自动化测试的代码重构都是耍流氓。如果你重构了代码，却破坏了基本的功能，纵使代码再漂亮，性能再高，又有何用？

自动化测试
那么如何保证重构不破坏既有的功能？答曰：测试。无论你是单元测试，功能测试，集成测试，还是哔哩哔哩测试，总之你需要尽一切可能去测试。重构有一个个「点」（细胞）的重构，所以你需要单元测试；也有一个个「切面」（器官）的重构，所以你需要功能测试；当「切面」的改动甚大（器官移植），还需要集成测试…相关的测试是否存在决定了你能否重构；而测试所花费的时间直接决定了你是否会进行重构，以及以一个什么样的频率进行重构。如果重构了十行代码，却需要花费一个小时进行运行一次单元测试，那么你要么不会去重构代码，要么你重构了不会去测试。
好的重构发生在构建系统的每时每刻，而非问题发生或者老板要求。如果重构之后测试立刻会告知你结果，你会更有信心进行更多的重构，使其成为你工作生活的一部分。
你也许会质疑：什么样的单元测试可能会需要一个小时来完成？答曰：手工测试。这是为什么先验条件不是「测试」，而是「自动化测试」。没有自动化测试（以下简称测试），谈重构纯属扯淡。如果要重构的环节测试覆盖率不好，先想法提高覆盖率。

TODO 测试驱动开发
在测试驱动开发（TDD）这本书也写到，如何利用测试驱动开发。

总结
子曰：读万卷书不如行万里路。行动起来吧， 用实践说话，实践是检验真理的唯一标准。如果根本没有测试例，请先做好这个基本功再谈重构。


原文来自：jason’s blog