这叫埋点测试还是埋点查询？

调用 JS 意味着放弃使用元素交互的方式来执行操作，也就是说万一哪天这个输入框真出 bug 了，自动化脚本也测不出来。

不错的分享，对没做过的团队很有启发作用。
吐槽下文档，实施细节的 1 到 10 点整理得有点乱，有点混淆分层跟流程。期待能看到分层，每一层再有其专门的实现流程。

结合历史发帖看挺有意思的。
第一个问题还要具体分析再判定，第二个不就是等价类、边界值吗？
如果随便点点就当通过了，那不如随便找个应届生把主流程走一遍，线上有没有问题全看开发对异常情况的兜底水平。
测试搞代码只是为了提高自己的效率，从不觉得写代码的一定比做业务的强。
作为团队真要追求代码，还不如从 it 培训班招个开发，何苦逼着测试卷。

简单说就是并不是所有的方法都能使用 fixture 作为参数。
具体的作用域 pytest 源码里的注释里有写，可以参考。
另外为什么还要有 setup_class 呢，都用 fixture 不就没这问题了。

感谢开源，虽然暂时用不上，但从演示来看，效果很棒。

公司在不同的发展阶段对质量的需求是不一样的。
只能说现在的环境对测试不太友好，但是如果你能与其他团队达成质量上的共识，定下最低质量标准并去推动它，最后伴随公司发展逐步提高对质量的要求就很厉害了。
如果测试 leader 也没什么话语权，就趁早走人吧。

首先我没用过图里的工具，从字面上获取到的信息是测试执行了 11 分钟多点，并发用户最大为 178，而设定目标是 1000。
大概率是加压策略的问题，用户数是可以直接计算出来的，性能再差，不妨碍我们继续加压，只不过很多用户可能无法得到响应而已。

这个问题换个角度想，如果"想知道这个怎么计算请求接口多少次 起始人数是 5 最多人数 10，每次持续 30 秒
那是不是每秒请求 5 次持续 30 秒，然后每秒请求 10 次持续 30 秒。计算公司 5*30+10*30=450 次"这里的思路是正确的，那是不是压力测试只要设计好就能知道 TPS 了，根本不用测
所以答案很简单，那算法只是你期望的最理想值，而实际结果跟服务器的性能相关，那也正是测试的意义所在。

随机这事可太折磨人了，这题也不知道原始出题人的思路是啥，到底想考察哪方面，建议大家不要使用这道题