3月25日，MeterSphere开源持续测试平台正式发布v1.8版本。在这一版本中，MeterSphere项目进行了如下重要更新：
◼︎ 测试用例支持思维导图编辑模式
◼︎ 接口测试支持导入JMX文件
◼︎ 性能测试支持自由组合场景
◼︎ 增加报表统计功能（X-Pack）
MeterSphere产品总监王振为您演示本版本的主要内容，点击观看。
现将答疑环节的观众提问整理如下：
Q1：啥时候升级JMeter到5.4.1? 希望能用上groovy 3。
我们在下一个版本就会进行此升级，若经验证后没有兼容性问题，最迟在v1.9就可以做到。
Q2: 用例名称列过于窄怎么处理？
可以用自定义展示列功能，先隐藏不常用的列，当展示的列少时，用例列名称就可相对宽一些。另外，也可以手动调节列宽。
Q3: BeanShell怎么链接写Python代码，现在JMeter里面的BeanShell只能写Java，能不能写Python?如果能，Python是怎么获取上一个接口的返回数据的？
可以直接选择使用Python的脚本。您用的脚本可能选择了一个BeanShell前后置脚本步骤，如果是直接用的JMeter，可以选一个JSR233类型的前后置脚本，在该脚本中可以选择其他语言。若使用Python，还需要额外安装Python的Java解释器。我们在MeterSphere平台上直接完成了这些工作，在用户添加前后置脚本时，可以直接选择选用BeanShell脚本、Python脚本，或者是JavaScript脚本。
Q4: 用例结构支持脑图编辑层级吗？
这个问题对应我司产品用例模块的概念。目前我们还不支持在脑图上编辑该类模块，主要原因是因为右侧已经有模块编辑的功能，通过树状的模块编辑便可以清晰展示出当前用例组织的结构。如果在脑图中编辑，会发生跟此模块树冲突的问题。目前尚不能很好地解决，所以暂时禁用了模块编辑功能。如果后期得到解决，我们会开放脑图功能，可以做到在脑图中直接编辑。在1.8版本中，需要在左侧的模块树中把用例的模块层级先维护好。
Q5: 现在可以支持多域名服务器访问的复杂场景了吗 ？
目前有几种方式。第一种是把其放到不同的项目中，每个项目用一个域名，抛弃管理上带来的不便，可以满足场景。另外一种是计划在版本1.9中，增加这样的功能，可以针对不同模块下的接口，或者不同URL接口来给它匹配到不同的域名。
Q6: 脑图性能怎么样 ？1000个用例会崩么？
目前有进行一些处理，具体能支持多少还有待验证。
Q7: 自定展示列给个赞，能保存配置么？
可以保存。不同的用户都可以有自己的配置，不同用户不会互相影响。大家看到的都是经过自己调整的展示列的信息。
Q8: 关联需求这可以关联禅道里面的吗？
可以的。我们目前已经对接了TAPD，禅道和Jira，这几个平台的都可以进行关联。
Q9: 当用例多的时候，点击脑图存在加载很慢的问题。
现在确实会有这样的性能问题。我们会尽可能地优化。
Q10: 可以在脑图上创建用例创建的详细步骤吗？这样就可以直接操作脑图了。
可以。整体上就是在一个用例下添加一个子节点，给其加标签的操作形式。
Q11: 1.8版本导入后直接修改后执行无效、引用后经过调整也无效，这个问题是否修复了？
这是1.7版本存在的问题。我们针对引用场景，会进行一些问题的修复。您可以更新后去验证一下。需要特别说明，如果您在场景中引用的是单接口的用例，然后用例所对应的接口（如URL），这些用例本身以及场景中引用的用例不会更新，需用户手动更新。
Q12: 文档可以导出吗？
目前还没有提供导出功能，现在可以把接口导出成Swagger这样标准的格式。在之后的版本中也会增加文档导出的功能。大体的导出形式应该会是PDF和Markdown。
Q13: 导入后存在断言不好用的问题，如何解决？
比较具体的问题可以在GitHub上或者交流群中反馈。
Q14: 接口自动化能导出成jmx文件吗？
可以。接口自动化除了导入jmx文件外，现在也可以直接导出jmx文件。
Q15: jmx上下游关联的用例，即下一条用例的入参是上一条用例的结果，这块能正常使用吗？
这是接口自动化创建场景中比较典型的功能。在我们的文档、包括公众号中都有对应的相关教程。如有兴趣和需要，大家可以自行搜索查看。
Q16:每个编辑元素上下margin太大了，Mac一直要上下滚动，使用不太方便。
如果是指接口自动化场景编辑的情况，可以先使用全屏的模式。针对所提到的关于margin以及panding比较大的问题，我们会在后面的版本中具体地去优化。让整个布局更紧凑些。
Q17:新版本中，接口自动化引用了其他场景后。执行能不能执行引入场景内的场景变量呢？
可以。这个版本中有对其修复。
Q18:jmx导入的接口用例能不能和业务接口用例一一对应进行匹配？
可以用创建业务用例时关联用例的功能，通过这个功能就可以关联到接口。
Q19:JMeter所需的Jar直接上传就可以用吗？
是的。接口测试和性能测试都可以通过上传Jar包的方式来扩展测试能力。
Q20:建议不要修改代码里面db/migration下面的SQL文件，而是在每次变更后创建一个新的文件。
目前我们是按照版本来控制。在没有发版本前，SQL文件里的内容都是可能被随时更新的。针对此情况可能需要用户手动去处理。但在我们发了版本之后，比如现在发了1.8.0版本，已有的SQL内容就不再进行变动。在这种情况下就会去添加新的SQL文件。
Q21:接口测试导入har文件，会保存请求的响应内容吗？
会把相应内容展示上。如果请求又发送了一次，相应内容就会被重置和覆盖。
Q22:这个版本有报表统计的功能吗？
有的。
Q23:能把控制台输出放到场景级别吗，不用在自定义请求中显示。以及如果场景没有自定义请求，在哪里查看在自定脚本中打印的日志？
有用户反馈过。我们会尽快在版本中进行优化。现在在请求中展示的是控制台的日志。每个请求里展示的内容一样，还不是理想的效果。
Q24:能不能统计每条Case的执行时间？
可以。但如果是功能测试用例、业务测试用例，还不能统计。我们会在后面的规划中把相关功能计划一下。
Q25:有考虑过支持支持Redmine吗？
暂时未考虑。下一个版本会支持TFS。Redmine会考虑用户的反馈情况。如果用户反馈该平台的使用比较多，我们会相应地调高该优先级。