互帮互助 各位兄弟姐妹测试人儿,请教个问题,感觉最近陷入了一个误区,就是接口测试和功能测试是不是感觉必然冲突

陈辉 · 2021年02月05日 · 最后由 ata360 回复于 2021年02月22日 · 1889 次阅读

一些疑惑

只是单说接口测试,接口测试能帮功能组的同学节省工作量吗?是这样的,我们公司有个项目接口量比较大,有接口覆盖度要求,所以要从功能组的同学那边借资源一块编写,前期给他们培训,然后脚本编写,花了挺多资源的,但是结果好像并没有太大的产出,对于功能的同学而言,该执行的用例还是需要执行,并没有减少他们的工作量,反正增加了许多,那接口自动化的定位应该是什么?
看了一下大佬输出的文章 “如何度量测试开发的价值产出?”,还是不明白自己的疑惑点,希望各位不吝解惑一下,各位的公司,测开人员的定位都是啥样的?

共收到 20 条回复 时间 点赞

接口功能测试,包含功能

gocopper 回复

那前端的功能如何保证呢?我们公司前端问题其实比较多,不能保证功能没有问题了,这条用例就放弃

陈辉 回复

后端主逻辑,先保证逻辑没有问题

gocopper 回复

理是这个理,但是对于功能测试的同学,该有的工作量还是有的,并不能节省对应的工作量,所以我的定位是不是不应该这样定位

接口自动化主要是为了回归测试用的,顺带在测试过程中可以提前发现一些业务逻辑的问题。但是就发现 bug 数量来说,还是要功能测试的时候发现的比较多,这个时候可以反过来再去补充接口用例覆盖。
我是这样理解的。

个人理解,先接口测试后可以减少功能测试时后端大部分逻辑问题,提早的介入接口测试也能让后面功能走的很流畅些,对功能测试还是会时间周期会减少些

这个怎么说呢,我觉得这个取决于你们的产品是否真的做到了前后端分离。 如果你们测试的工作没有前后端分离, 接口测试依然是压在功能测试人员, 那我个人认为大面积铺开接口测试确实不值得。 都不如写主流程的 UI 自动化来的好。

前后端分离就是前端和后端各自有自己的迭代周期和提测时间, 各自分开的。 这时候的接口测试也是会加入到持续集成中来的,可以做到尽早的发现 bug。 而不是等前后端都联调完了, 交给前端测试人员的时候才跑的。 这样才会更有效果。

接口自动化测试不是为了发现问题,是为了验证已覆盖的场景是否 ok,发现 bug 只是额外的产出,要把接口自动化持续运行起来才会产生价值

首先接口测试就是功能测试。你想想对不对,涉及到性能吗?涉及到安全吗?功能测试分手工执行和自动执行。(当然,我不喜欢聊概念)
第二:接口覆盖率没有意义!!!应该关注的是代码覆盖率。(动态插桩,检测开发的代码,有哪些是被执行过的。不了解的,可以先去了解下这个)
功能测试,接口测试,UI 测试,最终都是想提高本次增量代码或全量代码的代码覆盖率。
只有开发写的所有代码,都被我们用例覆盖了,就几乎没有漏测的情况。
自动化,手工,只是执行的方式

其实你不用在意到底是怎么定位了,因为好多高位的人其实也不知道。只是说出来糊弄人而已

赞同楼上孙高飞的回答。分层测试也要建立在具体架构和研发流程上。。。不要盲目的做。
另外有些接口拆的过于细了,你可以做按功能来的接口集成测试。
正常情况下,接口测试做完,你业务逻辑应该是差不多都覆盖到了,前端只负责展示。

只有前端功能测试,没有后端接口/服务测试的团队,搞不好质量
只有后端接口/服务测试,没有前端功能测试的团队,质量不好搞

不太认可楼上 “只有开发写的所有代码,都被我们用例覆盖了,就几乎没有漏测的情况”,具体不细说。

楼主提到的疑惑,看起来组内是分为了做接口测试和做功能测试两部分,“所以要从功能组的同学那边借资源一块编写,前期给他们培训,然后脚本编写,花了挺多资源的,但是结果好像并没有太大的产出,对于功能的同学而言,该执行的用例还是需要执行,并没有减少他们的工作量,反正增加了许多”,分成接口和功能两部分的情况下,我觉得这样借资源的处理确实是对功能测试同事没有太大益处。
一、接口功能测试。我觉得接口层的功能测试主要是去覆盖到一些前端不能触发的场景,测功能的同事可以重心放在验证客户端可触发的测试场景。举个例子,一个购买接口,功能测试同事测试点都是能从客户端触发的,余额足的时候购买余额不足的时候购买...接口测试同事可以验证修改商品 id 成已购买的 id、修改 id 成特殊符号...
二、接口自动化测试。我觉得这个是用来确认每一次代码修改后新旧接口逻辑正确性的一种方式,并不能帮助前端做什么,毕竟前端也有自己的自动化。
PS.我感觉既然内部已经接口测试&功能测试划分比较开的话,就尽量还是不要让功能测试的同学去支援接口测试吧..除非功能测试的时候接口测试同学也去支援了,不然多少有点心里不平衡鸭。而且如果做接口测试的同事水平已经到达测试开发水准的话,写脚本效率应该大大高于功能测试同事,从个人心态、脚本效率、代码质量几方面考虑,感觉都是让接口测试同事亲力亲为合适点。

