在自动化测试工作之前，你应该知道的 10 条建议

关于自动化测试，这些年经历了太多的坑，有被动的坑，也有自己主动挖的坑，在这里做了一些总结。
主要思考总结下这些年来自动化测试过程中的一些基本的东西，例如何时进行自动化、如何自动化、或是怎么自动化我们的测试工作。
c
注：笔者在这里对自动化的定义，不局限于UI、接口等，而是指在测试过程中所有基于技术进行解决问题和改进效率的技术测试，包括但不限于UI、接口、性能、安全等。
为什么要进行自动化测试？
1. 在我们日常的测试工作中，经常会引入新的需求或是修复bug，那么如何确定新的需求的加入或bug的修复没有在原有功能中引入新的bug呢？
我想为了保证原有功能的正常，是很有必要对原功能进行测试的。
那么在每次修复bug或新增需求时，我们都需要手动的测试所有功能吗？在没有更多的成本、资源、时间时，你依旧需要手动的进行测试，但其成效是否能达到要求呢?
我想这个时候，自动化测试的需求来了，在我们的日常测试工作中，有大量的回归测试需要我们把它们给自动化了。
2. 在我们的日常测试中，你会不会收到老板对你说：对我们的系统压测下，看看性能怎么样？
通常，对于大部分从事软件测试的同行来讲，不管是否具备这个技术能力，大都会收到这样的工作需求。
那么如何对系统进行压测呢？我想肯定不是让你去喊几百几千甚至过万的人来一起点点点，因为这个靠人力来做是不现实的事。
所以自动化你的压测工作就是必须的选项了。
3. 在日常测试工作中，是不是经常面临着这样的情况？UI已经不再大幅变更，而后端服务接口在不停的升级，这个时候UI级的自动化测试就显得有价值了。
同样的，在项目初中期，UI在不停的变更，但核心的业务接口已经初步稳定，这个时候接口级自动化测试也是引入的好时机了。
在不同的技术层级，我们可以根据其更新频度等情况，我们可以将其自动化，以达到改进效率和提升质量的效果。
将测试工作进行自动化，必然需要成本的投入的，同样也有着各种风险，下面是一些总结。
自动化测试的风险是什么?
在某些情况下，可能需要考虑自动化我们的测试工作，如果你已经做出了自动化的决定，或是打算进行自动化，那么你就需要考虑以下几个方面的场景：
1. 你的团队是否拥有足够熟练的资源？
想想你的团队，对于自动化测试是否有足够的编程开发知识和能力？如果没有，他们是否具备一定的基础，可以快速的掌握相应的技术？
是否打算组建一个好的自动化团队呢？如果是，那么可以考虑自动化你的测试工作。
2. 自动化的初始投入成本非常高
不可否认的是，手工测试的成本也是很高的，尤其是对于高素质的手工测试人才，如果你认为自动化测试能解决手工测试的成本问题，我建议你三思而后行。
自动化测试的成本体现在以下几个方面：
- 自动化工具的采购
- 人才的引入或培训
- 自动化测试脚本的维护
- 自动化测试的实施推广
等等其他
许多开展自动化测试的团队对于其自动化成果感到遗憾，因为在投入了大量的人力、时间、资源后，得到的仅仅是一堆基本的自动化脚本或是一个好看的测试工具。
请思考， 如果是这样的成果， 那么自动化的用途是什么呢？
3. 慎重对待UI自动化测试
在进行UI级自动化测试前要谨慎选择业务场景，尤其是要注意规避可能的大面积发生UI更新的场景，不然自动化脚本的维护成本会非常的高。
所以UI级自动化测试，笔者通常只自动化最核心的业务流程、或最典型用户业务场景，或重点关注的功能模块。
4. 是否需要系统足够稳定才可以自动化我们的测试工作？
笔者以为不用等到系统足够稳定时才开始自动化测试。
当然，前提是团队拥有足够强的技术功底，能从源码级或数据层级就开始规划、设计自动化测试解决方案。
5. 是否要考虑100%的自动化？
只能说，别做梦了，你要是都能100%了，那我点点点的功力如何发挥装X？当然了，在性能测试、回归测试、负载压力测试等领域，是有机会实现“100%”的。
6. 不要对一次性工作进行自动化
对于哪些可能只需运行一次或几次的测试工作，请不要将其自动化，太浪费了。
7. 你的自动化套件寿命足够长吗？
如果你选中的自动化场景生命周期不够长，那么请不要自动化它，构建自动化的一个基本准则是让自动化了的测试工作比手工执行成本要明显降低。

原文转自：http://www.ltesting.net