如果假定 chrome 的同一个 49 的版本在不同操作系统上面都已经做好了兼容性测试，那么理论上在最主流的操作系统上面测试这这个版本就可以了。
我们目前的兼容性测试策略，是用挑选主要的自动化用例对主流的四大浏览器（chrome，edge，Firefox，Safari）的最新三个大版本加 beta 版本进行测试（比如 chrome 现在最新是 120，就是测 120，119，118，121 beta）。

正好我们也有做这个，讲讲我的理解：

1. 这个字体变化是符合需求的吗？ 一般来说这是经过设计的， 如果字体变了不是预期的那个，这应该是ｂｕｇ
2. 如果页面上有某些不确定的元素（比如时间的变化），你可以在做图片比对的时候调整你的阈值， 比如相似度从 100 降低到 98， 这样可以有效避免这种可接受范围内的变化造成的误报。 但也是要商量的，既然减少误报，也不能造成漏报，自己掌握平衡吧

问开发啊，这个是怎么生成的，用一样的方法去生成

那就把困难提给领导吧， 加能做自动化的人

这个事情已经是一个政治任务了：既然是投入了两个季度才完成的事情，那么肯定已经被汇报成为了团队的一个政绩。你觉得领导会轻易冒着让整个团队被质疑和笑话的风险，把这个事情完全给否定掉吗？

所以最好的方式，还是顺着领导的思路，把遇到的不稳定问题好好研究，分析和解决，在已经实现自动化这个 1.0 版本基础上，跟进一步进化成为 2.0

另外如果自动化不能做到每日构建，把维护用例的工作拆散到每一天，让用例长期维持在一个相对稳定的状态，那么到真正发版前才来期望它会有一个好的结果，是不实际的

任务完成之后不释放吗？

鸿蒙找专职的， 小米澎拜要不要加一个？ 以后 OPPO vivo 也自研呢， 要不要继续加？
我那天在深圳参加测试大会的时候和 open harmony 的人聊了一下这个话题： 我们做测试怎么考虑以后的兼容性开发和测试？ 大概了解的情况就是： 在得到广大开发者支持之前， 鸿蒙还是会继续兼容 Android， 不可能抛弃这个成熟的生态自己从头建一个全新的；对于测试来说，鸿蒙就是 Android 测试的其中一个分支， 除非你们的应用正式咬研发鸿蒙的版本，否则就是一个特别设备的兼容性测试。

说不定是阿里云的锅呢？

支持 PPT 下载吗？ 有些 topic 很想和团队分享

不同银行有不同的选择吧， 像我们的话只要是经过审核的开源工具都可以用，也能做二次开发

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

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

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

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

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

https://testerhome.com/topics/36226

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

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

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

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

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

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

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

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

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

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