接口自动化落地的一些总结

接口自动化落地的一些总结

Scroll Down

前言 & 本文定位

先说一下我个人的背景:我只是一个刚实习一个月左右的校招实习生,到目前为止的实际工作中,我负责的往往只是整个接口测试自动化的某一到两个环节。中间虽然扩展过一点测试框架的功能,但我个人觉得这并不算自动化落地的一环,因为在我看来要做自动化的前提首先就得拥有一套相应的框架。

尽管我工作实际接触到的内容很少,但这并不妨碍根据现状去云一云整个自动化落地的流程,所以这篇文章的定位就是:尽量整合我能查到文档、资料,描述出整个接口自动化落地背景、流程、指标等关键点

另外,本文提到的自动化默认是指接口自动化


自动化从需求到上线全景


我脑海里成熟的方案流程

image.png

上图文字描述:

  • 测试前
    • 需求迭代:通常由PM准备好需求文档,初步对需求的可行性,合理性进行迭代。
    • 需求评审:通常由PM、QA、RD一起进行完整的、一致的review,不仅仅是确保需求的核心点合理,同时也是保障三方对需求有一个一致的理解。QA在这个阶段也可以左移化,比如有经验的QA可以对需求点进行合理评估(比如评估需求点的事故等级,测试的覆盖范围),提前预测上线风险。
    • 方案设计:RD负责技术实现的方案设计,并输出相应的方案文档(包括接口文档),通常后端的工作量会大一些,比如后端需要尽早的定义接口文档,跟前端同学沟通合理性。而QA则可以输出核心校验点的文档,或者某些情况下需要根据业务特性订制化测试环境,也可以在这个阶段就整理文档。
    • 技术评审:对RD的技术实现进行可行性、风险性评估,这阶段主要是为了避免RD在对实现方案心里没底的情况下排期,而导致出现天坑来不及处理,最终项目上不了线。同时QA在这个阶段也可以了解技术实现,使测试用例更加充分,避免侧漏,进一步提高了上线质量。
    • 需求排期:在经过一系列的评审之后,就要开始对需求分配资源了,这个需求需要多少人力、物力、时间。什么时候开发完第一版,什么时候能自测、什么时候联调、什么时候提测...什么时候上线等,都需要在这时候安排妥当。
  • 测试中
    • 开发阶段:在需求开发阶段,RD负责技术实现,同时他们手上应该有核心校验点的文档,这可以提前让RD规避一些问题。这个阶段QA也在编写测试用例,并且要对测试用例进行合理评审(包括评优先级),评审之后同样会给到RD,让RD知道更多测试点的同时,能让测试点驱动开发,及时对写出来的代码查缺补漏,有效减少bug产生,规避因bug导致项目无法上线的风险,也是测试左移化的一种体现。
    • 冒烟自测:通常在RD开发完之前,QA的测试文档、测试用例代码也应当准备就绪了。在RD开发完之后,RD可以根据相关文档进行充分的冒烟测试。冒烟测试通过以后应当由测试的主导者去跑自动化流程,这里的主导者是指:出bug谁跟进就谁跑。
    • 自动化测试(测试环境):再经过冒烟自测后,应该由测试主导者开启测试环境的自动化测试,这里可以对相关业务的重要性进行评估,判断是否需要对存量case进行回归。(主导者一般是指:出?后跟进的人)
    • 联调、PM验收、提测:在经过前面的接口测试后确保没问题后,前后端就需要一个联调的过程,确保核心功能、视觉体验没有Bug;联调之后,通常需求的功能就能正常使用了,这时候一定要找PM来验收下效果,将一些关键的问题前置发现,避免出现提测后经过大量测试之后才发现不是PM想要的效果;再之后就发起提测流程(提测信息应包含服务端环境、代码分支等信息)。
    • 验收提测、开始测试:QA确保提测信息有效、无误后,验收提测、Code Review;验收提测后应该由Hook调起自动化测试,此时的测试环境应该是最接近线上环境的环境,通常称为预发环境 Product Preview Environment(比较核心的业务可能需要人工测试兜底),在这个阶段就应该保证没有重大事故发生(比如>=P1级的Bug)
    • QA验收、上线准备:进行线上发布之前,RD需要准备详细的上线计划,并按照上线计划执行上线操作。因为线上环境以及配置和测试环境是不同的,比如域名地址、数据库等。因此线上发布完成后我们需要进行线上验收,同样在客户端发版之前,我们需要进行一轮release版本回归(如果release包和debug包是不同的),确保发出去的包版本功能正常。在有一些重要的业务场景中我们还要构建系统的灰度发布&验收流程,这样可以提前验收好了之后再全量上线,这种方式往往非常有效,能帮助我们提前发现问题,避免线上故障发生。
    • 接口上线、回归:经过前面的ppe环境测试后,接口就要上线了,上线之后可能还需要做回归测试、小流量测试等。
  • 测试后
    • 正式发布:经过一系列打磨之后,新功能就可以对外正式发布了。
    • 发布之后:完成线上验收之后,为回顾整个线下测试以及线上验收过程中的问题,我们需要编写测试报告进行总结复盘,主要包含两个方面:
      1. 对研发环节中各个关键节点中出现的影响项目质量以及按时交付的问题进行总结,回顾问题发生的背景、原因并针对性思考后续的优化措施;
      2. 对线下测试以及线上验收过程中的发现缺陷进行总结梳理,并针对性的思考改善方法。那么为什么是QA来做这个复盘的工作呢?很大部是因为在整个研发流程中,测试是最后的一个环节,与PM&RD相比经历了更加完整的项目周期,因此对研发过程中存在的问题了解的更加清楚。
    • 除了对线下的流程复盘以外,也要及时监控线上的表现,比如线上告警等。对于线上问题要保持高度警惕的态度,在这之后也需要对线上事故的根本原因进行复盘,以免重蹈覆辙。

