处理这类问题的时候我们一般是跨一层解决，上面说线上 bug 多，你要知道是谁告诉他的就是谁在跟上面施压，你做这个方案你上面要拿来给别人交代的
比如是老板或者客服头头反馈，那么出的方案就要忽悠住老板或者客服头头，为什么说忽悠，这只是方案不是结果，无非是看了觉得靠谱，又不是定期存款
客服他不关心你 bug 什么等级优先级他也没必要懂，能减少他的工作量他做的舒服就会少比比，反过来用户高频使用场景问题少他的投诉是不是少
如果是老板，那就要你适当的问你的上面透点口风，是弄的专业点还是高大上就看具体了

我这一般是用 explain 看 select 的各种条件是是否用了索引

很对，这个社会就是这样，盈亏同源，你赚的是别人亏的，同样作为一个普通人深知经济链跨越的艰难，有的人手里四个 2 一对王，自己手里只有 345，命运只负责发牌，打牌的还需靠自己。你有自己的交易体系就赢了 90% 的人了，我的肯定不适合你，只要坚持活下来，就有机会赢，共勉。

嵌入了简型精准测试模块，并持续完善

能点的技能点满，作一个合格的工具人，具体可参考培训学校的大纲，人家培训出来目的是为了就业。
工具人只是起点，有口饭吃，然后看看距离你最近的上层是谁，学习他然后复制他，毕竟你走的路他大部分也走过，而且他也干掉了与之竞争的不是。
上面是就个人来说的，就整体而言，当你发现你即使复制了他也不能成为他时，比如不能升值加薪，那么你就该换个环境了。
以上是一些个人的浅薄认识

AI 给的答案，仅供参考。

你才 6 年 我这都 10 年了还是功能点点点

从机的 Stepping Thread Group 插件装了么。分布式压测是将整个脚本的 HashTree 推到从机

首先要确定 PLC 使用哪个指令集，这个可以根据设备型号获取，比如西门子等
根据指令理解程序的逻辑，判断输入和输出是否正确 (测试用例)
ps：还要测下兼容性，有的机器型号对程序支持的不同，这些涉及到硬件。现实中可能出现一些意想不到的情况，比如电压，空气潮湿等。

分布式压测，源码是将整个 HashTree 都推送到从机去执行的，然后结果又是汇总的。
看不出来具体哪个机器的性能如何，可能 jmeter 认为测试的机器默认配置都一样

可以试试启用线程去执行 subprocess，同时记录这个线程的 id，处理完业务需要关闭的时候杀掉线程:

t1 = threading.Thread(target=***)
t1.start()
self.tid = t1.ident  #获取线程id
#业务代码
_async_raise(self.tid,SystemExit) #强制关闭线程

def _async_raise(tid, exctype): #关闭线程方法
    """raises the exception, performs cleanup if needed"""
    try:
        tid = ctypes.c_long(tid)
        if not inspect.isclass(exctype):
            exctype = type(exctype)
        res = ctypes.pythonapi.PyThreadState_SetAsyncExc(tid, ctypes.py_object(exctype))
        if res == 0:
            # pass
            raise ValueError("invalid thread id")
        elif res != 1:
            # """if it returns a number greater than one, you're in trouble,
            # and you should call it again with exc=NULL to revert the effect"""
            ctypes.pythonapi.PyThreadState_SetAsyncExc(tid, None)
            raise SystemError("PyThreadState_SetAsyncExc failed")
    except Exception as err:
        print(err)