这个要是测试能直接打回就好了。。。。。。人家产品才是说了算的人。
这个其实是 1 个现实场景中的缩影，就算那个产品经理已经考虑了这种那种场景，但还是有各种场景坑在里面。
需求如果完善的整理好，就该 1 篇 10 页以上的需求文档了，但目前现实是需求工程师这个岗位已经没有了，只有产品岗：只有我要什么就得做什么，负责的还会给你考虑各种情况，不负责的真得测试或者开发深入后，反向推动产品去完善各种场景。

好了，牢骚发完了，说下正题，这个是个面试题（所以需求比较短，而且背景就是针对就微信扫码支付场景）
一是看看测试人员考虑问题的全面性，是发散式的。这里面涉及等价类、边界值，也涉及页面与后端二次校验、幂等校验等等：直接反映出测试基本能力：你能保证自己的测试足够充分吗（这个可是支付，容错性要求可是极低的）
二是看看测试人员做事方式，是找到一个问题直接撂挑子，还是罗列尽可能多的方式找产品沟通并一一确认。

可以质疑啊
但看这个主题的标题啊。

上面是产品的定义。
至于你的考虑，只是一种测试需要考虑的场景。

appt= Flask(__name__,
             template_folder='templates',
             static_folder='static',
             static_url_path='/static'
)

检查下 static 的路径及 url 配置，其他的不知道了

locust 本地也可以多起 1 个或多个实例来提高负载利用

如果以下问题需要先排除：
【1】环境特殊的配置
【2】locust 的 bug
【3】压测机资源负载情况
【4】脚本中做了延长事务时间的处理（比如构造协议、复杂的断言、解析）

另外 locust 本身的压测能力是有一些不足的，这点 locust 和 jmeter 做比较的文章网上已经很多了：
因为 python 的语言特性还有默认的 requests 包都是影响 locust 压测能力的，官方也推荐大家使用 FastHttpLocust（据说提高 5-6 倍）。
但你说你的非 http 的，那你还想使用 locust 的话，建议换其他语言的 locust 的压测端，比如 boomer。

佩服啊，年纪差不多，看看我自己只能一声叹。
工作已经变成了大杂烩：除功能测试、工具、自动化；还兼数据爬取、帆软、安全测试...
感觉自己啥都做，但都不透，迷茫....

我手头没有导入 csv 的例子，但应该很简单的，使用 golang 的 csv 包读取 csv 然后进行自己规则化的脚本编写。
boomer 我只有改版的例子：https://testerhome.com/topics/31192

不知道是是否我理解偏差，文章作者的标题的 boomer 是这个平台的名字吗，还是在 locust 的开源的 go 实现的压测端。
如果是 go 实现的压测端那个 boomer，本身不带导入 csv 功能，需要你在编写的 boomer 脚本中编写 csv 导入的处理

可以采用配置文件的方式，将一条条 path 规则写入规则文件。
这里代码写遍历规则即可

boomer 是个 go 写的 locust 的压测端，本身是编译后命令执行的。
不知道你的 csv 为什么要导入 boomer？
你的意思是不是指标 csv 导入普罗米修斯吧？

可以试试 muggle-ocr

内部的，不过市面上的用例平台包括开源也不少了，还是要匹配自己公司及部门的规范习惯才是合适的。

我们这个不复杂，主要是 antd pro+flask，那个思维导图及流程图组件则是 gg-editor 改造的

目前 github 上各种接口自动化测试平台层出不穷，各说各的好，实在无从下手。
随着项目开发模式、架构的不断演变，测试平台也会更新换代，谁又能保证这个平台的生命力有多久呢

主要看新的需求是否以后是否需要维护及当前的 xmind 用例是否有保留价值呢？
如果有的话，xmind 的数据可以像其他楼层提议转化 excel 保存下来，或者就使用适合的测试用例平台是比较合适的。

对于一个持续进行的业务，除了考虑当前是否方便，也得考虑后续的维护、参考及协做了。

就我来说，类似 excel 表格方式及思维导图的方式、甚至流程图方式的用例都存在，毕竟各有各的场景及方便之处。
表格类型适合执行时一条条过，思维导图适合设计时发散思考，流程图更是适合便于理解业务及执行时清晰了解执行的分支覆盖情况。
不必纠正统一那种格式。
如果是要有 1 个平台或者工具统一管理及方便执行，那肯定是比较好的