实际工作中肯定都是基于业务展开的，自动化或者性能的落地都必须与业务强关联。举个例子：前司的自动化测试一开始是一个单独的部门做，是与测试执行团队独立的，结果开发出来的自动化测试工具在推广和应用的时候效果并不好，还提出了全员自动化测试的口号，结果由于每个人的 coding 水平参差不齐，手工测试的时间还压缩一部分给自动化了，导致测试进度缓慢且产出低。在实际工作中跨行业（指的是完全无关的行业）跳槽的应该还是少数吧，比如我之前是做金融行业的，可能跳槽的时候会找相关的领域的企业，大概率不会去找一个做交换机的公司，这其实也印证了精业务的重要性。

感同身受。自认为是一个精业务、懂技术、会架构的测试人员，且在项目管理和团队管理方面也有一些经验。但是面试的时候有很多面试官都过多关注自动化知识，性能测试工具的使用，对底层逻辑和测试策略聊之甚少，岂不知工具只是解决问题的手段，深入理解业务和架构，结合有效的测试策略才是精准测试的根本之道。

人在郑州，我的建议是保持现状。

从你的描述来看，需要的是一个 PQA 的角色。

同意三楼四楼的意见。自动化虽然听起来很高级，但是并不适合你们团队的现状且不能解决问题。单就功能测试方面也有很多可做的东西，就比如测试左移，我认为就可以对你的现状有改善，测试更多的参与到需求分析，设计，编码阶段，负责做保障，提前提出不合理的需求和设计，将问题提前解决，这也是一种突破。

首先，你说的这种交叉测试是有必要的，保证组内不止一个人熟悉对应的功能模块。我们的解决方案是：每个产品/模块有一个专门的负责人，这个人会主要测试该产品/模块，但不一定在每个版本都负责测试该产品/模块，他会参与到该产品/模块新需求评审，负责相应用例的维护，业务流的梳理与面向组内共享培训。相当于给每个模块安了一个唯一责任人，他需要搜集平时该模块的发测版本，每个版本测试中的问题，及时修正补充，根据需要给其他组员定期分享该模块的业务（内容不限，可以是新的功能，新版本增加的用例，问题定位总结等）。测试中遇的问题需要向这个负责人请教，这样也能保证及时了解到版本测试以及漏测情况。

前司有自研的测试管理平台，所有测试计划，任务，用例执行，bug 管理都在上面完成，但是用例必须 excel 导入。大部分人平时喜欢用 xmind 写用例，所以用了 xmind2testcase 工具二次开发，生成可以导入的 excel，用起来还挺不错的。

问题发生了，测试肯定是作为第一追责方的，这个无论在哪个软件公司都是一样。
对于这种问题：
一是总结教训并改进以避免下次再出现。
二是后续工作中要留底，对于临时插入需求且多方评审的结论要有会议纪要输出避免背锅。
三是作为测试遇到这种事情不能怕，会议上问到你了要勇敢站出来讲，陈述事实就行，该担的责任就勇敢承担，不是测试的责任那也要说清楚，不能为别人的错误买单。

使用 python 语言往消息中间件推送数据是极其方便的，学习门槛也不高。网上范例一大堆。重要的是要理清楚推送的数据结构，以及数据变化范围。尽量达到模拟真实数据的效果。

连 VPN，开远程桌面都只是你测试的前置条件，不是你测试的对象，这些前置动作可以做成一键式或者自动执行。重点还是要放在你远程的机器上搞 UI 自动化。