• 可以的,我查了一下 response 里面还有个 request 用来查发送的内容,把 request 调用起来就行了。

  • 绿盟?很多银行机构都是找的这个第三方

  • 不懂就问,d = {k: v.replace("$", "2") for k, v in d.items()},中{k:v}这个写法为什么可以这样,难道这样写法不是代表一个字典吗,后面的 for k,v 是把字典的 key value 代入到 k,v 但怎么有会让每个 key value 一次一次去找到对应的 $ 呢

  • 你这个是压力测试的一个小部分环节,压力测试重点应该放在调研方面,如测试方案,准出标准,性能测试场景,脚本调试,数据分析,问题定位,优化方面等

  • 自动化不是应该追求低耦合性吗,如果是联调测试那就按联调测试去考虑用例

  • 学历卡得死死的~😂

  • 测试用例编写规范 at 2022年06月28日

    我感觉这个太偏向理论点了,在编写用例的时候,实际情况是针对需求来进行,而上面的这些理论如果按一个功能点来考虑,那编写的工作量太大,且很难维护。

  • 刚看到你们公司因为投资理财暴雷了~

  • 好家伙,那么强吗

  • 1、nginx 的日志是看 access.log,这个日志吗;我对 nginx 是比较陌生~,可以确定的是 nginx 的分发是没什么问题的,但在场景四是不是按设置的权重可能是看看这个 access.log 日志,但这个日志是如何可以看出权重是不是一致,我得查查资料了。
    2、我去到对应的 nmon 查看了对应的时间段,可以肯定就是一个 tomcat 服务器低,另外的一个 tomcat 服务器就会高。
    3、这个我估计没吧,我去问问开发,我们公司在设计方面应该是不会用到这些高级的东西~,还有这个业务场景其实就是查询类,前面几个场景也是查询类。所以我推测大概率不能存在这些分布式锁的设计(这个我还是确定一下再答复)
    4、我在正文补充了一些细节和图形,其他细节你想知道的我再补充。

  • 我也考虑过这个问题,看过一篇文章是说 nginx 的权重分配策略是根据连接数还是请求数进去分配,如果 tomcat1 有对应的连接数/请求数不处于空闲状态就不会继续分发请求到 tomcat1。

  • 我是觉得 nginx 是没有问题的,看前三个场景,两台服务器受到的压力都差异不大,说明 nginx 是在有生效的。

  • 已补充手机号码信息,进行回复测试

  • 一个性能问题咨询 at 2022年06月15日

    建议可以监控对应的前端应用服务器(nginx 或者对应的应用服务器),然后把首页的资源都采集下来,当成一个事务,看看对应的并发数产生的最大带宽是多少,然后把公司对应的服务带宽作比较,得出是否满足。(PS:做性能测试个人认为还是需要一个明确的准出标准,比如 10000 用户需要多久时间可以满足,多少的带宽在多少的时间能够准出等)

  • 夏日打卡冲冲冲,马克杯我来了。

  • 各有优点吧,基准的 ramp up 不能达到某个线程进行持续,而梯级的可以保持持续时间,找拐点和分析都是比较合适的

  • 1、说点真实的一些事情吧,其实我们这些测试虽然深入不了这个性能测试,但是还是知道工具的线程数和真实的并发不能相等。真实情况往往是测试人员对接的是甲方的一些非技术人员,他们也不会理线程数是不是就是并发数~,实际情况就是很多人都是为了出一份报告给到领导或者需要这样一份报告,但是他们又不会很专业的来进行对性能测试深入。大概就是我们按他们的要求和想法进行一次 “性能测试”,给出的结果能让他们认为是正确的就行了。
    2、其实这个项目是这样的,我们的服务器都是在内网,然后这个系统是一个 APP,客户端通过外网访问,我们就利用 nginx 做一个代理,客户端外网访问--》我们公司外网地址--》nginx--》--》应用服务器
    3、一般都是入口带宽,上传类操作基本为 0 呢
    PS:其实自己也想做得更专业~但现实是甲方的人员也只是想糊弄过去让项目能正式上线。

  • 你也有使用这个平台吗,我实在找不到这个平台可以在那里单独维护元素😂

  • 我觉得也挺那个的吧,假设我现在的场景就是你说的复制每一条用例进行维护,如果我写了 10 条用例,然后前端修改了某个登录元素位置,那我就要把 10 条用例的这个登录元素位置都修改一遍...

  • 不是这样呢,同样的操作就可以用数据驱动,这也是自动化的一个核心思路啊

  • 1、500 用户指的就是 500 线程数,不是在线人数或者 TPS 是 500, 甲方想要的就是 500 个线程数并发一段时间内,在这段时间产生的平均带宽是多少。
    2、服务器不放在云(例如:阿里云)上也是云厂商的带宽吗?服务器放在内网,然后是通过 internet(网线,宽带?反正服务器是在内网)进行接收发送数据。
    3、有道理啊,那按这个业务场景,我是不是考虑压的是前端页面 + 后台接口产生的流量情况?(因为后台的接口全是返回的是字符串数据格式)
    按第三点的场景来说,数据库服务器的数据给到应用服务器是内网上产生的带宽,而应用服务器产生的数据是给到 nginx 服务器,也是内网产生的带宽...,只有 nginx 发送给客户端的数据是要经过外网的一个传输,是不是可以认为 nginx 服务器的产生的带宽就是甲方需要的带宽呢~
    PS 太细节了,带宽的基本单位是 b(比特)
    网速(速率)的基本单位是 B(字节)
    1B=8b(1 字节=8 比特)
    现在我有 50000KB/S,即带宽为(50000/1024)MB/S * 8= 390M b/s

  • 😂 ,这方面知识比较薄弱,不知道是合起来算,还是说要找到对应的服务器瓶颈再进行换算。

  • 看前端开发人员开发素养,因为有时候不加一些标签对实现并没太大影响。

  • 卧槽,喷神光临,受宠若惊!