自动化

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 目录 简介 安装Allure Allure测试报告的结构 Java TestNG集成Allure Report Python Pytest集成Allure Report 简介 假如你想让测试报告变得漂亮一点，那你一定会在搜索引擎中找到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 Categories 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> 然后执行命令： ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 测试环境困局 测试环境治理专项是在我入职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占比的意义更大，因为使用测试环境与否，最终的体现还是落在缺陷上面的，比较容易量化，需求使用测试环境占比不是很确定，需求多少功能在测试环境使用了，相对来说不是很好度量，但也可以作为辅助指标进行观察。 测试环境破局 测试环境关联了很多东西，比如物料、自动化、精准、流水线等，都可以围绕测试环境来做文章。测试环境既是团队重点，也是是我个人的大案例，目前已经解决了部分困难，要想做出一鸣惊人的成绩，还需要站在更高的角度去看待整个事情，这也是一个全新的挑战，需要不断刷新自己，突破。

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 什么是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： ...

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

基本功能：

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 如何评价接口自动化项目 我理想中的接口自动化项目，是有一套脚本，能够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接口 我所在的部门是技术中台，主要负责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