一、工具型产品和平台型产品的区别

在聊测试平台之前，可以先聊下平台型产品和工具型产品的区别。

什么是工具型产品：

工具型产品通常是为了解决某个领域当中的某个具体的技术问题，满足某一具体需求而设计研发。研发的出发点是个体用户，能够让用户节约时间、提高工作效率等。工具本身无需太关注企业管理模式，流程方式等。

什么是平台型产品：

平台型产品的设计是定位为是成为行业内大部分企业对功能、管理等需求最佳的承载体，同时为企业的最终用户提供媲美工具的能力和使用便利性。一个平台型产品在企业的落地使用，除了从企业用户的使用满意度视角来看外，同时也需要从企业顶层视角来看平台所带来的规模化效益。所以企业在考虑平台型产品，不仅会从功能角度考虑，也同时会从企业管理的角度进行考虑。

工具型产品与平台型产品的区别：

两者的差别主要体现在设计理念、管理领域、部署架构三个方面。

首先在设计理念上，工具型产品解决的是用户具体某一功能的使用。侧重于具体功能的设计，同时在会从部署简单、架构轻量等方面考虑。平台型产品则是侧重于系统平台的整体设计，包含了技术架构选择、企业业务需求，企业用户功能需求等各个方面因素。

其次在管理领域上，工具型产品遵从功能实现的角度出发，不太注重企业管理上的能力，工具的使用规范、标准等依赖个人用户和企业明文的一些规章制度进行约束。而平台型产品，除了功能的实现同时，也注重人员权限的管理、流程的规范上的考虑。比如大部分的平台型产品都会包含的 “基于角色的访问控制” 管理模型（RBAC）。

再者在部署架构上，工具往往以独立部署在个人用户 PC 上为标准，比如办公 Office 软件、运维工具 XShell、测试工具 Jmeter 等。平台性产品需要考虑高可用、集群分布式等架构，而且能随着企业用户的逐渐增多支持部署架构的纵向与横向扩展。

二、测试平台的几大特性

随着软件产品的在不同行业的发展，软件产品的复杂度也在不断提升，软件研发生产至交付部署各个环节的分工越来越细，测试与开发相分离（这边只是说的分离是指工作内容边界清晰，并非工作岗位分类，现在测开岗也很多）。软件的高标准测试要求逐渐成为保证软件质量的重要手段之一。如 DevOps 所提倡的，软件质量的保障需要产品、开发、测试、运维、技术运营各个部门之间的沟通、协作的共同努力。

从整体测试过程中看，不同的测试阶段进行了细化，一般都遵循：手工测试->工具测试->自动测试->测试平台->测试服务化的演进和发展（这个只是测试阶段描述，并非说企业到测试平台阶段后就不再需要人工测试、工具测试等）。很多企业管理者也深知测试平台带来的管理和经济效益，但是只有部分企业开展了测试平台的建设，大部分的企业依旧停留在前三阶段。那么一个测平台具体需要什么样的能力呢？个人为至少具备以下四个方面的特性：

测试平台能够支持不同测试群体。从企业测试团队看，测试团队包含了测试人员，测试经理，项目经理，乃至测试开发人员，测试运维人员，测试平台应该支持不同人员的分权分域管理和跨部门测试协作支持。
测试平台能够包含多种的测试类型。从技术角度看，测试平台应该支持不同的测试类型，包含传统的功能测试，广泛使用的接口测试，企业积极尝试的性能测试，业务收益最高的 web、app 测试、基石保证的安全测试等。当然如果支持基于不同的测试类型衍生出的测试类型，比如混沌测试、精准测试、探索性测试等测试类型更佳。
测试平台能够和企业现有的项目管理系统、流水线平台等无缝集成。从测试平台的本质来看测试平台建设目标不仅仅是满足测试人员的功能性需求，最终目标是提高软件的交付质量，而在测试平台中承载了大量的测试数据和测试报告，所以在保证测试平台自身的的独立性外，应该但是更加重视和企业现有的平台系统的联动和集成。
测试平台应该具备测试的服务能力。测试平台，顾名思义是支持测试人员开展具体测试工作的平台。不同的测试类型在开展上有可能千差万别。但作为一个测试平台，需要具备为不同的能力的测试人员提供统一测试抽象能力。比如支持接口测试，测试平台除了支持接口测试能力之外，更应该支持让测试人员在测平台上按照业务场景自我组装接口测试自动化场景的服务能力，而非让测试人员上传类似代码型的测试脚本，平台本身只负责测试脚本的分发、运行、报告收集，此模式只是测试平台化，并非测试服务化。
当然，除了上诉的必须特性之外，测试平台的易用性，扩展性、可维护性、技术通用性等也都是核心的特性。

三、如何评判一个测试平台是否优秀

评判一个测试平台是否优秀需要站在不同的角度和立场看待这件事情。一般需要从企业和供应商两方面角度综合评判这件事情，因为太多供应商认为的 “优秀 “平台在用户端反而被 “不好” 的标签，其实原因也很简单：

在企业看来，一个好的测试平台需要具备的因素包含了：是否满足自身测试功能和测试场景需求、是否能够让企业员工简单方便的使用和推广、是否满足自身企业未来 3~5 的测试规划和发展，当然必不可少也是非常核心的一点是否 “高性价比”。

在供应商看来，一个好的测试平台需要具备的因素包含了：是否满足市场上大部分企业测试功能和测试场景需求、软件的技术架构是否能够支持行业未来 3~5 年的发展、是否具有较高的市场知名度和企业采购率。所以综合上诉两方面来看，企业视角和供应商视角看待一个测试平台有相同的点，也有不同的点。就是由于不同的点过渡 “激化” 导致上述关于平台 “优秀” 评判的不一致。但是综合企业和供应商的的角度来看，评判一个优秀的测试平台还是有着很多类似的观点：

