• 列表数据的校验是一个难点,我的方式是通过列头的文本值来通过 xpath 相对定位获取这一列所有元素 再逐个与期望值校验

  • 其实也是参考 RF 的设计,把元素和动作分开,页面不带任何动作 需要操作时把元素和动作组合起来使用就行了

  • 把元素定位和动作分开封装,PO 只维护对象,动作可以抽象出来和元素进行任意组合,一般的 WEB 页面也就是几十种动作类型

  • 根据公司项目的业务特点和 UI 自动化的职能目标而定

    如果 UI 只是用来做页面的 CURD,各用例之间有依赖是可以接受的。每个用例都做前置后置数据维护工作量会更大
    如果需要做流程,用例最好能做到独立运行。一般还是推荐用接口做流程回归,受客观因素影响比较小
    另外还可以加入重试机制,能很大程度降低外部因素引起的测试失败
    我这里 UI 只用来做功能冒烟 约 500 个页面 用例数 2500~3000 之间 通过率平均 93~95% 左右

  • 嗯 使用哪种方案还是根据项目具体情况而定

    jmeter 资料丰富 上手快 对人员要求也低 用来做一些短期项目的接口自动化还是挺不错的

  • 可以在测试框架中集成大漠插件 不过只能在 windows 中使用

  • jmeter + ant + jenkins 短平快

  • 这是 Driver 内部的通讯超时了 检查一下 driver 和浏览器的版本是否匹配 或者浏览器是不是自动升级了

  • 1、在开发环境运行时可以直接在 IDE 的控制台里查看日志
    2、在非开发环境以本地方式运行,可以使用日志工具写日志文件,再做个桌面应用读取刷新
    3、如果是以远程方式运行。写个 web 页面来获取服务端 log

  • 动作无非就是哪些 单击 双击 输入 切 iframe 访问 url 之类的 一般也就几十个 可以抽象出来 将元素和这些动作进行任意的组合

  • 链式写起来舒服,对调试就不怎么友好了

  • 不建议用这种 PO 设计
    页面对象建议只维护元素定位,动作可以再抽象一层独立出来

  • css 不怎么用 如果用 xpath 可以这样

    eleAs = driver.findelementsbyxpath(".//div[@class='A']")
    eleAs.foreach(eleA->{ eleas = eleA.findelementsbyxpath(".//div[@class=a]") })

  • 1、容器类元素带唯一标识就行了,叫什么随便定
    2、不同页面的同类元素 最好使用统一的命名

  • 用 text 来相对定位 比如 .//span[text()='福州白金翰宫']/..

  • 参数流转可以参考 jmeter 的方式 都是相通的
    可维护性这个得具体问题具体分析了

  • 嗯 它可以做到流程自动化 但是断言什么的功能需要自己实现 而且按键只支持 VBS 扩展能力弱了一点

  • Selenium:xPath 定位实践 at 2020年09月11日

    多 PO 模式是个什么概念? 不太了解

  • 嗯 你说的也是我们期望达到的一种状态 只是应用到具体项目上还是得看实际的需求和场景来决定。
    比如我司的产品是企业应用,自动化脚本不仅需要在公司内的测试环境使用 还需要部署到客户现场执行
    而客户提供的环境是我们无法预料的,大多时候性能无法保障,甚至还需要和其他系统共享。所以我们的主要关注点在于测试框架与脚本的稳定性和减少脏数据引起的问题。同时也外挂了性能监控的插件,对于一些操作等待时间很长的步骤也会在测试报告中进行警告提示。但是 也只是如此了。 同样的脚本,在公司中和不同的客户环境中运行,执行时长可能大相径庭,只能做到尽量兼容。

  • Selenium:xPath 定位实践 at 2020年09月10日

    有一说一 懂 xpath 的还是不少 只是能越灵活运用的不多 毕竟 UI 相对接口来说 适用的范围更小一些
    我现在公司的产品是属于管理类的系统,产品周期长,前端的风格也是比较统一的。
    所以我们在实际工作中也在不停的对 PO 模式进行改进,现在系统几百个页面 实际只需要维护一个 PO 文件,一共不到 100 个元素。
    在定义元素 xpath 时把公共部分剥离出来,实际写测试脚本时再输入变量部分就行了,比如某个控件的 label 文本之类的,这也是为什么要使用 xpath 相对定位的好处

  • 是指的通过率 是包括了失败和跳过的一起计算的,稳定性这个指标不好用数字量化吧。
    2500+ 全是回归用例,现在大概有 430 个页面。 失败 case 里面 真正是功能有问题的 大概 20~30% 左右
    有时候可能同一个问题引起很多页面测试失败

  • 1、功能用例和自动化用例想要共享同一套是有点困难的。
    自动化用例需要标准化的输入和输出,而功能用例因为人员素质或者团队管理方面的原因很难做到这一点。
    并且,方便给机器识别的自动化用例往往很难做到像功能用例那样方便让人来阅读。 只能尽量取双方的一个平衡点。
    也可以由你们的自动化团队开发一个功能->自动化的转化工具,这样相对来说对于功能组来说会容易接受一点。毕竟如果你强行要求功能组来编写自动化用例的话,对团队管理水平以及人员的技术素质是有一定的要求的。

    2、用例存在哪里都可以,是你们的实际需求而定。常见的还是 excel 或 yaml 比较多。sql 和 json 的可读性差一些。

    3、测试脚本也需要遵循高内聚,低耦合的原则,颗粒度尽量细,用例之间尽量极少依赖,可以独立运行也可以随意组合运行。

  • 可以用多线程执行用例,单独开一个线程跑这个用例。但是对于你这个异步查询用例所在的线程来说 还是阻塞的。
    如果所有用例都是你说的这种要等 10 分钟才能进行断言的情况,似乎也没有想到有更好的办法

  • 根据领导支持的力度和团队本身的技术水平来决定

  • 2500+ 左右 UI 冒烟用例 通过率基本维持在 85~90% 之间 你说的指标很难达到

    UI 测试受到各方面的影响太多了
    而且很多用例之间有依赖的 前面的挂一个 后面的全 skip