🌈 赏金任务 - 在接口自动化测试过程中,如何开展接口自动化测试?单个模块和多个模块关联又怎么去做测试的呢?

赏金任务每周更新,请持续关注哦 :love_letter:

题目

  • 模拟面试场景,面试官提问以下问题,你如何回答。
  • 在接口自动化测试过程中,如何开展接口自动化测试?单个模块和多个模块关联又怎么去做测试的呢?

参与方式

  • 本帖下方回复你的答案即可

赏金

  • 100元京东购物卡

活动时间

  • 2023å¹´4月10日 - 2023å¹´4月16日

本周赏金任务汇总: 🌈 赏金任务发布 2023-04-10

本问题参与赏金活动,详情点击 :rainbow: 赏金活动上线啦 丨做赏金任务挑战千元奖金 查看活动介绍

在接口自动化测试过程中,一般需要以下步骤:

  1. 接口测试用例设计:根据接口的功能和需求,设计相应的测试用例,包括参数设置、请求方式、返回结果等。
  2. 接口测试数据准备:准备测试数据,包括正常数据和异常数据,以及边界条件数据等。
  3. 接口自动化测试脚本编写:使用自动化测试工具,如Postman、Jmeter等,编写接口自动化测试脚本。
  4. 接口自动化测试执行:执行接口自动化测试脚本,检查测试结果是否符合预期。
  5. 接口自动化测试报告生成:自动生成测试报告,包括测试结果、测试覆盖率、测试耗时等。
    对于单个模块的接口自动化测试,一般只需要测试该模块的接口即可。测试用例设计和自动化测试脚本编写的过程与上述步骤相同。

对于多个模块关联的接口自动化测试,需要考虑如何模拟多个模块之间的交互和协作。可以采用以下方法:

  1. 使用Mock数据:对于其他模块的数据和接口,可以使用Mock数据进行模拟。
  2. 使用集成测试:在模拟多个模块之间的交互时,可以采用集成测试的方式,将多个模块集成到一起进行测试。
  3. 使用自动化测试工具:可以使用自动化测试工具,如Selenium、Appium等,模拟多个模块之间的交互和协作。
    总之,对于接口自动化测试,需要根据实际情况进行测试用例设计、测试数据准备、自动化测试脚本编写、测试执行和测试报告生成等步骤,并针对多个模块关联的情况,采用不同的方法进行测试。

接口自动化测试开展过程

在进行接口自动化测试时应保证测试结果的准确性和可信度。在测试用例编写过程中建议进行代码规范和重构优化,使代码清晰简洁、容易维护和复用;同时建立合适的封装层次和测试框架机制,以便修改和扩展测试脚本。最后,还可以引入自动化测试报告来记录测试过程和结果的信息,方便这个技术或业务部门之间协调沟通,以优化产品质量和促进技术团队的提高。

接口自动化测试的开展过程如下:

1. 确定测试目标和测试范围:

确定被测接口,包括请求参数、期望结果等。根据需求文档或接口描述,了解接口所在的环境、调用方式、返回数据格式等信息。明确需要进行接口自动化测试的接口对象、测试目标和测试范围,包括接口的URL、请求参数、请求头、请求体等。

2. 设计测试用例:

根据测试目标和测试范围,设计测试用例,包括正常情况下的测试用例和异常情况下的测试用例。如:

  1. 功能覆盖率:针对接口的每一个功能点,设计至少一个测试用例以实现基本验证。

  2. 参数组合覆盖:针对参数的不同取值情况设计多组测试用例,例如以边界值、正常值和异常值为主要的分类。

  3. 业务场景覆盖:根据具体的业务需求和场景,设计并执行涵盖全部场景和各个模块的完整测试用例套件。

  4. 接口调用链验证:对于依赖其他接口的接口,需要使用先前已经通过稳定测试的结果进行验证,包括数据输入、输出等环节的检查。

  5. 并发性及负载测试:在设计测试用例时,需要考虑并发性和负载条件下系统的承受能力,设计并发及大规模操作的测试用例。

