那就解决自研平台的问题呗。

把使用中的问题记录下来，并表述清楚这些问题严重影响效率，然后反馈得领导，借助领导的力量去推动平台维护方解决。当然就算解决确实不及时，也先用一段时间吧。

其实你第一句已经说的很清楚了，领导要强推这个测试平台（都和绩效绑定了，足够明显了吧），不管好用不好用都得用。那你的沟通就应该要先遵循这个大方向，然后在大方向下提问题和寻求解决方案。你提出用开源框架，和团队的大目标不一致，当然会被否决。

一年前在 a 项目中用过，提了不少问题，回复的是在排期，左右拉扯。。最近转到 b 项目，发现去年提的问题还没有解决，真是心累

这个平台的落地情况是领导的 kpi，你清醒一点，不完善就迭代开发完善，造个轮子而已，不一定要用开源框架。

我也是这么想的，和他们三番五次沟通，也一起拉过领导，但收效甚微，现在严重质疑搞工具那帮人的能力

二楼说的非常正确，领导要推动的事情、和绩效挂钩的，就算现在认为是有问题的也需要坚决执行，但是可以跟领导沟通一下目前的问题就好，但是提出问题的同时，最好有相应的解决方案，领导更喜欢解决问题的人

我现在做的很多事情与本身工作和绩效无关的，都是领导安排的，不得不做，你现在的情况比我好多了

领导要求使用测试平台，称只有通过测试平台统计的接口覆盖率才能作为年底绩效指标。

这就是你现在的工作目标，应试考核，问题多就先把 kpi 顶上去再说

你们领导的目的是想推动平台的落地和建设吧，大多数平台落地都有这个问题，不过还是要硬着头皮上的。
使用过程把问题都记录，推进老板去解决呗。

这种情况很正常。其实领导自有领导的安排与考虑，所谓平台，就是要各项目共用，发现问题再解决问题，即使按题主说的采用新的开源框架，有可能一样有问题，只是没遇到，所以我们还是要减少重复造轮子。尽量去维护原来的平台（之前应花了不少人力造的轮子），抱怨一下无妨，但重要的是要主动去解决当下的问题，问题解决后，为了防患问题的重现，建议可以主动制定平台维护或开发的机制，再与领导商量，以便团队的长治久安。（长远打算）

你不能看平台的代码吗? 别人不修你自己修不行吗? 是不是你提的问题没提到点上? 足够牛逼的话是不是自己就修了
实在不行自己写一套. 这玩意儿有啥难的？

测试平台很多，开源的也很多，找到符合要求的就行；没必要自己造轮子

建议让自研平台走公司项目流程，定期统计 bug 情况反馈给领导，用数据说话，平台从新生到成熟总有段过程