1 定义
把以 人为驱动 的测试行为转化为 机器执行 的一种 过程。
- 简略讲：比方应用自动化测试框架、脚本、工具等主动关上测试对象（援用），主动去执行测试用例（此过程中蕴含自动化查找元素、控件等），主动输出测试数据、主动生成测试报告等一系列的自动化过程；
- 艰深讲：用机器来 模仿用户的理论行为，如键盘、鼠标等操作，来达到预期。
2 做自动化的目标是什么？
- 测试 工作量比拟大，应用自动化来实现一部分工作；
- 测试过程有 大量反复的工作，应用自动化来进行晋升效率；
- 手工测试难以 笼罩的场景，须要自动化造数据等来实现；
- 有些测试后果，可能自动化比手工更为 准确。
3 自动化测试的优缺点
| 长处 | 毛病 |
|---|---|
| 反复执行、频繁操作 | 不能 100% 代替人工测试 |
| 模仿手动测试无奈笼罩的场景 | 不能达到 100% 覆盖率 |
| 利用闲暇工夫执行 | 须要工夫去剖析后果 |
| 开释一部分测试人员精力 | 对软件品质依赖大（前提是软件稳固、改变小等） |
| 测试后果主观公正 | 须要业余的工程师投入专门的工夫开发 |
| / | 投入老本可能会大一些 |
4 自动化测试的前提条件（重要）
即做自动化前先对软件进行剖析，是否满足或者要不要做自动化，有几个前提条件须要留神。
4.1 需要变动不频繁
- 脚本的稳定性最直观的决定因素是 需要的变动 ，如果需要变动大，隔三差五的进行需要更改，那脚本势必也要进行同步更新，这样投入的 保护老本就很大，得失相当，还不如不做。
4.2 我的项目周期比拟长
- 自动化测试和一般的测试一样，须要后期的布局、框架设计、脚本开发、人员抉择、脚本执行、前期保护以及后果跟踪剖析等，是一个 比拟全的且投入较多 的一个过程，如果我的项目周期很短，就不适宜做自动化，其实也没必要；
- 另外我的项目周期短，手动测试都 无奈保障 的前提下，更不必谈及做自动化了。
4.3 脚本的反复使用率高
- 咱们投入了较大的人力、物力、财力等最终实现了一套比拟完满的自动化脚本、框架或者平台，然而 复用率很低，只能在单个产品独自应用，那么这样的代价就太大了。此时咱们须要评估是否必须要进行自动化测试，如果非必须，能够不做；
- 相同的，如果自动化的一系列货色都能 迁徙到其余的产品 测试，那这样的投入是值得的，也是必要的。咱们也应该投入更多的精力进行测试开发。
4.4 团队实力
- 做自动化，不是轻易摘抄一些代码拿来用，他是一个 专项测试 ，须要投入专门的 人力去钻研及测试 ，那么咱们要想做好自动化，先要对本人的 团队进行评估 ，团队的 人员、技术能力 等是否满足要求；
- 另外，自动化须要一直的进行 迭代和优化 ，不能拿着脚本运行看看后果，那其实很多时候，并不能给产品带来 主观的价值 。咱们须要进行不定期的 降级保护 ，针对我的项目业务要进行优化，依据测试过程和后果的数据反馈要进行 稳定性的降级 等等。所以这也须要专门投入人力进行钻研。
4.5 部门的布局和下级的反对
这个是我加的，依据集体的教训的总结；
- 部门的布局：如果自动化是在部门布局中，以及有考核指标，那必定是要做的。如果不是布局，也没有纳入计划，那就要依据理论状况定，毕竟这不会间接影响你团队的理论考评。你的重点应该是在其余的中央，优先保障工作重点内容的实现；
- 下级的反对：这个很重要，做自动化无非是为了晋升效率和品质，然而如果没有失去应有的成果，领导看不到问题，也无感知，那么做自动化兴许不会短暂。这个得缓缓领会了，哈哈。
5 利用场合
自动化测试次要利用在以下场合，具体还要依据我的项目以及自动化的理论开发状况开定：
| 场景 | 阐明 |
|---|---|
| 测试周期 | 我的项目周期长，轮次较多的软件 |
| 数据量级 | 须要制作大量的测试数据 |
| 软件稳定性 | 应用稳固和成熟阶段的产品测试 |
| 回归测试 | 须要进行简略回归的测试 |
| 冒烟测试 | 主线性能的冒烟 |
| 巡检测试 | 线上环境的定期巡检 |
| 公布验证 | 主线性能的公布验证测试 |
6 自动化意识误区（重点）
6.1 自动化可 100% 笼罩
- 概率不大，要使得自动化的测试覆盖率达到 100%，须要投入专门的人力、物力、财力等，老本比拟大；
- 某些业务的特殊性，或者场景的复杂性，用自动化是无奈进行笼罩的；
- 我的项目的周期限度，不容许投入更多的精力去开发；
6.2 自动化可代替人力
- 领导的口头禅：你就通知我，自动化能干掉多少人力？！==== 每次听到这样的话，不晓得你们怎么想的，反正我是很无奈。但从领导的角度来思考，也不为错；
- 这里存在一些误区，自动化测试是 辅助功能测试 的，或者说是为了解决某些人工不能笼罩的场景；
- 另外，不存在 完完全全的自动化，都是须要人工参加的；
- 遇到相似的意识，倡议自动化测试人员 须要进行解释，不能任由这个观点滋生，不然 === 你猜会咋办！！
6.3 自动化很牛逼
- 任何的事件，都是看谁先晓得而已，与其说牛逼的技术，不如说牛逼的人。
- 自动化只是一门技术，咱们不能脱离业务搞自动化；
- 很多人认为自动化很厉害，就脱离了工作的重心，天天喊着自动化、自动化，最初到头来啥也不是，啥也没失去。当然如果是业余、专门搞自动化测试开发 的那就另说了。因为他们的工作就这，就是 转、精。
6.4 万物皆可自动化
- 这个其实和前边的提到的统一，搞自动化，先要合乎一些 前提条件 以及明确他的 利用场景，不是所有软件都要搞自动化。
- 自觉的自动化，只会事与愿违。
6.4 自动化很简略
- 这是一个很简单的然而又简略的话题，对自动化的方向、工具、技能等 钻研的水平不同，对他的意识就不一样；
- 如果只是解决一些简略的问题，你把握他很简略。如果是简单的一些货色，可能须要深入研究；
- 自动化方向也是很多，不论是性能、性能，还是面向接口、UI、GUI、协定，更或是自动化工具开发等，都须要不同的技能和常识，入门或者简略，要做的很专一，还是须要点积攒的。
6.5 自动化尽早做
不肯定。不同的自动化，染指工夫可能有差别，比方
- UI 的，倡议软件略微稳固或者需要变更不频繁的时候再去开发；
- 接口的，能够在开发阶段同步进行；
7 自动化测试工具
太多了，举个例子，不代表所有的。事例而已：