3. 编写测试脚本:

编写测试用例代码或测试脚本,包括发送请求并接收响应、对响应结果进行校验等。可以结合数据驱动或参数化来提高测试效率和覆盖率,与此同时保证覆盖全面性和可靠性。根据测试用例,使用测试框架和工具,如JUnit、TestNG、Postman、RestAssured等,编写测试脚本,对接口进行自动化测试。

4. 执行测试脚本:

启动被测接口的测试环境,确保被测及关联模块及其依赖库能正常运行,并运行测试用例集。尤其是测试时要保证数据的准确性和稳定性,一般情况下可以使用虚拟化环境进行隔离测试,以减少环境变化和问题发现时间。执行测试脚本,对接口进行自动化测试,记录测试结果和日志。

5. 分析测试结果:

在测试执行完成后,查看测试结果和日志分析故障原因。测试结果和日志分析能提供足够的线索定位问题原因,同时使用编程调试工具进行调试和分析代码。分析测试结果和日志,查找接口中的问题和缺陷,并及时反馈给开发人员。

6. 定期维护测试脚本:

编写时要保证代码的质量和可维护性,避免无节制拷贝粘贴代码造成代码冗余和混乱。应尽可能减少重复代码,并且使用代码规范指导等各种方式来保证代码品质。根据接口的变化和需求的变化,定期维护测试脚本,确保测试用例的准确性和完整性。如:

  1. 配置文件:使用配置文件来存储测试数据、环境变量和测试参数等信息。通过统一的配置文件可以更方便地管理测试所需的各种参数,并且能减少在代码中硬编码的情况降低测试脚本的成本。

  2. 模块封装:将相似的测试步骤和逻辑封装到一个模块里面,这样便于维护和灵活修改。对于一些公共的操作步骤和检查点,可以将其封装成独立的函数或类,在测试脚本中进行调用。

  3. 常规更新:根据业务需求和接口变更及时修正接口测试脚本。在开发迭代、新增接口或者接口变更时,需要关注测试用例是否需要跟新。及时地更新测试用例,保证测试用例的正确性。

  4. 定期回归:制定一个合适的回归测试计划,定期执行测试脚本并核查测试结果。在项目周期内,定期地进行回归测试,并且保证测试用例可用和有效。

  5. 自动化脚本维护:保留和记录测试用例脚本的历史版本,以备不时之需。同时对脚本升级、重构或者大规模修改增加注释和文档说明,方便后期回溯和理解调整。

单个模块如何进行测试

在进行单个模块接口自动化测试时,需要结合被测模块的实际情况,包括模块所处的环境、数据的完整性和正确性、接口返回的状态码和错误信息等。同时,还需要做好测试数据和测试环境的管理,确保测试的稳定性和可重复性。

进行单个模块接口自动化测试的一般步骤如下:

  1. 确定被测模块中需要进行接口自动化测试的所有接口,包括请求参数、期望结果等。

  2. 根据被测模块所在的技术栈和应用场景,选择适合自己的自动化测试框架,比如pytest、unittest、JMeter等,并安装好相应的依赖。

  3. 编写测试用例代码,包括发送请求并接收响应、对响应结果进行校验等。根据模块的复杂度和接口数量,可以考虑使用数据驱动或参数化来提高测试效率和覆盖率。

  4. 启动被测模块的测试环境,并运行测试用例。在测试过程中,可以使用日志或调试工具对程序进行跟踪和监控,发现问题并及时解决。

  5. 针对测试中发现的问题进行修复,并重新运行测试用例以确认问题已经得到解决。

多个模块如何进行测试

在进行单个模块和多个关联模块接口自动化测试时,需要统一规范接口设计以及输入输出格式,保证不同模块之间数据交互的正确性和可靠性。同时,还需要建立合适的封装层次和测试框架机制,尽可能使测试用例的编写、维护和执行变得更加自动化和方便。可以使用代码版本控制工具如Git等,进行测试脚本的版本管理和分享,方便团队的协作测试和持续集成部署。

