点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快作为测试你可能会对以下场景感到似曾相识开发改好的 BUG 反复横跳版本兼容逻辑多修复一个 BUG 触发了更多 BUG上线时系统监控毫无异常过段时间用户投诉某个页面无数据改动祖传代码时如履薄冰心智负担极重。为此本文提出一个自动化测试系统它能够低成本实现100%的测试用例覆盖率极大减轻管理自动化测试用例的工作量并提高测试效率保障后台服务平稳变更。欢迎阅读~一、背景1.1 接口自动化测试介绍顾名思义接口测试就是对系统或者组件之间的接口进行测试主要校验数据的交换、传递以及系统间的相互依赖关系等。根据测试金字塔的模型理论测试分为三层分别是单元测试Unit Tests、服务测试Service Tests、UI 测试UI Tests而我们的接口自动化测试就是服务测试层。单元测试会导致工作量大幅提升在需求快速迭代和人力紧张的背景下很难持续推进本文暂不讨论。而接口自动化测试容易实现、维护成本低且收益更高有着更高的投入产出比。1.2 现状及痛点实际上我们有一个叫 WeJestAPITest 的自动化测试平台它是基于 Facebook 开源的 Jest 测试框架搭建的用于校验后台的接口返回是否符合预期。在这个平台此前运行了数年的测试一定程度上保障了后台服务的平稳运行。但在长期使用中我们也发现了一些痛点遇到失败用例习惯性申请跳过测试自动化测试形同虚设版本需求迭代速度飞快用例落后于需求变更用例迭代成本高开发同学很难参与到用例维护中而测试同学对接口逻辑了解不深编写的用例过于简单、僵硬导致覆盖率低、用例质量差开发上线心理负担重。我们需要的不只是一个自动化测试系统而是一个更好用的、管理成本更低的自动化测试系统。1.3 为什么要自研提到接口自动化测试工具开源有 JMeter、Postman 等司内也有成熟的 WeTest、ITEST 等这些都是开箱即用的但经过调研和评估我们还是决定自己造一个轮子。考虑的点如下测试工具的实现原理并不复杂实现成本不高维护难度不大现有工具并不符合业务要求例如自定义的调度方案以及支持内部 RPC 框架我们需要把自动化测试与现有的系统连接起来比如上线系统用例失败告警系统流量分析系统等当我们需要一些非标准能力的时候外部工具很难快速甚至无法支持拓展性弱这个系统主要是为了覆盖后台接口测试使用体验上要更贴近后台同学的使用习惯降低用例管理成本。1.4 目标结合我们遇到的痛点以及业务需求自研的自动化测试系统应该具备以下的能力它应该是跟实现语言无关的甚至是无代码的消除不同编程语言和框架带来的隔阂编写用例应该是纯粹的用例跟测试服务分离变更用例不需要变更自动化测试服务能够支持场景测试多个用例组成场景且能支持用例间的变量引用提供多种调度方案可以按全量调度、按业务模块调度、按用例组调度、按单个用例调度充分满足业务和调试需求这个系统要支持同时管理 HTTP 和 RPC 用例可以覆盖请求的上下游链路尽最大可能降低后台同学编写用例的成本。二、自动化测试系统实现2.1 整体架构2.2 统一 HTTP 和 RPC 访问形式HTTP 和 RPC 请求在形式上可以被统一起来其描述形式如下HTTP访问方式http://host:port/urlpath reqbodyRPC访问方式rpc://ip:port/method reqbody通过这种统一的描述形式再结合我们的业务架构就可以设计一种通用的访问方式。后台的系统架构如下图所示从 proxy 层往下所有的调用都是一个个后台服务模块HTTP 访问的是逻辑层RPC 访问的是服务层。那么只需要配置用例的归属模块通过模块名 Client 配置就可以对 HTTP 和 RPC 请求进行区分以及寻址。从变更系统的角度来看我们的上线变更也是按模块来的。因此把用例归属到一个个具体的模块是最符合后台同学认知的做法。因此我们通过配置模块名这种统一的形式为使用者提供了统一的管理方式只需要指定模块名就可以任意访问 HTTP 或者 RPC 请求其流程如下在红色虚线框的流程中只需要配置模块名就可以通过模块名获取到 RPC 服务的所有信息包括其接口定义、请求包定义、回包定义这不是一种通用能力需要业务基于系统架构以及线上环境去拓展但这带来了以下便利可以支持任意的业务 RPC 框架拓展性强只需要配置模块名就可以访问所有的 RPC 请求无需逐个手动上传解析 proto 文件减少操作步骤不需要关心 proto 的更新实时拉取线上 proto 的信息协议永远是最新版本。这里的统一包含两部分第一部分是访问形式的统一模块降低了配置用例的成本第二部分是数据的统一JSON它统一了对回包方式的校验降低了校验成本。2.3 接口参数传递参数池构造很多业务场景的完成都是由多个接口组成的一条链路实现而且这种链路型的自动化测试通常会存在参数依赖关系一个用例的入参可能要依赖上游响应回包的某个字段值因此需要提取出来并传递给下一个接口。如下图其解决方案是通过正则或者 JSON Extracor 等提取的结果作为变量然后再传递给下游用例使用这也是很多测试工具使用的方式但是维护起来不够方便仍有进一步优化的空间。于是我们提出了参数池的概念将每个用例可能用到的字段都放入一个池子里这个池子的元素是一个个 key-value。key 是我们要使用的变量value 则是 key 对应的取值值得注意的是value 既可以是一个字面值也可以是一个 JSONPointer 的路径这个路径可以从响应回包中提取变量值。在这种方式下不同用例间的参数依赖不再是从上一个“传递”到下一个而变成了一个随取随用的池子因此我们把它称为参数池。同时我们通过自定义的语法实现了一个简单的模板引擎将我们引用的变量替换为池子里的 value 值。参数池构造以及使用图示如下2.4 JSON Schema 组件下面贴一段代码看看现有 WeJestAPITest 框架是如何对返回值做校验的并分析一下它可能存在的问题function bookInfoBaseCases(bookInfoObject) { it(预期 bookInfo.bookId 非空且为字符串且等于12345, () { expect(bookInfo.bookId).not.toBeNull(); expect(typeof bookInfo.bookId).toEqual(string); expect(bookInfo.bookId).toEqual(12345); }); }这种校验方式存在以下几个问题这是针对单个字段进行校验如果一个回包里有几十上百个字段这种手工方式不可能实现全量字段校验编写一个用例需要有 js 基础对其他编程语言的使用者不友好断言规则都是一条条散落在代码文件中展示和管理有难度调试需要变更测试服务调试成本高。现有框架的不便导致了用例管理上的种种问题而我们根据这些不便之处去反向思考我们到底需要什么样的校验方式这种情况下我们找到了 JSON Schema。JSON Schema 是描述 JSON 数据格式的工具Schema 可以理解为模式或者规则它可以约束 JSON 数据应该符合哪些模式、有哪些字段、其值是如何表现的。JSON Schema 本身用 JSON 编写且需要遵循 JSON 本身的语法规范。下面以bookInfo的校验为例写一份 JSON Schema 的校验规则// bookInfo信息 { bookId:123456, title:书名123, author:作者123, cover:https://abc.com/cover/123456.jpg, format:epub, price:100 } // 对应的JsonSchema校验规则 { type: object, required: [bookId, title, author, cover, format, price], properties: { bookId: { type: string, const: 123456 }, title: { type: string, minLength: 1 }, author: { type: string, minLength: 1 }, cover: { type: string, format: uri }, format: { type: string, enum: [epub, txt, pdf, mobi] }, price: { type: number, exclusiveMinimum: 0 } } }通过对比JSON Schema 的优点非常显而易见可读性高其结构跟 JSON 数据完全对应所有规则都处在一个 Schema 中管理和展示清晰易懂它本身是一个 JSON对于任何编程语言的使用者都没有额外学习成本此外我们可以通过一个现有的 JSON 反向生成 JSON Schema然后在这个 JSON Schema 的基础上进行简单的修改就能得到最终的校验规则极大降低了我们编辑用例的工作量和时间成本。2.5 JSON Path 组件有了 JSON Schema 之后我们校验方式看似已经非常完美了。它既可以低成本的覆盖全量字段校验还可以很方便的进行字段类型、数值的校验。但实际使用中我们发现有些测试场景是 JSON Schema 覆盖不到的比如一条用户评论有 createtime 和 updatetime 两个字段需要校验 updatetime createtime。这是 JSON Schema 的短板它可以约束 JSON 的字段但是它没办法对两个字段进行对比同时 JSON Schema 跟 JSON 是一对一的如果我们需要比较两个不同 JSON 的同一个字段它同样无能为力。这就引出了我们需要的第二个工具 —— JSONPath。JSONPath 是一个 JSON 的信息抽取工具可以从 JSON 数据中抽取指定特定的值、对象或者数组以及进行过滤、排序和聚合等操作。而 JSONPath 只是一个 JSON 字段的提取工具要利用它来实现一个断言判断还需要进一步封装。在这里我们用一个 JSONPath 表达式来表示一个断言下面是一些简单的使用示例// 校验updateTime createTime $.updateTime $.createTime // 返回的bookId必须为某个固定值 $.bookId [123456] // datas数组不能为空 $.datas.length [0] // datas数组中必须包含某本书且价格要大于0 $.datas[?(.bookId123456)] [0]值得注意的是JSON Schema 和 JSON Path 断言校验并非二选一既可以同时校验也可以根据场景选择任意一种校验方式。与此同时如果项目前后端交互的协议是 XML、 proto 或者其他协议可以将其统一转为 JSON 格式JSON 更容易理解且工具链更多更成熟否则我们将要为每一种序列化的协议都开发一套类似的工具重复劳动。2.6 变更系统接入与调度在这里我们使用异步 MQ 去调度测试任务它有三个主要的特点三、自动化测试系统实现在拥有了一个接口自动化测试平台之后我们面临一个新的问题如何快速提升自动化测试的覆盖率这个问题有一个隐含的前提我们需要一个可以衡量覆盖率的指标接下来将介绍我们如何构造这个指标并分享一些提升覆盖率的方案。3.1 变更系统接入与调度要衡量覆盖率第一反应必然是基于前后端约定的协议进行分析。但是沿着这条思路去分析我们遇到了以下几个难点协议管理不规范散落在 git 文档、yapi、wiki 等多处地方且格式不统一文档落后于实际接口协议且可靠性有待考究协议参数并非都是正交的使用协议计算出来的参数组合不符合实际情况因此使用前后端协议进行分析这条路是行不通的。因此我们打算从线上流量入手对流量的参数特征进行分析并使用线上流量来生成自动化测试用例。3.2 整体流程3.3 流量特征分析一个 HTTP 请求我们通常需要分析的是以下部分请求方法、URL、请求包、返回包。而结合我们的业务场景我们还需要一些额外的信息用户 ID、平台安卓、IOS、网页等、客户端版本号等。我们调研过一些流量采集分析并生成用例的系统大多只能对通用信息进行分析并不能很好的结合业务场景进行分析拓展性不足。我们有一个请求其 url 参数为 listType1listMode2、vid 为10000、平台为 android、版本号为7.2.0其请求体如下:{ bookId:12345, filterType:1, filterTags:[abc,def], commOptions:{ ops1:testops1, ops2:testops2 } }其中 url 和 header 里的参数都很容易解析不再赘言下面讲一下 JSON 请求中的参数提取方法。这里我们用 JSONPointer 来表示一个参数的路径作为这个参数的 key 值那么可以提取获得以下参数// url 和 header 中提取的参数 listType1 listMode2 vid10000 platformandroid appver7.2.0 // JSON 中提取的参数 /bookId12345 /filterType1 /filterTags[abc, def] /commOptions/opts1testops1 /commOptions/opts2testops2如此一来参数的表现形式可以统一为 key-value 的形式我们调研的工具也基本止步于此接下来要么是用正交计算用例的方式辅助人工编辑用例要么就是对大量流量生成的用例进行去重。但这达不到我们预设的目标我们不妨更进一步通过大量的线上流量构造出接口参数的特征在这里我们提出一个定义接口参数的特征包括五部分参数个数参数类型参数取值范围参数可枚举性参数可组合性。我们的工作主要集中在参数的可枚举性分析这也是参数分析的突破点。假设我们从线上对某个接口进行采样采样条数为 1W 条将得到以下的参数listType[1, 2, 3, 4] listMode[1, 2] vid[10000, 10001, 10002, 10003, ...] // 3000 platform[android, ios, web] appver[7.2.0, 7.1.0, 7.3.0, ...] // 20 /bookId[12345, 23456, 34567, 56779, ...] // 4000 /filterType[1, 2] /filterTags[abc, def, efg] /commOptions/opts1[testops1, testops1_] /commOptions/opts2[testops2]有了以上提取到的参数枚举值我们设定一个合理的阈值比如30就可以判断哪些参数是可枚举的很明显 vid 和 /bookId 并不是可枚举的参数在覆盖用例时不需要对这两个参数进行覆盖。在实践中我们发现固定阈值并不能精准识别到有效的枚举参数阈值需要跟随采样的数据动态调整。不同接口请求量可能从几十到几十万不等如果一个接口请求条数只有30条每一个参数的枚举值都小于设定的阈值所有参数都是有效参数这不符合实际情况。因此阈值要随着采样条数的变化而变化可以按请求数量阶梯变化也可以按请求数量成比例变化。对于特定参数还要提供人工配置快速介入指定参数是否可枚举。在我们知道哪些参数是可枚举的有效参数后接下来可以对参数的可组合性进行分析。实际上我们并不需要分析任意两个参数两两是否可组合基于线上流量去分析即可。我们简单给一个例子listType1listMode1platformandroidappver7.2.0 listType1listMode1platformiosappver7.2.0 listType1listMode1platformwebappver7.2.0 listType2listMode1platformandroidappver7.2.0 listType2listMode1platformiosappver7.2.0 listType2listMode1platformwebappver7.2.0 listType3listMode2platformandroidappver7.2.0 listType3listMode2platformiosappver7.2.0 listType3listMode2platformwebappver7.2.0那么在覆盖用例时我们需要覆盖这9个组合通过组合分析我们甚至可以发现线上是否有错误使用的参数组合需求是否发生了变更产生了新的组合参数。要提升覆盖率本质上就是覆盖所有可枚举参数的枚举类型以及组合这就是我们在上面提到过的覆盖率指标。有了这个指标我们就可以对覆盖率提出以下计算公式全局覆盖率 已覆盖的接口数 / 全部接口数 * 100% 接口有效用例 全部可枚举参数的可枚举值 全部可枚举参数的组合 接口覆盖率 已覆盖的有效用例数 / 接口有效用例数 * 100% PS当接口覆盖率达100%时视为接口已实现用例覆盖3.4 用例生成经过上面对流量的特征分析以及筛选我们得到了一批有效流量接下来就可以使用这些流量来自动化生成用例其中最主要的工作是为用例生成校验的 JSON Schema 规则。其生成过程如下图所示如上图所示任何 JSON Schema 的生成工具所生成的 Schema 都不可能百分百满足业务需求我们仍然要根据业务场景对 Schema 进行微调。比如在搜索场景下我们用一个 results 数组来承载返回结果生成器生成的 Schema 只约定了 results 字段必须要存在并且字段类型为数组类型。如果有一天返回了一个空的 results 数组那么默认生成的 Schema 是检查不出这个问题的我们可以为 results 数组增加 minItems 1 的规则要求 results 数组必须大于等于 1下次校验时遇到空数组就能够告警出来。同时在用例执行时遇到校验不通过的情况我们也设计了一套自动化 promote 用例的流程不需要手工对用例进行改动。其流程如下其中用例优化分为三种情况移除用例用例已失效直接删除用例替换用例用例不符合预期从线上根据同样的参数选取请求重新生成一个用例优化 Schema用例中某些字段并非必需字段或者属于预期内的变化比如用户的未购变已购导致某些字段被替换。我们使用的 Schema 生成工具是 genson它可以为一个 JSON 生成对应的 JSON Schema。这个工具有个很重要的特性它是一个多输入的 JSON Schema 生成工具可以接收多个 JSON 或者 Schema 作为输入参数生成一个符合所有输入要求的 Schema这一点正是我们自动化的关键使得我们不需要手动编辑校验规则。下面简单展示一下我们现在的系统是如何优化失败用例的3.5 用例发现与补全用例的自动化发现分为两个离线任务一个是新接口的发现一个是新用例的发现。新接口是指我们有新的功能上线当线上有流量访问时我们应该及时发现这个新的请求并将这个请求纳入我们的自动化测试管理范围。新用例是指通过对流量分析发现了新加的可枚举参数或者之前用例未曾覆盖的参数组合我们通过对比线上流量和已经采集落库的用例进行 diff 分析得到并生成新的用例。下图是对用例的自动化发现与补全的简单示例3.6 流量特征应用基于上面提到的流量特征分析以及用例生成我们的用例个数从150提升到8000实现了读接口100%用例覆盖覆盖率有了一个质的飞跃。对于写接口实现了覆盖率统计以及用例推荐极大降低了在编辑用例时的心智负担不需要自己去构造参数以及遍历所有的参数组合跟随着推荐的用例去补全即可。同时针对我们前面提到的前后端协议分散在各个地方且接口与文档不一致的问题我们通过线上流量对请求参数和请求回包的 Schema 进行持续的迭代然后再将 Schema 反向生成 JSON 就可以得到一份最全、最新的接口协议同时这份协议还可以提供给客户端同学用来构造参数进行 mock 联调。四、总结至此我们已经完成了整个后台接口自动化测试系统的搭建并完成了预设的全部目标集成 JSON Schema 和 JSONPath 这两个组件实现了一个无代码以及用例跟测试服务分离的自动化测试系统通过用例的组合以及参数池构造实现了场景测试和用例间变量引用支持了多种定制化的调度方案并接入到上线系统流程中打通 HTTP 和 RPC 接口访问结合业务架构极大降低了接入 RPC 用例的成本通过用例自动化生成进一步降低用例管理成本快速提高了自动化测试的覆盖率。对于旧用例系统上的数据我们花费了将近两周将数千行测试代码、将近一千条校验规则全部迁移到新的自动化测试平台上得到了150的新用例并且校验的规则变成了150的 JSON Schema不需要维护任何一行代码就得到了比之前更完善的全字段校验规则覆盖。此外我们通过用例发现和用例生成生成了8000的用例实现了读接口100%用例覆盖并多次辅助发现线上异常数据问题在用户还未感知前就已经将问题扼杀在摇篮之中。笔者认为本文最重要的并不是对各种工具的集成和使用100% 的用例覆盖也并非本文的最终目标。各种开源和付费工具数不胜数只要舍得投入人力 100% 的用例覆盖也并非难事。本文真正重要的是提出了一种通用的测试框架架构以及基于线上流量分析得到了一种测试覆盖率的度量方案。秉持着这种思路上文中我们提到的调度系统、用例执行 MQ、校验工具、测试告警系统、流量采集系统、用例生成系统都可以基于业务灵活调整低成本实现大规模用例覆盖。以上是本次分享的全部内容。最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。
接口自动化测试：测试用例也能自动生成
点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快作为测试你可能会对以下场景感到似曾相识开发改好的 BUG 反复横跳版本兼容逻辑多修复一个 BUG 触发了更多 BUG上线时系统监控毫无异常过段时间用户投诉某个页面无数据改动祖传代码时如履薄冰心智负担极重。为此本文提出一个自动化测试系统它能够低成本实现100%的测试用例覆盖率极大减轻管理自动化测试用例的工作量并提高测试效率保障后台服务平稳变更。欢迎阅读~一、背景1.1 接口自动化测试介绍顾名思义接口测试就是对系统或者组件之间的接口进行测试主要校验数据的交换、传递以及系统间的相互依赖关系等。根据测试金字塔的模型理论测试分为三层分别是单元测试Unit Tests、服务测试Service Tests、UI 测试UI Tests而我们的接口自动化测试就是服务测试层。单元测试会导致工作量大幅提升在需求快速迭代和人力紧张的背景下很难持续推进本文暂不讨论。而接口自动化测试容易实现、维护成本低且收益更高有着更高的投入产出比。1.2 现状及痛点实际上我们有一个叫 WeJestAPITest 的自动化测试平台它是基于 Facebook 开源的 Jest 测试框架搭建的用于校验后台的接口返回是否符合预期。在这个平台此前运行了数年的测试一定程度上保障了后台服务的平稳运行。但在长期使用中我们也发现了一些痛点遇到失败用例习惯性申请跳过测试自动化测试形同虚设版本需求迭代速度飞快用例落后于需求变更用例迭代成本高开发同学很难参与到用例维护中而测试同学对接口逻辑了解不深编写的用例过于简单、僵硬导致覆盖率低、用例质量差开发上线心理负担重。我们需要的不只是一个自动化测试系统而是一个更好用的、管理成本更低的自动化测试系统。1.3 为什么要自研提到接口自动化测试工具开源有 JMeter、Postman 等司内也有成熟的 WeTest、ITEST 等这些都是开箱即用的但经过调研和评估我们还是决定自己造一个轮子。考虑的点如下测试工具的实现原理并不复杂实现成本不高维护难度不大现有工具并不符合业务要求例如自定义的调度方案以及支持内部 RPC 框架我们需要把自动化测试与现有的系统连接起来比如上线系统用例失败告警系统流量分析系统等当我们需要一些非标准能力的时候外部工具很难快速甚至无法支持拓展性弱这个系统主要是为了覆盖后台接口测试使用体验上要更贴近后台同学的使用习惯降低用例管理成本。1.4 目标结合我们遇到的痛点以及业务需求自研的自动化测试系统应该具备以下的能力它应该是跟实现语言无关的甚至是无代码的消除不同编程语言和框架带来的隔阂编写用例应该是纯粹的用例跟测试服务分离变更用例不需要变更自动化测试服务能够支持场景测试多个用例组成场景且能支持用例间的变量引用提供多种调度方案可以按全量调度、按业务模块调度、按用例组调度、按单个用例调度充分满足业务和调试需求这个系统要支持同时管理 HTTP 和 RPC 用例可以覆盖请求的上下游链路尽最大可能降低后台同学编写用例的成本。二、自动化测试系统实现2.1 整体架构2.2 统一 HTTP 和 RPC 访问形式HTTP 和 RPC 请求在形式上可以被统一起来其描述形式如下HTTP访问方式http://host:port/urlpath reqbodyRPC访问方式rpc://ip:port/method reqbody通过这种统一的描述形式再结合我们的业务架构就可以设计一种通用的访问方式。后台的系统架构如下图所示从 proxy 层往下所有的调用都是一个个后台服务模块HTTP 访问的是逻辑层RPC 访问的是服务层。那么只需要配置用例的归属模块通过模块名 Client 配置就可以对 HTTP 和 RPC 请求进行区分以及寻址。从变更系统的角度来看我们的上线变更也是按模块来的。因此把用例归属到一个个具体的模块是最符合后台同学认知的做法。因此我们通过配置模块名这种统一的形式为使用者提供了统一的管理方式只需要指定模块名就可以任意访问 HTTP 或者 RPC 请求其流程如下在红色虚线框的流程中只需要配置模块名就可以通过模块名获取到 RPC 服务的所有信息包括其接口定义、请求包定义、回包定义这不是一种通用能力需要业务基于系统架构以及线上环境去拓展但这带来了以下便利可以支持任意的业务 RPC 框架拓展性强只需要配置模块名就可以访问所有的 RPC 请求无需逐个手动上传解析 proto 文件减少操作步骤不需要关心 proto 的更新实时拉取线上 proto 的信息协议永远是最新版本。这里的统一包含两部分第一部分是访问形式的统一模块降低了配置用例的成本第二部分是数据的统一JSON它统一了对回包方式的校验降低了校验成本。2.3 接口参数传递参数池构造很多业务场景的完成都是由多个接口组成的一条链路实现而且这种链路型的自动化测试通常会存在参数依赖关系一个用例的入参可能要依赖上游响应回包的某个字段值因此需要提取出来并传递给下一个接口。如下图其解决方案是通过正则或者 JSON Extracor 等提取的结果作为变量然后再传递给下游用例使用这也是很多测试工具使用的方式但是维护起来不够方便仍有进一步优化的空间。于是我们提出了参数池的概念将每个用例可能用到的字段都放入一个池子里这个池子的元素是一个个 key-value。key 是我们要使用的变量value 则是 key 对应的取值值得注意的是value 既可以是一个字面值也可以是一个 JSONPointer 的路径这个路径可以从响应回包中提取变量值。在这种方式下不同用例间的参数依赖不再是从上一个“传递”到下一个而变成了一个随取随用的池子因此我们把它称为参数池。同时我们通过自定义的语法实现了一个简单的模板引擎将我们引用的变量替换为池子里的 value 值。参数池构造以及使用图示如下2.4 JSON Schema 组件下面贴一段代码看看现有 WeJestAPITest 框架是如何对返回值做校验的并分析一下它可能存在的问题function bookInfoBaseCases(bookInfoObject) { it(预期 bookInfo.bookId 非空且为字符串且等于12345, () { expect(bookInfo.bookId).not.toBeNull(); expect(typeof bookInfo.bookId).toEqual(string); expect(bookInfo.bookId).toEqual(12345); }); }这种校验方式存在以下几个问题这是针对单个字段进行校验如果一个回包里有几十上百个字段这种手工方式不可能实现全量字段校验编写一个用例需要有 js 基础对其他编程语言的使用者不友好断言规则都是一条条散落在代码文件中展示和管理有难度调试需要变更测试服务调试成本高。现有框架的不便导致了用例管理上的种种问题而我们根据这些不便之处去反向思考我们到底需要什么样的校验方式这种情况下我们找到了 JSON Schema。JSON Schema 是描述 JSON 数据格式的工具Schema 可以理解为模式或者规则它可以约束 JSON 数据应该符合哪些模式、有哪些字段、其值是如何表现的。JSON Schema 本身用 JSON 编写且需要遵循 JSON 本身的语法规范。下面以bookInfo的校验为例写一份 JSON Schema 的校验规则// bookInfo信息 { bookId:123456, title:书名123, author:作者123, cover:https://abc.com/cover/123456.jpg, format:epub, price:100 } // 对应的JsonSchema校验规则 { type: object, required: [bookId, title, author, cover, format, price], properties: { bookId: { type: string, const: 123456 }, title: { type: string, minLength: 1 }, author: { type: string, minLength: 1 }, cover: { type: string, format: uri }, format: { type: string, enum: [epub, txt, pdf, mobi] }, price: { type: number, exclusiveMinimum: 0 } } }通过对比JSON Schema 的优点非常显而易见可读性高其结构跟 JSON 数据完全对应所有规则都处在一个 Schema 中管理和展示清晰易懂它本身是一个 JSON对于任何编程语言的使用者都没有额外学习成本此外我们可以通过一个现有的 JSON 反向生成 JSON Schema然后在这个 JSON Schema 的基础上进行简单的修改就能得到最终的校验规则极大降低了我们编辑用例的工作量和时间成本。2.5 JSON Path 组件有了 JSON Schema 之后我们校验方式看似已经非常完美了。它既可以低成本的覆盖全量字段校验还可以很方便的进行字段类型、数值的校验。但实际使用中我们发现有些测试场景是 JSON Schema 覆盖不到的比如一条用户评论有 createtime 和 updatetime 两个字段需要校验 updatetime createtime。这是 JSON Schema 的短板它可以约束 JSON 的字段但是它没办法对两个字段进行对比同时 JSON Schema 跟 JSON 是一对一的如果我们需要比较两个不同 JSON 的同一个字段它同样无能为力。这就引出了我们需要的第二个工具 —— JSONPath。JSONPath 是一个 JSON 的信息抽取工具可以从 JSON 数据中抽取指定特定的值、对象或者数组以及进行过滤、排序和聚合等操作。而 JSONPath 只是一个 JSON 字段的提取工具要利用它来实现一个断言判断还需要进一步封装。在这里我们用一个 JSONPath 表达式来表示一个断言下面是一些简单的使用示例// 校验updateTime createTime $.updateTime $.createTime // 返回的bookId必须为某个固定值 $.bookId [123456] // datas数组不能为空 $.datas.length [0] // datas数组中必须包含某本书且价格要大于0 $.datas[?(.bookId123456)] [0]值得注意的是JSON Schema 和 JSON Path 断言校验并非二选一既可以同时校验也可以根据场景选择任意一种校验方式。与此同时如果项目前后端交互的协议是 XML、 proto 或者其他协议可以将其统一转为 JSON 格式JSON 更容易理解且工具链更多更成熟否则我们将要为每一种序列化的协议都开发一套类似的工具重复劳动。2.6 变更系统接入与调度在这里我们使用异步 MQ 去调度测试任务它有三个主要的特点三、自动化测试系统实现在拥有了一个接口自动化测试平台之后我们面临一个新的问题如何快速提升自动化测试的覆盖率这个问题有一个隐含的前提我们需要一个可以衡量覆盖率的指标接下来将介绍我们如何构造这个指标并分享一些提升覆盖率的方案。3.1 变更系统接入与调度要衡量覆盖率第一反应必然是基于前后端约定的协议进行分析。但是沿着这条思路去分析我们遇到了以下几个难点协议管理不规范散落在 git 文档、yapi、wiki 等多处地方且格式不统一文档落后于实际接口协议且可靠性有待考究协议参数并非都是正交的使用协议计算出来的参数组合不符合实际情况因此使用前后端协议进行分析这条路是行不通的。因此我们打算从线上流量入手对流量的参数特征进行分析并使用线上流量来生成自动化测试用例。3.2 整体流程3.3 流量特征分析一个 HTTP 请求我们通常需要分析的是以下部分请求方法、URL、请求包、返回包。而结合我们的业务场景我们还需要一些额外的信息用户 ID、平台安卓、IOS、网页等、客户端版本号等。我们调研过一些流量采集分析并生成用例的系统大多只能对通用信息进行分析并不能很好的结合业务场景进行分析拓展性不足。我们有一个请求其 url 参数为 listType1listMode2、vid 为10000、平台为 android、版本号为7.2.0其请求体如下:{ bookId:12345, filterType:1, filterTags:[abc,def], commOptions:{ ops1:testops1, ops2:testops2 } }其中 url 和 header 里的参数都很容易解析不再赘言下面讲一下 JSON 请求中的参数提取方法。这里我们用 JSONPointer 来表示一个参数的路径作为这个参数的 key 值那么可以提取获得以下参数// url 和 header 中提取的参数 listType1 listMode2 vid10000 platformandroid appver7.2.0 // JSON 中提取的参数 /bookId12345 /filterType1 /filterTags[abc, def] /commOptions/opts1testops1 /commOptions/opts2testops2如此一来参数的表现形式可以统一为 key-value 的形式我们调研的工具也基本止步于此接下来要么是用正交计算用例的方式辅助人工编辑用例要么就是对大量流量生成的用例进行去重。但这达不到我们预设的目标我们不妨更进一步通过大量的线上流量构造出接口参数的特征在这里我们提出一个定义接口参数的特征包括五部分参数个数参数类型参数取值范围参数可枚举性参数可组合性。我们的工作主要集中在参数的可枚举性分析这也是参数分析的突破点。假设我们从线上对某个接口进行采样采样条数为 1W 条将得到以下的参数listType[1, 2, 3, 4] listMode[1, 2] vid[10000, 10001, 10002, 10003, ...] // 3000 platform[android, ios, web] appver[7.2.0, 7.1.0, 7.3.0, ...] // 20 /bookId[12345, 23456, 34567, 56779, ...] // 4000 /filterType[1, 2] /filterTags[abc, def, efg] /commOptions/opts1[testops1, testops1_] /commOptions/opts2[testops2]有了以上提取到的参数枚举值我们设定一个合理的阈值比如30就可以判断哪些参数是可枚举的很明显 vid 和 /bookId 并不是可枚举的参数在覆盖用例时不需要对这两个参数进行覆盖。在实践中我们发现固定阈值并不能精准识别到有效的枚举参数阈值需要跟随采样的数据动态调整。不同接口请求量可能从几十到几十万不等如果一个接口请求条数只有30条每一个参数的枚举值都小于设定的阈值所有参数都是有效参数这不符合实际情况。因此阈值要随着采样条数的变化而变化可以按请求数量阶梯变化也可以按请求数量成比例变化。对于特定参数还要提供人工配置快速介入指定参数是否可枚举。在我们知道哪些参数是可枚举的有效参数后接下来可以对参数的可组合性进行分析。实际上我们并不需要分析任意两个参数两两是否可组合基于线上流量去分析即可。我们简单给一个例子listType1listMode1platformandroidappver7.2.0 listType1listMode1platformiosappver7.2.0 listType1listMode1platformwebappver7.2.0 listType2listMode1platformandroidappver7.2.0 listType2listMode1platformiosappver7.2.0 listType2listMode1platformwebappver7.2.0 listType3listMode2platformandroidappver7.2.0 listType3listMode2platformiosappver7.2.0 listType3listMode2platformwebappver7.2.0那么在覆盖用例时我们需要覆盖这9个组合通过组合分析我们甚至可以发现线上是否有错误使用的参数组合需求是否发生了变更产生了新的组合参数。要提升覆盖率本质上就是覆盖所有可枚举参数的枚举类型以及组合这就是我们在上面提到过的覆盖率指标。有了这个指标我们就可以对覆盖率提出以下计算公式全局覆盖率 已覆盖的接口数 / 全部接口数 * 100% 接口有效用例 全部可枚举参数的可枚举值 全部可枚举参数的组合 接口覆盖率 已覆盖的有效用例数 / 接口有效用例数 * 100% PS当接口覆盖率达100%时视为接口已实现用例覆盖3.4 用例生成经过上面对流量的特征分析以及筛选我们得到了一批有效流量接下来就可以使用这些流量来自动化生成用例其中最主要的工作是为用例生成校验的 JSON Schema 规则。其生成过程如下图所示如上图所示任何 JSON Schema 的生成工具所生成的 Schema 都不可能百分百满足业务需求我们仍然要根据业务场景对 Schema 进行微调。比如在搜索场景下我们用一个 results 数组来承载返回结果生成器生成的 Schema 只约定了 results 字段必须要存在并且字段类型为数组类型。如果有一天返回了一个空的 results 数组那么默认生成的 Schema 是检查不出这个问题的我们可以为 results 数组增加 minItems 1 的规则要求 results 数组必须大于等于 1下次校验时遇到空数组就能够告警出来。同时在用例执行时遇到校验不通过的情况我们也设计了一套自动化 promote 用例的流程不需要手工对用例进行改动。其流程如下其中用例优化分为三种情况移除用例用例已失效直接删除用例替换用例用例不符合预期从线上根据同样的参数选取请求重新生成一个用例优化 Schema用例中某些字段并非必需字段或者属于预期内的变化比如用户的未购变已购导致某些字段被替换。我们使用的 Schema 生成工具是 genson它可以为一个 JSON 生成对应的 JSON Schema。这个工具有个很重要的特性它是一个多输入的 JSON Schema 生成工具可以接收多个 JSON 或者 Schema 作为输入参数生成一个符合所有输入要求的 Schema这一点正是我们自动化的关键使得我们不需要手动编辑校验规则。下面简单展示一下我们现在的系统是如何优化失败用例的3.5 用例发现与补全用例的自动化发现分为两个离线任务一个是新接口的发现一个是新用例的发现。新接口是指我们有新的功能上线当线上有流量访问时我们应该及时发现这个新的请求并将这个请求纳入我们的自动化测试管理范围。新用例是指通过对流量分析发现了新加的可枚举参数或者之前用例未曾覆盖的参数组合我们通过对比线上流量和已经采集落库的用例进行 diff 分析得到并生成新的用例。下图是对用例的自动化发现与补全的简单示例3.6 流量特征应用基于上面提到的流量特征分析以及用例生成我们的用例个数从150提升到8000实现了读接口100%用例覆盖覆盖率有了一个质的飞跃。对于写接口实现了覆盖率统计以及用例推荐极大降低了在编辑用例时的心智负担不需要自己去构造参数以及遍历所有的参数组合跟随着推荐的用例去补全即可。同时针对我们前面提到的前后端协议分散在各个地方且接口与文档不一致的问题我们通过线上流量对请求参数和请求回包的 Schema 进行持续的迭代然后再将 Schema 反向生成 JSON 就可以得到一份最全、最新的接口协议同时这份协议还可以提供给客户端同学用来构造参数进行 mock 联调。四、总结至此我们已经完成了整个后台接口自动化测试系统的搭建并完成了预设的全部目标集成 JSON Schema 和 JSONPath 这两个组件实现了一个无代码以及用例跟测试服务分离的自动化测试系统通过用例的组合以及参数池构造实现了场景测试和用例间变量引用支持了多种定制化的调度方案并接入到上线系统流程中打通 HTTP 和 RPC 接口访问结合业务架构极大降低了接入 RPC 用例的成本通过用例自动化生成进一步降低用例管理成本快速提高了自动化测试的覆盖率。对于旧用例系统上的数据我们花费了将近两周将数千行测试代码、将近一千条校验规则全部迁移到新的自动化测试平台上得到了150的新用例并且校验的规则变成了150的 JSON Schema不需要维护任何一行代码就得到了比之前更完善的全字段校验规则覆盖。此外我们通过用例发现和用例生成生成了8000的用例实现了读接口100%用例覆盖并多次辅助发现线上异常数据问题在用户还未感知前就已经将问题扼杀在摇篮之中。笔者认为本文最重要的并不是对各种工具的集成和使用100% 的用例覆盖也并非本文的最终目标。各种开源和付费工具数不胜数只要舍得投入人力 100% 的用例覆盖也并非难事。本文真正重要的是提出了一种通用的测试框架架构以及基于线上流量分析得到了一种测试覆盖率的度量方案。秉持着这种思路上文中我们提到的调度系统、用例执行 MQ、校验工具、测试告警系统、流量采集系统、用例生成系统都可以基于业务灵活调整低成本实现大规模用例覆盖。以上是本次分享的全部内容。最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。
