fastbot 官方好像有交流群的，你到项目主页看看？

另外，如果是想在社区寻求帮助，除了一个报错信息，建议附上更详细的操作信息以及 fastbot 版本号等信息，像报 bug 一样完整阐述你的问题吧。

光一个报错信息，除了肚子里货非常多的搜索引擎，作为个人实在很难解答。

没太明白你想表达什么，如果是想协助解决问题，可以把你具体的操作步骤、报错信息等附上来？

这个可能会有比较多难点。

1、在控件内容（比如原来定位的 id）变了的情况下，怎么判断新的元素是用于替换旧元素的？这个我没想到什么比较固定的准则，实际项目里基本也是需要结合需求判断，有些不确定的需要找开发二次确认的。

2、如果不只是改控件，而是连布局、交互都改了呢？这种情况下可能不存在原来的控件改成了什么新控件这种一对一关系，需要改动的其实不只是定位元素，甚至用例逻辑都得改。这时候可能需要的是会自动生成用例，而不仅仅是维护用例的工具了，现阶段除了智能遍历类外，暂时没见到这方面有比较成熟通用的工具。

所以，如果界面元素持续变动很大的话，建议取消做 UI 自动化，或者考虑用录制之类的更便捷的方式生成用例。

偶现性问题的复现，我理解最有效的方式是：多试。

然后试了之后，不要只记录步骤（因为相同的步骤不一定能复现），还需要记录现场的所有相关信息，包括相关日志、内存 dump 信息等。

两个都需要。

OK

这个是你额外引入的吗？我印象中我项目没有用到 Vue.locale = () => {} 这个。

从用例上看，挺清晰的。提个小疑问，websocket 建立连接后，一般主要传送的应该是 message 内容，但我看到用例里每个都有 url 参数，这里的 url 实际对应的是 websocket 里传输过程中的什么内容？

欢迎加入~

话说，你的用户名是不是当时注册时设置有问题？我看到末尾带了一个挺长的 url ，有点奇怪。
如果是注册时没设置好，可以在右上角的个人头像点击->个人资料设置->姓名 里进行调整。

1.如何做一位合格优秀的业务测试？
——没太明白这里问的是合格还是优秀？个人理解优秀的业务测试，应该对业务和背后系统的熟悉程度，可以达到快速看出需求、技术方案里存在的问题以及怎么调整会更佳，并且这些意见能得到大家认可的。

2.业务测试在一线城市有封顶薪资吗？
——封不封顶，取决于公司。理论上没有封顶，但能拿到高薪资难度会比较大，机会也相对少。

3.业务测试如何去发展自身的特长，也就是职业发展？
——我觉得技术应该是测试岗的基础技能，但不一定非得变成自己的特长（技术真的是自己特长的，我估计大多都去做测开甚至开发了吧）。每个人的特长不一样（有的可能善于协调沟通，有的可能善于发现缺陷），根据自己的情况，找到自己在匹配职业发展方面的特长，并持续去发挥和发展自己的特长，让其变得比团队里大部分小伙伴更突出就好。

4.如何让技术循循渐进的进步？
——个人觉得 2 个点很重要：
a. 重复的东西聪明做，比如第二次做要比第一次更快更好，同时做好文字记录（很多时候第二次可能离第一次，时间上已经很远了，脑子回想起第一次怎么做已经很难了）。
b. 遇到技术问题（包括但不限于被测物的缺陷、线上的故障、自己写的代码等）多寻根问底。解决只是暂时的终点，在解决的基础上了解清楚原因以及为何这个方式可以解决、是否有更佳的解决方案，才能让你记忆更深刻，下次变成预防而非只是解决。

能否建个 Issue ，把详细操作步骤、运行环境都发下？

我刚拉仓库最新代码跑了下，也进入编辑模式试了下加标签，都很正常，console 里没有任何 error 日志。

get，从报错上看，可能和你本身的脑图数据有关。

可以在 https://github.com/chenhengjie123/vue-testcase-minder-editor/issues 上单独提一个 issue ，并附上你的操作步骤、 xmind json 数据么？方便的话，能把一个能复现这个问题的最小项目直接提供过来最好，能复现才能有办法获取到更多的信息，有助于解决问题。

大招呀，更新了这么多功能，点赞！

1、大部分场景下，500 用户!=500 线程数，因为真实的用户并不是像压测工具那样，一个接着一个发请求过来的。可以看看这篇文章：https://developer.aliyun.com/article/709950

2、服务器不放云上，用的就不是云厂商带宽。不过你这段话没看懂，那 nginx 到甲方走的是内网还是公网？

3、要不要压前端页面，取决于你前端页面是不是也走得这个链路给到甲方的，不过大部分情况下前端浏览器自己会缓存资源（js、css 等），所以前端资源除了首次加载外，其他大部分时间不怎么消耗带宽，一般不用特别去评估。
另外，既然用的不是云厂商，那你问清楚甲方需要配置的是出口带宽还是入口带宽，还是两个都要。nginx 发给客户端的只是出口带宽，如果你的业务上传类操作占比比较多，入口带宽可能也要考虑下。

