我了解到的，要么是直接前备份数据库里恢复（可能会有数据丢失），要么是从数据库的 log 里面找出来恢复。具体没做过。
PS 我们那个例子好像真的是物理删除，因为 DBA 说没办法恢复

看起来是你用的 selenium 版本兼容性问题。 你先试试本地直接跑 selenium 是不是能跑起来？ 就随便用 python 写个 selenium 的测试脚本，能调起浏览器和打开网页就基本上没问题了

不是把表给删了，而是删了表里的数据。 所以不管物理删除还是逻辑删除都可能发生吧，区别是操作一条数据还是操作多条数据？
对业务来说，就是数据不可用了

原始逻辑是真的一言难尽，我大概知道的信息是当这个 ID 包含非法字符的时候，被处理成了 null，然后删除的逻辑里面原本是根据 ID 来锁定要删除的记录，结果因为这个 null 就变成了全表删除…

逻辑删除也会造成业务影响，物理删除也能通过备份之类都手段恢复，所以这不是重点；重点是这个 API 的处理是有问题的

很多 bug 都不能用常理去推测的。 所以作为测试，我们要考虑的是全面的质量保障。 比如这个字段的验证，其实在不同的阶段都可以有办法去预防： 开发正确的使用字段长度的检查（或者使用对应的插件）、单元测试、接口测试、页面自动化测试，等等。
但是如果作为测试，我们都直接帮开发说： 这个没必要测接口，我是真的没办法认同。

我分享个例子： 我们最近在对某个删除的 API 有改动，然后开发用 postman 去验证这个改动的时候不小心传了一个非法的 product ID， 结果正好后台没验证处理这种情况，结果把整个表的数据都给删了… 幸好这是在测试环境发生的，要是在生产环境发生，后果不堪设想。

所以楼上说没必要的，祝你们不会遇到类似的问题

https://testerhome.com/articles/34758

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

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

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， 这样可以有效避免这种可接受范围内的变化造成的误报。 但也是要商量的，既然减少误报，也不能造成漏报，自己掌握平衡吧

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