大佬在工作如此繁忙的情况下，还能不断重构，真是我辈楷模！

不知道你说的老徐是不是我关注的老徐？

先点赞，后观看！

建了个 QQ 群，欢迎大家加入：799426282

net error -200，是这个错误。

这个配置可行吗？

几个 URL 连在一起了，不能直接点。

8

欢迎加入武汉测试社区

它这个也是通过循环去判断的，只是封装了，使用的时候看不到而已。

我也看了。。。

performance.getEntries 这个可以获取到所有异步请求的性能信息，但是说到底还是接口的性能。我个人理解这个还不是真正的前端的性能，前端的性能应该还会受到其它和后端无关因素的影响，比如 DOM 的一系列操作流程（我也不是很熟）。比如前端的一些 JS 逻辑操作，这个都是在接口性能上无法体现的。

performance.timing 这个在使用的时候还是不准确。 特别是当页面中有异步请求的内容时，这个就不是很准确。
话说我们以前做这个方面的性能的时候，是通过在代码中的关键位置埋点打日志，然后计算时间的。

当然，这么长时间来，我也很少看到有专门去测试前端页面的性能的，一般的性能测试都只考虑后端（接口），
网上也很少有相关的知识。

现在在用 Katalon, 模式和这个差不多。

1. 控件定位支持参数化。
2. 基于控件的操作封装。 --支持参数化
3. 基于基础操作的常见逻辑封装组合。 --支持参数化
4. 基于 2 和 3 的组合形成用例。（加一些参数）。
5. 另外通过提供的关键字接口封装所谓的常用工具类方法。

在武汉给老乡发来一个赞！

极客时间的《软件测试 52 讲》，作者:茹炳晟.
记得好像作者也在论坛里。

武汉的小伙伴表示没有听说过有沙龙活动。。。

这种小工具的改进，挺有用的，赞！

Celery 这个可以不？

1. 对于幂等性，我个人人认为面试官是在说你的这个测试脚本不符合幂等性。你的用例每次运行的结果就应该是一样的，多次运行结果都是一样。而你说的测试方法是运行两次，而结果却不一样，这个是不符合幂等的。
2. 结合说的幂等性，我觉得用例应该考虑到自己准备测试数据，运行测试，进行验证，然后进行数据清理，这样就能做到幂等性。
3. 回到说的这个唯一字段的测试，那么结合 2 中说到的这种方法，那么就应该是先自己造一个数据（模拟系统中已有这个数据），那么再次使用接口发送同样的数据，这个时候接口应该返回数据重复的提示，包含一些错误码等等，用例进行验证，最后再清除掉先前造的数据。 以上这个用例就符合幂等性，无论运行多少次，结果都是一样的。

个人意见，仅供参考！

一、接口功能测试。我觉得接口层的功能测试主要是去覆盖到一些前端不能触发的场景，测功能的同事可以重心放在验证客户端可触发的测试场景。举个例子，一个购买接口，功能测试同事测试点都是能从客户端触发的，余额足的时候购买余额不足的时候购买...接口测试同事可以验证修改商品 id 成已购买的 id、修改 id 成特殊符号...

以前觉得接口测试可以无限覆盖各种场景，但是后来发现业务不可能触发的场景，测试了没太大意义。 因为从用户角度出发，永远不可能用到这个场景，这些测试就是浪费。 ----个人建议。

不管是在 setup 和 teardown 里面做这些事情，都会遇到你说的并发的问题。个人觉得现在有两种方案：

1. 简单粗暴一点的： 对于 case 强制分类，数据会影响的放到一组。 不影响的放到另外一组，所以在并发的时候，多组之间的用例是不会相互影响的。
2. 高级一点的：在每个用例运行的时候，初始化自己的数据库，如 H2, 这样所有的用例都是有自己的数据库（运行完毕后释放即可），就不会相互影响了。