能否建个 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 模拟器
能找到很多资料呀。所以为啥卡住?
测开我理解有两类,一类是业务测开,一类是平台测开
业务测开应该和你现在做的差不多,业务为主,过程中涉及部分技术类工具的使用和少量的脚本/二次开发,主要需要的技能是业务测试 + 各种技术工具的使用(包括自动化)+ 脚本开发能力(比如 shell 、python )。这类其实在很多公司也直接叫业务测试,相当于把业务测试的要求提高了。
平台测开则偏开发多一些,接触业务相对少一些。相比质量保障,更偏向于做效能提升。做的事情主要是公司统一的测试工具/平台开发,比如开发自动化平台、自动化测试框架、性能测试平台等,有时候还会跨界做 DevOps 平台之类的。技能一般要求是有一定的平台/工具开发经验(比如 Web 平台前后端开发、自动化框架设计开发等)
这里面其实没有绝对的分界线,更多看公司自己对测开岗位的定义和理解。据我所知,运维也有类似的运维开发岗位,专门开发一些自助上线相关的工具平台,提高自己的效能。
有几个点和我的认知有些差异,一起探讨下:
中台是作为一个数据存储并提供所需数据的地方吧,就是有多源数据经过大数据的清洗处理后存放的地方,个人简单理解就是作为一个多源数据的存储仓库。
这个我理解就是数据仓库,不是中台。因为听起来基本没有业务逻辑在里面,只是单纯数据存储和获取。
在中台进行算法,前端只负责显示,这个毫无疑问速度是最为流畅的。
我理解这里的前端和题目里的前台应该不是同一个东西?一般说 中台、前台 ,里面的前台指的还是服务端里的一些服务,而不是前端。
2.双 11 做一个抽奖活动的功能。①抽奖核心抽奖算法功能在前台做,中台负责相关数据存储。 ②前台只做数据展示,中台负责核心抽奖算法。
①:以上两种各有什么缺点
②:如果是你,你该如何设计
这道题尝试回答下。仅个人观点,欢迎拍砖:
①:以上两种各有什么缺点
大前提:因为这里没明确前台中台的定义,我先按比较常见的 “大中台,小前台” 概念来,即前台=整体服务端架构中接近业务应用的部分,典型的如 app 直接对接的 app 服务端;中台=整体业务架构中各业务共用比较多的部分,典型的如交易系统、支付系统,中台内部通过租户等方式进行各业务数据隔离同时,服务共用。
优点:题目有提到双 11,意味着会有高并发。放在前台做的话可以让抽奖算法这块的压力由前台去抗,降低中台的压力。
缺点:通用性比较弱一些,比如这套算法如果别的业务也要用,得自己另行开发 + 测试,形成重复建设。
优点:前台很简单,只需要做一些参数转换就可以。别的业务要用这个抽奖算法也可以快速接入。
缺点:中台处理压力很大,而且由于中台一般是多业务共用,压力过大会影响性能,进而影响别的同样用这个中台的业务
②:如果是你,你该如何设计
如果团队人足够多,可以多维护一个服务的话,单独拆一个活动服务放到中台部分,内置抽奖算法相关逻辑,并进行独立部署方便按需扩容。否则直接用前台做,先保障抗住压力。
@ZhouYixun 看下?