自动化测试，除了coding还需要掌握什么？

一、自动化测试项目

自动化测试本身是一个项目，它属于业务项目的子项目，因此自动化测试项目也具有项目所有的特征

既然提到自动化测试是一个项目，那么首先需要大家理解一下为什么叫做自动化测试项目，而不单单是自动化测试。

1.1 软件项目生命周期

首先我们可以先看一下项目的几个主要阶段：

起始阶段 – 有一个好的想法：具体构想出终于产品的设想和它的业务案例，确定项目的范围。
细化阶段 — 计划必要的活动和所需资源，具体确定功能并设计构架。
构建阶段 – 构建产品，发展最初的设想、构架和计划，直到一个能够交付给用户的产品（完毕后的设想）完毕。
交付阶段 – 将产品移交使用，包含：制造、交付、培训、支持、维护。

有没有发现想要完成自动化测试也要经过软件项目的4个主要生命周期。

1.2 自动化测试项目生命周期

1.2.1 起始阶段

确定项目目的（自动化测试目的）

自动化测试的目的是什么？优化测试速度？提高准确性、稳定性？提高工作效率？
项目的目的取决于项目需要，每个项目都有自己不同的目的，自动化测试作为一个项目它的目的也不固定的。（目的决定期望，不要产生盲目的期望）
可行性分析
- 是否适合做自动化测试？
  长期的项目才能体现出他的价值作用，预防缺陷、减轻测试人员的工作量。短期的或者频繁变动的项目，是不适合做的。
- 自动化测试项目启动的时机是否成熟？
  项目是否趋于稳定？对于自动化测试的需求是否强烈？团队对于自动化测试的认知是否统一？
- 自动化测试目的是否合理？
  是否自动化测试的预算成本大于收益？是否可以量化体现的目的？

1.2.2 细化阶段

确定项目范围（自动化测试范围）
需要精准的需求分析，确定被测系统的模块、服务、用例等，划定自动化、手工测试范围，范围决定了自动化测试的方向。
人员分工/资源管理（自动化测试投入）
脚本编写是赋能于QA还是专职人员？测试环境、执行设备(电脑、手机)、人力投入预算，能力的培养计划等。
构建实施条件（自动化测试条件）
自动化测试实施需要被测系统满足实施条件，就需要优化被测系统或业务项目以达到实施条件。
计划研发流程（自动化测试流程）
测试用例脚本开发是与开发同步还是延后？需要紧密贴合业务项目流程，将自动化工作变为日常开发/维护工作。
选择/设计框架（自动化框架设计）
选择合适(热门、持续更新)框架，由于测试用例数量庞大，一定要根据复用性、维护性进行合理的设计，减少测试用例的维护成本。
需求管理（测试点管理）
自动化测试的需求来自于测试用例，面对数量庞大的测试用例也需要循序渐进，通过用例管理的方式逐步完成。

1.2.3 实施/交付阶段

实施/交付过程（迭代实施/交付）

介于大量的测试需求、被测系统的需求变更造成的测试需求变更，自动化测试项目注定是一个长期的过程。但是又由于测试需求（测试点）之间有着相对独立的关系，决定了自动化测试项目是非常适合迭代实施。并且越早有可用的自动化测试脚本投入，自动化测试的成效越高。

可根据测试分层和测试需求优先级的管理，控制自动化测试项目的迭代实施/交付。
自动化测试项目的CI/CD

自动化测试是一个测试脚本交付的项目，由于被测系统的需求变更直接带来测试用例的变更，也就间接带来了自动化测试项目的维护需求。自动化测试项目也需要迭代、更新，那么也就需要迭代管理、代码分支管理。

而自动化测试项目的交付就是测试用例的执行、报告、结果分析，自然也需要用例执行管理。
可通过Git的分支管理、Jenkins的定时任务、测试用例集的制定，实现自动化测试项目的持续集成、交付。
与被测系统CI/CD的融合

自动化测试用例的执行是贴合被测系统环节的，编码完成开始测试（执行用例）也是被测系统持续集成/交付的一个环节。

例如：将用例的执行与自动部署融合，部署自动触发用例的执行，或将冒烟测试加入部署环节作为部署完成的一个标准；将用例执行与任务卡融合，研发任务卡进入指定状态触发用例的执行，完成验证。

