进程和线程在操作系统层面效率是完全不一样。进程要做上下文切换，而线程是轻量级的跑起来快。用python去压，自己动起来就已经累趴下了，怎么能把别人压出来呢。。。

只要是测试，它就具有“从属性”，“从属性”意味着不是核心，不是核心就可以随时被开、被移除。测试开发和测试是IT行业发展阶段性的产物，阶段性产物意味着它是妥协出来的，行业高速发展，用于质量建设的人才梯队跟不上，就只能退而求其次的招聘点点点工人。行业越发展到后期，成熟度越高，人才梯度结构趋于合理，用于质量保障的角色绝对不是测试这个岗位，测试不会消失，但是岗位会。在未来，测试就是开发的一项必备技能，测试必然融入更大的技术洪流中，测试只是个研发的工序和基本技能，而不再是个技术岗位。

六楼正解

普通账户的脚本里写些不是它这个账户可以操作的脚本。比如，把普通账户加入sudo账户里，加入到root的group里。再比如，修改root的密码。这里面核心逻辑就是，使用高权限账户执行普通权限脚本，等同于高权限账户自己操作。

人手一个开发者工具并给开发者权限。

在有限的人力状态下，新技术如果可以提高单位人员的生产力，应该是没有问题的。现在我们单位代码规模扩张的很厉害，有3个团队加起来40多号人，10个以上的子系统，都有构建发版的需求，使用jenkins+shell驱动，把工具交付出去，让他们自己玩，生产力解放了。

经济的寒冬，创业的项目不是抱大腿（国企、央企、BAT一线互联）的，活下去都难。

很多执行层面的落地，单枪匹马是很难落地的。比如我，这一年抽空，研究代码静态扫描、apollo配置管理、docker、infer之类的技术，也搭出来了，但是没有落地到实际生产。原因很简单，我们这个团队现阶段不适合，业务价值为首要目标，业务优先驱动下，优化性质的工作，实际上并没有多大的投入产出比，就算有，也没有人手来做。比如要推apollo配置管理，框架是优秀的，但是我们的的代码框架已经固定，生产若干服务，要换下来，折腾个把月，还面临着生产不确定的风险，自己评估了一下，找几个技术到老和leader开会3次，我自己就放弃了，因为它落地真的在公司这个阶段不合适。这一年，我计划中所有落地的都是我自己能控制的技术，对团队干预最少，风险最小，投入产出比合适的。楼主说的性能大家不care，这个对团队来说就是在欠账，等业务规模上来，迟早要还的。要落地，感觉还是得沉到业务里面，找真的痛点啊。。。。中年危机真到了，加油干

或多或少的自己思考，使用过大神说的一些方法，成长还是感觉有点慢。大神的体系给渴望成长的测试很大的启发，真的有同感，本文应该知识付费。