手把手带你设计接口自动化测试用例(二):根据接口信息设计测试用例

简介: 上一篇文章 手把手带你设计接口自动化测试用例(一):提取接口信息并分析 详细介绍了如何提取并分析登录、发布、修改、删除、查询等接口信息,这篇文章来看一下如何根据接口信息设计测试用例。ZrLog 系统接口测试用例的字段可以设计为 3 个部分,分别是主测试用例的字段(重要)、配置信息的字段、执行结果记录的字段。下面分别介绍这 3 部分字段的名称和含义。

1、设计主测试用例的字段


主测试用例的字段一般包含用例标识的字段、请求信息的字段和响应信息的字段,响应信息的字段一般作为接口用例执行结果的断言字段;另外由于本书的接口涉及 cookies 信息及接口之间的关联信息,所以需要加上 cookies 字段及接口关联字段。基于以上规则,ZrLog 系统主测试用例的字段设计如表1 所示。


表1 主测试用例的字段

image.png


2、设计配置信息的字段


配置信息的字段一般用来存放接口自动化框架中所需要的各类环境配置信息,具体需要哪些字段,在实际中可根据项目需求灵活设置,在 ZrLog 系统中对配置信息设置了 4 个常用字段,如表2 所示。


表2 配置信息的字段

image.png


3、设计执行结果记录字段


执行结果记录的字段主要用来存放测试用例执行的最终结果及相关的信息。具体需要设置哪些字段可根据项目情况灵活决定。


在 ZrLog 系统中对执行结果记录设置了以下常用的 5 个字段,如表3 所示。


表3 执行结果记录的字段

image.png


4、设计主测试用例内容并解决关联关系


接口测试用例与功能测试用例本质上并无区别,常用的设计方法有:有效、无效、边界、错误推测、场景法、正交法等。接口测试包括单接口测试和多接口测试,单接口测试是指针对单个接口的用例设计,而多接口测试是指针对多个接口的用例设计,一般是基于正向的业务流程去设计用例,并且要处理上下游接口的关联关系。


基于此规则,对于文章 手把手带你设计接口自动化测试用例(一):提取接口信息并分析 的 5 个接口,共设计出 11 个测试用例。其中登录接口为单接口,一共设计了 7 个用例;其他的 4 个接口为多个接口,一共设计了 4 个用例。主测试用例的内容及结构如图1、图2所示。


5783138238d186149afe8c543564cb7b.png

 图1 主测试用例的内容及结构(1)


b659687be26dd14c9736cf3d13839318.png

图2 主测试用例的内容及结构(2)


