Selenium 有没有想给 GUI 自动化测试平反的请进

开奔驰的QA · 2019年05月17日 · 最后由 david 回复于 2019年05月28日 · 2028 次阅读

在进入移动互联网时代之前那些年,GUI 自动化测试火了一阵子,老 QA 基本都听过 QTP,后来进入移动互联网时代后,前后端分离,微服务等框架出现,API 自动化测试随着几篇科普文以及改写转发的软文火起来了,直到现在,做没做过自动化测试的 QA,开发,CTO 都统一口径的说 GUI 自动化测试不行,UI 不稳定经常改动,写完的自动化测试投入成本太高......google 搜索 GUI 自动化测试基本都是提缺点的,元素定位难,操作某元素失败,执行 GUI 自动化测试慢等等,可是 selenium 和 webdriver 一直没有停的不断更新着....

一直期待听到不同的声音和新的实践,但是寥寥无几,像这篇《测试人员必看:传统测试向工程效能转型的最佳实践》提到 “自下而上依次是 unit test、API test、GUI test。在转型之后 unit test 减少,API test 增多,GUI test 依旧,上方多了一层 Exploratory test,这一层是真正的基于测试的理念和探索式方法来尽可能多的发现软件系统潜在的缺陷。从人员的角度来看,无论是转型之前还是之后 unit test 都是开发来做,但是 API test 和 GUI test 在转型之后从测试转向了开发,原来团队的业务测试人员现在专注于 Exploratory test。” 好像并没有得到太多的支持和采纳。

正题

1、怕 testcase 因前/后端程序变更而失败吗?
2、写出来好几百个接口测试用例,回归执行通过率平均 99.99%,维护脚本的投入很小,说明自动化测试做的很成功吗?
3、GUI 自动化测试用例编写难度比 API 测试用例大吗?写好 GUI 自动化测试对 QA 要求更高吗?
4、是否分析过缺陷发生在 API 还是前端更多一些,再考虑投入在 API 自动化多些还是 GUI 多一些呢?
5、如果遇到接口参数多数据依赖复杂的应用,业务流程和场景的测试是否通过 GUI 进行测试才是最好的选择?
6、API 自动化测试能对流程场景进行覆盖,那么对于支持定制的流程、复杂的数据关系的应用程序能通过串联起来 API 实现流程场景覆盖,编写这样的用例投入的成本是不是太高?

以上问题如果在一些 2c 的小程序,小 app,小电商应用上讨论答案可能很容易得出。如果是一些 Saas 平台 2b 的企业级应用呢?

参考贴:
搜索了论坛关于 “UI 自动化” 的搜索结果, 共 1411 条
《关于 UI 自动化的前途》https://testerhome.com/topics/16015

共收到 4 条回复 时间 点赞

有需要平反的必要? 就因为最后那个没什么人评论的帖子?

社区里觉得 GUI 自动化测试有用的人一直在做,那些觉得没有的人也一直在看衰,硬要拿出来讨论到最后都是骂街。

努力做好自己,如果有好的框架或者成果,分享出来就是对 GUI 自动化最大的支持。

还是得看投入产出比啊。以目前的技术环境,还是做和产品代码直接打交道的接口测试或者 intergration test 比较靠谱,至少有稳定输出,也的确能反映问题。
我面试碰到简历上有写 UI 自动化的,都会问一个问题,覆盖率,发现 bug 率,回归成本,稳定性/可靠性。基本没碰到几个满意的回答。
当然可以打打擦边球,做一些简单的 monkey 或者登陆/登出检查,复杂场景,还是手工吧= =
UI 自动化这个,可以做,但是要时间啊,3 个月不出成果,OK,一年两年不出成果,你跟领导怎么交代?。。。
不过随着 AI 的发展,我觉得 UI 自动化还是有潜力的,但是这部分,得看大厂输出框架吧。之前去腾讯看过他们 WeTest 游戏 AI 自动化,做的挺不错的。

david 回复

您好!
在做小程序或者小 app 这种接口测试的时候发现维护接口自动化冒烟测试投入确实要少于 UI 自动化测试,接口用例回归执行成功趋势接近 100% 的时候其实也是因为就是接口不怎么变化了,偶尔增加一两个接口读写一些信息,偶尔增加几个参数,很少有把原来的参数废掉或者改名字的情况,API 的特点是这样有时候你多传几个参数过去都不会导致失败。

但是这个时期 UI 经常发生变化,进入这样的时期,手工测试基本每次都是在 app 功能测试上进行回归和测试新功能新 UI,QA 会向上级报告他们的回归进度,上级就觉得回归时间太久了能不能优化效率,这个时候我们有些策略就出来了,既然 API 接口测试这么容易写,这么不容易打破,这么容易维护(不需要操心总盯着怎么有被打破了),就用 API 接口来实现 UI 的流程覆盖和一些场景覆盖吧,(说到这里,我们必须要考虑对比一下简单的应用程序的流程和场景也是十分简单的,但是企业级应用类似有审批流程的,有自定义信息模版和自定义流程的这种应用程序,其流程和场景也是复杂的。)

可是这么做真的有用吗? 我们真的理解我们的测试过程中或者线上缺陷成因分布吗?了解我们前端开发的能力吗?前端在处理复杂的接口处理参数和响应出错吗?前端不会在处理复杂的流程出错吗?

最近对比了一个 Sass 的应用的接口与 UI

开奔驰的QA 回复

简单的场景是可以跑 UI 自动化,传统的基于元素检查的框架,和新一点的基于图像和场景识别的框架,发展很快。但是 UI 自动化不可避免的有随机假摔的情况,应付复杂场景的时候,稳定性还是欠佳啊。
还是坐等大佬的框架吧,目前的情况,不看好啊。

需要 登录 後方可回應,如果你還沒有帳號按這裡 注册