要对设备管理有对应的策略啊，多少台应该升级，多少台保持在旧版本，不能说一股脑都升到最新版本，旧版本就不理了.
像 iOS 一般来说保持最近两三个版本就差不多了，大部分客户都会升级到最新版.

都已经有 docker 了，我理解把它放到 pipeline 的准备阶段就可以了吧？
或者另一种思路是你把 selenium 作为一个长期的服务放在那里， pipeline 里面直接去调用和启动。不过感觉这样虽然 pipeline 节省了启动 docker 的时间，但长期保持一个空闲的服务也是一种浪费。

我们送了个无线充电器，还有内部的比赛和活动

听起来就很厉害，给你点赞

自动化测试在我的团队里面不存在 “是否需要” 的争论。整套质量管理的流程下来，每一个步骤都可以这么讨论：单元测试需不需要？集成测试需不需要？需求设计评审需不需要？
在 “自动化是一定要做的” 这个前提下，团队的精力才会集中在怎么做得更好。

我不完全同意你的说法。
迭代快的项目不代表不适合做自动化，反而由于迭代频繁，回归测试的次数更多，对自动化的依赖更大。不然每周一个版本，每周一次全量回归，全靠手工测试，早晚把团队干废了。
只是对应的策略要适当调整： 既然迭代那么频繁，自动化的颗粒度是否可以粗一点？ 代码是否用上了 po 模式，可以快速适应页面的变化？ 自动化能不能左移，在需求确定下来之后，开发完成之前就把自动化调整好或者写好了？

每个任务都要考虑投入产出比和承诺时间啊
如果领导都支持你或者希望你能做，就把主要精力放在规划和计划上面，找领导支持； 不容易承诺，有时候在领导眼里就是没有干劲，畏首畏尾。

是的

是的，我们也是快跑了一段时间，但是效果不容易体现出来，才慢下来思考和改变。

看问题的不同角度而已，可能面试官着重考察的是你落地的能力

那没办法了，对于我们这种传统行业，产品已经存在了十几年，而且很可能在未来的十年里都会一直存在。即使已经迭代过好多批人，这些业务知识和用例也会一直存在，只是随着产品的更新不停地在微调和迭代。

08 年毕业入坑到现在。毕业那年正好遇上雷曼暴雷，金融危机，当时整个班的同学就业情况都很差，迷茫了大半年才在当年的 10 月底误打误撞进了某家小公司，进了测试这一行。
今年身边的情况都很差，去年年底到今年年初，团队在广州和西安都缩减了不少人员，而且可怕的是有很多同事已经过了大半年都还没找到新的工作。

一大早被直击心灵。

我记得你之前是不是有发过一个类似的帖子，我好像还回复了。
这个 ID 会变的话你就别写死，用 contains(@resource-id, 'page') 来定位

看了下官方文档，就正常的 pytest 启动命令就可以了。可能难点是怎么准备环境，官方推荐是用 Docker

https://testerhome.com/articles/34758
之前做的总结

1. 基础的东西大家都做得差不多了，没什么新的可以分享
2. 社区的发帖评论的审核机制，一定程度上会打击发帖的积极性（老人不太习惯）

这个界面是 流利说 吗？我前两年也用过一段时间，挺好的。不过最锻炼人的，还是大胆说，特别是在工作中

这种情况，要么是这位同事短时间内得到很大的提升，要么就是给你们产品埋下很多坑。
我们最近也在做折叠屏的适配，本来开发想直接让我们测试去测一轮，发现问题开发再改，被我拒绝了：折叠屏不是一种全新的东西，开发应该先从 Android 的系统上面入手做调研，为了适配折叠屏，Android 官方文档会要求做什么，以及有什么特性需要去注意和测试。这些都需要 Android 开发的 lead 去 review 过之后，一起和测试过一遍，再交给测试去做对应的测试和适配计划。
你们这种直接交给一个开发去做，然后还出现了那么多 bug，这完全是没重视起来其中的影响和风险啊，建议尽快和领导汇报；而且抛开适配的特殊性，任何项目如果缺陷数量异常的高，而且还没有收敛的趋势，是一定要尽快上报的，说明存在非常高的质量风险。

第一种 diff image 的方案我们也在使用，主要是针对那些相对来说比较固定，以及包含各种图标或者图片，不容易判断元素是否存在错位情况或者颜色错误的页面，比如登录页，设置页等。
第二种场景，在某些元素因为某些特别奇怪的原因导致各种奇怪问题，比如 webview 页面元素突然无法识别，某些元素明明能定位到，但是点击却没有反应等问题，我们也尝试过这种这种方式去做。PS：这种用图片来定位元素的方式其实早在 qtp 时代就已经支持了。

iOS 17 都马上要更新了

匿名用户你好（错以为我已经屏蔽的匿名区又出来了）

请重点说说 2

Xdist 好像可以设置不同的 group，你查一下

用例的质量和作者的表达能力关系很大，碰到很多历史的用例，得花很长时间才知道到底是想测什么点和场景；而且本身对测试用例的产出就缺少一个质量把控的过程，很少有人会认真地去 review，也不会有什么 bug 被人发现出来。