并非功能越多的测试平台越优秀。在功能方面，企业会从自身现状考虑，除了具体的测试功能外，还包含人员管理要求、测试规范要求、系统集成等等，而在这些功能要求里面，功能要求往往较为靠后。而用户需求和企业需求的排序正好相反，功能一般都为第一需求。所以一个测试平台能如够满足测试行业 80% 的企业需求，满足 60% 的用户需求就不失为一个优秀的平台，当然达到这个满足度也需要有测试平台在需求平衡和功能设计做好平衡。
在易用性和功能性之间能够取得非常好平衡。一个平台好不好用，在企业能不能不能被广泛接受，易用性要大于功能性，市面上也有过功能非常非常多的平台，但是企业内部无人愿意使用的情况，就因为过度配置和使用复杂导致。
能够形成市场一种标准，这边所说的标准并非功能上的标准。而是用户市场（非企业市场）使用标准。由于 IT 人员的流动率现状，所以用户市场对产品的接受度高，背后亦代表着产品在企业中使用率不会低。而开源是最快扩大用户市场的模式之一，红帽是此模式最为成功的企业之一。

四、企业为什么要建设测试平台

当然测试平台是否优秀，并不是企业一定要建设测试平台的必要因素，那企业为什么要建设测试平台？

测试平台是测试服务化的必经阶段，测试平台是测试服务化的支撑平台。几乎每一个软件企业都对测试有着严格的定位和要求。尤其互联网 +、数字化转型之后，更多的企业主意识到了软件质量高背后所带来的极大商业价值，而企业如果需要将测试作为一种服务（测试服务化代表着企业测试的高度规范化、标准化以及测试结果的高质量和可信任）在企业内部推广，则需要一个测试平台作为支持基石。
测试行业的发展，测试的种类变多。工具只解决的具体的功能问题，没有解决企业在测试管理和规范上的要求，工具的价值体现在个人维度，而测试平台的价值提现在能够提升企业管理和团队的能效。
DevOps 发展逐渐成熟与持续被企业采纳和实施。企业关注点逐渐从 CICD 工具链建设转向软件研发效能提升、质量度量。而质量度量的建设，由于测试种类多样化，工具多样化等，测试数据度量这块一直较为滞后，而测试平台的特性（上述第二章）能够很好的弥补这块的欠缺。
软件市场的高速的发展，未来任何企业都是一家软件公司，而有软件的公司都需要进行测试。所以对企业而言一个稍微复杂点的软件测试的标准就无法依赖单一工具或者 DIY 式测试平台解决（DIY 测试平台人员的招聘成本、培养成本、学习成本，还有 DIY 平台的可持续衍生发展成本都是非常大的隐性开销）。
不同于软件开发，在测试方面大部分形成规模化的企业反而不太希望，某一个测试人员 “能力特别强”。究其原因，也很简单，个人的 “炫技”，只能解决一时测试问题，无法帮助企业持续、持久的解决测试本质问题。而测试人员如何展现自己的测试能力 “强”，往往代码脚本方式编写测试用例是一种普遍的衡量标准，因为大部分企业无法要求所有测试人员遵循 “编写代码脚本测试的要求”，除非测试人员能将其个人能力转化为企业可持续测试能力。

五、如何建设测试平台

从上述这个角度来看，个人认为测试平台架构设计上在如何满足企业和用户的需求是非常关键的一点。具体来说应该需要包括以下几个方面：

统一的用户/租户体系：尽管测试平台提供了多种的测试能力，但是需要将这些能力提供暴露给最终的用户，所以建立一个统一的逻辑用户/租户体系，并和企业现有的组织管理架构进行映射比不可少的关键能力之一。
完整的权限管理体系：测试平台的使用者不仅仅是测试人员，同时也有开发人员、运维人员等。测试平台需要具备权限管理体系，实现人员、角色和功能权限的解耦，从而可以让企业非常方便地建立出一套符合自己企业内部实际情况的测试权限管理管理体系，不同的角色人员在测试平台中依据其职责边界开展工作。
完备的 API 访问接口：大部分企业建设的 DevOps 平台或者 CICD 工具链，都已经提供相关的 API 访问接口。测试平台在这方面的要求也必不可少。测试平台作为独立一个环境，它必然要和其上层或者同级服务进行数据交互。
测试工具兼容能力：企业测试经过了很长时间的累计，在不同的工具商累积的大量的测试用户或者测试数据，测试平台应该支持用户一键导入现有测试工具的数据至平台中，比如 PostMan 接口用例、JMeter 接口测试、Swagger 接口等脚本、Selenium IDE 自动化脚本，最终实现统一的管理。
灵活的协议体系：虽然软件测试包含了常规的 HTTP 协议的测试，但是不同企业、不同行业、不同的场景，对于测试的协议有着不同的区别。测试平台应该支持将测试协议的支持与平台进行解耦，灵活的支持用户通过自定义开发协议方式在平台中开展其特需协议的自动化测试和性能测试。
大规模横向扩展能力：不同的企业测试团队人员从几人至几十、几百人都有。测试平台应该支持调度测试资源池的方式支持测试机的动态扩容，所有的测试任务，无论接口测试、性能测试还是 UI 自动化测试都可以采用资源池的方式调度与运行。可以同时满足几人到几百人团队的高频测试需求。