测试左右移

上面的图是已经接入自动化,并且左右移之后的图,下面我们先来看看什么是左/右移,再看看左右移在图中是怎么体现的

测试左移:测试左移的思想,本质是在一切开始之前先进行测试(或尽早让测试介入),测试对象是需求,越早的发现需求不合理的地方出问题的几率就越低。除此之外,提前告诉开发测试点、测试代码集成CI/CD也是测试左移化的体现,前者让测试驱动开发,后者能保证代码提交的质量。
测试右移:左移是尽早开始测试,右移则是更晚结束测试。右移一般是指测试工作往发布之后移,也就是产品上线且通过常规线上测试后,继续在生产环境做监控,监控线上性能和可用率,一旦线上发生任何问题,做到快速响应,代码回滚,避免给用户造成不好的体验。

左右移在图中具体体现,红线没指的地方一般就是左右移前QA不应该参与的部分

image.png


增量case和存量case概念

上面的图就是一个新需求->正式发布->测试用例维护的一个大致全景图,请注意这个流程是从RD还没开发开始的,写出来的测试用例一般称作增量case而对于过去已经被开发的接口,要接入的自动化测试,那么写出来的测试用例就叫存量case

对于存量case的需求->自动化上线流程图,这里就不再整理了,实际上就是根据上图过滤掉RD的流程就可以了,PM流程仍然是需要保留的,因为对现有的接口做自动化本身就是一个需求,是要走完整的需求流程的。


接口自动化建设背景

为什么要做自动化

首先回答一下上面的标题,我认为之所以做自动化测试,肯定是跟公司的业务量、迭代模式脱不开关系的

为了增加代入感,我先描述下我在两家公司的不同感受:

  • A公司:业务体量较小,通常开发的新需求与其它业务关联性不大,比如只开发一个音频模块->只跟用户业务有关联,回归测试覆盖的范围很小,人工回归通常只需要半天不到的时间;公司体量不大,业务不需要赛跑。
  • B公司:业务体量庞大,通常开发的新需求会跟很多其它的业务组成关联,比如开发一个音频模块->关联用户业务、支付业务、广告业务、存储业务等,回归测试覆盖的范围巨大,人工回归测试可能需要几天或者一周的时间;公司体量大,有竞争对手,需要赛跑抢占业务线。

