自动化 on 测试开发刚哥

Allure测试报告完整学习笔记

Wed, 07 Jan 2026 00:00:00 +0000

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。

简介

假如你想让测试报告变得漂亮一点，那你一定会在搜索引擎中找到Allure测试报告的。Allure官方给出了个在线网站，访问以下链接就能一睹为快：

https://demo.qameta.io/allure/

可以在左下角切换为中文报告：

如此好看的测试报告，哪个老板不喜欢呢？

安装Allure

1.在GitHub releases：

https://github.com/allure-framework/allure2/releases

或者Maven Central：

https://repo.maven.apache.org/maven2/io/qameta/allure/allure-commandline/

下载安装包并解压。

2.找到bin目录，Windows使用allure.bat，Unix使用allure：

3.为了后续方便使用，可以把bin完整路径添加到系统环境变量PATH中，然后在命令行直接输入allure命令。

官方也给出了通过Linux的ppa、Mac的brew、Windows的scoop的安装方式，不过对于咱们老百姓来说，不如手动下载包来安装实在。

安装后就可以检查是否安装成功了：

$ allure --version
2.17.2

因为Allure是用Java写的，所以如果无法运行，那么要检查下有没有安装Java。

Allure测试报告的结构

Overview

Suites

Graphs

Timeline

Behaviors

Packages

Java TestNG集成Allure Report

集成

在Maven的pom.xml中添加：

<properties>
    <aspectj.version>1.8.10</aspectj.version>
</properties>
<dependencies>
    <dependency>
        <groupId>io.qameta.allure</groupId>
        <artifactId>allure-testng</artifactId>
        <version>LAST_VERSION</version>
        <scope>test</scope>
    </dependency>
</dependencies>
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.20</version>
            <configuration>
                <argLine>
                    -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
                </argLine>
            </configuration>
            <dependencies>
                <dependency>
                    <groupId>org.aspectj</groupId>
                    <artifactId>aspectjweaver</artifactId>
                    <version>${aspectj.version}</version>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>

然后执行命令：

老板给我安排了个测试环境治理的活

Tue, 06 Jan 2026 00:00:00 +0000

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。

测试环境困局

测试环境治理专项是在我入职2个月接手的活，用“烂摊子”来形容一点也不为过。年久失修，需求基本没有在测试环境使用，想用也有很多问题。人员缺乏信心，之前负责测试环境的同学抱怨极多，外部推不动，内部又没有技术能力支撑，负能量已经蔓延到整个团队。当然，我也是其中一员，这事确实难搞。在技术部测试环境平台化的大方向下，需要每个组出一个接口人来牵头，考虑到我以前写过测试平台，乱七八糟的事都整过，老板就指定了我。

What，测试环境是什么？

测试环境是一套能够支撑业务系统运行的环境，是相对于预发环境和生产环境来说完全隔离的环境。测试环境=应用+数据+配置+依赖服务。应用包含系统应用和中间件等，数据就是测试物料，配置针对测试环境应该有单独的一套，依赖服务要跟外部联调好以后整个环境才是可用的。测试环境治理就是通过内部搭建和外部联调，保障业务系统能够在完全隔离的环境中运行。

Why，为什么要做测试环境？

测试环境是为了隔离。如果只有一套生产环境，那么开发、测试、上线等活动，可能会对线上系统稳定性造成影响，可能会污染线上用户数据，可能引起客户投诉甚至资产损失，所以需要有一套完全隔离的测试环境。

Who，谁来负责测试环境？

每个测试人员都需要具备测试环境搭建能力。当然可以推动运维或研发来搭建测试环境，但是测试人员需要具备搭建能力，能够自主编译，构建，部署，遇到问题能够根据日志做初步定位，将问题抛出推动研发或外部依赖方解决。

When，什么时间做测试环境？

测试环境治理需要前置到研发自测阶段。在实践过程中，测试同学暴露出来最多的问题是，没有时间投入到测试环境搭建中，一方面是缺乏动力，不肯迈出艰难的第一步，另一方面也是跟项目节奏有关，研发就算用测试环境自测，也会在预发联调好以后再提测，到测试手上时，已经有可用的预发环境了，就不会再去用测试环境。“项目时间紧，测试环境不好用，直接用预发测吧”，顺理成章的就成为了很合理的借口。所以需要从提测，前置到，研发自测，做测试环境治理：

Where，从哪里入手测试环境？

