其实说下来还是流程不清晰：
混淆版，开发版和正式版的区别： 这几个版本之间除了配置不一样， 还存在什么不同？ 你要和开发坐下来去聊， 把最重要的测试放在开发版，改 bug，重测，回归这些都按流程去走。 当开发版认为已经没问题了， 再出混淆版和正式版， 然后走个冒烟测试，以及重点关注配置的验证，比如商品配置，是否关闭 debug 等。一定要保证不同版本之间不存在业务代码的差别，不然你永远测不完。

我理解这种崩溃都是没做好异常处理， 所以可以多往这方面尝试， 比如输入异常字符啦，重复点击某些按钮啦， 快速切换啦， 之类的
但另一方面要让开发研究 rootcause， 为什么会崩溃， 举一反三看什么地方得补

那必须不能让它那么顺利上线了

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

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

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
之前做的总结