相信通过将自动化测试与项目生命周期的结合思考，已经发现自动化测试确实可以按照项目形式展开。
下面针对一些具体环节进行一些介绍。

二、需求管理

自动化测试的需求来自测试用例，那么相应的需求管理来自于对测试用例的分析。

2.1 需求归类（测试分层）

以上的测试分层相信很多人都有见过，但是在这里并不对测试分层进行更多的介绍，而是结合测试用例分析，确定测试需求。

首先，剔除不适合自动化的测试用例（自动化收益远远小于手工测试的、需求不稳定变更频繁的）
其次，筛选测试用例确定测试方式，找出只能通过单元测试、接口测试、UI测试执行的测试用例（例如复杂的算法或内部逻辑只能通过单元测试、接口自动回调逻辑只能通过接口测试、UI与浏览器交互只能通过UI测试等），这一类用例不再需要考虑测试分层，只能通过指定方式执行
再次，筛选测试用例确认测试重要程度，找出测试需求重要程度较高的测试场景（例如支付、转账），这一类用例最好是覆盖所有测试方式，实现从处理逻辑到用户体验的全方位覆盖
最后，对于其他的测试用例，才根据团队测试分层计划归类于不同层次，开展测试任务

2.2 需求优先级

考虑到测试用例的庞大，需要对测试用例进行优先级规划，分批次迭代实现。对于测试用例优先级的评定可以结合以下三种方式

按照测试阶段

测试活动有很多环节，功能回归也分散于各个环节，既然自动化测试服务于测试活动，那么可以根据测试阶段目的对用例进行分类，例如冒烟测试、回归测试、集成测试。显然冒烟测试用例更简单、成效更高。
按照用例类型

测试用例可以分为功能逻辑测试用例、边界值测试用例、异常输入等等类型。显然功能逻辑测试用例相对更重要一些。
按照执行频率

不论是基于业务场景还是用户习惯，都是存在执行频率差异的。例如淘宝的商品搜索频率是远大于浏览足迹的，显然执行频率越高的场景，用户使用频率也越高。

三、框架选择/设计

3.1 UI自动化测试框架选择

3.1.1 常见UI自动化测试工具/框架

3.1.2 元素定位典型–Selenium简介

Selenium是一个用于Web应用程序测试的工具。
框架底层使用JavaScript模拟真实用户对浏览器进行操作，直接在浏览器中运行，就像真实用户所做的一样。

组件：

