传统API管理的“矛”与测试过程之间的“盾”

2022-09-26  微不足道 

说起接口测试,我想测试同学们并不感觉陌生。作为一名测试工程师,尤其是做了多年业务测试的测试工程师,在开始接触接口测试时,无论开发工程师是否提供了接口文档,我相信你都会对下面几种场景似曾相识:

➢ 开发人员提交测试的项目,附带着一个几十页的 Word 文档,里面是一行一行的访问地址和路由,面对这样的 Word 文档,不知道如何开始验证;
➢ 开发人员在即时通讯工具上,甩给你有好几页的这么一个传输消息,里面有各种嵌套的参数,你不知道这些参数都是干什么用的;
➢ 开发人员口头告诉你需要测试的接口地址,然后就什么都没再多说,你问了他几句话后,他就借口说自己忙,不再理你,而你看到那个又长、又复杂的地址,束手无策。

难道,面对这些状况,测试同学们就没办法自己分析接口,完成测试吗?

我现在告诉你,当然不是。

接下来,我就带你一起看看,一个理想的提测项目是什么样的,在实际工作中,绝大部分的提测项目又是什么样的,然后我们一起看看,如何一步一步解决一个不理想的提测项目。

一、关于一个理想的提测项目

一个理想的提测项目,在提测的过程中应该既包含前期参与的产品需求、原型设计,这些是由产品经理来提供的;也包含后端接口文档、代码单元测试脚本,这些是由开发工程师来提供的。这些都是你开展测试的必要输入内容,它们具体有这些作用:

➢ 产品需求
描述了系统的业务逻辑,通过这个文档,你才能知道怎么来设计测试用例;
➢ 原型设计
会更加直观地告诉你系统的使用逻辑,这对测试用例的设计、对系统的前期认知都是有辅助作用的;
➢ 接口文档
详细地描述了后端接口的访问方式和参数说明,使用这个输入项才能开展接口测试用例的设计、测试脚本的准备和测试数据的构建;
➢ 单元测试脚本
它是保障提测质量的必要环节,是研发工程师自测的一个有效手段,可以保障提测项目的提测质量;

这些内容不局限于 SUT(System Under Test,被测系统)的类型,SUT 既可以是一个手机 App,也可以是一个 Web 服务,甚至还可以是一个微服务接口。

所以,对于接口测试阶段来说,一个非常理想的接口测试,就是从完美的接口文档开始的。开发工程师在设计和开发接口的过程中,就在不断维护和更新接口文档,这其中包含了每一开发工程师提交测试的项目,附带着一个几十页的 Word 文档,里面是一行一行的访问个接口的访问方式、访问路由、输入参数含义、返回参数含义,以及一个完整的例子。

这种接口文档可能是以 Word 文档形式存在,也有可能是以Eolink 这种规范文档工具形式存在。说到 Eolink,这只是我使用过的一个接口文档的存在形式,是一个从代码生成的、以 Web 服务形式存在的接口文档,它可以伴随代码的变更同步变化,这就减少了很多开发工程师和测试工程师之间的沟通成本。

这样,当你拿到接口文档时,就可以快速使用各种工具或者代码来完成你的单个接口测试任务了。与此同时,你还可以通过一些参数设计、参数上下文传递,来完成接口的流程测试。

二、理想的情况很难发生

上面我说的是很理想的情况,但往往理想很丰满,现实很骨感,我相信你测试同学们肯定遇见过下面这些场景:

场景一:根据产品经理的一句话需求,开发工程师便开始任意发挥,“所见系统即需求”的情况普遍存在,这就更别说后续的单元测试和接口文档了;

场景二:开发工程师从来不写单元测试脚本,提测项目质量无法保障,接口文档更无从谈起,测试更是不知道如何开始完成接口测试;

场景三:就算拿到提测项目后,从部署测试环境到开始测试,一直都是摸索着前进,由于接口测试没有充分的输入条件,只能从 UI 层开始测试,结果导致交付质量大打折扣。

就像墨菲定律说的那样:可能发生的事情必将会发生。所以,上面我列举的接口测试难以推行的一些常见情况,都是日常在工作中会碰见的问题。

传统API文档管理繁琐:

  • API数量,协议,规范众多
  • 编写文档麻烦,协作效率下降
  • 项目维护成本增加

