这个文档有点笼统，相信大家也都有自己的想法，我在这里写一些我自己的看法，请大家指教。
自动化测试工程师的理解
什么叫做自动化测试工程师
首先，会使用自动化测试工具的测试人员不能够称之为完全的自动化测试人员，这类测试人员被称为『工具小子』(Script Kid)。这个阶段还是处于自动化测试的一个比较低级的阶段，因为这些工具都不是测试人员开发的。
对于高手来说，要能写一些独立的测试脚本甚至测试工具。
更高的高手则是能脚本和工具和实际工作紧密结合起来，解决工作中遇到的问题。
自动化测试工程师应该具有开发能力吗
- 通过上述内容，应该可以看得出来，自动化测试人员一定要有开发能力，而这恰恰是测试人员目前所欠缺的。没有开发能力的测试人员虽然也可以做一些所谓的自动化，但是仅仅是一些皮毛，没有办法做到活学活用。
- 根据某机构的调查数据，目前所有从事测试工作的人中，90%的人都没有任何开发能力。根据目前的市场行情，如果在精通一门开发语言，能够从纯手工测试转型为自动化测试工程师，月薪至少增加3~5k。(没有前提, 这就是社会! ! !)
自动化测试的层级
一般来说，自动化测试分为三个层级：单元测试、接口测试和UI测试，这三层成一个金字塔形状分布。最底层是单元测试，接口测试在中间，UI测试在最上层。下面通过一个表格来对比着三层测试。
| 层级 | 所处位置 | 受益 | 测试对象 | 运行速度 | 定位问题难度 | 维护成本 |
|---|---|---|---|---|---|---|
| 单元测试 | 底层 | 70% | 类或者方法 | 极快 | 十分容易 | 低 |
| 接口测试 | 中间 | 20% | 服务接口 | 快 | 一般 | 低 |
| 功能测试 | 上层 | 10% | 界面 | 慢 | 较难 | 非常高 |
不是说功能测试不好, 而是根据接口测试,与单元测试进行对比得到的结果!
测试人员应该怎么办
单元测试
单元测试无疑是最适合做自动化的，但是，大多数单元测试都是由研发人员自己完成。单元测试的代码行覆盖率能够达到70%，就是一个非常不错的程度了。测试人员不做单元测试，但是可以尝试推动研发人员来编写单元测试用例。
单元测试框架
- 单元测试常用的框架——XUnit，比如Java的JUnit，PHP的PHPUnit，Python的unittest等等；
- 一个测试用例通常由三部分组成——setUp，测试逻辑，tearDown。setUp用于准备测试数据，tearDown用于清理数据；
-
一般单元测试框架都支持装饰器设计模式的注解，比如跳过执行，测试套件的组织，测试用例依赖管理等等
单元测试框架可以无缝地在UI测试和接口测试中使用，它们的基本思想都是相通的。
UI测试
目前，大众眼中关注的比较多的是UI的自动化测试，这是由大家的思维惯性导致的。传统的测试行业，测试工程师都是从UI下手，来完成所有的测试工作，所以到自动化领域，大家也理所当然的喜欢从UI层来进行自动化。做UI自动化，最重要的是要能有一个好的自动化测试框架，这里有一些框架的基本设计思路供大家参考：
- 分布式——case增加到一定程度后，如何快速的运行所有的case，这就涉及到分布式的概念。对于Selenium，官方提供了一个Grid，感兴趣的同学可以研究一下；
- 行为驱动——也就是常说的Cucumber，这个领域笔者没有太多的涉足，不误导大家
- 关键字驱动——由『操作对象』、『操作』、『数据』关键字组合成测试用例，框架来把关键字解析为脚本并执行。这种框架最大的优点就是可以提供给不懂代码的测试人员使用，典型的代表是Robot framwork
- 数据驱动——同一段代码的业务逻辑通过更换数据输入来生成多个测试用例，我们只需维护测试数据就可以维护case，这种框架思想在很多测试工具中都有实现
-
关键字和数据混合驱动——目前最高级的框架，将上述两种框架结合起来
当然，这些思路不仅仅能用在UI层的自动化。
对于UI自动化，我个人的建议是只做冒烟测试用例的自动化，这样既可以从UI的角度来重复性的验证主业务主流程没有问题，又可以降低维护成本。
以上 原文出自: https://blog.csdn.net/flying1943/article/details/51504651
接口测试(重点)
1. 什么是接口测试
接口的自动化是目前最适合测试工程师进行自动化的一层。接口不但变化小，运行速度快，受益高，还有着出现问题后能够很快定位的优点。(说白了, 就是我还不会单元测试)
顾名思义，接口测试是对系统或组件之间的接口进行测试，主要是校验数据的交换，传递和控制管理过程，以及相互逻辑依赖关系。其中接口协议分为HTTP,WebService,Dubbo,Thrift,Socket等类型，测试类型又主要分为功能测试，性能测试，稳定性测试，安全性测试等。
在分层测试的“金字塔”模型中，接口测试属于第二层服务集成测试范畴。相比UI层（主要是WEB或APP）自动化测试而言，接口自动化测试收益更大，且容易实现，维护成本低，有着更高的投入产出比，是每个公司开展自动化测试的首选。
下面我们以一个HTTP接口为例，完整的介绍接口自动化测试流程：从需求分析到用例设计，从脚本编写、测试执行到结果分析，并提供完整的用例设计及测试脚本。
2. 基本流程
基本的接口功能自动化测试流程如下：
需求分析 -> 用例设计 -> 脚本开发 -> 测试执行 -> 结果分析
2.1 需求分析
一般情况是 产品经理, 或者产品人员在原型, 或者需求文档评审完成以后, 开发人员会很久原型文档设计接口, 咱们接口测试人员就要根据开发设计出来的文档设计, 来分析接口和原型文档定义的是否完全, 同时根据接口设计用例.
2.2 用例设计
到了这一步, 就要设计了, 不过,不用像功能测试用例那样, 设计的特别详细, 只需要有主流程, 或者流程分支的用例就好了, 毕竟自动化测试, 不是用来发现BUG的, 而是用来确定这个流程上, 是不是有问题.
2.3 脚本开发
这一步, 就有很多种选择了, 可以用 JMeter, postMan, readAPI, java, python 等等 测试工具都可以使用. 具体的我后面会写. (我使用过很多工具, 最后我决定了用灵活的编程语言python, 来写自动化接口测试. 没有复杂的语法, 却又有不一般的灵或性. )
2.4 测试执行
这一步, 就简单了, 右键 RUN 所有工具全都是, 运行结果要保存起来, 不然, 根本不知道运行完了, 有没有问题.
比如说: 注册的接口, 注册完了, 数据库里有没有添加数据. 或者说, 查询接口,有没有吧数据库里的数据查询出来. 等等这都是需要断言的地方. 用一个专门的日志文件, 保存起来, 还有有专门的程序,去断言. 不然写完了, 也要自己去看, 这不能是自动化测试.
2.5 结果分析
这个就是分上一步输出的日志, 或者说是断言结果.
总结
接口测试吗, 可不是, 用个工具, 写个路径, 添点参数, 调用一下, 一看返回值是成功的, 就说这个接口就成功了.
实际上, 就一个简单的 添加数据,
- 数据的接口, 是给出接口需要的参数, 然后调用接口
- 看接口的返回值, 是成功的, 还是失败的.
- 在看接口保存数据的地方, mysql , mongDB 等等的中的一个, 看数据是否保存进去.
-
在调用查询接口看这条数据能够白查询出来
看上去复杂的4步, 但是用 python脚本来执行的话, 执行下来,连 1秒钟都用不上.
用例要怎么设计, 脚本要怎么写, 执行结果要怎么看, 我后边会慢慢的更新, 求大家给个关注 谢谢了