针对这个问题，我也请教了多位测试行业大佬，收获了诸多不错的建议。
其中，一个观点给了我比较大的启发。我们可以反过来看，现在有了这些测试工具平台各个项目组可能都在用，那假如没有了这些测试工具平台会怎么样？是毫无影响？是变得有点不大方便？还是无法正常开展工作？问题越严重，说明工具平台本身的价值就更大。这也可以作为我们不断自我衡量工作成果产出价值大小的一种思路。
但要更好地进行量化，用户使用率会是一个比较不错的度量方式。
回归工具的属性，假如一个工具真的能帮助项目组带来价值，不管是效率优化还是质量提升方面，那么项目组成员肯定会更多地使用该工具；否则，项目组成员完全没有理由在这些测试工具平台上投入时间，因为使用也是有人力时间成本的。特别是在没有强制要求项目组使用的前提下，最终工具的覆盖用户范围和使用频率更能充分说明问题。这和当前各商业工具平台追求的用户数和日活数也是同样的思路。
因此，在 2019 年，我们也打算改变下思路：
1、在质量部总体层面，不再对各项目组制定自动化测试覆盖率的目标要求，对于项目组测试人员的考核方式也不再关注测试工具平台使用的情况，最终只重点关注交付效率和线上质量两大维度（统计方式同上）。
2、对于测试开发团队，测试工具平台的价值展现将更多地通过覆盖用户范围和使用频率进行展现；若要更多的提升用户范围，那么就需要更主动地去挖掘业务项目组的痛点，让开发出的工具平台能帮助更多的人（目标也不再局限于测试人员）解决实际工作中遇到的问题；而要达到比较高的使用频率（日活数），那么就势必要提升平台的可靠性，对问题反馈进行更快地响应，以及进行更多的宣传和推广。
当然，除了用户使用率（覆盖使用人数、日活数）这一类最核心的指标，我们也会关注其它的一些指标，包括：故障响应效率、平台可靠性、发现问题数、口碑评价反馈、响应需求数等。总之，这些指标都是可以明确度量和展现的，并且所有指标最终都将指向用户的实际使用情况（Adoption Rate）。
写在最后
有时候我不禁在想，做测试开发这个岗位也真挺不容易的。我们不仅需要负责需求规划和交互设计（想清楚要做什么），然后是开发和测试（将想法实现落地），并且要花费较多的时间和精力去进行推广（获取反馈及时调整），最后还要对工作成果进行度量和展现（收获价值认可，获得更多资源），只有我们开发出的工具平台最终在各业务项目中得到了很好的应用，才能说明我们的工作成果产出了价值。
这个过程跟创业真的挺像的，我也一直都是希望我所在的测试开发团队能更多地用创业的心态来对待我们的工作，而整个经历的过程，也许就是最大的乐趣所在吧。