一种解决方案是使用版本控制系统，在提交和推送更改之后，您可以在服务器本身上构建jar。你可以为此编写一个简单的脚本。
另一个需要时间和精力的解决方案是建立一个ci-cd管道，该管道将使整个过程自动化，并将大量手动工作减至最少。
另外，如果必须将jar scp到集群中，请尽量不要使用fatjar来最小化jar大小。

首先，现在上传70MB不需要几分钟。您可能需要检查您的网络配置。当然，如果你的网络连接不好，你也没办法。
一般来说，我会尽量避免集群测试运行。调试起来又慢又难。它应该只用于性能测试或在正式投入生产之前使用。
所有逻辑都应该进行单元测试。完整的工作应该经过集成测试，理想情况下，还应该进行端到端测试。我建议对外部系统使用基于docker的方法，并使用kafka的测试容器之类的东西，这样就可以从ide运行所有测试。
进入测试集群应该是一件罕见的事情。如果您发现任何自动测试没有涵盖的问题，您需要添加一个新的测试用例并在本地解决它，这样就很有可能在测试集群上解决它。
编辑（寻址注解）：
如果编写一个flink作业来生成数据要容易得多，那么这听起来是一个可行的选择。我只是担心你也需要测试这份工作。。。
这听起来像是你想要一个端到端的设置，在那里你连续运行几个flink作业并比较最终的结果。这是由几个flink作业组成的复杂管道的常见设置。但是，如果它涉及多个团队的组件，那么它很难维护，并且可能具有不清楚的所有权状态。我更喜欢通过拥有大量的度量（产生了多少条记录，在每个管道中过滤了多少无效记录……）和只评估（中间）输出质量的特定验证工作（可能涉及到人）来解决这个问题。
因此，根据我的经验，要么你可以在一些本地作业设置中测试逻辑，要么它太大，以至于你在设置和维护测试设置上花费的时间比实际编写生产代码要多得多。在后一种情况下，我宁愿信任并投资于（预）生产的监控和质量保证能力，不管怎样，您都需要这些能力。
如果您真的只想用一个flink作业测试另一个flink作业，那么您也可以在testcontainers中运行flink作业，因此从技术上讲，它不是一个替代方法，而是一个附加方法。