背景

接《自动化测试的适用范围》

会用工具就是自动化测试工程师吗

会使用自动化测试工具的测试人员不能够称之为完全的自动化测试人员，这类测试人员被称为工具小子(Script Kid)。这个阶段还是处于自动化测试的一个比较低级的阶段，因为这些工具都不是测试人员开发的。

对于高手来说，要能写一些独立的测试脚本甚至测试工具。更高的高手则是能脚本和工具和实际工作紧密结合起来，解决工作中遇到的问题。

单元测试无疑是最适合做自动化的。大多数单元测试是由研发人员完成，测试人员可以不做单元测试，但是可以推动研发人员来编写单元测试用例

1、单元测试常用的框架有很多，比如Java的JUnit，PHP的PHPUnit，Python的unittest等

2、设计自动化单元测试测试用例时一个测试用例通常由三部分组成：setUp，测试逻辑和tearDown，其中setUp用于准备测试数据，tearDown用于清理数据

3、一般单元测试框架都支持装饰器设计模式的注解，比如跳过执行，测试套件的组织，测试用例依赖管理等等

4、单元测试框架可以无缝地在UI测试和接口测试中使用，它们的基本思想都是相通的。

接口的自动化是目前最适合测试工程师进行自动化的一层。

接口不但变化小，运行速度快，受益高，还有着出现问题后能够很快定位的优点。

目前，大众眼中关注的比较多的是UI的自动化测试，这是由大家的思维惯性导致的。

传统的测试行业，测试工程师都是从UI下手，来完成所有的测试工作，所以到自动化领域，大家也理所当然的喜欢从UI层来进行自动化。

做UI自动化，最重要的是要能有一个好的自动化测试框架，这里有一些框架的基本设计思路供大家参考：

case增加到一定程度后，如何快速的运行所有的case，这就涉及到分布式的概念。对于Selenium，官方提供了一个Grid，感兴趣的同学可以研究一下。

行为驱动就是常说的Cucumber

由『操作对象』、『操作』、『数据』关键字组合成测试用例，框架来把关键字解析为脚本并执行。这种框架最大的优点就是可以提供给不懂代码的测试人员使用，典型的代表是Robot framwork

同一段代码的业务逻辑通过更换数据输入来生成多个测试用例，我们只需维护测试数据就可以维护case，这种框架思想在很多测试工具中都有实现

较为复杂的测试框架框架，将上述两种框架结合了起来
当然，这些思路不仅仅能用在UI层的自动化。
对于UI自动化，可以选择只做冒烟测试用例的自动化，这样既可以从UI的角度来重复性的验证主业务主流程没有问题，又可以降低维护成本。

《在做自动化测试之前你需要知道的》https://www.cnblogs.com/fnng/p/3653793.html