规范化API文档管理:
统一的API文档有助于减少项目维护和沟通成本,无论什么项目、什么人编写什么API,系统都可以保证API文档的可读性,方便后续维护和团队协作。有一款方便管理、查阅API文档,提高日常代码(CV)效率,如果有一款API文档管理工具可以大大提高工作效率和高质量交付工作。

传统API开发协作慢:
➢ 前端开发进度受制于后端:单纯API文档缺乏Mock API,前端需要等待后端开发完成才能拿到测试数据,自己构造测试数据费时费力。
➢ 反复沟通浪费时间:由于文档滞后于代码,而开发经常在开发最后才完善文档,导致前后端对接需要反复沟通确认。
➢ 缺少统一沟通平台:如果API出现了什么问题,只能在内部通讯工具交流,既没有存档,也不便于多人协作。
➢ 文档变更不通知:后端开发改了代码和接口习惯于口头沟通,而不是通过文档明确地指出修改的内容,导致后期沟通成本高昂。
➢ 文档阅读体验差:文档不标准、内容不清晰、平台不统一等问题导致最终文档效果也不好,体验越差越不维护,导致破窗效应。
➢ 接口测试不方便:需要看着接口文档再另外使用工具进行测试,如果接口发生了变化,写好的测试也作废了,增加了重复工作量。

管理缺乏工具,针对研发工作需要有深入参与研发的管理工具才行。
通过Eolink工具管理API帮助团队内部进行协作,共享劳动成果:
团队之间没有参与任何沟通协作的内容,缺乏API定义、测试、协作的主动权。

测试维护成本高:
➢ 测试工作重复:需要看着接口文档再另外使用工具进行测试,如果接口发生了变化,写好的测试也作废了,增加了重复工作。
➢ 工作成果无法分享:每个测试人员都用单机测试工具编写测试脚本,但却没法共享和协作。
➢ 测试工作不自动化:一直希望促进自动化测试,但是没有真正运作起来,每天“点点点”依然消耗大量测试团队的精力。
➢ 测试效果无法量化:无法准确了解测试效果,没人可以说清今天、昨天、上周、这个月的测试情况如何,和之前比有何改进。
➢ 测试工作被动:测试总是排在最后进行,无法参与项目讨论,无法进行快速大范围回归测试,甚至无法按时完成测试任务,导致项目延期或带着忐忑上线。

引入Eolink管理API测试:
将文档和测试关联起来有助于减少API测试和维护测试用例的时间,不再需要一边对照API文档,一边打开其他的工具来测试。提高测试人员的工作效率。所有API测试数据、用例、报告都在平台中统一管理,减少测试团队的重复工作,让团队成员可以共享工作成果。

使用Eolink工具可以整合测试数据,测试用例,丰富测试报告;缩减API测试和维护测试用例的时间,减少测试团队的重复工作,提高测试人员的工作效率,并让团队人员可以共享工作成果。

借助工具开展自动化测试
传统API自动化测试工具上手门槛高,对成员水平要求高,无法快速在团队推广API自动化测试经常受到测试人员编码水平等因素的影响,难以大范围和高效实施。Eolink提供的API自动化测试可以不编写代码,测试人员进行简单的培训后即可编写复杂的测试用例,通过自动化取代手工来进行重复的API测试。

Eolink工具可以帮助测试团队提高测试效率和测试覆盖率

目前面临的测试过程中,我们完全可以借助工具作为辅助并且可以提高完成接口分析的效率:

➢ 通过 Eolink 来完成接口信息;
➢ 通过分析接口的访问方式、参数等信息整理出一些问题,和研发工程师沟通这些问题,将一些不知道的参数含义、参数取值范围等问题问清楚;
➢ 通过 Eolink 接口信息进行编辑,测试,一键生成测试用例,mock测试数据,监控,等功能促进团队高效协作;

通过这三步的循环,你就可以完成一个对系统接口信息的完善和维护,最终得到一份完整的高质量的测试结果。

https://www.eolink.com/ 可以把整个过程流程化,规范化,可能只需要我们花费一部分的时间去了解和真正使用这个工具,就可以做到在工作中效率最大化,不妨测试和开发同学都来试一试这个工具,感受是否可以让工作变的更加的高效呢?

93°/930 人阅读/0 条评论 发表评论

登录 后发表评论