前言

周边第一次听到这个话题的测试童鞋，一般都是这个反应：
“JMeter 可以做自动化测试框架？ 不是一个性能测试工具么。。。”

其实不然，按我的理解：“自动化框架技术主要是一种思想，只是在不同工具&平台下可以本土化为适合的框架而已”，所以"xunit 框架思想 +JMeter 工具=JMeter_xunit 接口自动化框架"是没问题的。

在自动化测试这个领域，由于 “框架” 这个词用得很多，"xunit/junit/testNG/robotFramework/selenium/Jmeter/TDD&BDD"这些都可以称为框架，所以很容易混淆 “工具类框架” 与 “抽象类框架” 的概念，下图是我梳理出来的 “通用自动化测试测试技术分层图”：

Why？为什么要用它、价值在哪？
背景：
以网上比较流行的 RF 框架 (RobotFramework) 为例，在实际使用过程中有 2 个痛点：
1) For 开发人员：本地调试不方便，因为要安装 RF 环境、一大堆依赖库等
2) For 测试人员：应用在中等复杂程度的项目，在框架限定的应用层 (写用例,写脚本) 玩得还能比较溜。 但是对于大型项目，需要 “深刻学习框架层代码、甚至二次开发” 时，就会发现 “应用层->框架层” 不是一道梯子，而是一道深渊。

该框架的优势： ①工具形式可以直接 copy，可以与开发人员快速集成，敏捷测试。 ②框架 90% 的代码是基于 JMeter 工具本身，成熟后几乎 NoCode，易推广 ③统一风格的底层工具函数构建，代码质量>>自开发类似底层工具函数。 ④几乎 NoCode 的平滑梯度学习自动化框架思想（管理、封装、报告）。

该框架的不足： 只适应轻量级的接口测试类 (包含数据库)，不适用于 UI 测试这类复杂技术。

What? 做出来的效果如何

How? 具体如何实现的
封装： "TestFragment+ 模块控制器"模拟函数
管理： 外部 tsv 文件 +csv 配置器 + 循环控制器 +switch 控制器
报告： Jmeter 自带 ant 报告插件上，优化 xsl 文件，生成优化后的 html 报告
其它： 命令行启动方式 +jmeter.properties+Jenkins_Jemeter 插件，可以与 CI-Jenkins 的结合
// 参考下一篇补充文章： JMeter_xunit+Ant 报告优化 +Jenkins

后续待完善：
示例项目的配套教程正在编写中，对 jenkins 熟悉、并且想抢鲜体验童鞋的见附件《JMeter_Bin_Test.zip》 【https://github.com/jayveeYao001/JMeter_xunit】

有兴趣的童鞋欢迎提建议