以下文章来源于CSDN博客分享，作者为plateauandsp。
关于MeterSphere
MeterSphere一站式开源持续测试平台是由FIT2CLOUD飞致云发起的开源项目，目的是打造测试一体化管理，提高测试人员能效，降低测试成本。在其功能上包含测试用例管理、接口测试、性能测试等，查看官网的架构描述，后续还会增加UI测试、MOCK服务等，这点还是比较期待的。
MeterSphere目前在测试圈非常火，打破了近几年测试圈工具类型的一成不变，笔者也是经朋友介绍，然后自行尝试了下MeterSphere平台，并把公司部分系统的接口和用例转移到MeterSphere上，整体感觉不错。总结了下MeterSphere具备的优势大概有：
- 定位持续测试平台，需要涵盖大量不同的测试类型，这点其实不易。MeterSphere目前涵盖的测试计划能够关联测试用例、接口测试、性能测试，这点深得测试要点。
- 不同于以往的接口测试工具，MeterSphere还具备接口管理能力，间接地降低了和研发在接口描述上“扯嘴皮”的功夫。
- 测试报告给个赞，比我现在手动汇总的好看，哈哈。
官网架构图链接：
https://www.fit2cloud.com/metersphere/index.html
思路说明
作为一个不断持续迭代的产品，MeterSphere当然也有缺点，比如数据库提参和断言相对使用难度较高，而且吐个槽，官网没详细说明哈。但是作为ITer，我们有爱专研的精神是不，所以详细研究下了在MeterSphere中如何针对数据库进行提参和断言（后来了解到MeterSpher底座是基于JMeter的，所以思路从这点入手了）。
思路如下：通过SQL请求，返回SQL查询值，采用和JMeter同样的数据存储方式进行参数提取，通过自定义脚本的方式对参数进行断言。
具体操作（提取参数）
数据库的查询接口存储分为“按结果存储”和“按列存储”。
比如数据库查询结果如下图：
按结果存储为org，按列存储为orgid,orgname，如下图：
按结果存储，会将所有的查询结果按照对象的模式进行存储至变量org。
按列存储，会将查询结果的第一列储为orgid，第二列存储为orgname。
如采用了按列存储，后续通过${orgid_n},${orgname_n}进行引用，n为行数，${orgid_1}为orgid这列的第一行值。为了展示，可以利用后置脚本对结果在控制台中进行打印如下图：
后置脚本如下：
org=[{name=ilufutuid, description=form api, update_time=1611202281786, id=438265bc-dc8a-4e46-bdb9-35fa3bffd0b7, create_time=1611202281786}]orgid_1=438265bc-dc8a-4e46-bdb9-35fa3bffd0b7orgname_1=oilufutuid
具体操作（断言）
关于断言操作其实类似上面描述的，采用脚本断言进行操作。需要在SQL请求下创建断言，选择脚本类型：
选择脚本断言后，通过MeterSphere脚本自动填充能力，自动生成断言脚本，比如判断orgname_1的值是否等于oilufutuid：
value = vars.get("orgname_1");result = "oilufutuid".equals(value);if (!result){msg = "assertion [${orgname_1} == 'oilufutuid']: false;";AssertionResult.setFailureMessage(msg);AssertionResult.setFailure(true);}
具体的BeanShell语法和JMeter中用法一致，但是MeterSphere能够自动生成，这点降低了测试人员的一些上手难度。
最后建议
对一些新手或者刚接触MeterSphere平台的测试人员来说，上述的脚本断言的方案或许依旧有一定的难度，建议MeterSphere在这个基础上能够在进行一次易用性上的封装。
比如在SQL请求上直接添加类似接口请求断言，而不是采用脚本的方式进行。在接口请求下支持添加SQL断言，自动比对SQL查询值和接口JsonPath提取变量。
————————————————
版权声明：本文为CSDN博主「plateauandsp」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：
https://blog.csdn.net/plateauandsp/article/details/114646657