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 的,你参照下这篇?
时机上接近,但场景上不一样。
监听器更多是类似 AOP ,方便各种框架获取测试运行时相关数据以及有需要时改变运行结果,一般只有框架开发人员用。
而 beforexx 这些注解更多是用于测试运行时减少代码重复用,拿不到太多测试运行时数据(比如上一个用例的执行结果、用例名等),一般是写自动化测试的人员用。
终于抽空看完了,点个赞。
这块确实是个盲点,现在大部分都是集群部署,甚至跨机房部署。一些中间件的网络一旦出问题,如果没设计好对应的处理方案,很容易引发数据不一致。但这块很多时候并不会作为功能需求由产品明确提出,所以很容易被忽略。
感谢。
也就偶尔等编译或者发布的时候瞄一下社区,能回答尽量回答。
不明觉厉。
话说怎么结论看起来不像是测试结论,是这种量化交易的测试结论就是这样子的么?
额,建议你弄个带 GUI 界面的 linux 系统吧。
浏览器有专门的无头浏览器用,但没有 GUI 的前提下装 android 模拟器还没怎么见过。而且没有 GUI ,你怎么确认模拟器是否正常启动和可以正常使用呢?
另外,建议你花时间折腾模拟器前,先看看我前面回复的,模拟器测试结果的可借鉴性是很差的,你先确认是否可接受再继续弄吧。大部分公司,是从测试机里面挑几台长期插到自动化服务器上运行自动化的,大点的公司还会专门弄云真机平台做统一管控,用模拟器作为主力的比较少见。
没在 linux 下弄过 android 模拟器,所以没什么可以推荐的。
mac 的话用过 genymotion ,还不错,但 linux 怎样不清楚。
可以看看《海盗派测试》,会有点难懂,但也是一种新的思维方式
有的人写的用例出 bug 的效率低,有的人写的用例出 bug 的效率高
这个倒是建议你们可以内部交流下。个人建议是不能直接用出 bug 效率评估的,也得综合看 bug 的严重程度,有些非常偏僻的路径出的 bug ,优先级并不高。
报错的不是你截图这个代码文件,是另一个 test.py 文件。报错原因是在那段代码里, AppiumBy 是个 None 类型数据(类似其他语言的 null ),所以没有任何子属性和子方法可供调用。
你确认下那段代码的 driver 是不是真的有 AppiumBy 这个子属性?driver 会不会引用错了,用了 selenium 的而不是 appium 的?
如果想统计,提几个建议:
1、用专业问卷来收集,而不是让大家自己想办法遵守你的格式
2、通过匿名方式收集,而不是让大家用真实账号回帖
3、这种数据建议找几个关系比较不错的同行哥们去私聊问吧。你这里的外网 bug 在我看来像是线上故障数相关指标,这种数据还是比较敏感的(毕竟谁会对外说自己负责的业务线上故障率高,揭自己的短?)。怎么规避才相对不那么敏感。
linux 下安装 android 模拟器,我试了下,用 linux android 模拟器
能找到很多资料呀。所以为啥卡住?