以下文章来源于CSDN博客分享，作者为plateauandsp。

关于MeterSphere

MeterSphere一站式开源持续测试平台是由FIT2CLOUD飞致云发起的开源项目，目的是打造测试一体化管理，提高测试人员能效，降低测试成本。在其功能上包含测试用例管理、接口测试、性能测试等，查看官网的架构描述，后续还会增加UI测试、MOCK服务等，这点还是比较期待的。

MeterSphere目前在测试圈非常火，打破了近几年测试圈工具类型的一成不变，笔者也是经朋友介绍，然后自行尝试了下MeterSphere平台，并把公司部分系统的接口和用例转移到MeterSphere上，整体感觉不错。总结了下MeterSphere具备的优势大概有：

1. 定位持续测试平台，需要涵盖大量不同的测试类型，这点其实不易。MeterSphere目前涵盖的测试计划能够关联测试用例、接口测试、性能测试，这点深得测试要点。
2. 不同于以往的接口测试工具，MeterSphere还具备接口管理能力，间接地降低了和研发在接口描述上“扯嘴皮”的功夫。
3. 测试报告给个赞，比我现在手动汇总的好看，哈哈。

官网架构图链接：

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-35fa3bffd0b7
orgname_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