用例分析如下。

  • 第 1 个测试用例为登录接口的测试用例,使用了错误的密码进行登录,登录过程无须携带 cookies,所以 cookies 字段设置为空,登录失败后,预期的业务状态码为 1。如果服务端响应的业务状态码不为 1,则代表此测试用例执行没有通过。
  • 第 2个测试用例为登录接口的测试用例,请求主体信息中不携带密码这个参数,登录过程无须携带 cookies,所以 cookies 字段设置为空,预期的业务状态码为 1。如果服务端响应的业务状态码不为 1,则表明此测试用例执行没有通过。
  • 第 3个测试用例为登录接口的测试用例,请求主体信息中使用了错误的用户名,登录过程无须携带 cookies,所以 cookies 字段设置为空,预期的业务状态码为 1。如果服务端响应的业务状态码不为 1,则表明此测试用例执行没有通过。
  • 第 4个测试用例为登录接口的测试用例,请求主体信息中用户名参数使用非字符串类型的数据,登录过程无须携带 cookies,所以 cookies 字段设置为空,预期的业务状态码为 1。如果服务端响应的业务状态码不为 1,则表明此测试用例执行没有通过。
  • 第 5个测试用例为登录接口的测试用例,请求主体信息中不携带用户名参数,登录过程无须携带 cookies,所以 cookies 字段设置为空,预期的业务状态码为 1。如果服务端响应的业务状态码不为 1,则表明此测试用例执行没有通过。
  • 第 6个测试用例为登录接口的测试用例,请求主体信息中用户名为空字符串,登录过程无须携带 cookies,所以 cookies 字段设置为空,预期的业务状态码为 1。如果服务端响应的业务状态码不为 1,则表明此测试用例执行没有通过。
  • 第 7个测试用例为登录接口的测试用例,请求主体信息中使用了正确的用户和密码进行登录,登录过程无须携带 cookies,所以 cookies 字段设置为空,登录成功之后服务端响应的预期的业务状态码为 0。如果服务端响应的业务状态码不为 0,则表明此测试用例执行没有通过。另外, 用户登录成功之后,会在服务端产生 cookies 信息。在 relation 字段中设置了 token=cookiess.admin-token,它代表的含义是取得 cookies 信息中的 admin-token 字段的值,并把这个值赋给变量 token,以便下游接口引用 token 变量而得到 cookies 的秘钥。
  • 第 8个测试用例为发布文章接口的测试用例,在 cookies 字段中设置了{"admin-token" : "${token}"},这说明发布文章过程中需要携带 cookies信息,且 cookies 信息中键为“admin-token”,其值引用了登录接口中所设置的 token 这个变量。从 request_body 字段的信息中可以看到发布文章的标题(title 为标题参数)为“付出”,文章别名(alias 为别名参数)为“付出”。在文章发布成功后,将会产生文章的 id 号和文章的 alias (文章别名),所以又在 relation 字段中设置了 id_name=body.id,alias_ name=body.alias,它代表的含义是取到响应正文中的 id 号,并把它赋给变量 id_name;同时取到响应正文中的 alias(文章别名),并把它赋给变量 alias_name,以便下游接口可以引用这两个变量。最后,当文章发布成功之后,服务端响应的预期业务状态码为 0。如果服务端响应的业务状态码不为 0,则表明此测试用例执行没有通过。
  • 第 9个测试用例为修改文章接口的测试用例,在 cookies 字段中设置了{"admin-token" : "${token}"},这说明修改文章过程中需要携带 cookies 信息,且 cookies 信息中键为“admin-token”,其值引用了登录接口测试用例中所设置的 token 这个变量。从 request_body 字段的信息中可以看到,文章的 id 号引用的是发布文章接口测试用例中设置的 id_name 这个变量的值,文章的 alias 引用的是发布文章接口测试用例设置的 alias_ name 这个变量,也就是说要修改的文章是 id 为 id_name 的文章,并且在修改过程中把文章的标题修改成了“付出才能杰出”。最后,在文章修改成功之后,服务端响应的预期业务状态码为 0。如果服务端响应的业务状态码不为 0,则表明此测试用例执行没有通过。
  • 第 10 个测试用例为删除文章接口的测试用例,在 cookies 字段中设置了{"admin-token" : "${token}"},这说明文章过程中需要携带 cookies 信息,且 cookies 信息中键为“admin-token”,其值引用了登录接口测试用例中所设置的 token 这个变量。从 request_body 字段的信息中可以看到,要删除的文章的 id 号引用的是发布文章接口测试用例中设置的 id_name这个变量的值,这说明要删除的文章是 id 为 id_name 的文章。最后,在文章删除成功之后,服务端响应的预期业务状态码为 0。如果服务端响应的业务状态码不为 0,则表明此测试用例执行没有通过。
  • 第 11 个测试用例为查询文章接口的测试用例,在 cookies 字段中设置了{"admin-token" : "${token}"},这说明查询文章过程中需要携带 cookies 信息,且 cookies 信息中键为“admin-token”,其值引用了登录接口测试用例中所设置的 token 这个变量。因为此接口的请求方式为 GET 请求,所以 request_body 字段中信息为空,请求的参数直接放在 url 中。最后,由于文章已删除,查询的结果为空才是正常的,服务端响应的预期业务状态码应该为 0。如果服务端响应的业务状态码不为 0,则表明此测试用例执行没有通过。


5、设计配置信息的内容


