自动化测试选型分析

文章编写初衷：整理已知的自动化知识，并帮助初次接触自动化测试的同学

一、 自动化测试的含义

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

二、 自动化测试的特点

优点：

• 支持快速执行大量的测试数据，提高测试效率
• 对重复的功能测试，自动测试具有一致性和可重复性的特点，测试更客观
• 破除了时间和地点的限制，可以对程序进行监控
• 提高工作质量，从而减少了发布后修复故障的必要性，并降低项目成本
• 通过程序的不断累计，可以执行更多与应用程序相关的测试，这样极大的提高测试覆盖率

缺点：

• 永远不可能替代手工测试。自动化测试无法做到手工测试的覆盖率，不是每个测试用例都适合实行自动化。
• 手工测试发现的bug远比自动化测试多。自动化测试几乎是无法发现新bug的，最大的用途是用来回归，确保曾经的bug没有在新的版本上重新出现。
• 自动化测试工具比较死板，灵活性比较差。自动化测试的效果好坏，完全取决于测试工程师。
• 成本投入大，风险高。对测试人员的技术要求高，对测试工具同样也高。测试用例需要根据版本迭代进行更新，还有一定的维护成本

三、 什么时候需要自动化测试

3.1 需求变动不频繁

测试脚本的稳定性决定了自动化测试的维护成本

如果软件需求变动频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，建议需求变动较大的仍使用手工测试。

3.2 项目周期足够长

项目周期短且无后续规划，自动化测试无需进行

自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要较长的时间来完成。而无法保障项目正常交付的过程，都是无效的工作内容。

3.3 自动化测试脚本可重复使用

自动化测试不应该是练手之作，而是真正可产生效益的测试方法

如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值。

在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。此类可以归类于数据重复或操作重复。

四、 自动化测试类型

4.1 UI 自动化

在原有的应用上，通过驱动或者增加插件的形式，模拟用户真实的操作。如：QA Run、selenium等。

优点：

• 真实的模拟了用户的操作，可以覆盖大多已知的问题和功能回归
• 可以有效的检查前端界面和后端交互逻辑（其他自动化无法检查前端）
• 市面上有较多的工具和框架选型，可以快速的入门并完成简单的UI自动化（如：按键精灵等）

缺点：

• 受到的外界影响会直接影响到自动化测试的成功率，如网络、机型、设备内存等
• 部分的应用需要内嵌插件才能进行UI自动化，与原应用在性能等因素上有差异
• 前端的修改会直接影响到脚本的执行，维护成本较高

4.2 接口 自动化

模拟前端应用对后端提供的接口服务进行测试。如：Postman、JMeter、pyhon-request等。

优点：

• 后端的接口改动对业务的影响较少，脚本的修改成本较低
• 可以快速的部署和落地一套合适的接接口自动化
• 可以在前端没有开发完成的情况下，提前通过接口自动化测试，完成业务测试

缺点：

• 完全脱客户端的测试，在实际的场景中，会有一些不可预知的BUG
• 接口自动化没有界面，对测试人员的代码能力有一定需求，门槛较高
• 除客户端与服务端的接口交互外，还有一部分是服务端的同步、定时任务等无法通过接口自动化完成

4.3 性能/压力 自动化

通过模拟线上用户的某些行为，对服务端或客户端性能监控手段。如：LoadRunner、JMeter等。

优点：

• 可以确定应用的速度、可扩展性和稳定性特征，从而作出明智的业务决定
• 支持调优、容量规划和优化工作等
• 通过压力或对性能报告的分析，预知程序内的设计缺陷

缺点：

• 在负载或者单性能场景下无法有效检测功能缺陷
• 对生产环境等测试前置条件要求很高，脱离环境的测试没有意义
• 在设计的用户场景中，如果没有仔细的设计和验证，绝大数的性能数据都没有意义

4.5 配置/单元 自动化

使用一些内置的工具、或者程序，对一些常见配置或者代码逻辑进行测试，大部分情况下由程序开发者进行。

优点：

• 高效而准确的对大量配置进行校验
• 在开发阶段暴露部分BUG，提高开发质量

缺点：

• 在进行配置自动化的过程中，绝大多数需要人工参与部分校验
• 需要测试的配置和程序杂而多样，单一工具无法满足，而多工具又难以管理

五、选型原则

• 选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本；
• 测试流程管理自动化通常应该优先考虑，以满足为企业测试团队提供流程管理支持的需求；
• 在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑；
• 尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持；
• 应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。

六、自动化测试过程

自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。

6.1 测试计划制定与需求分析

在经过自动化测试可行性分析后，结合需求、设计、开发、维护及配置管理等各个方面，对当前程序进行需求拆解，选择最合适自动化测试方法或工具