进行单个模块和多个关联模块接口自动化测试的一般步骤如下:

  1. 确定被测模块中需要进行接口自动化测试的所有接口,包括请求参数、期望结果等。同时,根据被测模块与其他模块之间的依赖关系,确定需要测试的关联模块及其接口。

  2. 根据被测模块所在的技术栈和应用场景,选择适合自己的自动化测试框架,并安装好相应的依赖。通常情况下,对于关联模块的接口,可以将其封装成独立的函数或类,在测试脚本中进行调用。

  3. 编写测试用例代码,包括发送请求并接收响应、对响应结果进行校验等。对于涉及多个模块之间的数据交互或过程协作的测试用例,可以使用基于场景或业务流程的测试设计方法来保证测试覆盖能力和准确性。

  4. 启动被测模块的测试环境,并运行测试用例。在测试过程中,可以使用日志或调试工具对程序进行跟踪和监控,发现问题并及时解决。

  5. 测试结束后,可以根据接口上下游关系来判断是哪个模块出现的问题。可以使用日志或异常信息来定位问题发生的位置,进而进行修复和改进。

面试官,您好!
对于您的第一个问题我的回答是:
“开展接口自动化测试”,首先对业务要有相当程度的了解,这会对之后开展工作有一定的定向作用。我们要的最终结果是要服务于用户,给用户良好的体验。因此,首先要做的就是分析用户需求,通过一些调查或者其他的手段,我们明白了用户需求之后就可以开始编写自动化测试用例了,我们不可能做到穷尽测试用例,只能做到问题考虑周全之后尽量完善。俗话说,“三分手艺,七分家伙”,对于测试工具的选择尤为重要。包括编写脚本的语言、jemeter等测试工具和其他资源的利用。最后的测试结果是检验我们整个测试流程是否成功的重要参考,如果结果还相当符合预期,那么这项工作可以说完成的比较成功了。
对于您的第二个问题我的回答是:单个模块和多个模块关联的测试是集成测试的范畴,每个模块之间的情况可能不同,也可能相同。对于情况不同的,我们要根据实际情况去考虑问题,编写不同的测试用例,编写不同的测试脚本,逐个分析测试报告,而对于不同模块之间情况相似,就可以考虑脚本复用等问题,充分把握他们之间的共性,寻求最佳解决路径。

