自动化测试概述
自动化测试的概念
背景
互联网行业的公司，基本上半个月会进行一次迭代，就算每次迭代发布时只回归核心与增量功能，对测试人员来说工作量也不小，而且回归测试是一项非常枯燥且重复的任务，持续时间长了也容易出错
引入自动化测试的前提条件：
- 项目环境稳定
- 项目周期较长，需求变动不频繁
- 项目中的部分模块相对稳定
- 自动化测试脚本可重复使用
前期自动化测试的策略是模拟真实的操作，替代手工测试的执行，这样一来，在平时就可以定时定量的进行业务流程的逻辑覆盖，增强产品的稳定性，而且版本迭代回归时重复的工作也可以用自动化来替代，测试人员只需要验证每次发布的增量功能，后期可以转变为分层自动化测试，这也是当下最理想的自动化测试模型，分层自动化测试是指在产品的不同层次都进行自动化测试
Unit-单元测试
-
单元测试需要做DAO层和Service层的测试，数据驱动层的单元测试主要保障SQL脚本的正确性与合理性，Service层的单元测试主要保障单个功能函数逻辑的正确性
-
单元测试的外部依赖可以通过Mock框架 (Mockito等) 模拟返回，使得自动化测试尽量做到可以随时随地运行，某种意思上来说这一层自动化测试的投入产出比是最高的
Service-接口测试（集成测试）
在服务层接口测试关注的是某个接口的输入输出功能是否正确，以及业务流程的逻辑测试，初期测试自动化起步较晚，代码覆盖率不高，所以初期接口自动化策略是增加业务场景的覆盖
- 优先覆盖核心业务的场景
- 接口所依赖的数据选择使用接口返回值的方式
- 暂时不做系统间的Mock，更多的考虑系统之间的依赖
- 优先做场景覆盖，之后再考虑代码覆盖
这样做可以快速增加业务场景的覆盖，同时写好的API接口就算后期产品业务流程发生变化一样可以使用(对UI层的接口逻辑不变)，以这种方式编写的脚本，后期维护成本较低
接口测试由测试人员完成，接口测试时测试人员不需要非常详细的了解内部接口代码的实现，编写的脚本中体现了对不同接口、模块之间关系的梳理，后期在核心业务流程覆盖率较高的情况下，可以增加对单个接口的覆盖
- 进行接口依赖的解耦，比如数据从调用接口变为直接往数据库插入数据
- 逐渐细化拆分业务场景
- 由系统级的自动化测试逐渐转为灰盒与白盒自动化测试
UI–页面测试
这一层主要是页面展示逻辑及界面前端与服务的集成验证，适当的UI自动化测试是有必要的，因为UI自动化可以在版本迭代回归时替测试人员进行重复的工作，实实在在的解放劳动力
- 只做核心的功能的自动化覆盖，脚本可维护性尽可能提高
- UI自动化测试脚本遵循Page Object设计模式
- 通过数据mock的方式减少对后台数据的依赖
UI测试由测试人员完成，在覆盖了核心场景之后，没有必要在UI层投入太多的精力和资源，因为UI界面是变化频率最高的一层，后期的维护成本太高
持续集成
有了各层的自动化测试，需要建立起持续集成体系
- 流程自动化，提高自动化效率
- 定时定量重复执行，最大化自动化测试脚本的价值
目的：
- 代码提交自动执行单元测试
- 单元测试通过后自动部署整体的环境
- 自动执行集成自动化测试 (Service/UI)
- 自动生成构建的详细测试报告，同时自动通知相关人员
可以推动开发进行单元测试的覆盖，制定接口自动化脚本编写规范，增加代码的可读性、有效性与可复用性，脚本设计时尽可能脱离测试、预发布和线上三个环境数据的依赖，在时间可控的情况下增加核心业务流程UI自动化测试的覆盖
在各层自动化测试都比较成熟的情况下，后期可以加入代码覆盖率自动收集、代码静态检查等测试左移的活动以及线上数据与BUG的收集与监控（接口性能、crash率、用户行为分析等）等测试右移的活动，搭建符合公司风格测试平台等
自动化测试的意义
预期
- 不清楚自动化测试的目标，以及为达到目标所计划的投入
- 自动化测试可以干很多活的同时省很多钱
- 成功的自动化测试，从最终效果来看，能够提高产品质量和节省人力成本
投资回报率（ROI）
自动化的收益=迭代次数*（全手动执行成本-自动化维护成本）-首次自动化脚本成本
自动化的收益与迭代次数成正相关，与自动化成本与维护成本成反相关
公式的自动化收益仅仅考虑时间和资源成本的节省，成熟的自动化带来的是迭代周期的缩短，在某些时候能变不能做为能做，进而带来的机会收益是巨大的，这点是很难量化的
作用
- 突破效率瓶颈，同时降低人力成本
- 降低人为错误率，规避因为人的疲劳和惯性思维以及投机取巧导致的错误
- 提升执行效率，以及应对高强度连轴转任务，搞定长时间的系统稳定性测试
- 增加软件的信任程度
适合项目
回归测试为主的项目/接口比较稳定的产品，需要长期做支持维护的产品
一个项目一周甚至有的时候几天就可以发布一个功能，按照这个节奏，开发只需要改几行代码，你可能要回归几十条甚至上百条的用例，改动会越来越频繁，每一次改动，测试人员都要去做回归，而这种回归，手动测试特别费时费力，甚至无法达到测试目的，在这种迭代时间越来越短的节奏下，自动化收益就非常高
时间点
一个项目的初期不太适合自动化，因为项目初期用户界面和接口没有稳定，自动化代码会被动的要求频繁改变，维护成本非常高，反而手动测试能够快速发现问题，反馈给开发人员，而到了项目后期和维护期，自动化再介入为回归测试做准备，可以最大化自动化收益
最佳情况下，后端与前端分开迭代，在项目初期与后期全面介入，自动化回报率最大
局限性
- 较为依赖用例设计，如果测试人员的业务流程不熟悉或者相关文档缺少，自动化测试的效率也是较低的
- 如果期待自动化去发现大量新的缺陷，这不现实，更大的意义在于用在重复已经运行过的测试
自动化测试的流程
自动化测试流程包括测试分析及计划、测试设计及开发、测试执行和测试总结四个阶段
测试分析及计划
自动化可行性分析
在进行需求自动化测试之前，先要确认是否可以实行测试自动化，必要时进行抽样demo分析（如涉及第三方系统等），自动化测试应该遵循以下几个前提条件：
- 需求变动不频繁
- 项目周期为足够长的时间段
- 自动化测试脚本后期可重复使用
抽样demo分析是将实体案例进行更深层次的可行性分析，demo的选取，一般直接选择冒烟用例写成测试脚本后执行，检查脚本是否能运行通过，设计的测试点是否全部覆盖
测试需求分析
确认需求自动化测试可行后，对需求进行梳理，划分出可以进行自动化测试的功能点，划分的标准一般是重复性高、业务不过于复杂的功能点，便于快速脚本实现，如果选择功能点过于复杂，会花费大量的时间在脚本编写上，这样就丧失了做自动化的初衷
在这个阶段，要确定自动化测试覆盖率以及自动化测试颗粒度，原则是在项目周期内尽可能提高自动化测试覆盖率
制定测试计划
测试计划主要包括以下内容：
- 准入准出：自动化测试介入时间点，达到什么标准后，自动化测试结束
- 测试范围：确定测试需求的优先级与业务范围
- 进度安排：在什么时间点输出什么成果
- 风险评估：对项目过程中的风险进行预估并给出应对的方案
- 所需资源：测试所需要的人员、软件、硬件与文档等资源
- 工作安排：具体人员的分工
测试设计及开发
测试用例设计
先进行测试用例的设计，测试用例编写完成之后，进行用例评审，评审通过后再进行测试脚本的开发，设计自动化测试用例过程需要遵循的原则：
- 一个用例为一个完整的场景，覆盖核心的业务流程
- 优先考虑实现正向的测试用例，辅以个别重要的反向用例
- 数据计算类的用例需要在数据驱动中提供预期结果进行比对
- 新增类与修改类的用例需要在新增与修改成功后重新查询比对查询结果
- 用例和用例之间尽量避免产生依赖
- 用例完成测试之后需要对测试场景进行还原（数据清除等），以免影响其它用例的执行
脚本开发与版本控制
根据写好的测试用例，编写对应的自动化测试脚本，测试脚本的编写遵循脚本开发规范，编写过程中应考虑脚本的可维护性、可重用性、简单性与健壮性，同时要注意确保自动化项目的结构化和一致性，脚本开发完毕后，至少运行成功3次以上，才能认为脚本已经没有问题
当日进行脚本编写前，在本地拉取Master分支代码，保证本地代码为最新版本，当日脚本编写与调式完成后，上传到自己的分支，后期统一Merge到主分支
测试执行
- 在迭代需求系统测试已经完成的情况下（如迭代需求线上发布后），采用Jenkins工具任务触发方式进行脚本的无人值守执行
- 执行过程中发现的有效BUG记录在华为云上并提交给对应的开发人员修复，标题前缀加上【自动化测试】，以便后期跟踪处理
- 开发人员修复BUG后，需要对BUG进行回归测试，如果问题的修改方案与原来的需求有偏离，那么在回归测试前，还需要对用例与脚本进行的修改
测试总结
对自动化测试的结果进行总结，统计发现的BUG与产生原因，提交测试报告文档
自动化测试报告
- 版本运行总结：每次新功能上线的自动化测试覆盖率，通过率，缺陷率，与上版本相比的质量数据
- 每日运行总结：发布后的自动化测试质量追踪，问题分析，确定缺陷的原因
包含：
- 所有的自动化统计报表，囊括所有的脚本运行的历史数据和近 7 天的脚本成功率趋势
- 单次自动化统计报表，统计了单次运行脚本的详细信息，分为失败统计和全部统计和日志复盘信息
- 单条自动化统计报表，单条用例的详细信息，包括检查点，执行步骤
最后针对测试报告进行脚本与测试用例的维护与优化，归档