产品解读丨MeterSphere开源持续测试平台助力企业测试平台化建设

Posted 2022-05-27 FIT2CLOUD飞致云

大部分测试人员一开始接触测试的时候，往往是先进行手工测试，然后借助如Postman、JMeter等测试工具进行接口调试，以及开展核心场景的性能测试。随着测试人员技术的日渐提升，他们在自动化测试以及测试框架方面也会慢慢熟悉起来，同时可以开始不断进行新的尝试。在这个过程中，软件测试从业者尤其容易对Selenium、Robot Framework、Pytest等开源框架青睐有加。

对企业来说也是如此，虽然测试技术在国内不同行业、不同企业的发展深度不同，但总体演进的方向和路线是基本一致的：都是从最传统、最原始的手工测试开始，中间历经测试工具化、自动化以及平台化阶段，一步步发展到目前处在技术前沿的智能化测试阶段。这期间每一次的技术演进，都可以说是一次生产力飞跃的重要里程碑。

出于行业特殊性或企业对测试重视程度不足等原因，手工测试的部分依旧被保留在很多企业中，即使是腾讯、华为等互联网企业也不例外。而随着国内企业软件开发的不断发展及测试水平的不断提升，许多企业开始在测试工作中尝试开展自动化测试的应用，并且不断扩大应用范围，以提高测试效率和测试质量。

不过，目前国内只有少数大型互联网企业对智能化测试进行了探索性的试验，所以无论是在理论方面还是在技术成熟度方面，智能化测试都还有较大提升和完善的空间。对于绝大部分企业来说，近年来测试平台化的建设就和持续集成一样，需要各行业的测试人员不断进行探索与实践。

所谓“平台”，就是实现了某类功能的一种体系，包括了各种不同的元素和组成，例如平台的架构、工作流程、执行标准、运行机制以及执行工具等。

从必要性上来说，平台化测试相比于工具化和自动化测试的主要差异包括：能够有效提升内部测试能力和测试数据管理能力、不断降低应用门槛和应用成本、提高对测试数据的利用水平以提高测试质量，以及将测试能力输出到外部测试或非测试团队，以支撑包括测试团队和非测试团队的整个团队的高效率、高质量交付。

初步了解了平台化测试相关内容后，我们就可以开始进一步思考，企业在进行测试平台化建设时需要着重考虑哪些因素？平台的能力应该覆盖哪些内容？

本文将着重从以下五个方面的平台属性内容来解读MeterSphere的平台化测试建设：

1. 测试平台的用户是谁？

2. 测试平台所具有的测试能力是什么？

3. 测试平台适配测试团队整体的测试水平，还是拔高少数个体的测试代码能力？

4. 是否可以无缝衔接测试人员目前的测试工作习惯？

5. 测试平台如何与第三方系统进行服务集成？

测试平台的用户是谁？

不同角色所属的人员应该拥有哪些权限；以及不同角色人员（例如开发和测试人员、测试执行人员和测试负责人）应该如何进行协作？

测试平台所涉及的人员肯定不仅仅局限于测试团队。在一些测试活动中，除测试人员以外，还需要研发人员，甚至需求分析、运维等岗位人员来进行协作。

例如，在架构师定义好接口文档之后，研发需要根据架构师的定义进行接口的实现；而在接口自动化测试时，测试人员需要查看经过研发二次定义的接口文档，来进行接口定义步骤，以及使用Mock服务；在测试人员设计好用例之后进行的用例评审中，一般也是多方进行评审；每个产品的测试负责人也需要将测试任务进行分解，并指派到具体的测试人员。

MeterSphere开源持续测试平台通过工作空间（Workspace）以及项目（Project）进行层级管理，并依据角色设定来下发管控权限。除了系统自带的角色以外，MeterSphere还可以自定义新角色（例如开发组、接口测试组、性能测试组等）和对应权限，甚至应用到单个项目界面，实现灵活适配。

测试平台所具有的测试能力是什么？