对于接口自动化如何开展?
首先,我们测试要与项目经理、产品以及开发开展会议,会议内容为:
1.要确定好哪些项目需要开展接口自动化(因为并不是所有的项目都适合自动化,也不是所有的项目自动化都能覆盖率很高。)
2.自动化覆盖率的要求,例如:这个项目,自动化是需要覆盖主要业务与分支流程流程,还是说只需要覆盖主要业务流程
然后,我们确定好自动化测试关于“测什么”的目标之后,我们接下来就需要关注的就是“怎么测”这个问题。关于怎么用自动化去测试,我们就需要考虑到以下几个问题:
1.自动化需要覆盖的接口出入参信息需要收集
2. 每个接口需要测试什么?
3.选择用什么工具进行自动化测试?
4.如何去断言每个接口的返回情况是否符合预期?
5.出错的接口怎么反馈给开发?
6.出现大规模接口报错的情况,如何及时通知对应人员?
对于上诉的问题,可以这么去处理:
1.跟开发沟通,通过swagger或apifox或其他接口文档,将收集到的接口根据业务分类,从而整理成一个excel或者金山文档的轻维表.
2.根据整理出来的接口文档,从功能性(接口功能是否正常,文档标记的必传或必返回的参数是否正常出现、健壮性(例如:边界值,字段最大长度)、安全性(平行越权)几方面去考虑自动化测试用例
3.可以选择目前常用的jmeter、pytest+request、unnitest、junit去实现自动化
4.像是jmeter的话,可以通过自带的断言工具去断言或者通过beanshell去编写断言脚本,而若是通过编程语言实现的自动化,初级的可以通过自带的assert方法去断言,比较建议的是通过编写jsonschema检测脚本去断言返回的入参是否符合预期
5.当我们自动化出错的接口通过断言发现错误后,可以通过将对应的问题,通过一定格式写入对应日志文件或yaml文件中。然后通过去请求禅道或jira这些项目管理平台开放的resfulAPI,将自动化发现的BUG自动上传至对应的管理平台
6.由于我用的是pytest,在pytest底层有个插件叫pytest_reporter_xx(测试报告结果收集),可以通过在conftest.py重写这个插件,获取此次测试的成功率,然后根据对应的成功率与自己设定的临界值做比较,如果低于这个临界值,那么就通过自己编写的邮件模块的代码,发送告警邮件通知测试与项目管理人员。

单个模块与多个模块关联怎么去测试?
这个问题,我理解是这样的,目前模块是通过微服务去实现,这个问题实际上是问多个微服务直接互相关联,这应该怎么去测试。
首先,我们就需要通过列出接口流程图,理清楚大致这几个微服务之前调用的顺序,上下游关系。
然后,在理清楚之后,我们可以先设计根据上下游关系顺序的测试用例,其次在设计跳过上游,只测试下游去检测模块之间是否做了关联关系状态的限制

1 Like

在接口自动化测试过程中,我们需要首先确定接口测试的目的和范围,然后进行测试计划的制定和测试用例的设计。

对于单个模块的测试,我们可以采用黑盒测试和白盒测试相结合的方式,通过对接口参数的输入和输出进行验证,以及对代码逻辑的覆盖测试,来保证接口的正确性和稳定性。

对于多个模块关联的测试,我们需要先确定模块之间的依赖关系和数据流程,然后进行接口测试的集成和回归测试,保证各个模块之间的数据传递和交互的正确性。

在测试过程中,我们可以使用自动化测试工具来提高测试效率和准确性,同时也需要注意测试数据的准备和管理,以及测试结果的分析和报告,及时发现和解决问题,确保接口测试的质量和效果。

(一)接口自动化如何开展?

0、调研、前提准备和思考
a)前提:
1、正式设计用例的时候,结合postman/jmeter这样的工具
2、去设计不同的测试数据,发起请求,查看响应结果与设计是否一致
3、(要走一遍手工测试的) – 发现的bug
b)用例的存储方式:
1、excel表格 - 配置json路径
2、json文件 - 请求参数比较多,写在json文件里
3、yaml文件 - httprunner3.0
4、数据库 - 创建表格
c) 自动化覆盖率怎么样
覆盖率:功能上/手工用例覆盖率 - 30% - 90%
1、你做这个项目的接口自动化多久了?
2、系统大不大?是否复杂?
3、覆盖率用例多少条?遇到什么困难(及解决方案)?

1、需求分析
了解项目的业务功能,bug较多的模块,比较稳定接口有哪些,核心功能有哪些

2、 了解接口
2.1 抓包看接口
2.2 通过接口文档了解

3、自动化框架、工具的选择
3.1 工作的可扩展性以及扩展语言 + 选几个复杂的接口试用
3.2 框架结构的比较
3.3 规范命名

4、写接口用例
4.1 写接口用例脚本

  • 1、核心业务的先走 - 用户使用率最高
  • 2、用例优先级 - 常用的功能场景/必填参数
  • 3、参数的格式有效性-后端没有做校验
  • 4、正常用例先设计、异常场景(全面)

4.2 尽早加入jenkins集成
4.3 定期汇报进度
4.4 测试报告,自动发送报告、分析用例失败原因
4.5 记录接口自动化开始到当前的bug
4.6 异常处理情况

5、持久化层构造
1、数据库直接插入数据

6、维护阶段
1、开发修改接口,测试同步修改接口脚本
2、新增接口,同步新增接口用例
3、脚本、日常框架优化
4、配置文件持续更新

(二)单个模块怎么去做测试的呢?

单模块测试:在测试工作中主要用于检查单个业务功能的接口实现,或者调试测试数据。

第一步:梳理上下游调用链

