我记得是要切换不同国家的 Apple ID 来切货币。
不过其实这是 Apple 的功能，我们一般能保证可以调起对应的 UI 和完成支付流程就可以了，不需要测试不同的货币（原则上 Apple 都是已经做好了的，要是有问题也是 Apple 的问题）

那继续更开心啊，都有机会和 CEO 直接对接了

我中午也收到了这个网站的邮件通知

M3 你自己安装有什么坑吗？一般来说不会有太大差别啊

既然你都走在潮流前沿率先用上 M3 了，是不是应该自己去搭一遍，然后把经验和坑都分享出来呢？

国产浏览器一般有两个模式，兼容模式（IE 内核）和极速模式（chromium）。
如果要通过自动化测试来覆盖，首先保证 chrome 吧，毕竟业界占有率过大半；有余力的，edge，Firefox 也可以跑一跑，selenium 和 playwright 都支持同一套代码在不同浏览器跑，花点时间改造一下 driver 的初始化配置可以选择不同浏览器就可以了；硬件上面可以支持的话，Safari 也可以跑一下； IE 太古老，而且官方已经不支持了，除非你们还有这么顽固的客户要照顾，建议别花时间在上面了。
至于国产浏览器， 我觉得 chrome 跑过了就行，都是一样的内核出问题的概率不大。
另外万一碰巧你们老板就用的国产浏览器，不妨打听一下，手工测一遍。要是你们测都没问题，刚好老板的浏览器上面出问题就悲剧了

一般发版都是挑对客户影响最小的时间，比如周末的晚上，然后需要提前规划好每一个步骤的时间，几点开始停服、部署、测试、恢复，以及万一遇到问题怎么回滚等等。甚至要提前给客户发提醒，估计什么时候进行维护。这些步骤都是需要评审、领导批准和严格遵守的，像你们这样随意更改时间，当作是一个深刻的教训吧

如果假定 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 就不一样，这种都是可以总结的.
我们的做法是除非这种和操作系统相关的差异，其他都要求和设计一致；如果有差别就让产品决定如何统一.