今天在某问答平台看到一个问题：如何突破职业瓶颈？ 刚好接着这个问题分享一下去年的一段经历，回答一下。 去年某个时候，感觉自己在接口测试这个方向上走到死胡同了。不管是自动化还是性能测试，都已经轻车熟路。对于日常工作，真就只剩下搬砖的一种感觉，缺少挑战，也就失去了方向。在接口性能测试方面，我探索了一些其他场景，比如：全链路压测、链路支路、等比压测、提高数据精准度等等。单感觉是东一榔头西一棒子，一个点，一两周就完成了，只能换去另外一个角度。后来短暂去搞了静态代码扫描，后来效果不佳也放弃了，中间倒是学了不少细碎...

2021年马上就过去了，去年这个时候我写了一篇2020年FunTester自我总结，感觉也是对FunTester有个交代。 2021年也不能例外，下面分享一下FunTester在2021年末的自我总结。 公众号 2021年FunTester的重点还是在公众号上，目前已经730+原创文章，7200+的粉丝，算是一个里程碑。今年彻底放下了去年的 日更 flag，自然也少了很多非更不可的压力。精神上轻松了许多，自然文章的质量上也有所提高。不少同行问我为何有那么多东西可写，古语有云：问渠那得清如许，为有源头活...

之前写过一个FunTester框架对Redis进行几种常见API进行性能测试的系列文章，今天如约开始写FunTester框架对MySQL常用功能的性能测试。 我们来回顾一些Redis性能测试的文章： FunTester框架Redis压测预备 FunTester框架Redis性能测试实践 FunTester框架Redis性能测试之list操作 FunTester框架Redis性能测试之map&INCR MySQL系列文章预计分两期，分别是增删、改查，进行简单的SQL语句操作，如在实际工作中用到，需要...

之前吹过的牛逼终于实现了，之前分享过一个简化的版本动态模型之增压暂停【FunTester测试框架】。今天给大家分享一下动态增减压力的实现的简化版本，总的来说就是在压测过程中随时调整（增加或者减少）压力（线程数）。 思路 首先要抛弃原有的模型结构，将每个多线程任务都当做一个可管理对象，需要有一个中断方法，然后有一个全局的运行状态的管理类，包含一些基础添加，删除，终止单个多线程任务的能力。 通过一个外部因子触发不同的管理类方法：比如增加用例，然后从任务池中随机（后期会选择某一任务）克隆一个任务，重新放到任...

距离上次对FunTester测试框架功能规划之后，已经很久没有更新过功能规划了，主要因素是FunTester测试框架目前支持的功能已经完全满足工作需求。无论是分布式性能测试框架，还是全链路性能测试支持，以及量化模拟线上流量，基本技术验证都完成了，余下的都是在技术方案的上进行调整以更适应现在工作需求，不存在技术障碍。 虽然FunTester测试框架还在不断更新，但很久没进行过功能更新了。最近在设想为了可能用到的测试场景中，动态压力是目前最有可能在工作中应用的。 终极目标 最终想要实现的就是在不断压测过程...

经过了两次更新，DCS_FunTester框架的基础功能已经接近尾声了，目前的状态基本能够使用，所以近期不会再进行功能更新了。 DCS_FunTester分布式压测框架更新（一） DCS_FunTester分布式压测框架更新（二） Gradle多模块 由于之前一直写成了两个项目master和slave，考虑到这样使用多有不便，所以写到了一个Gradle项目里面了。算是个小小地更新。也踩了踩Gradle多模块项目的坑。 这里有几个坑，可以给大家分享一下： 依赖另外模块 经过一顿乱操作，我找到了...