1)为什么要梳理上下游调用链?
目前互联网产品的后端服务,基本上都是分布式部署 的,一个接口可能会调用其他接口,也有可能被其他接口调用,接口与接口之间,具有千丝万缕的依赖关系。
如果只是单独的调调参数,就希望把接口测试做好,显然是不可能的。(开发自己都能调(tiao)接口参数,还要测试做什么?)
2)怎么梳理上下游调用链?
1、看项目wiki、产品文档和开发文档
2、看开发写的代码,阅读代码
3、梳理出上下游调用关系,手绘一份系统流程图,如果还有不明确的地方,可以找PM、开发沟通确认

第二步:编写接口测试用例

如果说要做接口自动化,接口测试用例也是很有帮助的。
这里给出一个接口测试用例的案例:

第三步:测试接口文档&调试接口

在项目开发之初,前端开发和后端开发会共同去约定一套接口规范,然后由后端开发去编写接口文档,然后前后端就可以按照约定去进行协同开发。
接口文档的管理和编辑有多种方式:

  • 有的团队习惯用wiki或者在线文档去编写接口文档;
  • 有的团队喜欢用专业的接口文档工具,比如:Swagger、Yapi等去生成接口文档。

测试接口文档可以参考以下测试点:

  1. 确保开发必须提供接口文档。如果开发没有写接口文档的习惯,应push开发去写接口文档。
  2. 检查接口文档的格式内容等是否完备,包括:URL、请求方法、Header、入参、返回值、示例Demo等。
  3. 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。

当后端开发完成接口的开发工作时,我们就可以提前开始对接口进行初步测试了。
步骤如下:

  1. 把后端代码部署到测试环境上。
  2. 通过postman或swagger去对接口文档提到的接口进行测试。

第四步:前端接口测试&Mock数据(接口层面的测试)

前面的步骤只是利用测试工具去发起网络请求,来模拟接口调用。

但在真实的场景下,搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。

我们同样也需要关注前端调用过程是否是正常的。(需要等待前端开发完毕,才能介入测试)

可以利用Charles来对前端发送的请求进行抓包,

  1. 验证前端调用接口的传参是否正确;
  2. 验证后端的接口响应是否符合预期;
  3. 前端拿到数据之后,交互和UI展示是否正确。

当有些数据有多种状态,并且数据比较难以构造时,我们可以通过Mock数据去进行测试。

常见的Mock数据的方式有:

  1. 用 Fiddler 或者 Charles 去篡改请求和响应。
  2. 如果是PHP或者Python等动态语言,可以直接在后端代码里面去更改条件。
  3. 数据库中去修改数据。
  4. 用专业的Mock工具去构造数据,如:EasyMock、TestableMock、Mockjs等。

比较快速的方式,当然是直接用Charles去模拟。

第五步:后端接口测试&业务逻辑覆盖(看日志、看代码)

看日志

业务测试过程中,我们需要时刻关注后端日志状态。
有时候接口响应数据是正常的,但是后端日志可能正在报错,

看代码

推荐大家在做接口测试的时候,一定要去阅读开发的源码。
阅读源码可以对业务逻辑实现了解更加深入。

如果代码量很大怎么办?

告诉大家一个小诀窍:当开发提交代码之后,我们可以在Gitlab上看他的Commit记录,或者将他的开发分支和生产环境的分支做个diff,这样就能知道他改了哪些地方。

第六步:接口性能调优(Arthas)

排查过程 :
(1)先在APP上尝试复现
(2)通过Arthas的trace逐步去排查接口响应慢的原因:
进入Arthas命令行

java -jar arthas-boot.jar

trace 接口调用的方法

trace 类名 方法名 

第七步:接口版本控制&diffy

一般接口都会区分版本,如果接口不是很规范,或者改了一些通用的逻辑,这个时候就需要对老版本进行一次回归测试。

最笨的方法就是拿新老版本的两个app对比测试。我们也可以用diffy这个工具来做回归测试。

第八步:开始做接口自动化