如果让我评估哪家公司需要接入自动化,显然是选B,原因如下:

  • A公司不追求敏捷迭代,且测试量小+测试时间短,无需搭建测试自动化,如果搭建自动化反而可能会造成人手不足的情况。
  • B公司追求敏捷迭代,因为关联的业务很多,所以测试工作量会非常庞大(尤其是回归),为了后续新需求能更加敏捷的迭代,应该抽离/招聘一部分人力去搭建自动化,通过缩短重复测试的时间,加快产品迭代,跑赢竞争对手,最终为公司带来正向利益。

自动化的优缺点

优点:

  • 显著提高测试效率(尤其是回归),快速定位问题,让测试人员有更多的时间集中在设计更好的测试用例上,而不是重复性的点击。
  • 间接提高质量,在保证主流程稳定的前提下,能更好地发现深层次问题(例如:局部修改能够快速发现主流程问题、尽早发现程序设计的不合理)
  • 可以做到一些人工很难做到的测试,比如并发测试、并行测试、在各个时间段测试、在代码合并/上线等各个阶段自动测试
  • 具有一致性和可重复性(不一致说明?),代码每次执行的动作都能保证是一致的,相比于人工在某些测试用例上要更加准确。
  • 节约成本(并非所有企业),能让更少的人做更多的事。
  • 多环境并行,一个系统往往会被要求能支持各种不同的环境并稳定运行,但是这么多不同的环境如常用的浏览器:IE6,IE7,IE8,FireFox等,系统有:windows2003,windowsXP,windows Vista,windows7等,甚至还有杀毒软件,那么多环境组合,如果每一种环境组合都来人力完成,那么研发周期得成倍增加,而自动化可以发挥其优势与作用,由计算机代劳,在不同的环境组合中运行。

缺点:

  • 维护成本高:这里的成本不仅仅是时间,除了基本的测试脚本外,还有自动化框架维护、自动化平台维护,同时对编写测试代码的同学要求有一定工程能力。相比于按着文档一步步走的人工测试来说,无论是前提投入还是后续维护都需要相当高的成本。
  • 不能完全替代人工测试:对于一些极其复杂(牵一发而动全身)、对业务非常重要的测试用例(如支付等),仍然需要人工去兜底,市面上基本不可能实现所有业务完全自动化,更多的是半自动化,需要记住目前自动化的收益更多是体现在回归阶段
  • 对现有的手工测试质量的依赖性极大:自动化测试的运行,首先是建立在手工测试质量稳定的大条件下,如果当前版本手工测试的质量都不够稳定,那么建设自动化测试会非常不顺利,几乎是一种无用功(因为代码几乎没法复用)。

测试自动化快在哪?

这里举一对?比较一下:

  • 传统的测试

    • 比如现在有个发表文章的case,传统的人工测试大概是这样的:
      • qa人员复制粘贴文本到app,确认发表。
      • 发表之后要人工肉眼和真正发布的内容是否符合发布时的设置,如tag、文本的每一个字等。
      • 每个case/每次回归都要人肉去核对,复现,流程非常慢,复杂逻辑也容易出错。
  • 自动化测试

    • 依旧拿上面的发布文章case举例子,自动化大概是这样的:
      • qa人员编写测试检查点代码,复杂逻辑省去人工校验。
      • 由devops平台接入自动测试用例,定时/hook/第三方回调触发自动测试。
      • 测试报告文档生成方便,便于维持各版本的连贯性
      • 每个自动化的case能做到可复用、平台化,节省大量回归测试时间。

根据网上查询的资料,加自己实践的感知,我认为自动化主要是快在回归测试上,因为回归测试通常都是一些重复性质的测试。


自动化前置条件