测试环境治理需要从上往下才能推动，先有文化，才有行动。假如只有某个部门想做测试环境治理，外部依赖基本上是推不动的，一个人呐喊得再愤怒其他人也可能无动于衷。所以得先把测试环境治理这件事，跟老板沟通，从高层入手，把它定义为一项政治任务，从上往下层层递进。

How，怎么做测试环境？

工欲善其事，必先利其器，公司的基建比较完善，给测试人员搭建测试环境降低了很大难度。设想一下，假如只能折腾Docker和K8S，那可能需要专门的运维才能搞得定环境，对测试来说门槛就会比较高了，除了少数技术能力强的，其他同学基本没有什么可操作性。测试环境平台化就是武器。公司有个部署平台叫做JDOS，日常运维都是在这上面操作，没有运维人员，环境全靠开发人员和测试人员自己整。JDOS已经是页面化操作了，但它对测试环境没有特殊的应用场景，是个大而全的平台，所以二级部门开了一个测试环境平台，Env，“一款全流程自动化测试环境搭建的利器”。

Env的核心思想是1+N。1代表稳定分组（分组≈Pod），搭建稳定分组需要经过创建系统，创建应用，创建集群，申请机器，代码编译构建，部署镜像，修改配置等操作，需要选取master稳定版本，这样才能对外提供稳定服务。N是克隆1产生的多个分组，相互隔离，能让开发同学复用测试搭建好的环境，完成冒烟自测等过程；也能在多业务联调测试时，通过平台快速搭建一套全链路测试环境。

Env提供了环境监控的功能。对于搭建好的稳定环境，它可以每天监控机器是否可用，服务是否正常，镜像是否老旧，等等等，让你及时维护环境，保障稳定性。

Env提供了一键搭建的功能。新克隆的环境，只要点一下“一键搭建”，就会基于稳定分组，自动化搭建一套新环境，大大节约了时间成本。

Env提供了拓扑画图的功能。将多个应用拖到一张拓扑图里面，根据依赖关系连线，能够直观了解到应用之间的依赖关系。基于拓扑来克隆新环境，也能批量克隆多个应用。假如多项目需求并行迭代，想要多套联调的测试环境，就可以克隆多套新环境。

Env还解决了一个资源浪费的问题，以前搭建测试环境比较随意，申请资源也很容易，其实会导致很多机器用过后，一直空置在那里。Env收拢了申请资源入口，基于Env来创建稳定分组，只能有1个，想要更多必须走审批。而对于克隆的新环境，也会有期限，14天以后会自动释放，想要延期也必须走审批。

我所负责的第一件事，就是用Env来搭建一张拓扑图，把组内所有应用都从JDOS迁移到Env上，维持稳定环境对外提供支撑对接，克隆环境对内支持多项目并行。

搭建测试环境只是起步，测试环境治理的目标是需求能够使用测试环境。对于外部依赖少的业务模块来说，这相对容易。对于外部依赖很多的业务模块来说，这就很难了。那么该如何推动这件事呢？

第1个策略是共建，让研发和测试一起来搭建和维护测试环境。

第2个策略是做功能验证，梳理出链路用例，跟踪验证结果，识别卡点问题：

对于卡点问题的处理，把干系人单独拉群对，响应超过3天就往上抛，一定会遇到推不动的问题，那么办法只能找自己的上游负责人，层层向上反馈，让上面的负责人去找对方负责人，然后推动对方的下游同学来协助解决。卡点问题记录后需要做问题分类，做好统计，这既是工作量的体现，也是每周进度汇报的依据：

第3个策略就是制定kpi，强制大家使用测试环境完成绩效。

How much，测试环境做到什么程度？

测试环境的kpi能反应出测试环境应该做到什么程度，可以使用需求使用测试环境占比和测试环境bug占比。需求使用测试环境占比的计算公式是打标了测试环境的提测卡片数/总的提测卡片数，测试在点击开始测试时，选择是否使用测试环境进行打标。测试环境bug占比的计算公式是测试环境bug/(测试环境bug+预发环境bug+生产环境bug)，在提交缺陷时选择环境类型进行打标。测试环境bug占比的意义更大，因为使用测试环境与否，最终的体现还是落在缺陷上面的，比较容易量化，需求使用测试环境占比不是很确定，需求多少功能在测试环境使用了，相对来说不是很好度量，但也可以作为辅助指标进行观察。

测试环境破局