接口自动化一般常用于进行线上巡检回归、提测冒烟测试等场景。

实现接口自动化,采用一下方式:

coding:

python+pytest+requests,目前采用这种方式去做。(小而美,方便定制化)

(三)多个模块关联怎么去做测试的呢?

模块关联:是指将两个及以上相关API的出入参以参数化的形式达成动态关联,以实现整个事务的测试覆盖,达到基础的工具接口自动化测试。

第一步:梳理上下游调用链

1)为什么要梳理上下游调用链?
目前互联网产品的后端服务,基本上都是分布式部署 的,一个接口可能会调用其他接口,也有可能被其他接口调用,接口与接口之间,具有千丝万缕的依赖关系。
如果只是单独的调调参数,就希望把接口测试做好,显然是不可能的。(开发自己都能调(tiao)接口参数,还要测试做什么?)
2)怎么梳理上下游调用链?
1、看项目wiki、产品文档和开发文档
2、看开发写的代码,阅读代码
3、梳理出上下游调用关系,手绘一份系统流程图,如果还有不明确的地方,可以找PM、开发沟通确认

第二步:编写接口测试用例

如果说要做接口自动化,接口测试用例也是很有帮助的。
这里给出一个接口测试用例的案例:

第三步:测试接口文档&调试接口

在项目开发之初,前端开发和后端开发会共同去约定一套接口规范,然后由后端开发去编写接口文档,然后前后端就可以按照约定去进行协同开发。
接口文档的管理和编辑有多种方式:

  • 有的团队习惯用wiki或者在线文档去编写接口文档;
  • 有的团队喜欢用专业的接口文档工具,比如:Swagger、Yapi等去生成接口文档。

测试接口文档可以参考以下测试点:

  1. 确保开发必须提供接口文档。如果开发没有写接口文档的习惯,应push开发去写接口文档。
  2. 检查接口文档的格式内容等是否完备,包括:URL、请求方法、Header、入参、返回值、示例Demo等。
  3. 检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。

当后端开发完成接口的开发工作时,我们就可以提前开始对接口进行初步测试了。
步骤如下:

  1. 把后端代码部署到测试环境上。
  2. 通过postman或swagger去对接口文档提到的接口进行测试。

第四步:接口场景化设计

背景:现有平台对单服务单接口自动化测试流程相对成熟,而对于复杂的跨服务的自动化用例配置的需求反馈日益增多,所以,增加对于复杂测试场景的支持

什么样的用例适合场景化
也可称为业务流,例如:举个电商类case,下单购买-支付-验证支付状态-查看权限-退款-验证退款状态

  1. 无论是否跨应用,步骤有前后有强依赖关系
  2. 核心兜底业务场景,比如,下单-支付-履约-退款

基于以上背景,此次项目对应的功能点如下:

  • 增加【场景集】概念,等同于原有的【项目】
  • 增加【测试场景】概念,与原有的【用例集】类似
  • 触发关联的测试场景

第五步:前端接口测试&Mock数据(接口层面的测试)

前面的步骤只是利用测试工具去发起网络请求,来模拟接口调用。

但在真实的场景下,搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。

我们同样也需要关注前端调用过程是否是正常的。(需要等待前端开发完毕,才能介入测试)

可以利用Charles来对前端发送的请求进行抓包,

  1. 验证前端调用接口的传参是否正确;
  2. 验证后端的接口响应是否符合预期;
  3. 前端拿到数据之后,交互和UI展示是否正确。

当有些数据有多种状态,并且数据比较难以构造时,我们可以通过Mock数据去进行测试。

常见的Mock数据的方式有:

  1. 用 Fiddler 或者 Charles 去篡改请求和响应。
  2. 如果是PHP或者Python等动态语言,可以直接在后端代码里面去更改条件。
  3. 数据库中去修改数据。
  4. 用专业的Mock工具去构造数据,如:EasyMock、TestableMock、Mockjs等。

比较快速的方式,当然是直接用Charles去模拟。

