从测试框架向测试平台的切换：某即时配送平台拜访回顾

hybridmisc

大概十年前，Quality Center(QC), Quick Test Pro(QTP), LoadRunner几乎是每个测试从业人员都耳熟能详的经典测试工具。那时候会自动化和性能的测试工程师都很抢手。

再后来，开源测试工具如Selenium逐渐流行起来，整个测试行业开始拥抱开源，一部分测试从业人员开始倒腾和研究框架，比如Web自动化框架。

Selenium

当微服务出现并盛行后，PostMan开始家喻户晓，和Jmeter一起成为开发和测试最常选择的接口测试工具。

Apache JMeter - Apache JMeter™

随着接口数量的越来越多，接口测试越来越越专业化和团队化，接口测试工具的缺点慢慢开始暴露出来，分散（想想几百几千个接口测试用例分散在各个开发、测试那里），无法协同，不利于团队提效，同时这些工具迭代升级慢，更谈不上 什么售后服务。

​

​

​编辑​

这时候，接口测试框架开始出现，测试团队开始开发和维护维护自己的测试框架，整个团队基于该框架开发接口用例，同时也能集成到CICD流水线，皆大欢喜。慢慢地，随着接口用例的越来越多，项目越来越多，接口测试框架的缺点也开始暴露出来，时间和人力维护成本越来越高，新人上手门槛高，无用户界面或交互太差，新的框架需求出来后无法及时响应，动一发而影响全局其它已有用例。

测试平台化逐渐在整个行业开始出现并被大家接受，核心思想是测试团队基于平台管理和开展测试工作，实现全面的测试协同，和效率度量，度量团队和个人的测试产生。新的测试工种测开出现并野蛮生长，薪水报酬也水涨船高。开源社区也出现了一批开源测试平台，其中也包括我们MeterSphere，一站式持续测试平台，截止到今天在http://github.com/metersphere上收获超过8200个star。

http://metersphere.io

​

​2021年底我们受邀去上海某知名及时物流平台（美股上市）进行产品技术交流，从交流得知该公司测试团队已经使用了MeterSphere一段时间，并且将接口测试搬到了MeterSphere。他们之前基于Python接口自动化测试框架RF(RobotFramework) 维护了几千条接口测试用例，期间随着人员的流动（互联网行业，正常现象），之前留存的几千条用例维护成本越来越高，后来的人需要花大量时间阅读之前同事写的接口自动化代码。使用MeterSphere一段时间后，他们把新接口测试放在MeterSphere上，找我们技术交流的目的之一就是商讨将已有的基于Python语言的接口自动化用例迁移到MeterSphere。

类似的案例，我们碰到挺多，核心还是想把基于框架的接口自动化测试转换为基于平台的接口自动化测试，实现整个测试团队接口测试的全面协同。同时将测试人员，测试脚本，测试报告，测试数据等诸多测试资产的管理全面平台化，实现测试效率的全方位度量。 高级的还有把测试平台和研发效能平台集成到一起，和需求管理平台如JIRA或禅道或tapd等实现对接，让测试管理不再孤立于公司其他平台。

最后我们看一下MeterSphere+DataEase这两个开源软件组合的效率度量效果：

​