我当时没有集成 iOS 的代码

我理解性能测试不应该以单个业务来设计， 而是去评估每个接口分别会有多少流量，然后按比例来构造。 比如 四个接口的流量比例分别是 1:2:2:3 类似这样。
具体的比例是多少，要么是看生产的数据统计，要么是根据业务模型去评估。

我们应该要感谢一直在 “卷”，还愿意免费分享出来的同行们

Pyechart 我以前用的是 0.5.5 ， 你看看能不能安装这个版本

看你的截图，失败的是 验证 的那个步骤，也就是断言失败了。
你可以点开旁边的截图看看具体是什么问题，有可能是你用错了关键字

这三百多评论里有一般是我的回复，哈哈

我了解到的，要么是直接前备份数据库里恢复（可能会有数据丢失），要么是从数据库的 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 直接对接了

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