我们期望测试平台所具有的测试能力，应该是能够全面覆盖所有的测试活动、并对相应活动进行有序组织的能力。当然，不同的测试团队选择测试平台也需要围绕企业的实际需要以及所关注的重点进一步细化需求，并对所需的能力进行筛选和区分。

不考虑各行业的特殊性，作为通用的测试平台，其主要覆盖的平台层核心能力应该包括：

■ 用例统一管理

测试用例是测试执行的基础，关系到测试的正确逻辑以及所能覆盖的广度。为了能够重复执行这些测试用例，测试平台需要将用例统一管理起来；

■ 测试环境管理

测试用例要在具体的运行环境中才能真正执行，不同的运行环境有可能导致不一样的测试结果。从软件上来说，运行环境一般包括操作系统环境（操作系统、数据库等）以及业务系统环境（被测试的系统）；

■ 测试任务管理

测试任务管理的主要职责，是将测试用例分配到具体的资源上进行执行，并跟踪任务的执行情况。测试任务管理是测试平台设计的核心，它可以将测试平台的各个部分串联起来，从而完成自动化测试的全流程；

■ 测试资源管理

一般的自动化测试对测试资源的数量以及性能并没有太高要求。但性能测试（尤其是10万级并发以上的场景）对测试主机的数量和性能都有针对性的要求，所以会要求测试平台能够对测试资源进行有效管理。为了提升资源利用率，可以通过虚拟机、Docker等虚拟技术来充分利用硬件资源；

■ 测试数据管理

测试任务执行完成后，需要记录执行时间、执行结果、用例执行期间的CPU、内存占用情况等各种测试期间产生的数据。因为这些数据中隐藏着巨大的信息价值，不仅能够展现当前用例的执行情况，还可以作为历史数据与后续的测试数据进行对比，从而发现明显的变化趋势。从长远来看，每一次测试活动中记录的任务数据也可作为大数据的一部分，并可以基于它进行一些数据挖掘工作，甚至为后续测试智能化奠定数据基础。

MeterSphere开源测试平台具备以上所有的测试能力。尤其是对于测试资源以及测试数据，MeterSphere有着更加全面和精细的管理。对于测试资源，MeterSphere提供了Node、Kubernetes两种类型的测试资源管理方式，也可以将JMeter作为一种资源以镜像的方式与MeterSphere相关联；对于测试数据，无论是接口测试还是性能测试，都会通过测试报告的方式对测试结果进行持久化存储。

测试平台适配测试团队整体的测试水平，还是拔高少数个体的测试代码能力？

非平台化的自动化测试最显著的特征就是脚本化。例如，一种典型的非平台化自动化测试流程就是以Python语言为基础，采用Request、Selenium等框架为核心模块，使用Allure来展示测试报告。脚本化的自动化测试往往更能体现出测试人员的代码编写能力和个人测试水平。

然而，脚本化的自动化测试可能会有以下几条弊端：

■ 主要会在工程化环境搭建、本地脚本编写以及调试这三个环节具有较高的时间成本；

■ 由于测试环境和测试数据往往与脚本直接关联，非平台化的自动化测试在测试环境及测试数据方面，很可能会因脚本水平低下而出现数据场景单一、覆盖范围有限等较大弊端。也就是说，会在一定程度上拔高对测试人员的要求；

■ 自动化测试的测试经验无法及时沉淀，脚本里沉淀的能力也难以快速复用，一旦出现人员的流动变化，将直接导致测试工作的停滞不前，甚至中断。

相比于非平台化的自动化测试，MeterSphere开源测试平台的低代码式自动化接口测试介入门槛极低。平台提供图形化编排模式的接口测试，且可以通过文档驱动的方式来支持接口测试用例的编写。MeterSphere的界面简洁、条理清晰、输出规范、简单易用等特点不仅能够规范测试标准和测试流程，还可以提高测试人员使用平台的意愿，从而全面提升测试团队的水平。

是否可以无缝衔接测试人员目前的测试工作习惯？

