• 这种场景下,就要考虑实际业务中,不同业务的实际请求比例(有条件可以线上直接通过日志分析等手段来做,未上线的话只能靠对业务逻辑的了解和与项目成员沟通推导了),然后在压测的时候,按照基本一致的比例来分配压力。这样测出来的 TPS 和响应时间,是具备参考意义。

  • TPS 有意义,说明以目前的配置,你的系统实际能承受的性能水平就是这个水平了。没意义的是,你 TPS 已经没变化了,继续增大压力持续 1 小时没意义,因为你系统早就满负荷了,当响应时间增加到你觉得正常用户不可承受的水平时,就可以停止增大压力了。

    至于响应时间增大,很正常。一般情况下,当全部处理线程都处于满负荷状态时(有监控工具可以看到这个信息),就已经达到最大 TPS 了。类比一下,类似常见的柜台处理业务。一共就 5 个柜台(类比 5 个工作线程),不足 5 个顾客时,还有余量,但超过 5 个顾客时,柜台已经达到最大处理速度了(以现有资源没有可提升的余量),第六个就开始排队了,继续加也只是队伍变长,柜台的处理能力还是不变的。要优化速度,要不增加柜台(增加线程数或者其他限制了速度的资源阈值),要不让每个柜台处理业务的速度加快(优化逻辑)。

    这些性能测试的基本概念,建议可以看下极客时间高楼老师的性能测试课程,里面讲得比较清晰。

  • 看来背后有故事

  • 好建议。已经记下来了,抽空改下这个文字。

  • 平台有草稿功能,保存按钮的旁边就是草稿了。

  • 内容是还有没补充的,还是这就是全部了?

  • 你的意思是,mock 时截取的图片,在换为非 mock 时,数据会对不上,导致干扰?

    如果是这种场景,两次都用一样的 mock 的数据给前端获取,不就解决了?

    至于怎么让自己的前端走自己的 Mock 而非走默认的测试环境,可以用 proxy 做。在 proxy 里面设定固定的返回值,我理解应该就可以了。

  • getInteger() 和 getInteger() 两个方法都是 com.alibaba.fastjson.JSONObject 中的两个方法,功能类似,从一个 JSONObject 对象中获取到某个 key 的 value 值,区别在于 getInteger() 返回的是一个 integer 类型的对象,而 getInteger() 返回 int 值,属于基础数据类型。

    这里的第二个 getInteger ,是不是写错了,应该是 getIntValue 吧?

  • 精准测试的目的,应该是在减少测试内容的同时,也能有效保障改动引起的质量风险。

    虽然目前各种原因还没有类似接口测试这么成熟的落地方案,但梦想总归要有的,不成熟不也等于有机会么。

  • 是否可以把解决方案也在正文末尾附上,便于后人快速解决?

  • 不客气。

    这个也只是我个人观点,实际性能工具作者自己的思考,可能还得问作者本人才能知道了。我只知道在 Jmeter 或者 nginx 里面,每个请求结束后(包括超时或异常引起的结束),都会记录一条日志,带有响应码、响应时间、记录时时间戳等信息。所以基于这类工具做 TPS 统计,最方便的方式就是基于这个日志来统计了。

  • 一个菜鸡的精准测试实践 at 2021年08月09日

    如果是担心过滤过度,有 2 种方法:
    1、也分析.java 文件,看 .java 文件是否有这些方法。如果没有,说明是编译时生成的,可以忽略。
    2、分析是否符合自动生成的 get set 方法命名方式(例如 get+ 大写开头的属性名),如果符合,也忽略。

    不过,这部分就算带上,我理解也问题不大?因为一般都不会改到,而且从链路完整性角度,带上这些也更完整。

  • 一个菜鸡的精准测试实践 at 2021年08月09日

    很不错呀,麻雀虽小,五脏俱全,点赞!

    针对提出的几个问题,尝试回答一下:

    我在处理的时候,发现我生成了大量的 getset 方法,怎么去对这些方法进行过滤?

    不知道你这里的 get set 方法,是不是 mybatis 自动生成的 entity 实体类的对应方法?如果是,遍历类的 method 进行存储的时候,应该可以过滤。

    对于通过反射实例化的类是不是就没有什么好的解决方法了?

    有解决方法,但要通过运行时采集调用链。可以看下这个项目:https://github.com/lastwhispers/trace-spring-boot
    但注意一个点,运行时的采集,意味着如果没运行到这个链路,就会采集不到。所以只能作为补充,不好保障齐全。

    另外,有个点我看文中没有提到,采集了 Controller 和 mybatis 的代码后,两者是怎么进行关联的?正常中间应该还有一个 service 层来把两者关联起来的吧,我看文中没有提及?

    PS:项目时间长,没有任何的接口文档,也没有人愿意编写 swagger 这个问题,其实不用写也可以的。swagger 也认识 spring 各种注解,能自动生成包含路径、request 参数、response 格式(前提是代码里用 dto 这类实体类来写 response,而不是往 map 里加)的接口文档,只是会少了些字段说明之类的信息罢了。

  • 放这个位置纯粹是为了方便。setup.js 是总入口,不用担心不会加载到,而这段代码也不算复杂,所就直接写在这个位置了。

    实际工程里使用,如果有更复杂的上报策略,建议抽离单独 js 文件出来吧。

  • 这个问题看得有点一头雾水。。。这个场景是想测试啥,想测试多节点重启是否平滑,还是什么?

  • 重复劳动倒不至于很多,还是会有些侧重点的。只是这个容易中空的地带两边都需要参与,不能成为只是其中一方,这样容易由于不熟悉和关注点不够全面,导致遗漏。

  • 里面也有说,之所以保留工程师批准,只是因为如果出问题线上可能有较大影响,所以还是保留了人工二次确认。实际上准确度能提高到一定程度,加上自动的灰度校验,这道关卡就可以去掉了。

    这个算是一个正向循环,bug 案例越多->自动化处理比例越高,准确度越高->人工介入程度越低。

    不过这个 18 年提出的,后续也没见到有什么更新,不知道是不是已经夭折了。

  • 可以跑,前提是:
    1、你的 app 用到的所有包,包括第三方依赖,都支持模拟器(有的包只支持真机 arm 指令集,不支持模拟器 x86 的)
    2、你的测试内容不需要用到真机才有的特性(如扫码之类的)

    满足这两个前提,然后打包的时候设定好参数打模拟器用的包(特别强调下这个,ios 用的是 oc 或 swift ,直接编译成机器码的,不是 android 那种还有个 jvm 虚拟机,所以打包时就已经设定好了能运行在什么平台上了),剩下的基本把原来真机的替换为模拟器的就可以了。

  • 问题 1 和问题 2,归根结底还是 TPS 的统计问题。即处理事务横跨多秒时,计数应该算到起始时间段还是完成时间段。

    个人理解, TPS 一般是用完成时间来计算的,因为这样计算,性能消耗成本最低(只要在完成时加一个记录即可)。如果按开始时间,甚至按照持续时间拆分,那么每个请求还得额外消耗资源去存储和计算这些。我觉得,对性能工具来说,发起大压力才是它的最根本的职责。统计数据这些说实话,只是附属功能,交给其他外部监控程序做都完全没问题(nginx 日志就可以反映每秒请求数量和每个请求的处理耗时了),没必要为了统计准确那么一点点,增加那么多系统负载,进而导致无法发起更大的压力。

    至于消耗的时间统计,这个是用响应时间这个指标来统计的,不是用 TPS 。一般看性能测试结果,响应时间和 TPS 都得看。TPS 反映的是系统性能是否已到达瓶颈(即在当前配置下都已经没法再快了),响应时间反映的是达到瓶颈后整体处理时间延长的情况(即给到每个用户体感,会慢多少)。

  • 拉一个单独的集成团队,负责整体。或者改变测试团队的结构,类似产品,按业务分,而非按端分。

    我们这边用的主要是第二种,不按端分测试团队,只按业务分。如果是有些需求涉及中台型的团队(如审核系统,一对 N,不归任何一个业务线),那集成部分这个团队的测试和业务团队都执行一遍,交叉验证。

  • 建议你可以买本《不测的秘密:精准测试之路》看看。不知道算不算是业内做得最好的(毕竟大部分实际效果你没在公司内实际用,都不好说),但应该算目前公开资料里最全的了。

  • facebook 还真做过这个自动修复 bug 的系统:https://www.jiqizhixin.com/articles/Facebook-ai-dubug-tool-SapFix

  • hmm,这种和开发人员本身习惯有关。来几次线上事故,复盘时明确说开发夹带私货不同步,让开发背下锅,就好了。因为这个夹带私货本身在研发过程就是不好的事情,正常开发领导都不应该允许这种情况在团队里随意发生。

    前面 @gyyfifafans 提到的封版也是一种很好且简单的方式。只要测试握有测试环境、生产环境的代码发布版本控制权就好。

  • 从目前我看到的几类方式上看:

    基本原理上,大多是通过覆盖率来关联的。比如执行 A 用例的时候,通过覆盖率数据可以知道会执行到 a 函数。然后记录下 A 用例->a 函数 这个关系。后面如果 a 函数有变更,就会认为 A 用例需要执行。这里面也会有一些精细化的调整,比如可能会细化到函数内部的 if else 分支级别,或者结合一些算法来减少推断出来的用例数(比如一个底层网络库调用调整,全部涉及接口交互的用例都自动出来了,但实际可能只需要执行任意一条即可校验)

    也有的是到接口级别,执行 A 用例,会调用 a 接口,那映射关系就是 A 用例->a 接口。 只要 a 接口有变更,A 用例就要执行。接口级别甚至可以不用覆盖率,只需要日志打印。

    还有只是反推到接口级别的,通过 ASM 分析(通俗点说,有点类似于平时 idea 里的 find usage 倒推调用位置,一直倒推到 controller 层)+ 运行时数据采集(比如通过反射来调用的,就只能用这种了),反推某次代码改动影响到哪些接口,然后执行这些接口相关的接口测试用例。客户端类型的话把接口改为界面(activity/fragment/view/url),也可以同理推断

    不过怎么维护好 测试用例->代码(函数/行/接口)这个映射关系,除了接口测试用例天然自带映射关系外,目前还没见到有特别好的招。

  • 你们现在是开发提的影响范围都不靠谱,还是夹带的私货都不同步你们,导致你们没测到,所以直接在线上出问题?