这个问题就像去马路上随便找个陌生人问你自己的钱都藏在哪里一样，完全不了解你们公司的人怎么可能知道答案？
直接问你公司的同事不就知道了吗？

方案更多的是这个项目有什么影响和改动，对应的要测什么和怎么测； 而计划是你怎么安排资源和排期把这些都做完。

https://testerhome.com/topics/36226

上次在小红书也看到了类似的商品， 不是特例

这说明凭 “感觉” 去测试是有问题的
其实多端测试和兼容性测试很类似，绝大部分功能在不同的浏览器，设备上期待结果都是一样的，多端测试也是一样。我们应该以需求和用例作为标准去执行测试和判断结果是否符合预期，而 “感觉” 这个东西应该帮你去怀疑这个结果是不是缺陷，然后通过需求，讨论等流程去验证你的怀疑，而不是通过 “感觉” 来把一个不符合预期的结果变成一个合理的需求。

楼主的需求就是要部署到 Jenkins 啊， 来怼我很有意思吗？
而且谁和你说流水线就只是研发用的， 自动化测试集成到 C I 里面不都已经是普遍的做法？ 都有现成的 Jenkins 不用， 难道自己把定时触发，拉取最新代码，执行，邮件通知这些都重新写一套？

如果是同一个产品，相同的设计，在不同端唯一的差别就是操作系统的风格不一样. 比如日历控件在 iOS 和 Android 就不一样，这种都是可以总结的.
我们的做法是除非这种和操作系统相关的差异，其他都要求和设计一致；如果有差别就让产品决定如何统一.

要对设备管理有对应的策略啊，多少台应该升级，多少台保持在旧版本，不能说一股脑都升到最新版本，旧版本就不理了.
像 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，这完全是没重视起来其中的影响和风险啊，建议尽快和领导汇报；而且抛开适配的特殊性，任何项目如果缺陷数量异常的高，而且还没有收敛的趋势，是一定要尽快上报的，说明存在非常高的质量风险。