Selenium 什么时候需要自动化什么时候用自动化?

BenCoper · 2020年08月19日 · 最后由 MarvinWu 回复于 2020年08月28日 · 196 次阅读

最近在封装符合项目的自动化框架代码遇到很多问题
1.项目规定有统一的 id,前端不加 id 用其他元素定位项目经理会让反工
2.界面需求随时新增没有稳定的需求
3.接口验证数据库后 UI 自动化也验证数据库???
4.自动化维护成本太高了效率也不怎么样

来自刚入行的萌新提问,大佬手下留情.很迷茫
不知道哪些页面需要自动化.最关键的是上一任的代码是 Selenium+unnitest 没有分层所有操作都在一起.现在要改在成 Pytest 封装成 POM
最后一个问题 (接口自动化和 UI 自动化哪个更适合职业发展)---感觉 UI 自动化不咋受待见....

项目类型腾讯文档在线编辑

共收到 13 条回复 时间 点赞

第一条看你领导还是挺支持的,已经让返工了

第二这个是哼多企业的常态,只能适应不然为甚么这么多人喊 UI 自动化不好做!!

第三这个有的人验证有的不验证,根据你自己的需求来,换句话说如果你不验证根本就无法保证你自动化的有效性,那么就要验证

第四 这是通病,估计有人会给你推荐 PO 模式,至于 PO 能否让你提高效率你可以评估,再者需要做减法,如果把所有用例都自动化那么就太大任务 维护起来也费力,可以主要放在核心业务 主流程 以及减少逆向场景等,看领导是否同意

第五肯定是接口更成熟,收益更高所以很多人看不起 UI,以上!!!

但是接口测试不是比 UI 自动化容易吗?

接口自动化投入产出比高一点,而且运行起来比 UI 自动化更快速稳定

  • 需求经常变动还必须要做 UI 自动化的话,团队最好是采用敏捷开发。除此之外提供一些减轻重复工作的建议:

    • 先写测试用例再开展编码和测试工作,让产品、开发和测试人员共用一种 “语言”,减少 Bug 和对需求的理解不一致,从根源上避避免需求的不停变动。
    • 对于经常变动的 UI 界面,学会使用 Selenide 而非 Selenium,使用 Selenide 的 $("页面元素定位符").find(byText("你要搜索的页面元素")); 去搜索页面上的元素会更高效,代码可读性更高。对于主力是测试前端 Web 页面的公司,那么 Taiko 比 Selenide 还要好一些。可以尝试使用 Taiko 去编写测试脚本。
    • 采用 Gauge+Selenium(或者 Selenide)去做测试,测试用例可读性高,测试报告清晰可见,测试代码复用率高,减轻重复工作量。
    • 需求变动导致工作量增加的本质是以前的代码会废弃,除了上述提到框架工具之外,阅读《Clean Code》这本书对你的帮助会很大,学习重构你的代码,减少代码中的耦合,归并功能一致的代码,抽取公共方法,适当构造静态类便于直接调用。还有清晰可见的方法名、代码即注释的命名习惯,可以很好地抵御频繁变动的需求,尽可能保证代码的可用性。
  • 虽然人们总说改变不了别人,就去改变自己,但是对于团队开发而言,这句话并不是那么妥当。

    • 测试人员最好要求开发人员做好单元测试,如果论收益而言,单元测试的收益是最高的。简单应付了事的单元测试也不行,应要求开发人员单元测试的代码覆盖率达到 95% 或者 100%。

最后针对你提出的问题:

  • 1.项目规定有统一的 id,前端不加 id 用其他元素定位项目经理会让反工
  • 2.界面需求随时新增没有稳定的需求
    • 减少 XPath 和 CSSSelector 的使用,尽可能使用 byText() 的方法去搜寻元素。
  • 3.接口验证数据库后 UI 自动化也验证数据库???
    • UI 自动化是有预期的,如成功或失败,准备好数据集然后开展自动化测试会更方便一点,即先从数据库里面把数据拉出来,放到 Excel 或者其他可以被编程语言读写的文件里面,然后在开展 UI 测试时去验证即可。当然你连通了数据库再去做测试应该也可以吧。
  • 4.自动化维护成本太高了效率也不怎么样
    • 自动化测试属于敏捷开发中的一环,团队的开发模式有很多种,比如野路子开发、遵循 DevOps 的开发等等,团队的交付有很多种,比如差不多就能上线了,也有遵循 CI/CD 的交付,理想的自动化测试应该是项目交付中的一环,以 Jenkins 为例,开发人员把写好的代码推送到 Git 上,运维人员在 Jenkins 点击构建,Jenkins 自动去 Git 上拉取最新的代码并且把项目打包好,然后上线到测试环境,然后测试人员写的自动化测试脚本(包括单元、集成、接口、UI)会自动执行,自动产出测试报告,如有问题会向开发人员发送邮件,有些做得比较好的测试平台可以自动提 Bug,如果没问题产品会自动上线。所以从总的情况上来看,自动化测试是效率高,收益好且易于维护的。

以职业发展而论,UI 测试、接口测试、压力测试、性能测试和抓包分析都是基本功,真正体现你测试能力的是参与产品的需求讨论、做好产品的缺陷预防工作,精准把控产品上线后可能会发生的异常,保证测试部门和其他部门的沟通顺畅,同时把控需求的合理性。做测试是容易做到管理岗的,这源自于测试岗位需要保证产品质量坚如磐石这一特性决定的。

秦岭 回复

目前正在封装的框架就是采用 POM 模式上面也同意了,最重要的是项目经理规定自动化要覆盖 70%.很多需求刚写一半用例流程就变了.所以最近就一直纠结于这个自动化有必要没有了

simonpatrick 回复

公司接口测试用的 Yapi 都是模拟的 Mock 数据

小酷 回复

是这么个道理但是现在自动化被说得很厉害

MarsOu1998 回复

感谢大佬的耐心回复!
仔细阅读了回答也去看了 Selenide 这个二次封装的框架,后面看看能不能用在项目上
开发的单元测试是有单独的人做单元测试覆盖率在 100% 后端 但是前端只有自测
验证数据库这个环节具体资料还在查看中也谢谢提供的思路

个人观点:

比较稳定且需要重复测试的,可以用自动化。

不稳定但自动化测起来比人工快的(比如各种字段校验),也可以用自动化。

这两天我也在用 YAPI,已经搭建起来了,想结合 Jenkins 做 CI,定时啥的,但是没搞起来。

项目周期不长 界面不稳定的话 不建议做 UI 自动化 费效比太低

接口自动化和 UI 都重要 不存在向哪个方向发展 都需要掌握

如果说用例写一半,需求就变了,只能说是自动化团队能力还有所不足,测试产出效率需要提高
就拿第二点来说,界面需求变了,在 PO 模式下,也就是元素定位发生变化了或者方法的流程变了,这个变动的影响范围应该只是页面级的,为什么会没有开发改得快呢?

另外接口自动化、UI 自动化完全是两套东西,也不具备可比性。
接口自动化无法替代任何手工功能测试,而 UI 自动化是可以解放部分手工工作,就冲这一点,UI 自动化会一直是效率追求的目标
接口自动化技术太成熟了,很难再玩出什么新花样出来。

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