第六步:后端接口测试&业务逻辑覆盖(看日志、看代码)

看日志

业务测试过程中,我们需要时刻关注后端日志状态。
有时候接口响应数据是正常的,但是后端日志可能正在报错,

看代码

推荐大家在做接口测试的时候,一定要去阅读开发的源码。
阅读源码可以对业务逻辑实现了解更加深入。

如果代码量很大怎么办?

告诉大家一个小诀窍:当开发提交代码之后,我们可以在Gitlab上看他的Commit记录,或者将他的开发分支和生产环境的分支做个diff,这样就能知道他改了哪些地方。

第七步:接口性能调优(Arthas)

排查过程 :
(1)先在APP上尝试复现
(2)通过Arthas的trace逐步去排查接口响应慢的原因:
进入Arthas命令行

java -jar arthas-boot.jar

trace 接口调用的方法

trace 类名 方法名 

第八步:接口异常机制(Chaosblade)

因为接口依赖的服务很多,经常需要调用其他接口。假如依赖的服务出现了异常,我们就需要考虑我们的接口是不是做了容错处理,或者是降级处理。

可以用Chaosblade去注入异常。(非必须,但有更好)

第九步:接口版本控制&diffy

一般接口都会区分版本,如果接口不是很规范,或者改了一些通用的逻辑,这个时候就需要对老版本进行一次回归测试。

最笨的方法就是拿新老版本的两个app对比测试。我们也可以用diffy这个工具来做回归测试。

第十步:开始做接口自动化

接口自动化一般常用于进行线上巡检回归、提测冒烟测试等场景。

实现接口自动化,采用一下方式:

coding:

python+pytest+requests,目前采用这种方式去做。(小而美,方便定制化)

接口自动化测试是通过编写自动化脚本来模拟用户的操作,调用接口进行测试的过程。在实际的测试中,我们通常需要遵循以下步骤来开展接口自动化测试:

  1. 确定接口测试的范围和目标:首先需要明确需要测试的接口的范围和测试的目标,以及测试期望达到的结果。
  2. 设计测试用例:将接口测试用例设计好,包括测试输入、预期输出以及需要验证的操作流程等。测试用例要尽可能地覆盖所有可能的情况,以保证测试的全面性和准确性。
  3. 编写自动化测试脚本:在确定了测试用例之后,需要编写自动化测试脚本来实现测试用例中的操作流程,包括调用接口、验证返回结果等。
  4. 执行测试用例:执行编写好的自动化测试脚本,并记录测试结果。在测试过程中,需要注意记录测试日志,以便后续分析和排查问题。
  5. 分析测试结果:对测试结果进行分析,包括验证返回结果是否符合预期、是否出现了异常情况等。

当测试多个模块关联的接口时,需要考虑接口之间的依赖关系和顺序。通常采用的方法是先测试单个模块的接口,然后逐渐将多个模块的接口进行组合测试,以验证整个系统的功能和性能是否符合预期。在测试过程中,需要注意记录测试日志和错误信息,以便后续分析和排查问题。

在接口自动化测试过程中,可以按以下步骤进行:

  1. 确定测试范围:定义待测接口和相关的功能点。
  2. 设计测试用例:根据接口设计规范,确定需要测试哪些参数及其取值范围,并编写测试用例。
  3. 编写测试脚本:使用合适的自动化测试工具和编程语言编写测试脚本,执行测试用例并生成测试报告。
  4. 定期维护测试脚本:随着项目的变化,需要对测试脚本进行修改和更新。

对于单个模块,测试脚本可以直接针对该模块的接口进行编写和执行。

而对于多个模块关联的情况,可以先分别针对每个模块进行接口测试,确保每个模块都能够正确地返回数据。然后再进行模块间关联的测试,即使用一个模块的输出作为另一个模块的输入进行测试,验证系统整体的功能和性能。这些测试可以通过集成测试或者端到端测试来实现。在实现过程中,可以使用脚本调用其他模块的接口,模拟真实的跨模块场景并执行测试用例,以便及时发现和解决相关问题。