测试环境关联了很多东西，比如物料、自动化、精准、流水线等，都可以围绕测试环境来做文章。测试环境既是团队重点，也是是我个人的大案例，目前已经解决了部分困难，要想做出一鸣惊人的成绩，还需要站在更高的角度去看待整个事情，这也是一个全新的挑战，需要不断刷新自己，突破。

端到端自动化的开源框架

Mon, 05 Jan 2026 00:00:00 +0000

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。

什么是Playwright？

Playwright是一个开源框架，用于对Web应用进行端到端测试。

什么是端到端测试？

这里的“端”，不是指A模块或B模块，而是可以理解为从前端到后端。举个例子，对于登录功能来说，如果只测前端，那么测试范围就是前端页面，可能会对后端接口进行mock。如果只测后端，那么测试范围就是后端接口等。而端到端呢，就是前端输入用户名密码，点击登录，与后端交互，查询数据库，鉴权，后端返回登录成功，前端进行页面跳转。端到端测试，可以理解为全流程测试，也可以理解为模拟用户场景测试。

Playwright框架特点

官方网站首页：https://playwright.dev/python/

总结下重点，一是跨浏览器、跨平台、跨语言；二是自动等待；三是多用户场景测试；四是只需要一次登录；五是可以录制脚本。

快速入门

在官网的顶部菜单可以切换不同编程语言的教程：

本文及后续文章均选择Python。

安装

安装Python的Playwright，这里结合了pytest：

pip install pytest-playwright

成功后安装浏览器：

playwright install

这里也可以不安装浏览器，而是在脚本里面指定现有浏览器路径。

示例

test_example.py

import re
from playwright.sync_api import Page, expect

def test_has_title(page: Page):
    page.goto("https://playwright.dev/")

    # Expect a title "to contain" a substring.
    expect(page).to_have_title(re.compile("Playwright"))

def test_get_started_link(page: Page):
    page.goto("https://playwright.dev/")

    # Click the get started link.
    page.get_by_role("link", name="Get started").click()

    # Expects page to have a heading with the name of Installation.
    expect(page.get_by_role("heading", name="Installation")).to_be_visible()

执行pytest后默认会选择chrome在headless模式下运行，可以通过日志观察运行过程。

更新命令：

pip install pytest-playwright playwright -U

编写测试

访问url：

send_keys报错element_not_interactable

Sun, 04 Jan 2026 00:00:00 +0000

这两天要在阿里云日志中操作UI，以输入关键字搜索日志。

webdriver使用已打开过的chrome

Sat, 03 Jan 2026 00:00:00 +0000

基本功能：

理想中的接口自动化项目

Fri, 02 Jan 2026 00:00:00 +0000

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。

如何评价接口自动化项目

我理想中的接口自动化项目，是有一套脚本，能够100%覆盖核心业务场景，能够回归线上频繁出现的问题，能够支持手工无法验证的场景，能够抛出偶现问题，能够包含容易遗漏的边界场景、异常场景，每天都能定时运行，出具报告，给予反馈。

用实际的指标量化下：

功能测试自动化率 = 自动化测试用例数/总测试用例数
自动化发现bug占比 = 自动化发现的bug/总bug数
自动化发现bug有效性 = 自动化发现的有效bug/自动化提交的bug总数
自动化执行成功率 = 自动化执行成功的次数/自动化执行总次数
周活跃自动化用例占比 = (∑每周执行过的自动化测试用例)/(∑周维度自动化测试用例)
应用维度自动化代码覆盖率 = 自动化用例覆盖代码行数/应用维度代码总行数

现状是什么(Situation)

我负责的业务是发票中台，数据流简化后如下图所示：

发票中台对调用方提供RPC服务，底层有读写MySQL、同步ES、消息队列、异步任务等服务，上游是用户和订单，需要账号、增票资质、订单等物料；下游是财务，推送申请单给财务开具发票等。

发票的接口自动化在多年前是写了的，用Java+TestNG+RPC本地化了一套框架来实现，因为人员离职和业务变更，这套自动化到我手上的时候，已经不能用了，本地化的接口自动化项目也无法做数据度量，只有接口测试平台写的自动化用例才会被统计到。

任务是什么(Task)

我给自己定的绩效是在Q2完成95条自动化用例，按照一个标准化的自动化项目来实现发票的接口自动化，结合测试环境、测试物料、流水线、精准分析，打造一个个人的稳定的沉淀物，无论是晋升还是求职，都能拿来讲点故事。

