其实个人觉得 D 接口自己构造一些业务数据直接压就可以，对于业务来说，场景里 D 接口查询的是不是 jmeter 压的 C 接口数据应该影响不大，对于 C 接口我一般会写一个脚本去统计业务异步处理的正确性和处理时效，这个也是一个性能指标数据

补充你的观点，有开发能力搞测开，我就不能图测开不加班不出差到点就走？没有业务上线压力那么大？需求设计一个部门内就搞定不用多部门扯皮？一个人前端后端设计全部搞了效率高？每次看到有开发能力干嘛不去干开发就心里不舒服，干测开就活该没啥开发能力？

额 把那个什么临界部分控制器 disable 下试试呢 看起来有点像多并发下的锁 我记得默认情况下脚本本身就是按顺序执行的 只是因为多并发的原因 结果树显示会有错乱

待执行的用例应该会以测试计划的维度来管理吧？前端展示测试计划的执行进度就可以，不过完整的执行过程不一定就只是用例执行，我这边还有测试报告生成、覆盖率数据生成、钉钉通知之类的，所以我这里会列出每一个待执行任务以及完成情况，用例执行任务处增加进度条，以已执行用例数/总用例数作为百分比显示执行进度。至于主要信息，日志及结果记录绑定每次运行的编号及执行的用例编号扔到数据库，前端就可以展示了

TPS 如果没有线上业务数据，我一般是用 28 原则来算，A 项目的 300 万事务量都不用乘 0.8，算 365*0.2=73 天全部跑完，每天业务量 300 万/73 约等于 4 万，4 万按 28 原则算也不乘 0.8 了，40000/(24*3600*0.2) 约等于 2.3，所以实际业务 TPS 预估到 3 就够，一般这种情况，我会给客户方一点面子，乘以个 10，TPS 定 30。这个是指标要求，跑一个小时无所谓，这个是验证一定压力下的短时间稳定性，关注重点在系统业务处理是否报错，系统资源是否问题。至于 B 项目就有点扯淡，你得直接回怼回去，2500 人提交审批又不是定个定时器来提交，如果要支持 2500 并发，需要另外设置场景，但 2500 并发的场景你得确定要达到的性能要求，性能要求高的话除了优化代码和配置策略外，大概率需要大集群来支持。至于 TPS，我还是觉得按业务量来算，不过你可以再给客户方留点面子。。。

感谢回复，前控控件和后端接口的映射关系，这个倒还好。主要是你说的第二个问题，比方说：通过前端解析，最后发现是一个确定按钮调用了后端一个/addUser 的接口，而这个确定按钮又在一个叫用户信息的 dialog 窗体中，而显示这个 dialog 又需要点击一个用户管理页面的新增按钮，要转到用户管理页面可能还是一个路由跳转，如果只是通过前端代码静态解析且都准确（请教有干过这个事的同学给个思路 ），那能拿到只能是用户管理 - 新增 - 用户信息 - 确定这样一个控件链路与接口对应。但是我和功能测试人员讨论的，他们想要的其实是"用户管理 - 新增用户"这个功能链路与接口对应关系，因为用例就是以这个维度来维护的，前面的控件链路对他们来说没用，因为他们看不懂前端代码。这样就能通过精准分析获取到的接口影响范围拿到前端功能手工测试的功能影响范围。可这就需要有个功能业务和控件的映射关系表，如果不能自动生成而要手工维护这个表的话，工作量太大了，而且还要实时根据前端变动来更新这个表。

最近刚好也在做精准，做的东西和作者很像，但是碰到个问题，如何获取后端接口和前端功能的对应关系，在产品开发前期没有这方面积累的情况下，想通过前端代码去做分析扒出接口和前端控件对应关系，即使成功也是控件的链路而不是功能的链路，而且还要面对各种前端开发框架的复杂局面，请教下这块作者有什么思路不？

个人理解：
1、查询本身也是接口，它的查询结果正确性也是未知的，以未知作为期望值还是有风险的
2、接口测试本身来说不应该依赖别的接口来做数据性校验，批量执行时，查询接口出问题，当前接口自动化用例其实相当于没有执行完成。流程性用例也应该是把当前接口作为前置用例来验证查询接口本身。
3、不一定所有需要校验的数据都可通过查询接口查询出来

我能想到的就 **，这个还能打出个 a 来：

def get_para_name(**kwargs):
    print(kwargs)


get_para_name(a=1)

多线程