一般这种合作公司，都会有限制的，不难随便在不同的外包公司之间换来换去，也不能辞职之后马上入职为正式员工。不然外包员工的稳定性根本没办法保障，怎么长期合作呢

各位不妨换个角度看这个问题：假如你的房子在装修，你找了个包工头，包工头请了几个工人来你家干活。你老婆（家里的领导）和你说：

1. 别想着看哪个工人手艺好就和他说要挖过来单独给你干，包工头知道了得和你闹
2. 要是发现哪个工人干活不好，就赶紧和包工头说，让他换人

这样看是不是感觉没那么难听了？

先说明一下你的需求？ 是你的 app 里面集成了谷歌广告，显示给客户看，还是说在谷歌广告⬆️推广你的 app？

1. 开发是否有在 run book 里面说明要重启？ 如果没有，是没有识别出来这个步骤。
2. 如果 run book 里面明确写了这个步骤，是不是运维没严格执行？
3. 开发 lead 和运维 lead 背责，整个上线流程有问题。
4. 一定要挑测试的问题，或者从质量最后一关的责任人来看，是不是你们的测试流程有瑕疵，或者覆盖率不够，导致不能发现问题。 虽然主要责任不在测试上，还是有优化空间。

你看看其他几个 template ，哪个页面要改就改哪个 template

先了解一下具体是限制了哪些地区，说不定你用的 VPN 也不给访问呢

在 app/templates/uitest/test_case.html 文件，29 行这个 option 里面改成你要的名字，或者增加 option 就可以了

这是你们的回归测试策略， 一般是要做改动范围和影响分析， 有改动的，需要测哪些功能；没有改动的，做什么级别的回归测试；就算什么都没改，直接重新部署，也要做基本的冒烟测试。

我记得是要切换不同国家的 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 等。一定要保证不同版本之间不存在业务代码的差别，不然你永远测不完。