行动是什么(Action)

编写自动化用例的方式

1、最理想的方式，是能够录制线上流量直接转换为自动化用例，修修改改即可。虽然我们有流量录制回放平台，但是它跟接口自动化平台并没有打通，很可惜不能采取这种方式。

2、参考线上流量日志，抓取接口、入参，人工转化为自动化用例。

3、参考接口的代码设计，比如controller/provider/sdk都定义了应用接口，能知道哪些覆盖到了，哪些还需要补充。

4、根据入参模板自行构造参数。参数个数太多的话造起来很麻烦。

我主要采用第2种和第3种方式结合来编写自动化用例。

典型自动化用例

前置步骤：初始化数据，将订单发票类型更新为3。

预设变量：提供参数化数据。

执行步骤：调用修改订单发票类型接口，将发票类型3改为2，入参引用预设变量。

财务接口：依赖测试物料无法满足，通过Mock来返回模板数据，让接口继续往下走。

基础断言：接口响应状态码200。

业务断言：调用订单列表查询接口，用JSONPath提取响应中的发票类型，断言已经改成了2。

场景用例

数据准备：通过物料工具造订单数据，写入MySQL数据库中。

更新MySQL数据：更新订单的部分字段数据，触发binlake，将数据同步至ES，因为提交开票申请是读取的ES数据；从预设变量获取orderId。

提交开票申请：从ES读取订单数据，提交开票申请；从预设变量获取orderId和userId。

查询申请单号：根据订单号查询申请单号；从预设变量获取orderId和userId。用JSONPath提取申请单号，存入动态变量中。

推送财务：把申请单号推送给财务；从动态变量获取applyId。

覆盖更多代码

①看代码：

在Java工程里面的Controller/Provider找到所有接口，分析可以用来做自动化的接口，设计自动化用例进行覆盖。

②代码覆盖率：

借助于jacoco，在执行自动化用例后，把代码覆盖率跑出来，分析没覆盖的代码，补充更多正常/异常/边界的自动化用例。也就是精准测试。

自动化巡检

每天早上8点，定时任务执行用例集；发送邮件，抄送测试组、开发组、领导，让测试、开发和领导都知道自动化建设情况；如果出现问题，一定要在当天解决，并邮件回复问题原因；确保当天的自动化用例结果都是正确的；第二天接着继续巡检。

流水线

在持续集成中，引入自动化用例环节，把自动化用例跑通作为提测卡点，不通过可以驳回。

产出是什么(Result)

定性来看：

结合测试环境、测试物料、自动化、流水线、精准测试，完成了一个能对环境和业务进行稳定性巡检，能对研发提测进行质量门禁，能对应用进行代码覆盖率分析的接口自动化项目。

定量来看：

功能测试自动化率 = 自动化测试用例数/总测试用例数 95/100=95%
自动化发现bug占比 = 自动化发现的bug/总bug数 2/53=3.7%
自动化发现bug有效性 = 自动化发现的有效bug/自动化提交的bug总数 2/2=100%
自动化执行成功率 = 自动化执行成功的次数/自动化执行总次数 5396/5621=96%
周活跃自动化用例占比 = (∑每周执行过的自动化测试用例)/(∑周维度自动化测试用例) 77%
应用维度自动化代码覆盖率 = 自动化用例覆盖代码行数/应用维度代码总行数 39%

这个Q主要完成了核心流程和重要接口的自动化用例，还需要持续补充场景用例和异常/边界的自动化用例。

中台RPC接口自动化怎么做

Thu, 01 Jan 2026 00:00:00 +0000

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。

RPC接口

我所在的部门是技术中台，主要负责toB业务，上游是业务条线，包括PC、APP、小程序等终端，这些端的后台是HTTP接口层，而在HTTP接口层之下，就是技术中台的RPC接口层。

HTTP是一种超文本传输协议，基于TCP/IP来传输文本、图片、音频、视频等数据。数据包的传输能力不是HTTP提供的，而是TCP/IP干的。HTTP的本质是客户端和服务端约定好的一种通信格式，是一种全世界认可的通用范本。

RPC是一种远程调用，也就是进程间通信，既可以用HTTP协议，也可以用自定义协议。RPC的好处是没有HTTP那么多约束，简化了写法，可以根据公司自定义规范，内部统一即可。 所以在公司内部特别流行，比如阿里的Dubbo接口就是一种RPC接口，我们公司用的JSF接口，自研的服务框架，简称杰夫。