除非是测试工作从零起步，否则无论是从手工测试阶段、还是从自动化和工具化测试阶段开始向平台化测试转型，在测试平台化建设时都需要考虑到平台所携带的测试工作模式是否可以无缝衔接测试人员目前的测试工作习惯，即能否让测试人员以最低成本的方式快速、方便地过渡至新的测试工作模式。

在手工测试阶段，以Excel、XMind等方式创建设计用例，并按照用例设计的规范进行调整即可将用例方便地导入MeterSphere测试平台。接口Swagger文件、性能测试的JMeter工程文件，以及JMX文件等原有测试工作的成果在MeterSphere平台中也都可以直接使用。

MeterSphere在接口自动化和性能测试方面与JMeter保持一致。MeterSphere的UI自动化功能模块采用了Selenium的技术架构，不过在展现层面上，MeterSphere并不是直接简单地嵌入完整的Selenium框架，而是首先对Selenium框架进行了简化，并在一定程度上对其进行了二次封装，使得操作更加简单、方便。

在测试执行层面，测试人员不需要再关心这些工具的安装部署等繁琐的过程，因为MeterSphere开源持续测试平台安装部署完成之后，这些测试工具都将以平台自身能力的形式汇总在MeterSphere平台之上。至于后台的具体实现过程，就不需要测试人员去过多关注了。

测试平台如何与第三方系统进行服务集成？

对于企业IT建设来说，各系统的相互关联也是至关重要的。因为系统之间要进行联动以及数据的共享，以避免数据孤岛、烟囱式以及重复性建设。而从MeterSphere的设计可以看出，MeterSphere团队对这一点有着深刻的理解，因为MeterSphere不仅是一个开源项目，更是一个开放的平台。

首先，MeterSphere可以实现DevOps的关联。DevOps相关理念以及实践在国内的很多行业早已深入人心，但是在实际落地的过程中，测试团队往往选择直接忽略这一环节的测试，或是由于太过偏重于研发侧的单元测试能力而无法提供通用、全面的测试方案。

MeterSphere开源持续测试平台可以很好地对测试方案进行完善和补充，通过MerterSphere Jenkins插件可以轻松打通与整个DevOps核心工作链的关系，然后以测试计划的方式组织测试任务，以实现持续测试。

其次，针对测试缺陷管理、需求管理的测试工作需要，MeterSphere并没有选择重复造轮子，而是选择以开放的姿态、灵活的方式全面且深入地对接TAPD、JIRA、禅道等市面上已有的成熟系统。

虽然缺陷管理、需求管理都是条目记录加上状态以及流程的扭转，从技术实现层面来说并没有太大的难度。但MeterSphere还是在实现这两项功能的基础上，更进一步细化了平台的操作。例如，在使用TAPD创建缺陷时，如果预定义字段还不足以支持其他信息的表达，测试人员还可以选择自定义字段。可以看出，MeterSphere在平台建设过程中考虑到了不少测试工作细节。

总结

■ 通过MeterSphere开源持续测试平台，企业用户可以快速构建企业级测试平台，打通功能、性能等各类测试的关系，将功能、开发自测以及性能等各类测试项目都集成到一个统一的测试平台进行管理。在人员管理层面，MeterSphere也可以将开发团队、运维团队、质量测试团队的测试活动统一纳入到测试平台进行管理。

MeterSphere打通了软件测试生命周期管理全流程，实现了测试工作全流程的集成管理，提升了测试过程各个环节的管理水平与质量。MeterSphere还打造了将需求、开发、测试和运维等环节全部关联起来的系统，实现了软件测试质量的闭环管理；

■ MeterSphere通过对底层技术架构的封装，提供跨平台、低代码、自动化的测试能力，屏蔽了测试人员对技术的依赖，实现接口、性能和Web自动化测试的普及，全面提升了测试工作效率和自动化测试覆盖率；

■ MeterSphere还实现了业务需求和系统功能的衔接，进而建立和完善了测试场景库、测试案例库和数据准备库等，持续积淀测试过程资产，提升测试资产的复用率。