总结来说:接口测试 or 前端测试,目的都是为了保障整个产品质量,接口测试的存在是为了让前端测试减少工作量的说法我认为很不靠谱。各有各的意义,不冲突,是协作关系。

这个要项目是否前后端分离吧以及测试周期吧,很简单的一个现象,功能测试就 2 个测试人员,并且客服端跟服务端基本提测的时候,一起测试,这时难道还接口测试?都来不及了,先把功能搞定了,然后看接口文档,看相关的接口参数是否有测试到,然后接口测试,或者稳定了,再来接口自动化,记得软件测试的目的:是在一定的时间内尽可能的发现问题,来降低产品发布出去给客户造成损失~
功能测试跟接口测试两者是不冲突,具体要看适用的场景,冲突的是时间~

接口自动化的定位最大的价值是做回归测试跑流程,接口测试阶段其实就是在跑无 UI 界面的功能测试验证后端的业务逻辑,在接口测试中发现问题越多那么在功能测试层面测试同学可以更专注的测试前端功能工作量也相对的减少,我是这样理解的

OllieForever 回复

一、接口功能测试。我觉得接口层的功能测试主要是去覆盖到一些前端不能触发的场景,测功能的同事可以重心放在验证客户端可触发的测试场景。举个例子,一个购买接口,功能测试同事测试点都是能从客户端触发的,余额足的时候购买余额不足的时候购买...接口测试同事可以验证修改商品 id 成已购买的 id、修改 id 成特殊符号...

以前觉得接口测试可以无限覆盖各种场景,但是后来发现业务不可能触发的场景,测试了没太大意义。 因为从用户角度出发,永远不可能用到这个场景,这些测试就是浪费。 ----个人建议。

t-bug 回复

举个例子吧,我这边的项目。
有个接口是用户提交身份认证,有一次测接口,我发现如果不带 headers 里的登录字段,提交一次认证时,该环境所有注册用户的身份认证都被改变到了。
如果这个问题发生在正式环境,有人恶意调接口去做了,影响面多大.....

当然,这种需要根据项目使用人群去决定要不要做,如果你的项目是面向用户,我认为这个是必须做,没时间另说。很多时候做一些安全等层面的测试不是在防常规用户,是在防一些不常规的用户带来的攻击。ps.内部人员用的接口我都是不单独做接口测试的,前端覆盖到啥就测啥。

我觉得接口自动化测试主要是用来快速回归的吧,一次编写,重复运行,可以快速发现开发改动的代码是否影响接口的响应准确性,如果功能测试有大把的时间测试,那还要这个干嘛,闲着也是闲着,测试下前端不好吗,另外接口测试可以构造一些特殊的请求,前端传参数都是不可信的

这里面我理解是两个问题。
一个是接口测试是否有必要,接口测试的目的是为了增加测试覆盖度、深入度,对接口的各个参数做实际场景中很难遇到的异常场景的测试,保证接口的稳定性。如果在这个前提下接口测试还是没有发现 bug,那么可以 review 下历次迭代中是不是业务测试发现的所有 bug 都是前端的。如果是那么说明你们的后端开发工程师能力实在很强,应该恭喜你们遇到了这么给力的队友,在测试压力很大的情况下就可以酌情考虑不做接口测试前端测试完成就上线了。如果不是那就应该 review 你们的接口测试用例了。是不是用例设计的还不如业务测试全面,是不是用例设计的时候默认按照正常的取值范围,按照正常的业务逻辑进行的用例设计导致用例的覆盖还不如业务直接黑盒测出来的覆盖全。
另外一个是接口自动化测试是否有必要,自动化测试的目的主要就不是发现多少 bug 了,而是为了快速对接口做回归、做线上监控等,避免接口出现了低级问题、阻碍问题但是大家不能第一时间知道,等过了很长时间线上出了强反馈或者在错误接口的基础上又做了很多开发才被大家发现。当然,在接口自动化的基础上再做压力测试、稳定性测试等也会更方便。在这个前提下再评估接口自动化测试是否有必要,思路就会清楚一些。
整体上测试是为了保证业务中的 bug 能够在有限的资源下最大量、最快速的发现,业务实际情况不同、测试团队规模不同、测试与业务的合作模式、测试团队成员的技术能力等等都会影响测试方案的制定。我觉得你们团队有专人做接口测试,这种情况下接口测试定位到用来发现更多 bug 是没有问题的,如果没有发现 bug 那就需要仔细找找接口测试用例设计的问题。接口测试的目的不是取代业务测试,而是减少业务测试遇到阻碍问题的概率以及减轻业务测试模拟异常场景的工作量。接口自动化测试的目的是在回归场景节约业务测试的工作量,在新业务测试中实际反倒会占用更多的测试资源。这是我对接口测试以及接口自动化测试的理解

t-bug 回复

某一个天,懂点技术的来了,抓个包试几次就发现所以东西都能 1 分钱购买,或者可以负数购买的时候,你就不这么想了

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册