我们现在就是半强迫式的。 年初会根据各自的实际条件给他们定好学习目标，由自己制定学习计划，每个季度一次考核，直接计入绩效。
另外每个人年内至少需要在公司内部发表一篇技术文章，并进行技术分享。 达不到要求的，绩效会收到很严重的影响

写的浅显易懂 但是也太浅显了一点 建议楼主可以做成一个系列 逐步深入

没有什么更好不更好的 合适的就是好的 每个公司情况不同 选一个合适的解决方案就行了 关键还是在于如何落地

至于你领导说有更好的 你也可以去调研一下 完了再写个报告分析下各种方案的利弊 要用数据说话

失败的比例有多少？ 为什么用无头模式能提高成功率分析过吗？ 前公司的 UI 用例也有 4000 多 执行环境还没有你这么好 没有遇到过这种问题

期待新书问世 ！ 已定阅，第一时间支持

感谢楼主分享

xmind 数据解析生成用例 我也了解过 需要指定 xmind 的格式才行吧 我们的测试点分析没有一定的格式 解析起来比较麻烦 而且我们的用例大部分是以 Word 格式存储的（交付需要） 所以没有朝这方面发展

jira 方面现在只做了缺陷的跟踪提醒，每天定时统计缺陷，
对测试发送当日的新增、关闭、待复验的缺陷信息以及缺陷信息规范性校验
对研发发送各自关联的待解决缺陷，延期缺陷和一些其他的预警信息 另外数据落盘方便后续的统计分析

可以尝试一下 airtest 基于图形识别的

响应式框架这种问题常见 一般都是下拉表一类的控件 可以自己分析 Dom 树找到对应的元素位置

了解了 我们现在也是用 jira 但是没有用它来管理用例 主要还是用于缺陷和 需求 任务 这一块的管理

工作内容大体上差不多

楼主可以介绍一下 自动化测试与 Jira 集成 jenkins 与 jira 打通 具体是做什么吗？

1、默认为 xpath 如果不是再传可选参数
2、是这个意思 在代码里定义规则和 Api 通过配置文件来实现业务脚本

确实比较繁琐 其实现在的前端响应式框架 基本都得靠 xpath 来定位元素了 所以你可以给个默认值为 xpath 可以省一个参数 另外定位元素的方法还需要多扩展几个 至少要覆盖常用的显示等待预定义条件以及自定义条件的场景

其实如果你是想要做框架的话 最好能让脚本能脱离代码环境 能通过编辑配置文件来编写用例脚本

可以参考下 RF 的设计 ，动作就是动作 元素就是元素

执行用例时 就是元素 + 动作 来完成一次操作 比如

1、用户名元素 + 输入 (参数)
2、密码元素 + 输入（参数）
3、登录按钮元素 + 左键点击

打个比方
类似于 selenium 本身也封装了 click 方法

你可以再封装一层 把 driver.click + Action 类的 Click + JavaScript 的 Click 封装到一起 做成自定义的动作 myClick 简化脚本开发的操作

页面基类只维护页面公共元素 动作另外封装

页面就是页面 动作就是动作 页面只维护元素对象 动作单独抽象出来 不建议写在页面对象里
写用例时再把元素和动作组合起来

分析得很详细了 我之所以不选 jmeter 是因为脚本量大了 维护起来简直要命 并且业务流程复杂了脚本不方便调试 如果是小项目倒是还好 短平快 对人员要求低

我 44 了 不也挺好 去年刚跳的槽 有些企业注重年龄不去就是了 总会有不看重这些的 关键是自己的底子要硬
我刚入行时的技术经理现在 50 多了 现在也还活跃在第一线 代码写的废寝忘食的

她女儿已经在美国博士毕业了 现在工作完全是为了兴趣。。

你这是拿一个元素对象和文本做比较了吧

看异常信息应该是第一个用例跑完后资源没有释放 第二个开启新 session 时无法连接 可以从这个方面来排查

那你看看生成测试报告的插件是不是有独立的时区设置？

jenkins 本身有个时区设置

常见的就是文本文件 比如 json yaml xml csv 都可以 要不就 excel 或者数据库
我见过的实际场景都是用 excel 存用例脚本 文本存配置信息

excel 用熟了 编辑效率比普通文本文件高得多 只是不太好比较历史版本差异

楼主，除非是不在 DOM 树里的元素 不存在有 Xpath 定位不到的

而且 Xpath 非常灵活 可以定义一个 pattern 来匹配多个类似的元素 就像是楼上的这种设计

确实 现在的前端框架只能用文本信息辅助定位，根容器能够有个唯一的的 ID 就不错了 ，你的设计方式和我的差不多 ，我这是这么写的

.//form[contains(@id,'#placeholder#')]//label[normalize-space(@title)='#placeholder#']//following-sibling::div//input[@type='text' and @name]