经过一阵子的断断续续的测试，DCS_FunTester分布式压测框架更新（一）完毕之后又增加了一些更新。 增加方案三支持 在分布式性能测试框架用例方案设想（三）、基于docker的分布式性能测试框架功能验证（三）中，我提到了方案三：基于Groovy脚本执行的测试用例，这次更新将支持执行Groovy测试用例。目前除了访问验证以外，但是对于脚本内容尚未过滤。 下面是master节点实现方法： @Override int runScript(GroovyScript script) { ...

终于抽出来时间整理FunTester测试框架的教程了，可喜可贺，希望大家能多多支持FunTester。 PS：本教程以文字版为主，视频版视情况录制或者直播。 环境搭建 郑重承诺：FunTester框架教程会兼顾Java和Groovy两门语言，DCS_FunTester也是支持两门语言的，但不在本教程范围内。 Java环境 这个过于简单，不再赘述。 Groovy环境 这个可有可无，但是最好有，不然打包的时候会把Groovy依赖当做环境变量，无法打包到jar包中。 下载Groovy3.0.8的...

在经过了一些人生的思考和积累，终于开始第一轮的更新，除了修复BUG以外，还进行不少功能性更新。另外本地部署已经完成了。有兴趣的可以自己多体验一下。分布式性能测试框架单节点内测 确定名字 确定项目名字DCS_FunTester，DCS全称Distributed Control System，既分布式控制系统。后缀FunTester。目前项目是slave项目，至于master项目还在思考。但是不影响slave项目的多节点部署。slave项目不依赖master项目，具有独立部署提供服务能力，当然也具有多节点部...

之前写了两篇文章分享自己对几种性能测试框架的测试：性能测试框架对比初探、性能框架哪家强—JMeter、K6、locust、FunTester横向对比。 上次的测试中，我在局域网起了一个基于FunTester moco server框架架构图的服务，服务单机QPS在15k左右到达瓶颈，但是初步判断是局域网带宽导致的，由于时间原因我并没有在深入排查原因。刚好一个朋友想知道Gatling性能测试框架在实际测试中跟其他框架的比较结果，我就趁着周末时间搞了一个本地的moco服务来测试K6、Gatling和FunTe...

经过了之前*方案一*和*方案二*的铺垫，*方案三*也呼之欲出，这就敬上。 首先我们照例先回顾一下之前两个方案的设想和实现文章： 分布式性能测试框架用例方案设想（一） 基于docker的分布式性能测试框架功能验证（一） 高QPS下的固定QPS模型 分布式性能测试框架用例方案设想（二） 基于docker的分布式性能测试框架功能验证（二） 基于脚本的压测场景 性能测试脚本基于FunTester性能测试框架，在之前的方案二中，我们需要将用例写进去基础的jar包中，然后通过反射调用，灵活之处就是可以将用例...

经过了之前的铺垫：性能测试框架对比初探，目前留下来的几个测试框架就是JMeter、K6、locust和FunTester。本次测试目的是对比几种框架的在各个并发下面的发压能力和资源消耗。本次值测试了最简单的GET接口，不涉及参数和POST接口。 先说结论： 低并发（100线程）情况下，FunTester资源消耗略微占优，但是高并发（200线程）情况下K6牛逼，golang还是比较狂野，优势明显。 在尚未达被测服务性能拐点的时候，FunTester测试框架在资源消耗还有一些优势，但是达到拐点之后，由于线...

最近收到一项任务，就是对比主流开源性能测试框架，我搜了一些，列出来JMeter、k6、Gatling、siege、ngrinder、locust以及FunTester。 下面是一些定性的指标收集结果： 工具 语言 使用方式 用例形式 分布式 易用性 拓展性 流量编排 链路 社区 可读性 JMeter Java Client/命令行 jmx文件 中 优 低 差 差 11,800,000 差 k6 JavaScript 命令行 JS脚本 否 中 优 中 优 1,840,000 优 ...

本文是FunTester测试框架分布式性能测试功能拓展实践，是一种比较粗略的技术验证实践，技术方案采用分布式性能测试框架用例方案设想（二）中所设想场景，基于jar包内函数的，这个方案需要将测试用例写到更新到jar包中或者classpath目录下。 粗实现方案分成三块：master调度机、slave测试机和server被测服务。 master调度机：处理用例、分配任务 slave测试机：接受任务、执行用例 server被测服务：提供测试接口 docker镜像 内容同文章基于docker的分布式性能...

在经过这么久的铺垫，FunTester测试框架分布式版本的工作正式开始了，我首先写了一个单节点的版本，通过HTTP协议接口进行任务上传，而非像之前设想中的，定时去master节点进行pull任务。 此版本为单节点部署，可本地部署，预计下个月开源，主要是考虑到版本不稳定，肯定会进行多轮更改。 当前服务只是针对之前设想的方案（一）（基于HttpRequestBase对象）进行实践，感兴趣的童鞋可以翻看旧文章： 分布式性能测试框架用例方案设想（一） 基于docker的分布式性能测试框架功能验证（一） ...

之前画了两张框架的架构图：FunTester测试框架架构图初探 和FunTester测试项目架构图初探，反响不错，最近又对moco API产生了兴趣复习一下，顺便做了一个总结。 其中大部分功能都是我在moco API的基础上封装而来的，简化了使用方法，增强了功能。少量是我自己做了补充，有兴趣的可以参考之前的文章： 解决moco框架API在post请求json参数情况下query失效的问题 给moco API添加limit功能 给moco API添加random功能 解决moco框架API在cycl...

书接上文分布式性能测试框架用例方案设想（一），方案二进行更加复杂的测试用例，以jar包类方法形式的用例进行测试，下期会基于docker进行技术验证。 基于jar包类方法的压测场景 性能测试脚本基于FunTester性能测试框架，今天分享提前将用例写好，暴露部分参数的用例。这类性能测试用例的测试场景已经提前设定，参数化目前都只是在测试线程数，软启动时间，终止条件等做了区分等等。 这类用例的修改增添都需要重新部署服务，所以比较适合稳定用例，比如基准性能测试用例这些，可用于性能巡检、定期性能回归等等测试场景...

在之前写过的文章固定QPS压测模式探索、固定QPS压测初试中，我用到了一个任务发生器和sleep()方法来达到固定QPS的请求实现。但是在最近的工作中，在高QPS场景下，这种方式就会显示出其缺点：单线程任务生成器性能不足，由此带来的副作用就是误差较大。为此，我引入了多线程任务生成器的功能。 主要思路就是在性能测试软启动完成后，根据设置QPS大小分配多个的线程来完成生成任务的功能。 这里引入一个常量： /** * 单个线程执行的最大QPS任务速率 */ public ...

任何成功的自动化测试过程的关键组成部分都是测试自动化框架。降低维护成本，测试工作效率提升和提高质量保证团队的投资回报率ROI是优化敏捷流程时所提供的主要优势之一。 出于以下原因，自动化对于高效的测试过程至关重要： 提高测试效率 降低维护成本 尽可能少的人工干预 尽可能大测试范围 代码的可重用性 软件开发领域的管理人员对实现自动化框架如何使他们的业务受益有了广泛的了解，并且在这个领域的许多人已经开始经常使用框架一词，它是成为软件自动化项目成功的关键。 但是对于许多人来说，问题仍然存在： 测试自...

在近期工作规划中，分布式压测框架提上日程，目前FunTester已经具备了一些分布式压测中用到的功能。 例如在执行用例端：利用反射根据方法名执行方法的使用示例、命令行如何执行jar包里面的方法； 或者在用例编写端：如何统一接口测试的功能、自动化和性能测试用例、如何在Linux命令行界面愉快进行性能测试； 亦或前段时间探索的Groovy反射执行问题：反射执行Groovy类方法NoSuchMethodException解答、Groovy反射invokeMethod传参实践。 目前看已经有了几种粗略的性能测试...