接口测试 [疑问] 小型公司是否适合做 app 自动化或者接口自动化测试

ddDian · 2016年10月19日 · 最后由 doyale 回复于 2020年05月15日 · 3319 次阅读

目前公司主要产品是一个电商平台,就移动端来说包括 android、ios、H5、微信。
好,现在领导需要测试部做自动化测试,然而移动端只有 2 个测试,1 个还不会代码。
所以呢,我认为做 UI 自动化(appium)是不实际的。自动化目的主要是回归所有用例并不出 BUG。以自己经验来说,可以把移动端 app 当做一个单机系统,出 BUG 的地方一般来说是请求 http 的跳转,也就是接口。因此打算使用可视化的 Jmeter 等工具去写接口测试脚本,达到回归整个 app 的目的。也就是抛弃所谓的 UI 自动化,这是我一直认为成本高意义却不高的工作,测试目的还是找 BUG,不知道你们 UI 自动化是否真的找出 BUG 了,或者说这些 BUG 我用接口测试也能测出来。
最后,对于刚起步的测试部门测试 app 端,是采用接口测试实际意义会更大。
优点 1.有可视化工具 2.可以不用代码 3.成本相对来说较低

欢迎各位的指教!

共收到 19 条回复 时间 点赞

先要了解到,做自动化的根本目的,并不是为了找出 BUG。
没发现 bug 的自动化不代表没有意义,可能只是没有覆盖到问题点上。

@hub128 UI 自动化根本目的是跑完整个程序是不,没出 error,通过;出 error,有 BUG。好,BUG,为什么不用接口测试写写 url,写写输入输出方便快捷呢?

个人认为,UI 自动乎测试的意义有两点:
1.节省回归时间.当当前版本有修改时,可快速回归;
2.代替人力检测上线版本.
当然,致命的缺点时,一旦当前界面发生变化,代码需要修改的部分很多.
意见浅薄,各位勿喷.算是抛砖引玉.

如果开发有成熟的 CI,可以考虑。
没有的话,原来干么还干么。

5楼 已删除

@kanchi240 还没去实现。我们是电商,微信是跳到微信 WEB 页面,按道理也是用 H5 的接口的吧

直接放弃吧。过来人。

8楼 已删除

#2 楼 @liweixin440 UI 也好接口也好,做自动化根本目的还是为了提高回归的效率。做自动化还是要讲究分层,毕竟接口测试只能覆盖产品的一部分代码,UI 自动化从执行效率、稳定性各方面也不比接口自动化。

1、首先我们跳出这个局限 1 or 0 的圈子。
2、可以把整个 APP 或者全部接口做一些粗略的拆分,只做部分,维度的可以考虑下维护成本,需求变更频率等。
3、个人觉得一般的 APP 自动化在 elements 维护方面比较麻烦,前期没有做好数据分层,后期维护成本巨大。相对而言接口做起来容易的多,也更容易进行持续集成

先保证服务端,手机前端(app,H5,微信)不会很重的,主要业务逻辑都在后端(也有例外)。服务接口没问题了,基本就剩下兼容性和特殊场景覆盖了。

自动化的目的不是发现 bug,而是质量保证

跟楼主情况很像的过来人表示,做好 Jenkins+ant+jmeter 就可以了,而且对产品质量的提升很明显

现在好多领导都是那种理论派,根本不懂技术,所以和他们讲道理是讲不通的,那么现在这种情况领导让你做有违背你的意愿,一方面是你们的理解有分歧,一方面可能你自己有问题,那么既然价值观不统一的情况下,要么就埋下头来做,要么就闪人找能与你价值观一致的地方。

首先自动化测试,不论是 UI 自动化还是接口自动化都是为了节省人力成本而不是为了找 bug。 第二移动端刚开始做自动化的话确实接口测试比较好。因为移动端的 UI 自动化成本比较高。不同的平台需要不同的框架,也就说你要写好几套代码去测试。 不像 PC 端,webdriver 解千愁。 第三,使用 jmeter 也好,soupui 也好,都是过渡阶段。以后 case 多了肯定得重写。 因为这些工具应变力比较差,开发那边随便改改你这边就得改一堆 case。 当然如果你们产品小,接口少,也没打算大规模铺开自动化。那就当我没说

#4 楼 @yangchengtest
我点赞了,所谓的自动化,也需要看贵公司的整体构建环境,如果有好的 CI 自动化构建的话,可以开始考虑把部分功能修改不大的拆分出来,比如自动化接口测试。微信和 app 接口测试,容易验证的就是 GET,POST 中的字段等等。流程验证接口自动化这个本人也不是很懂。就不说了

个人觉得,没必要

个人建议, 从怎么减轻自己工作量的角度去考虑自动化这个事,这样也能落地

把接口测试弄起来,后面会事半功倍,成本低,回报率高

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