前置条件一般是需要业务团队去评估的,主要有以下几点:

  • 需求变动是否频繁?
    • 自动化的瓶颈之一在于自动化用例代码的维护,对于一些极其复杂的测试用例,如果需求频繁变更,并且测试代码因为某个需求点变更而重构校验逻辑,那么这种需求就不适合马上接入自动化。
  • 项目周期是否足够接入自动化?
    • 接入自动化通常需要整理更多的文档,沟通成本也会升高,如果项目的排期非常紧张而业务重要程度又不高,则不适合马上接入自动化
  • 项目环境是否能接入自动化?
    • 通常一个项目要接入自动化,是有接入环境作为前提的,比如一些老旧的项目,本身就不具备接入自动化流水线环境的前提,那也是无法做自动化的,这时候应该先做环境兼容(前提是项目周期够长)
    • 除此之外,请务必保证自动化测试的环境是稳定的,不然自动化的脚本很可能就变成测测试环境的脚本了,迟迟无法得到想要的收益。
  • 自动化的脚本/代码是否能重复使用?
    • 如果写出来测试代码只能测试一次,那纯属浪费时间。

自动化的质量和效率

在了解整个需求->上线的流程之前,我们有必要先了解一下做自动化的两大目标:质量和效率

  • Q:自动化的质量和效率分别指的是什么?
  • A:
    • 质量:覆盖率高,稳定运行,结果可信。有效覆盖接口、需求、代码。
      • 质量好的表现
        • 用例是有效的,当被测对象有bug能够稳定拦截到,当被测对象无bug能够稳定运行。
      • 质量差的表现
        • 当被测对象有bug存在时,成功率仍然是100%,bug仍需要后续手工兜底发现。代码覆盖率低
      • 误报:测试脚本bug多于被测对象代码bug。case失败后需要花费人力去定位修复测试脚本bug。
      • 大量无效case存在,case更新不及时,case重复,case伪校验,一次性case。
      • 被测对象无变动时,测试用例执行时而通过时而不通过,偶现问题多而杂,难定位。靠重试解决。
    • 效率:用例要尽量全自动化,不需要人为过多多频繁的干预。用例执行速度要足够快,尤其是在devops中,流水线对时效性有严苛的要求。
      • 效率高的表现
        • 自动触发机制,无需人为参与
        • 执行时间短,结果呈现快
        • 报告可读性高,定位问题快
      • 效率低的表现
        • 执行前需要人工修改部分配置参数
        • 用例执行时间过长,线上监控不及时
        • 用例编写复杂,花费较长时间

自动化从建设到维护闭环

自动化建设的一个必要前提就是要保证自动化的脚本/代码能够复用,然而通常在需求发布以后,仍然可能存在一些问题,这种问题可能会破坏我们测试用例/代码的复用性。为了保证复用性,在后续需求的变化 or 发现新问题的时候,我们应该对测试用例及时维护。

下图就展示了从测试用例准备->测试用例维护闭环的大致流程:

image.png


测试代码规范

这里我先说一下我对代码规范的看法:只推荐,不强制

之所以不强制,是因为代码规范不同于其它规范,代码规范能不能落地还要取决于团队整体水平、实际业务复杂度等多个维度。如果实行了某种未经广泛实践代码规范,结果却发现开发的时候问题更多了,本末倒置,那就应该考虑"变通",不要为了规范而规范。

这里补充一下代码规范推出的背景,代码规范的推出有时候不仅仅是一个规范,它还可能是一个人or团队的KPI,所以...
举个例子,阿里自己出品的Java规范,在阿里的开源项目、内部其实也有很多不遵守的地方

下面补充一些常见的代码规范,以Java为例,比较少,但都是比较通用的

命名规范

  • 包名:小写,必须跟业务有关联,比如Tiktok订单->xxx.tiktok.order
  • 类名:拿Java的MVC做对照
    • DB层:业务名+框架操作实体结尾,如PayMapper(支付+Mybatis)
    • API层:业务名+API,如PayAPI
    • Test层:业务名+Test,如PayTest,其实就是单元测试代码的规范

