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

调用 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 了，根本不用测
所以答案很简单，那算法只是你期望的最理想值，而实际结果跟服务器的性能相关，那也正是测试的意义所在。

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

绕了一会才想明白，原来是只能生成 0 和 1 这两个值，所以就不能用类似 random.random() 的方法去获取一个 0 与 1 之间的小数。目前想到的解法也就是累加和 2 进制了，蹲个更好的答案。

测试讲究的是指定的输入得到预期的输出，那接口测试怎么验证实际结果就是预期的呢？
所谓去数据库捞数据校验并不是有没有必要的问题，而是比较省事的做法，而且这只适用于开发告诉你测试的 api 一定能在数据库中产生或修改一条记录的场景。
拿注册用户为例，接口返回注册成功了并不能保证接口一定没有问题，你得调用登录接口验证，那谁能保证登录接口又是好的，还不是数据库里查比较方便么。
按这个思路，我们只要查不出记录就说明接口有问题，具体原因可以再排查，就算是数据库产品的自身问题也不影响被测接口不可用这个事实。

有很多酷炫的 chrome 插件，其中有个叫 chropath，支持 web 页面的元素录制功能，可能不能完全满足需求。
如果自己会点 js,或者找个会 js 的帮忙改改源码，就都能搞定了
app 同样可以自己改 uiautomator，只不过是 java 的
如果你用 airtest，那就更简单，直接把页面上所有带有 text 属性的元素 dump 下来。
但话说回来，这种做法看似高效，实际意义并不大，元素定位并不是自动化测试的痛点

我们现在的方法是有自测用例，范围是正向业务流程，且通过开发及产品评审
每轮迭代自测用例 100% 通过的才接受提测
自测通过的用例被测试按同样的步骤、数据执行时发现有 bug 则打回该轮提测申请，要求开发修复后重新自测
定期统计测试打回次数

对 airtest 很有好感，工作中也一直在用。
希望能看到新的优秀技术或思路，而不是历史倒退啊。

本来想吐槽的，发现都被吐槽完了

上家公司的产品就叫项目管理系统跟 OA 系统这两名字么

就不限于的那几条，哪里有难点呢？
1、响应时间相关的工具会给
2、单次操作存在冗余请求，抓个包挨个看就行，那有没有什么请求是重复了或者当前操作并不需要的。
3、死锁，资源等待无非是先看资源有没有异常，出现异常增长了再去查日志，deadlock 写的明明白白，不可能不认识。线程的常见状态也就几种，思路一般是先看卡在哪了，在看当前的场景卡在这合理不合理，什么请求导致线程卡在这了。
4、内存泄露、内存溢出，看 JVM，看日志
发现问题后该怎么解决还是找开发吧，想直接调优没积累不行的。
上面说的这些需要具备的基础能力是读日志，不能看见一堆英文就想逃。
再就是找一些别人分析性能的文章学习学习，套路摸透了就不难了。

上面也说得比较中肯，写得不算好，但这个现象很常见。
就我个人而言，大部分招聘场景是想找个能踏踏实实干活的人，但人家大厂么总得体现出一些区分度吧，也就是所谓的面试造火箭。
简历能起到敲门砖的作用就 OK，弄得太华丽会提高别人对你的期望，落差过大就直接没戏了。
对外包不是偏见，而是外包的用人方式决定了一个人很难在工作中得到成长，首先自己得努力，但得有环境有资源支持你去努力。

https://www.cnblogs.com/poloyy/p/12694861.html

想想小马过河的故事，如果目标是一线大厂，这样的简历肯定是不够看的。
原因前面也说了，找不到亮点，只能说无错，而大厂总是挑剔的。
正常求职的话，没什么毛病，至少能进入面试环节。
但简历毕竟只是敲门砖，包装得跟上自己的实力才行。

别听 2 楼的，三年能把简历里的东西都做好已经很不错了。
就怕写得多，一问就卡壳。
比如为什么用 robotframework,有什么优势以及不足，如果让你改进，有什么建议？
monkey 测试如果想设置黑白名单，有什么办法？
测试环境怎么维护的？

不如贴个 excel 示例上来？看着是很实际的问题了，光靠嘴皮子不太好说清楚。

是个好问题，要不给 jetbrains 提个 issue?
前提得是正版用户啊。

解决问题可以考虑不要在一个 scope 为 function 的 fixture 里做初始化设备的动作。
调 BUG 得看下具体的测试项目，auto_setup 方法里使用了 “file” 魔法变量，要基于它产生日志文件，有可能是这里导致的问题。