😂 感觉这样的话弄着弄着后面就真的没法维护了

谢谢，目前我也打算这样弄

了解了，谢谢

插个耳机？

针对你的几个问题我的理解是：

2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖 app 的功能。

依据用户行为覆盖功能也算是一种场景测试方法吧，这个也算合理呀

3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。

这个是指脚本还没运行还是脚本还没开发完成呢

4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。 该怎么来规避？

异常现象是指的是脚本出错还是程序出错呢？脚本出错的话就要具体原因具体解决；程序出错的话，是不是说明出现 BUG 了呢

赞同，这种图形化式平台真的不好用

想了解下，你们那对 “造数 + 平台” 这种方式的用户和领导反馈是咋样的呢？

我这边的理解是，平台或框架都是为了业务而服务，所以能高效完成业务测试目标就行。所以造数脚本如果能提高效率，那也可以尝试下哇，至于平台使用率，感觉不是特别重要，菜鸡的理解哈，可能存在错误

接口测试的前置数据准备，图形化平台的 for 循环，变量的提取调用，数据库连接的封装，会感觉比用代码实现复杂度还高，不够灵活。用造数脚本的话，感觉会好很多，且造数脚本也可以平常手工测试时使用。

是的，接口测试平台直接以 http 方式调用 flask 的造数服务就行了

谢谢大家的建议，我这边还是准备继续找下一家了

谢谢，去外包看了一圈还是准备跑路了

确实，今天去看了下外包环境，和你说的一样，各种不舒服，已经决定跑路了

感谢各位大佬的回复，看了下大家的讨论，还是决定先手动处理把，等后面业务达到了一定高度在评估是否自动化吧。

那么你通过 git diff 看下改动的代码文件路径包含哪些 service 的文件夹，然后就只运行这个 service 对应的 docker build 命令，是否可以？

这个是可以的，单独的建 job 就行。
但现在的问题点是，Jenkins 怎样才能实现自动分辨 “代码变动的 service“ 并执行对应的 docker build 命令，而不是每次人工判断执行。

是由不同的 module 区分的

不好意思，可能我没表达清楚 。我的意思是，怎样才能从开发提交的代码里，决定哪些 service 需要重新 build？
例如，总共 3 个 service，开发第一次提交 “修改 serviceA 的代码”，第二次提交 “修改 serviceB 和 serviceC 的代码”。现状是这两次提交，Jenkins 每次都需要 build3 个 service。有没有一种办法让 Jenkins 只 build 发生修改的 service。

有个问题是，开发都是对一个工程提交代码，那么怎样从开发提交的代码判断需要执行的 JOB 呢？