接口测试 领导给了一个覆盖所有测试场景的接口自动化任务,接口测试到底应该怎样做才对?

默默无闻 · January 02, 2020 · Last by guiyu replied at January 09, 2020 · 3441 hits

我最初认为接口自动化,和自动化,只能用于覆盖一下冒烟和主要的场景,其余比较繁琐的场景,不利于自动化工作来做,做了也得不偿失,性价比低

目前现在领导(整个项目的技术总监,不是我们组的组长),就是要求我们使用接口自动化,做测试场景的覆盖,且是很大范围 (用例场景) 的接口覆盖 (测试数据必须源于线上的真实数据走)

就是基于Jenkins+RF进行构建化的接口测试,我觉得有点违背自动化的定义了,太过于依靠自动化了,会不会导致最终没做完,就放弃,发现不能这么搞,时间又浪费了

也可能是我没见过这样做的公司和我没这么做过,自认为不能做把,我想听听大家的意见,谢谢大家。

共收到 13 条回复 时间 点赞

哥们,你出现挺频繁的,又被扣了工资,所以我打算多跟你说一点。
首先,我本人在全力做自动化中,无外乎就是ui+接口。ui用用selenium和puppeteer,接口跑跑testng
自动化被定义为做回归和冒烟,其实是为了节省成本。但是如果你把所有能覆盖到的场景,包括文件下载验证文件内容等等,你会发现其实覆盖的越全,就越舒服。为什么呢?举个例子,你自动化用例写了1K条,2分钟跑完,没有发现问题,和人手工执行没发现问题是一模一样的,既然这样,领导会选哪个?
相反的,你跑了1K条,发了了几个迭代的bug甚至是很难执行到的长流程bug,功能测试没发现。这就更显而易见了。
不是说本末倒置了,自动化这块有没有价值,答案是有的,而且很大。你看国外乃至国内大一点的企业都会去有专门做自动化的人员,但是自动化这块弊端也很明显,就是很有可能覆盖不全,有些无法执行到,或者是必须用直观肉眼和逻辑思维去处理的流程,毕竟现在还没有这么智能,多半的用例都是提前录入或者万能不变的很难有成效。

要分层测试,单纯接口自动化不可能覆盖全场景。
另外要有衡量标准,如何认为全场景覆盖?功能case 全覆盖?还是代码分支全覆盖?空口说覆盖,结果就是领导认为怎么样就怎么样。

全覆盖不现实,然而项目领导们又不是很懂,“这怎么不能自动化,那怎么不能自动化,我跟你说你可以这样这样,可以那样那样”,给了任务要写个case就要一长串,想拆成小颗粒写但是需要一些资源上的支持,又TM不提供资源支持

好机会,又是一个涨薪的机会,先提出一个人搞不定,然后看领导脸色,如果面色不好赶紧解释这个会太累,接着透露出年底了可以加薪一波吗,剩下的我就瞎编不出来了

做自动化测试就是为了代替人。把冒烟当自动化测试的目的是做不好自动化测试的。
特别是接口测试,天然适合自动化测试。
覆盖所有测试场景这个描述是不准确也做不到的。应该是覆盖所有正向业务场景,以及你想覆盖的其他异常场景。

tester 回复

确实可能做好,覆盖全了,每次点一下执行就执行了1K的case,这样我认为对于不频繁变更的产品,确实带来好的效益,我们项目经常频繁变更(每周一次迭代),这样维护成本高,工作也不只是做接口,还有很多杂七杂八的,项目东西也很复杂,东西功能模块也很多

尚酷米 回复

一看就是有准备的人

好契机,有技术总监盯着这个事,开发没理由不去配合
要求没集成swagger的必须集成,接口文档/定义信息不完善的必须立刻搞好

前提是,你得说服你们总监,自动化测试不是测试工程师自己的事,开发必须配合,看看他是否还依然那么坚决,如果依然坚决,那么如上所说,你会做得很顺畅;如果不是,那么估计就是找个由头整你们,赶紧闪人啊~

槽神 回复

好的,谢谢大佬的建议。

来一波case评审了,他们觉得ok,那就是覆盖到位了

槽神 回复

最近听到一个观点: 组织内部达成共识,即使是暂时错误的共识也比没有共识要好。当然这种错误的共识也要是大家一起承担的那种,不是甩锅强推强迫类型的共识。

说实话,接口自动化测试我还是很支持的。这个基本可以保证业务流程不出什么大问题,当然客户端交互这个不说了。

是不是可以理解成监控线上业务是否正常

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up