那些让你目瞪口呆的 bug

之前看到过一个有趣的故事,来自知乎的「清夜」同学。

对接后台的一个接口,返回的数据中有一段类似于这种北京丨海淀,然后我只想要“北京”这个词,于是前端 JS 随手写下北京丨海淀'.split('|')[0],结果没取到。

当时愣了下,不过没在意,换另外一个方法继续试,还是不行。

这个时候就有点懵逼了,于是再换方法继续试,把所有的方法试了一遍全都不行,这个时候就有点慌了,局面好像有点控制不住了。

把所有的原因都考虑了一遍,甚至换了浏览器和电脑,试了很长时间都不行最后终于将目光放到了“丨”这个字符上,复制粘贴然后打印其 unicode 编码发现这个东西根本不是英文编码状态下的竖线|,而是一个拼音为 gǔn 的汉字。

当然实际工作场景遇到的问题千奇百怪,回过头来我们看看这个问题到底出在哪?其实还是信息不同步,造成返工。

在实际的项目开发中,会时常听到前端对后端的吐槽,我相信大抵是因为接口问题。

无接口文档

  1. “代码都写注释了,文档就没必要了吧,直接 Git 拉一下就好了。”

  2. “接口使用方法 QQ 发你了。”

  3. “我离职了,各位好好加油。”

后端增删改 API 没同步消息

改了 API 的一些输出格式,没知会前端,可想而知前端会多么崩溃。

前端内心 OS:“我太难了。”

如果后端开发一开始进行自测、测试再进行再测,定位问题来解决,想必到了前端这就无需再返工了。也不排除一些团队比较小,没有测试,还是得开发自己上。

当你打开搜索引擎,检索「后端接口」,联想搜索第一个词就是「后端接口测试」。要知道,联想词排名越高,说明检索的人越多,可见多少人都在这犯了难。

回归核心还是如何减少开发的返工工作量。毕竟开发的时间价值也很宝贵,这时候学习接口测试就显得很重要。但是开发是天生的效率狂,能不能把接口测试也自动化了呢?

完全可以!同时,自动化测试还有以下的优点:

  • 速度: 测试执行的速度远远快于人类用户。

  • 可靠性: 准确地执行测试,消除人为错误。

  • 可重复: 可以测试在重复相同的操作后 AUT 的反应。

  • 广泛性: 可以建立一系列测试来覆盖 AUT 的每一项功能,测试覆盖率高。

  • 可重用: 可以重复使用已有的测试,即使 AUT 的版本不同或用户界面发生了变化。

  • 高效率: 允许测试人员专注于验证新的 feature,而不是已有的功能。

那么如何学习接口自动化测试?

我想这个《接口自动化测试实战》专栏能很好地帮到你,从此节省回归测试时间,做到真正的持续集成、持续上线。

案例上手,多动图解析练习操作

每篇文章都有大量编程练习,让你真正具备独立搭建接口自动化测试脚本的能力。

由易到难、提供练习代码 Repo

从一键初始化项目 BaseCode 提交到 Github 开始,逐步推进,由易到难,让基础薄弱的小伙伴也能完全掌握。提供练习代码 Repo,不会存在因为自己调试不过而无法继续的情况。

搭建真实的 Web 项目进行实战练习

搭建真实的 Web 应用,从用例分析开始到搭建完善的接口自动化测试脚本。脚本可在多环境中切换运行并能集成到 jenkins 上随时执行。学完本专栏后,可独立上手自己所负责项目的接口自动化测试搭建。

Postman 可以完成接口测试,为什么还要学习专栏?

可能有些小伙伴会有疑问:花半天时间学习一下 Postman 或者 SoapUI 等工具就可以开始进行接口测试,为什么还需要对这部分内容进行深入学习。确实,如果你只需要调用少量接口,且只校验接口的 Response,那么使用 Postman 是可以的。但实际项目中的接口数量将远远大于 10 个,真正的难点在于如何保证复杂项目中的所有场景都能通过接口调用、进行充分覆盖且能在持续集成平台上稳定运行。

实际项目中实施接口自动化测试可能会遇到的难点

  • 接口改动频繁,每次改动都需要修改被影响的接口 Reqeust Body,维护成本大;

  • 测试数据被破坏导致接口测试失败;

  • Dev 环境运行 OK,切换了一套环境,大部分 Case 都跑不起来了。

本专栏除详细讲解所使用的编程语言和测试框架外,还会讲解如何解决上面这些难点,专栏会覆盖到的自动化实施策略如下:

  • 如何通过 Velocity 管理接口 Request Body,极大降低维护成本;

  • 如何管理测试数据,保证 Case 运行前能自动准备所需测试数据;

  • 如何管理配置信息,保证自动化用例多环境自动化切换。

除此之外,相比 Postman、SoapUI 这些工具,使用 REST Assured 完成接口自动化测试有如下优势:

  • 可以将测试脚本放到代码管理仓库统一管理,作为项目资产;

  • 可以对测试场景进行覆盖,而不是单独的某个接口,因为仅仅校验某个接口是否能调用成功并不能充分说明系统所涉及的业务场景正确;

  • 通过编写脚本完成自动化可以实现一切想实现的点,例如校验接口的 Shema、接口返回的数据和数据库数据是否相等、数据的初始化等。这是相比配置型接口测试工具 Postman、SoapUI 最大的灵活之处。

你能学到什么?

项目收益

  • 项目搭建了高覆盖率的接口自动化测试,可以缩短项目质量反馈时间,节省回归测试时间,做到真正的持续集成、持续上线。

  • 专栏中采用的 BDD 框架可以让项目的任何角色轻易读懂 case 的测试场景,测试场景背后是一个个实际功能点,优秀的接口自动化测试还可以作为项目的活文档。

个人收益

  • 对测试人员:提升技术壁垒,让只会手动测试的测试人员不易超越。

  • 对开发人员:掌握如何搭建接口自动化测试以及如何对各种测试场景进行取舍,有助于提高开发人员的测试 sence 和技术广度

专栏大纲

 

作者简介

现在订阅专栏,还能与作者互动,加入专栏读者专享的学习交流群。

点击阅读原文,试读更多免费章节

猜你喜欢

转载自blog.csdn.net/GitChat/article/details/103305812
bug