6.2 设计自动化测试用例

结合需求分析的结果，对核心流程并符合自动化测试用例设计规范的场景设计自动化测试用例

注1：自动化用例，部分需要结合人工测试，可以采取半自动化的流程来提高测试效率
注2：在非纯后端服务的程序中，需要注意，自动化的用例应保持在70%以下，保障可用性

6.3 搭建自动化测试的框架与环境

针对不同规模的项目，需要搭建不同的自动化框架，并优先保障自动化测试用例的可执行性和抗干扰性，同时需要支持后续对其他功能的扩展。如：接口自动化测试，需要对数据校验和性能测试等保留结构设计

可以参考不同的测试模型来设计：

• 线性模型。通过录制或编写脚本，一个脚本完成一个场景（一组完整功能操作），通过对脚本的回放进行自动化测试。
• 模块化驱动模型。将脚本中重复可复用的部分拿出来写成一个公共的模块，需要的时候就调用它，这样可以大幅提高测试人员编写脚本的效率。
• 数据驱动模型。通过输入不同的参数来驱动程序执行，输出不同的测试结果。实现了测试数据和测试脚本分离。
• 关键字驱动模型。具备一套易用的可视化界面，测试人员需要做的就是将测试脚本按照“填表格”的方式填入，并考虑三个问题就可以了：我要做什么？ 对谁做？怎么做？QTP、robot framework等。
• 行为驱动模型。这种模型通过使用自然描述语言确定自动化测试脚本，其优点是可使用自然语言编写测试用例。

6.4 设计与编写自动化脚本

• 一个自动化脚本中，最好是只有单个校验点，便于快速定位问题
• 设计脚本时，需要拆解最短最优路径，便于后续对其他组合逻辑的支持

脚本的设计原则：

• 测试用例是一个完整的场景。从用户登录系统到用户退出
• 测试用例只验证一个功能点。不要试图用户登录后验证所有的功能点再退出
• 测试用例尽量只做正向的逻辑验证，正向是指脚本可实现的而非主观操作。逆向逻辑的情况很多，验证比较复杂，需要编写大量的脚本，投入成本比较高
• 测试用例之间不要产生关联，也就是说每个测试用例是独立，不能依赖或影响其他测试用例，要求高内聚低耦合
• 测试用例需要更多的关注功能逻辑的实现，而不必纠结某些字段的限制
• 测试用例的上下文必须有一定的顺序性，要能够互相连接起来；并且前置条件要清楚
• 测试用例中检查点的设置（根据测试用例的侧重点设置检测点、设置检测点要全面和设置检测点要灵活）
• 测试用例要对修改的数据进行还原操作
• 测试用例必须是可回归的

可以参考以上的例子，设计自动化测试用例-用户使用android-APP通过手机号注册登录（经典面试题）

6.5 测试脚本的正确性

一个用于测试的"产品"，应该保障测试脚本在错误场景和正确场景的对比测试通过

七、简单的web-UI自动化示例

软件测试：在规定的条件下对程序进行操作以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# 创建Chrome浏览器实例
browser = webdriver.Chrome()
wait = WebDriverWait(browser, 3)

# 打开百度首页
browser.get('https://www.baidu.com')

# 在搜索框中输入关键字
search_box = browser.find_element(by=By.ID, value='kw')
search_box.send_keys('Selenium')

# 点击搜索按钮
search_button = browser.find_element(by=By.ID, value='su')
search_button.click()

# 隐式等待
wait.until(EC.title_is("Selenium_百度搜索"))

# 打开selenium 官网
link_text = browser.find_element(by=By.LINK_TEXT, value="Selenium")
link_text.click()

# 获取当前浏览器的所有窗口句柄
handles = browser.window_handles

# 切换到最新打开的窗口
browser.switch_to.window(handles[-1])
# 隐式等待
wait.until(EC.title_is("Selenium"))

# 校验当前网站URL
cur_url = browser.current_url
assert cur_url == "https://www.selenium.dev/"

八、实际落地自动化测试难点

8.1 基础设施和自动化测试规范

• 团队内成员技术水平有明显差异，交叉编写用例或审查时，需要项目早期进行测试规范
• 公司没有额外的资源投入（网络、服务器、人力等）

8.2 测试工具有效的推广

• 按照计划编写好的工具或平台，因为时间或其他问题，无法推广使用
• 工具由于开发时机，市面有更好的替代方案

8.3 实施团队和管理层的持续支持

• 需求提出方或执行方，由于难度或其他原因不执行
• 由于短期的需求变更导致自动化测试投入较多，管理层叫停