写个 for 循环，然后返回第一个找到的元素，没找到就继续循环；然后根据找到的元素判断你要做什么

另外再说一句：对于测试来说，我们的责任是质量把控，所以能不能按时交付，不归我们管，我们关心的是质量能不能达标。当然了作为团队的一分子，我们也要对交付时间做贡献，保障测试效率，按计划内时间完成测试；遇到开发延误的情况下，大部分情况下还是要尽力去配合赶上进度。 但原则还是质量标准不能降低。

所有的决定都应该是遵循大家都同意的规则去判断的。比如发版前是否还有哪个等级以上的缺陷，剩余的缺陷是否拿到业务的同意，可以接受这些缺陷在以后再修复。
如果目标是按时发版，那就以达到发版目标去提前规划，以及每天的日报里面把这些写出来：改修复的赶紧修复，不能修复的赶紧找业务商量，拿他们的背书。如果最后还是有严重的缺陷没办法处理完，业务也不同意上线，那就别上了呗，反正测试我就不松口，谁要违反流程去上，那就是谁的锅。

所以最根本的，还是要把相关负责人拉到一起，把这个游戏规则讲明白；统一规则之下，谁违反谁的锅。测试不能轻易降低自己的标准，这样也不会轻易被甩锅给测试。

要看自动化替代的是哪部分测试， 如果你是手工测试接口，那做成自动化就能替代这部分的手工； UI 的自动化对应就是替代页面的手工点点点。

可以用 sys argv 来传递

1. 接口测试只是分层测试的其中一环，整体的测试策略起码要在 UI 上多做一层 UI 自动化或者手工测试作为补充。
2. 要从流程上去分析，为什么前端改了代码而没测试到的原因是什么。 如果这个改动完全没有遵守流程（不在需求里面，没有提测给测试），那就是开发流程的问题，要去补充强化流程； 如果是开发已经提测了，但是测试以为跑个接口测试就能覆盖，那就是测试策略的错误，需要去强化测试设计和加强测试用例评审流程； 如果开发也是无意中带出来的改动，或者因为代码部署错误，把没提测的东西带上去了，就需要去强化你们的回归测试策略，不管有没有前端的改动，该做的回归测试都要做，并且基于这个去设计你们的自动化测试（包括 UI 和接口）

用 allure， 每个 log 都记录到 case level？

楼上的朋友们，这个项目我已经五年没维护了，所以你们如果遇到问题请尽量自己尝试解决和二次开发，恕我现在没办法帮到你们。 所以请慎重选择这个项目哈，抱歉！

首先一个原则，我们是不可能覆盖市场上所有的机型和操作系统版本组合的。
建议你整理成一个兼容性测试的方案给领导去 review：

1. 目标是要覆盖市场上多少比例的机型和操作系统？
2. 要达到这个比例，需要购买多少测试机？ 是否考虑使用付费云测平台？
3. 有了测试机和云测平台之后，你们的兼容性测试方案怎么和现在的回归测试策略结合起来？ 需要投入多少人力去执行？
4. 是否考虑用自动化测试来做兼容性测试？
5. 新机型怎么定期购买？
6. 新的操作系统版本怎么定期投入研究和兼容性测试，避免新版本发布之后对线上客户的影响？

然后呢，有多少钱干多少活； 出了问题，这是已知的风险， 因为没投钱啊

想起了脱口秀大会里小鹿讲过的一个段子： 你这个个人经验主要是太个人

检查一下是不是配置的地址是 localhost，导致不在那天机器上就访问不了（看你的截图）

我当时没有集成 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