谈谈京东的服务框架 https://juejin.cn/post/6948351920088186888

举个例子，本地调用，是调用的本地方法：

 public User getUserById(Long id) {
       return userDao.getUserById(id); // 这叫本地调用
    }

而RPC远程调用，调用的是另外一个服务的方法：

 public User getUserById(Long id) {
       return userConsumer.getUserById(id); // 这是远程调用，逻辑是用户小组的服务实现的。
    }

本地调用和远程调用的比较如下图所示：

左边的本地调用，只在应用内部调用。右边的远程调用，会跨应用在应用之间调用。

RPC和HTTP用法区别

HTTP接口在调用时，输入URL，Method，Headers，Body等等等就可以发送请求了。

RPC接口的调用大同小异，输入：

JSF地址：方法引用路径，比如com.dongfanger.api.service.ShopProvider。

方法名：方法名称，比如queryShopList。

别名：既可以是分组别名，也可以直连IP地址。

方法入参：JSON串。

等等等，就可以发起请求了。

从用法能看出来，RPC和HTTP接口的结构体是差不多的，但是RPC不需要Method和Headers，精简了许多。

接口自动化

首先需要考虑的是目录结构设计，HTTP可以模块菜单创建用例目录，比如：

一级目录：管理端

二级目录：发票管理

三级目录：发票查询

而RPC是无页面的，一般存在很多业务线，所以可以按照功能域和业务线来组织目录，比如：

一级目录：发票

二级目录：提交申请

三级目录：分销

其次就得考虑技术实现了，公司基建比较完善，无论是HTTP还是JSF接口，都能在接口测试平台上编写自动化用例。虽然是Web平台写用例，但是得益于测试平台的优秀设计和使用体验，用起来很方便，效率也很高。交互方式跟JMeter大同小异，只是在细节上做了很多打磨。

然后就是参数构造了，建议是用流量回放的方式来做，省去手工编写参数的崩溃感。流量用例创建好以后，需要做一些参数化处理和接口关联。这样才能够把多个接口串起来。

对于测试数据，通过预设变量来统一管理，自动化用例也尽可能设计成闭环，增加，修改，查询，删除，用例跑完后产生的数据也跟着清理掉。

最后就是断言了。没有断言的自动化用例，不叫做自动化用例。断言一定要加上，否则定时任务跑出结果后，无法判断到底有没有问题。而断言内容不能只是简单的code200，需要加上业务校验。

中台RPC接口自动化最难处理的是接口依赖问题，链路特别长，依赖特别多。我一般通过Mock来解决这个问题，公司的测试平台也提供了这个功能。

需要注意的是，核心用例定时运行监控起来，而一次性用例要及时维护或清理，防止变成僵尸用例。

最后，我准备基于Vue+FastAPI开发一套新的pytest脚本管理平台，集成流量录制创建用例和Mock等功能，并借鉴公司测试平台的设计，感兴趣的同学可以添加微信cekaigang加群讨论哟。

参考资料：

HTTP 的本质？HTTP 和 RPC 的区别？ https://www.jianshu.com/p/fe5ccfc5d7bd

谈谈京东的服务框架 https://juejin.cn/post/6948351920088186888

自动化 on 测试开发刚哥

Allure测试报告完整学习笔记

目录

简介

安装Allure

Allure测试报告的结构

Overview

Categories

Suites

Graphs

Timeline

Behaviors

Packages

Java TestNG集成Allure Report

集成

老板给我安排了个测试环境治理的活

测试环境困局

What，测试环境是什么？

Why，为什么要做测试环境？

Who，谁来负责测试环境？

When，什么时间做测试环境？

Where，从哪里入手测试环境？

How，怎么做测试环境？

How much，测试环境做到什么程度？

测试环境破局

端到端自动化的开源框架

什么是Playwright？

什么是端到端测试？

Playwright框架特点

快速入门

安装

示例

编写测试

send_keys报错element_not_interactable

webdriver使用已打开过的chrome

理想中的接口自动化项目

如何评价接口自动化项目

现状是什么(Situation)

任务是什么(Task)

行动是什么(Action)

编写自动化用例的方式

典型自动化用例

场景用例

覆盖更多代码

自动化巡检

流水线

产出是什么(Result)

中台RPC接口自动化怎么做

RPC接口

RPC和HTTP用法区别

接口自动化