工欲善其事必先利其器
为什么要定制测试工具，不直接使用现成的本地开源工具或者云测平台？现有工具无法满足部分测试需求，尤其是公共组件类测试对象常常是Java接口级，提测的产品不是HTTP、RMB等标准协议形式，而是一个Maven坐标表示的Jar包。Maven坐标通过POM文件依赖其他组件，比如fps-client-qcloud依赖腾讯云cos_api，cos_api继续依赖其他组件。此时，以往解决方式一般是开发JMeter插件，继承JMeter的AbstractJavaSamplerClient类定义自己的Java请求类，在runTest方法中定义各种TestCase，通过场景String Switch，然后设计Jmeter前端UI一一对应。这种方式可以解决大部分测试场景，并且操作简单。但在使用过程中发现一些痛点，比如：
1、版本频繁更新带来的插件维护成本，每次需重新打包；
2、各测试产品引用了不同版本jar包，每个版本都要对应独立的插件；
3、不同jar包依赖了不同版本第三方库，无法在一套环境测试；
4、被测应用请求基于Spring Cloud服务，需先初始化服务才能发起请求等等。
在通用工具基础上继续增加特殊功能导致逻辑过于臃肿，定制工具作为现有工具的补充是更好的方法。
定制压测系统既可以在开发本地IDEA/Eclipse调试，也可以在基于Spring的Web平台共享调试。其中，本地通过javaagent启动Maven工程进行调试，逻辑完全由java实现，不依赖特定控件，用户可以开发的方式进行测试，跳转熟悉需求的具体实现逻辑代码。同步至压测平台，开发同学可在平台的简易IDE（编辑器基于codemirror）上调试Maven工程，平台会自动从部门或私有的Nexus仓库拉取Snapshot或Release版本解决依赖问题。
基于Maven工程的压测流程
监控方面，为了实现非侵入式数据采集，我们基于开源的Telegraf/InfluxDB自定义插件完成了对被测项目特殊指标的收集，容器实例指标存储于Prometheus，统一在Grafana展示，通过调用Grafana API自动生成个性化的监控页面。
产品维度性能监控
测试设计的循序渐进
仅从需求文档设计测试场景往往无法考虑到一些异常点，根据系统架构与消息协议画时序图则是一种理解各子系统之间交互与依赖的可靠方法。更进一步，我们需要从代码层理解功能的具体实现方式，使用了什么框架，该框架的优缺点，可能遇到的坑。比如缓存类需求，需要确认使用客户端缓存还是服务端缓存，其中服务端缓存又分为数据库缓存、本地缓存、应用缓存等。如在W项目中，从1.0版本的Redis缓存方案改到2.0版本Guava Cache方案，减低了系统复杂度，同时测试场景也有很大的变更，我们除了阅读工程代码的实现细节设计边界值、等价类划分，再另外新建一个Guava Cache Gradle工程来模拟重要的测试场景。
技术与生活
生活爱好与工作技术可以有共性存在，比如跑步也有梯度性能测试（乳酸阈值测试），性能调优（HRV时域/频域分析），同样有AI性能预测（Firstbeat算法V2Omax/比赛预测）。跑步理论中同样有中国传统文化的呼吸方法。分析共性，触类旁通，不断调优，在短短几个月时间内实现从新人达到中低心率全程马拉松3h28m的水平。
Work Smart，Run Smart！