本框架中所涉及的配置信息是被测环境服务器的 IP 地址,在配置信息中设置服务端的 IP 地址,其原因在于可以将服务器的 IP 地址从接口地址中分离出来,主要是因为一旦服务器的 IP 地址要改变,只需要在配置信息的字段进行更改便可,而不需要到每个接口用例当中对 url 中的 IP 地址进行一一更改,以实现公共数据的分离。在实际项目中具体需要在配置信息的字段中设置哪些内容,可根据项目需求灵活设置。ZrLog 系统配置信息字段的内容如图3所示。

image.png

图3 配置信息字段的内容


6、执行结果记录的内容


执行结果记录字段的内容是由程序运行之后自动填充,无须手工填写。


下一篇文章将分享如何建立数据库实例和主测试用例表,敬请期待!


目录
相关文章
|
5月前
|
设计模式 前端开发 测试技术
告别脆弱:构建稳定UI自动化测试的3个核心策略
告别脆弱:构建稳定UI自动化测试的3个核心策略
541 113
|
6月前
|
存储 关系型数据库 测试技术
玩转n8n测试自动化:核心节点详解与测试实战指南
n8n中节点是自动化测试的核心,涵盖触发器、数据操作、逻辑控制和工具节点。通过组合节点,测试工程师可构建高效、智能的测试流程,提升测试自动化能力。
|
8月前
|
XML jenkins 机器人
JMeter+Ant+Jenkins实现接口自动化测试持续集成
本文介绍了如何使用Ant生成JMeter接口测试报告,并集成到Jenkins中实现自动化测试。内容涵盖Ant与JMeter环境配置、build.xml文件设置、测试执行及报告生成,同时包括Jenkins插件安装、项目配置和钉钉消息通知的集成,帮助实现持续测试与结果可视化。
991 0
|
6月前
|
机器学习/深度学习 人工智能 测试技术
EdgeMark:嵌入式人工智能工具的自动化与基准测试系统——论文阅读
EdgeMark是一个面向嵌入式AI的自动化部署与基准测试系统,支持TensorFlow Lite Micro、Edge Impulse等主流工具,通过模块化架构实现模型生成、优化、转换与部署全流程自动化,并提供跨平台性能对比,助力开发者在资源受限设备上高效选择与部署AI模型。
540 9
EdgeMark:嵌入式人工智能工具的自动化与基准测试系统——论文阅读
|
6月前
|
自然语言处理 前端开发 测试技术
使用 Playwright MCP 实现 UI 自动化测试
本文介绍如何结合Playwright与MCP协议实现智能化UI自动化测试。通过自然语言指令控制浏览器,降低技术门槛,提升效率,并涵盖环境搭建、核心功能、实战案例及最佳实践,展现对话式自动化的未来趋势。
|
8月前
|
人工智能 前端开发 测试技术
如何让AI帮你做前端自动化测试?我们这样落地了
本文介绍了一个基于AI的UI自动化测试框架在专有云质量保障中的工程化实践。
3108 22
如何让AI帮你做前端自动化测试?我们这样落地了
|
8月前
|
Web App开发 开发框架 .NET
Playwright 自动化测试系列(6)| 第三阶段:测试框架集成​指南:参数化测试 + 多浏览器并行执行
Pytest 与 Playwright 集成可提升自动化测试效率,支持参数化测试、多浏览器并行执行及统一报告生成。通过数据驱动、Fixture 管理和并行优化,显著增强测试覆盖率与执行速度,适用于复杂 Web 应用测试场景。
|
7月前
|
人工智能 IDE 测试技术
Browser-Use在UI自动化测试中的应用
Browser-Use是一款浏览器自动化工具,具备视觉与HTML解析、多标签管理、操作记录与复现、自定义操作、自我纠正及并行执行等功能,助力AI智能体高效完成网页任务。
758 0
|
8月前
|
测试技术 API C++
Playwright 自动化测试系列(7)| 第三阶段:测试框架集成​​Page Object 模式
本课程详解Playwright测试框架中的Page Object模式,通过电商登录-下单实战演示PO架构设计与高级技巧,结合Pytest实现多用户测试。重点解析PO模式提升代码复用性、降低维护成本的核心价值,并提供常见问题解决方案,助力构建高可维护性的自动化测试体系。

热门文章

最新文章