4、PS 部分，你的换算本身没错，只是你的单位写错了，你正文的单位转换后写的是 300MB/s ，这里的 B 看起来是字节，而非比特。

一般 10-30 左右。

增大压力（线程组数量）后，TPS 不再上升，只有 RT 增加，说明达到处理能力的瓶颈了。

1、我用 Stepping Thread Group 多一些，jmeter 自带的那个很少用。

2、线程数一般就自己定，这个属于执行层面的东西，只要线程数能发出足够的压力达到性能瓶颈即可，具体数量一般不纠结。tps 和 qps 我们这边不怎么区分（大部分情况下两个值差异不大），不过性能标准我们是 tps + rt（响应时间），具体值要达到多少这个，会先由性能测试负责人基于产品/开发提出的高压力场景进行分析转换，然后再项目组一起沟通确认转换过程是否合理，进而定下最终的目标值

3、这个要看压测机配置，没有很固定的数量。

4、我们运维用 grafana（服务器监控这些直接用运维提供的工具）

5、录制用得比较少，因为很多时候都需要多账号做参数化。

一般会讨论带宽，说的是公网出网带宽，即数据从你的服务出来，传递到用户的这个部分，因为这个部分机房/云厂商是要找运营商花钱买的。同机房内部服务间交互，不属于公网，一般都默认直接给万兆带宽（反正不额外花钱）。

可以参考腾讯云的： https://cloud.tencent.com/document/product/213/12523

另外，甲方给的需求从性能需求角度，还是不够清晰，建议有几个点你需要确认下：

1、500 用户是指 500 人同时在线，还是 500 个请求同时进来（TPS 500）？如果只是同时在线，那还得做转换，在线状态本身不消耗带宽（除非有心跳包啥的）
2、这里说的带宽，是不是云厂商给的带宽？
3、业务场景里，请求大资源（如图片、音视频、下载文件等）的场景多么？一般纯文字都不怎么占用带宽，都是大文件才会比较占用，所以评估带宽的大头是评估这部分资源的带宽消耗。

至于要不要监控数据库服务器的速率，取决于和数据库服务器交互的部分是否也属于甲方说的带宽评估范围内。

PS：第二点里你换算后的单位不大对。要乘以 8 这个是因为 1 byte = 8 bit ，所以 1MB/s = 8MBps（Bps = bit/s），你这里换算后单位应该是 390.8 MBps 。

从截图看，生产环境走的是 https ，所以你只抓到了握手的请求，过程请求都抓不到。

这种情况下，要抓生产环境的请求，网上搜下怎么抓 https 包吧，一般两种方法。一种是抓包工具生成自己的 https 证书，并给手机系统里配置信任这个自定义证书（前提是 app 内部没有额外校验逻辑，安全性要求高的 app 内部会直接硬编码自家证书的校验逻辑，不是自家证书的都认为网络不安全不发起请求），另一种是找运维拿到线上 https 证书私钥，配置到抓包工具里。

PS：这个问服务端开发是不会知道的，因为这部分的核心逻辑在客户端

这个问题感觉有点直接，可以先分享下你自己的想法，抛砖引玉么？

repeater-console 的，你参照下这篇？

http://testerhome.com/topics/27344

时机上接近，但场景上不一样。

监听器更多是类似 AOP ，方便各种框架获取测试运行时相关数据以及有需要时改变运行结果，一般只有框架开发人员用。
而 beforexx 这些注解更多是用于测试运行时减少代码重复用，拿不到太多测试运行时数据（比如上一个用例的执行结果、用例名等），一般是写自动化测试的人员用。

终于抽空看完了，点个赞。

这块确实是个盲点，现在大部分都是集群部署，甚至跨机房部署。一些中间件的网络一旦出问题，如果没设计好对应的处理方案，很容易引发数据不一致。但这块很多时候并不会作为功能需求由产品明确提出，所以很容易被忽略。

感谢。

也就偶尔等编译或者发布的时候瞄一下社区，能回答尽量回答。

不明觉厉。

话说怎么结论看起来不像是测试结论，是这种量化交易的测试结论就是这样子的么？

额，建议你弄个带 GUI 界面的 linux 系统吧。

浏览器有专门的无头浏览器用，但没有 GUI 的前提下装 android 模拟器还没怎么见过。而且没有 GUI ，你怎么确认模拟器是否正常启动和可以正常使用呢？

另外，建议你花时间折腾模拟器前，先看看我前面回复的，模拟器测试结果的可借鉴性是很差的，你先确认是否可接受再继续弄吧。大部分公司，是从测试机里面挑几台长期插到自动化服务器上运行自动化的，大点的公司还会专门弄云真机平台做统一管控，用模拟器作为主力的比较少见。