我感觉这个产品的演进方向大变，而且是在偏离测试赛道，想走软件产品的全生命周期。这可能是一个错误！
什么是开源？使用开源的人群是什么？
作为一个老测试员，我以前为什么选择 Metersphere。
1、用例：在线的 XMind 编写器 + 用例管理 + 用例评审 + 报表统计。测试计划、缺陷管理、测试报告说实话很鸡肋，这些功能必须结合软件全生命周期的管理软件，都得关联到需求及其软件研发的 Stakeholder，这套逻辑产品市面上太多竞品以及成熟产品了，开源、收费的多得去了。
2、接口、性能、UI 自动化等通用性的技术测试工作，可以有统一的平台，且都是结合市面开源的大家用得多的工具链，如 postman\jmeter\selenium 等，可以一份脚本多用（虽然还是要细微调整，但是还是节约很多工作），招聘的人可以快速切入工作，支持可视化脚本编写，也可以自己开发脚本。还可以管理性能测试时多肉鸡管理。。。。

但是现在这个方向很多优势都没有了，回归到非常平淡接口测试平台。

首页这篇文章写得牛，也非常赞同无数据不管理，绩效不能凭感觉给。
但是我几个疑惑点，不是质疑作者哈，只是想探讨一下：
一、这些指标数据高度依赖人的意识感知、使用项目管理工具的粒度、搜索数据的完整度、项目实际运作成熟度等。
1、如何保证每个需求都记录在案、且不同产品人员在同一产品线对需求的拆分粒度是相当的？ ==>决定了业务交付吞吐率的相对准确性。
2、如何保证评估工时和结果使用工时都记录在案、且记录数据是准确的？
3、测试自动率本身就是一个很大的指标，它的有效率、个数、覆盖率如何保证是相对准确的？提测时间如何保障准确记录在案？
4、开发自测通过率、冒烟前覆盖率、冒烟通过率如何记录在案，且没有受到认为影响？
5、缺陷记录在案是的粒度如何保证不同的测试人员提交的 bug 在同一模型下？例如，有的测试人员同一类的 bug 只提 1 个，有的却提很多个，一旦成为 “业绩” 的衡量标准，整个风向维度就变了。
6、用例设计的粒度也是跟第 5 点一样，缺陷引入率还需要测试主动管理需求，如果乱关联、不关联等。。。
7、用例是否记录到项目管理工具，回归用例选入管理执行计划，是否真的执行？
。。。。。。
以上种种，还有很多因素，在中小公司的研发团队，甚至大公司的研发团队里头都没办法保证这些数据来源的数据准确。
自己活儿都干不完，还为了保证你搜集这些数据投入大量的人力物力来保障效能度量工具的基础数据，这与效能本身的出发点是否就有点背道而驰了？

这种工具忽悠大老板还是相当适用，实际中层管理者落地推行，可能有很多阻塞点。
个人觉得，这些指标可借鉴，但数据源得全部选自于团队自身随意而为的数据，而不是固化这些数据，然后结合团队当阶段实际情况（项目、个人、特性、成熟度等仔细分析），有时候你可能会发现你会得出跟数据完全相反的结论。

个人意见：数据必须有，得分析，仅参考，不直接使用。