类名这块可能需要根据公司实际业务要求做调整,比如可能不叫API层,叫Page层

  • 属性名:驼峰式命名,如:orderId

  • 方法名:驼峰命名,动宾结构,如:checkPayInfo

  • xml名(特指TestNg)

    • 模板LVideo-xxx-test.xml
    • 业务维度:xxx为分组名,如:LVideo-stable-test.xml
    • 个人维度:xxx为用户名,如:LVideo-xialin-test.xml

注释规范

  • 每个类文件前添加作者信息
    • 如果你使用的是IDEA,可在Preferences->Editor->File and Code Templates->Includes下设置模版,新建类文件时自动添加。
    • image.png
    • image.png
  • 每个Test前加上统一注释,简单描述该test做的事情
    • image.png

代码风格

  • 一行代码过长时,注意换行:
    • image.png
  • 使用checkstyle.xml定义代码风格,这里贴一下我常用的checkstyle.xml,下面再补充下IDEA的配置方法:
    • 安装 CheckStyle-IDEA 插件
      • image.png
      • image.png
    • 配置 CheckStyle
      • 进入 CheckStyle 配置(不同版本IDEA可能在不同菜单,直接搜索即可):Preferences | Tools | Checkstyle;
        • image.png
        • image.png
        • image.png
        • 这里简单演示一下代码中含有无效import的扫描结果
        • image.png
    • 除了本地校验代码以外,CheckStyle还可以集成到Jenkins流程,用来检测提交的代码是再好不过了。
    • 如果你们团队不想自定义,那么大部分情况下直接使用阿里的代码检查插件就可以了,这里就不一一介绍了。

自动化运营指标

背景

通常在自动化落地以后,我们缺少统一的度量指标,自动化收益难以度量,各项指标没有统一的口径和标准,各个业务方的数据无法横向对比,做到最后业务方也不知道接口自动化做到了什么程度,十分难堪。这时候,自动化的度量指标就出现了。

接口自动化收益指标

  • 接口自动化的问题召回率(持续上升):每版本接口自动化发现缺陷数量 / 每版本缺陷总数 (持续上升)
  • 安全测试问题召回有效率(持续上升):安全测试有效拦截个数/总拦截个数 (持续上升)
  • 服务端线上问题占比(持续下降):每版本服务端线上问题数/线上问题总数 (持续下降)

接口自动化过程指标

  • 测试环境稳定性

    • 测试环境部署成功率 xx%->(xx+n)%:BOE部署成功次数/BOE部署总次数
  • 接口自动化

    • 单个接口自动化用例的稳定性(持续上升):(单个用例执行成功次数 + 单个用例执行后发现缺陷次数)/ 单个用例执行的总次数
    • 接口的PSM覆盖率(持续上升):已具备自动化用例的psm / 部署boe的psm数 (持续上升)
    • psm:product service module,即一个服务模块的意思

    • 接口的自动化覆盖率(持续上升):已具备自动化用例的接口数 / 总接口数 (持续上升)
      • 核心接口(P0 + P1)的自动化覆盖率(持续上升):已具备自动化用例的核心接口数 / 总核心接口数
      • 普通接口(P2 + P3 + P4)的自动化覆盖率:已具备自动化用例的普通接口数 / 总普通接口数​​​
    • 接自动化的绝对代码行覆盖率(持续上升)- PSM维度:执行接口自动化用例后,所覆盖的代码绝对行数/服务的总代码行数
    • 接口自动化的差异代码行覆盖率(持续上升)- PSM维度:执行接口自动化用例后,所覆盖的差异代码行数/服务的总差异代码行数
    • 流水线有效拦截率(持续上升):流水线有效拦截到问题的次数/流水线总执行次数
  • 长期OKR/KPI

    • 半年OKR
      • 测试环境部署成功率 70%->95%
      • 接口自动化用例的平均稳定性:95%以上
      • ...
    • 全年OKR
      • 核心接口的自动化覆盖率:90%以上
      • 普通接口的自动化覆盖率:50%以上
      • 绝对代码行覆盖率:60%
      • 差异代码行覆盖率:80%
      • ...