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

公司在不同的发展阶段对质量的需求是不一样的。
只能说现在的环境对测试不太友好，但是如果你能与其他团队达成质量上的共识，定下最低质量标准并去推动它，最后伴随公司发展逐步提高对质量的要求就很厉害了。
如果测试 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 很有好感，工作中也一直在用。
希望能看到新的优秀技术或思路，而不是历史倒退啊。