51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4600|回复: 0
打印 上一主题 下一主题

[转贴] 全网最详细的接口测试实战案例!小白必看!(下)

[复制链接]
  • TA的每日心情
    无聊
    昨天 09:34
  • 签到天数: 1052 天

    连续签到: 2 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2021-6-9 09:49:03 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    第四步:前端接口测试&Mock数据(接口层面的测试
      前面的步骤只是利用测试工具去发起网络请求,来模拟接口调用。
      但在真实的场景下,搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。
      我们同样也需要关注前端调用过程是否是正常的。(需要等待前端开发完毕,才能介入测试)
      可以利用Charles来对前端发送的请求进行抓包:
      1.验证前端调用接口的传参是否正确;
      2.验证后端的接口响应是否符合预期;
      3.前端拿到数据之后,交互和UI展示是否正确。
      当有些数据有多种状态,并且数据比较难以构造时,我们可以通过Mock数据去进行测试。
      常见的Mock数据的方式有:
      1.用 Fiddler 或者 Charles 去篡改请求和响应。
      2.如果是PHP或者Python等动态语言,可以直接在后端代码里面去更改条件。
      3.数据库中去修改数据。
      4.用专业的Mock工具去构造数据,如:EasyMock、TestableMock、Mockjs等。
      比较快速的方式,当然是直接用Charles去模拟。

      如果说只是改少量的响应数据,比如说:改变一个标签下发的文案,看看前端的展示。这种情形就非常适合用 Charles 去模拟数据。
      但是 Charles 模拟也有一个弊病,那就是假如遇到接口下发的数据结构比较复杂,涉及到多个字段的变更,用 Charles 去 Mock 数据就比较麻烦。
      第五步:后端接口测试&业务逻辑覆盖(看日志、看代码)
      看日志
      业务测试过程中,我们需要时刻关注后端日志状态。
      有时候接口响应数据是正常的,但是后端日志可能正在报错。
      比如:
      搜索结果页返回空数组是常见现象,一般代表搜索关键词没有召回任何商品。
      但是臻叔有一次测试过程中,发现同一个关键词,在同样的条件下,有时召回0个商品,有时召回多个商品。
      一开始觉得很蹊跷,后来一查看后端日志,才发现召回商品的时候超时了。
      看代码
      推荐大家在做接口测试的时候,一定要去阅读开发的源码。
      阅读源码可以对业务逻辑实现了解更加深入。
      另外,有些条件,在手工测试中很难模拟出来,但是通过阅读源码,甚至单元测试,就能够轻松的模拟出来。
      阅读源码还有个好处就是,对开发起到一个约束作用,因为代码是公开的,如果从代码层面发现很多Bug的话,开发的面子也过不去。
      关于阅读源码,我们可以把代码拉到本地,用IDEA等工具去查看源码。
      如果代码量很大怎么办?
      告诉大家一个小诀窍:当开发提交代码之后,我们可以在Gitlab上看他的Commit记录,或者将他的开发分支和生产环境的分支做个diff,这样就能知道他改了哪些地方。

      此外,还有2个工具推荐:
      java覆盖率工具 jacoco,这里可以用来统计代码覆盖率。

      感兴趣可以参考:https://github.com/jacoco/jacoco
      代码静态扫描 sonar,主要是用来检测代码编写是否规范。

      感兴趣可以参考:http://www.sonar.org.cn/
      第六步:接口性能调优(Arthas)
      这里再给大家看一个真实工作中的案例:

      排查过程:
      (1)先在APP上尝试复现

      (2)抓包看接口返回响应时间,一次请求居然花费了3.69s

      (3)通过Arthas的trace逐步去排查接口响应慢的原因:
      进入Arthas命令行
      java -jar arthas-boot.jar

      trace 接口调用的方法
      trace 类名 方法名

      最后发现可能是调用价格标签的时候很慢。

      后来终于找到了原因:
      调用依赖的服务的某个方法在测试环境中已经不维护了,但是代码存在bug,还会继续调用,导致调用超时。
      经过优化后,搜索网关响应速度从 3s 缩短到 300ms 左右。

      第七步:接口异常机制(Chaosblade)
      因为接口依赖的服务很多,经常需要调用其他接口。假如依赖的服务出现了异常,我们就需要考虑我们的接口是不是做了容错处理,或者是降级处理。
      可以用Chaosblade去注入异常。(非必须,但有更好)
      Chaosblade是阿里开源的混沌工程工具,感兴趣的可以去了解下:https://chaosblade.io/docs/
      第八步:接口版本控制&diffy
      一般接口都会区分版本,如果接口不是很规范,或者改了一些通用的逻辑,这个时候就需要对老版本进行一次回归测试。
      最笨的方法就是拿新老版本的两个app对比测试。我们也可以用diffy这个工具来做回归测试。
      diffy是推特开源的一款接口数据对比工具,这里是Github地址 :twitter-archive/diffy

      第九步:开始做接口自动化
      接口自动化一般常用于进行线上巡检回归、提测冒烟测试等场景。
      实现接口自动化,常见有几种方式:
      (1)coding:
      python+pytest+requests,臻叔公司目前采用这种方式去做。
      (小而美,方便定制化)

    pytest生成的测试报告

      (2)postman+newman
      (利用工具,效率最高,但是不太方便定制化)
      感兴趣可以参考:https://www.npmjs.com/package/ne ... n--run-eventemitter
      (3)流量录制与回放
      (低代码实现,但是实现成本颇高)

      常用的流量录制与回放工具:gor
      感兴趣可以参考:https://github.com/buger/goreplay
      好了,今天就写到这里。接口测试是测试的一个重要技能,希望能帮到大家。
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-28 03:35 , Processed in 0.066275 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表