Selenium IDE
Firefox插件，可以录制用户的基本操作，生成测试用例。
Selenium WebDriver（Selenium 2、Selenium 3）
提供了各种语言环境的API来支持更多控制权和编写符合标准软件开发实践的应用程序(Java\C#\PHP\Python\Perl\Rudy\JavaScript\C++等)
Selenium Grid
实现分布式自动化，可以在多个(不同)测试环境中以并发式执行测试脚本，实现测试脚本的并发执行，缩短了大量的执行时间

3.1.3 图像识别典型–Airtest简介

Airtest是网易开源的一款基于图像识别和poco控件识别的一款UI自动化测试工具，适用于游戏、APP。

Airtest的框架是网易团队自己开发的一个图像识别框架，这个框架的祖宗就是一种新颖的图形脚本语言Sikuli。计算机用户不需要写代码，而是用屏截的方式，用截出来的图形摆列组合。

poco控件搜索框架，原理类似于selenium，通过控件的名称，id之类的来定位目标控件，然后调用函数方法，例如click(),swip()来对目标控件进行点击或者是操作。

优点：
- 控件识别，操作简单，功能简明
- 代码要求低，可录制脚本一键生成报告，支持Python编辑脚本
缺点：
- 控件定位不够准确，控件位置变更、图案修改，会无法识别（因此更适合做游戏测试）
- 目前只支持Android、Window、(IOS支持更新中)，只支持Python

3.2 API自动化测试框架选择

3.2.1 常见API自动化测试工具/框架

类型	名称
库/模块	Python+Requests、Java+HttpClient、Java+RestAssured等
框架	HttpRunner、 Robot Framework等
工具	JMeter、PostMan、SoupUI等

3.2.2 API自动化工具、框架、库/模块的选择

工具
使用Jmeter/PostMan工具进行接口测试，就是典型的数据驱动模式，将测试脚本与测试数据分离，通过excel、csv管理测试数据，以完成多种测试场景
框架
Httprunner、Robot这类框架多使用关键字驱动形式，通过封装、关联关键字，满足任意调用所需。规范了脚本的编写方式，简化了脚本的编写成本，但同时使得灵活性、拓展性降低
库/模块
Requests、HttpClient库仅支持基础的Http等请求，可以根据项目的需要、自己的喜好任意定义、拓展。

3.3 自动化测试架构

数据驱动测试
测试数据与测试逻辑分离，通过建立测试与开发定义的软件元数据的关联——元数据映射表，在测试与开发之间建立松耦合关系。只需要修改元数据映射表，既可以满足多种测试场景。可以减少测试脚本调试的工作量，更好的实现自动化测试。
关键字驱动测试
关键字驱动的来源非常自然，从面向对象的思路出发，同样的业务逻辑会自然的编写成一个类或者函数作为关键字来被不同的测试脚本所调用。
在关键字驱动框架里，你可以创建一些关键字以及相关联的一些方法和函数。然后你创建一个函数库，它里面包含一个读取关键字的逻辑，然后调用相关的动作。
模块驱动测试
模块驱动测试使用独立的小脚本来对应待测试的模块、零件和子功能。这些不同层级的小脚本按照一定规则组合成更大级别的测试案例。
模块驱动测试引入了抽象和封装的原则，目的是提升自动化测试的可维护性和可扩展性。
混合自动化测试
混合自动化测试是由其他自动化测试框架综合发展起来的。成功的自动化测试框架通常融合了“关键字驱动测试”和“数据驱动测试”。他们即拥有测试逻辑与测试数据相互分离的优点，又集成了关键字驱动的先进架构。
该架构由核心数据驱动、功能函数组件、以及支持库组成。
基于模型测试
测试用例可以完全或部分的利用模型自动产生，适用于采用“基于模型设计”的软件系统。通过业务模型设计+测试用例设计方法（逻辑、参数等）生成测试用例。

四、构建实施条件

4.1 较小的用例颗粒度

由于机器本身没有处理复杂问题的能力，无法向人一样处理复杂的业务场景，为了更好的明确每个脚本的目的、保持测试点的单一性、减少缺陷范围分析成本，应该控制用例颗粒度。

如果一个测试用例中包含过多测试点，那么任意测试点的错误、需求变更都会造成用例执行失败，过多的测试点不利于问题的排查分析。

4.2 便捷的UI定位

图像识别
图像识别最大的弊端就是发生变化而造成无法识别，为了应对变化并且较少识别错误率，应尽量同前端公用图片库等资源，同时也更加需要规范公共资源的管理
元素定位
给元素定位带来困难的是需求变动带来的前端变化(交互、层次、位置)，在元素的8种方式中ID是最能保持元素唯一标识、便于维护的方式。因此也需要前端尽量对元素进行ID标注，并且进行规范管理

4.3 规范的接口设计

4.3.1 接口设计规范

统一请求、返回格式
单一职责
保证纯洁性（尽量小，高内聚）
可扩展
等等

规范的接口设计利于接口的维护成本，简单明了便于理解。

4.3.2 接口文档维护

接口自动化测试需要参考接口文档更好的理解接口用途(测试不参与开发，对于接口了解只能通过相关说明)，文档的维护有利于接口自动化的维护。

文档并不限于文本，Swagger等做到统一规范也是可以的，如果能够Swagger做到统一规范，完全可以直接将Swagger作为脚本的一部分（或者做到一键导入API）。

4.4 Mock规划

4.4.1 Mock

mock是在测试过程中，对于一些不容易构造/获取的对象，创建一个mock对象来模拟对象的行为。

被测系统Mock
特别是微服务应用中，如某些服务独立性较高（例如模型跑分等），对其模块的接口/功能测试可以通过Mock规避其他风险。
第三方系统Mock
第三方服务无遗是最不稳定的因素，它的不稳定必牵连测试工作，对其完全Mock无遗不是增加了自动化过程的稳定性。

4.4.2 MockServer

当Mock要求不断增多时，专门的MockServer也是需要的。

同时设定Mock根据不同类型的测试数据返回不同的响应，也是极大的简化了Mock的调用，也简化了自动化测试的维护、编写。当然使用MockServer就需要开发配合定义、调整代码。

4.5 其他

根据被测系统特性也可以引入其他机制作为辅助，例如：

一定程度上的减少使用带有功能特性的缓存，避免测试无法验证
引入有限状态机
等等