ui 自动化测试高投入产出比 -全讯平台

测试交流1090字数 1562阅读5分12秒阅读模式

前言:

最近浏览论坛里的帖子,只要是关于 ui 自动化测, 很大几率会看到有人在苦口婆心各种劝: ui 自动化收益不高、投入产出比低、ui 变动大,难以维护, 等等。
过去半年部门在迭代开发一个新产品,每一轮迭代和每一次发版,都坚持用我们的自动化用例进行回归验证。 作为一个 ui 自动化的中度使用者,想和大家一起探讨一下 ui 自动化的投入是否真的值得。文章源自玩技e族-https://www.playezu.com/516046.html

产品背景

产品结构:

  • 一个平台,前端分 pc 和 mobile web 两个版面。其中 pc 版比 mobile web 版多了一些附加功能,其他 90% 功能重合。
  • 一个 pc 版的管理后台,主要管理各种模块的增删改查。

产品迭代节奏:

  • 每个小版本周期大约 20-30 天。
  • 每个小版本比前一版本增加约 15% 的新功能,另有约 10% 的旧功能优化。

关于投入

1. 前期框架搭建:

前期已经使用 python flask bootstrap selenium docker 搭建了一套自动化用例管理平台,主要利用项目的空余时间进行开发,实际开发时间大约 10 人天。
如果你有一定的开发基础,建议可以花点时间搭一个符合自己使用习惯的框架; 如果不想花时间开发,用业界流行的成熟框架也很方便。文章源自玩技e族-https://www.playezu.com/516046.html

2. 用例覆盖与编写:

个人使用经验,ui 自动化要达到一定的健壮性,以下几点很重要:文章源自玩技e族-https://www.playezu.com/516046.html

  • 用例覆盖不能贪多,覆盖基本的增删改查功能即可。
  • 用例的测试目的明确、唯一,即一条用例只覆盖一个明确的测试点。
  • 用例设计要尽量简单,不要有和测试点无关的步骤。
  • 对重复的步骤,剥离出公共方法,方便维护。如登录、进入某个菜单,等。
  • 元素定位尽量使用 id、name、text 等不常变动、可唯一识别的属性。 这样即使页面有变动,也不需修改用例。

3. 用例维护:

如果有新的版本迭代,用例维护工作如下:文章源自玩技e族-https://www.playezu.com/516046.html

新功能:按统一的套路,设计需要覆盖的用例。

如管理后台新增了一个商品管理的页面,则需要增加以下用例:文章源自玩技e族-https://www.playezu.com/516046.html

  • 进入菜单公共方法:调用登录的公共方法,并增加进入到商品管理页面的步骤。该模块的所有用例都初始调用这个方法。用例如下: 公共方法 |login,点击菜单 | 系统管理,等待 |2,点击菜单 | 商品管理,等待 |2
  • 新增商品:进入页面>点击新增>填写必需字段>点击保存>验证是否成功>截图
  • 查询商品(抽取为公共方法):进入页面>输入查询条件>点击查询>验证是否成功>截图(便于后续查看)
  • 修改商品:查询商品>点击修改>填写必需字段>点击保存>验证是否成功>截图
  • 修改商品:查询商品>点击删除>点击确认>验证是否成功>截图

这部分用例在完成第一次冒烟测试后即可进行编写(确保功能已经调通),而且使用这个模板,可在 5-10 分钟内完成这个模块的用例设计、编写、调试,后续基本不需要维护。文章源自玩技e族-https://www.playezu.com/516046.html

功能变更:修改对应用例。

如商品管理页面中修改了一个必填字段,只需对应的用例中修改该字段即可。文章源自玩技e族-https://www.playezu.com/516046.html

执行效果:

  • 执行效率:目前产品中前后端用例接近 200 条,在使用 3 个线程并发执行的情况下,大约 15-20 分钟可完成一轮回归测试。
  • 执行结果:
  • - 每轮迭代开发完成第一次迭代,用例失败率大约是 15%-20%,可发现若干因功能修改引发的问题;
  • - 每轮迭代测试后几轮,用例成功率大约是 95%-100%(个别用例因环境问题无法执行),可替代 70% 的手动回归测试执行(剩下 30% 涉及复杂流程,更适合手动测试)

使用建议

  • 不管是长期项目还是短期项目,都应该尝试把 ui 自动化用起来。即使只能覆盖 20% 的基础功能,仍然能节省你手动回归的工作量。
  • 用例要多跑,才能价值最大化。每次有重新部署,都尽量让用例跑起来,甚至在空闲的时候也让他多跑几次,说不定某些偶发的 bug 就被发现了。
  • 做好用例设计。这是用例健壮性最大的保障,否则每次执行都要调一次用例,节省的工作量又加回来了。
  • 总结使用心得,优化框架和用例设计。 没有哪个框架是完美的,多总结自己使用中用得不爽的问题,把工具优化到自己最趁手的状态,也就越能发挥工具的作用。
文章源自玩技e族-https://www.playezu.com/516046.html文章源自玩技e族-https://www.playezu.com/516046.html
继续阅读
历史上的今天
12月
22

    风险通知:非原创文章均为网络投稿真实性无法判断,侵权联系

    免责声明:内容来自用户上传发布或新闻客户端自媒体,切勿!切勿!切勿!添加全讯足球网的联系方式以免受骗。

    评论  10  访客  10
    1. mingmingjiu

      大佬请问你上面修改流程里面的,查询那一步查的数据是怎么预置的?是使用的上面新增流程生成的数据吗

    2. 冷月醉夕阳

      还是要看公司业务,研发流程,测试案例设计等, ui 不是想像中的那么简单, 单从覆盖率节省人力方面来讲,假如说 ui 100 条案例,你只覆盖 50%,对于功能测试人员来说觉得没点用,为什么? 因为事实上另外的 50% 功能,手工测试时,其实差不多可以过到你覆盖的那 50%,这从人力节省上面来看,好像看起来没什么节省人力。

    3. abee

      这个只能是根据公司的业务来说适合不适合,而不是 ui 有用没用,如果产品迭代更新很快,ui 维护起来很麻烦的。

    4. sky

      只能说,你们公司的研发规范应该做的不错

    5. 我问问

      你有 1000 条 case,你手工能执行的过来吗,ui 很有用

    6. iced_me

      非常同意,觉得产出比不高只是因为不会做或做法不对而已

    7. jerry li

      看论坛里有关 ui 自动化的讨论,认为性价比不高、收益不高的还是挺多

    8. 开源吗?

    9. xdf

      谁说不高的

    10. 笑哼

    发表评论

    匿名网友