倘若互联网的尽头是编制、当下是互联网的寒冬，他就是个帅气的逆行者。
以下内容是根据 2 月 23 日的直播整理的文字内容，戳链接可收听完整音频分享。
如果在同一家公司做测试时间做太长的话，能学到的东西会是有限的，对个人职业发展来说容易有瓶颈。当然这个观点不是绝对的，在 BAT 这类大厂，待得时间久一些对个人能力提升是非常大的。但是，并不是每个人都有机会进入大厂，所以我更愿意去尝试一些不同的行业，去突破自己。
在不同的公司或者行业能学到的东西也不一样，就拿我在保险和银行的测试工作来说：因为它们背后的业务知识、业务属性，还有测试的方法都会有不一样的地方，在保险和银行工作的那几年对自己业务和产品方面能力提升都很大。后来在外企的工作经历，让我更好的实践和更加深入的学习了敏捷和 DevOps。
我给我自己的一个总结就是：尝试不同的行业，然后去突破自己。
第一个方面，以银行为例，金融业对安全性的要求很高
在银行在做测试的过程中，有一部分工作是做安全测试。为什么去做安全测试，因为在银行系统里面有很多开放的 API（Open API）。如果说这些 API 存在一些安全隐患的话，可能会导致银行的资产损失。
另一方面是业务复杂性高
还是以银行为例，不光要跟自己银行内部的业务去打交道，还要和央行或其他的一些银行的系统做对接。
补充：保险行业也是一样，一个保险核心系统，可能要对接不同渠道方的系统、理赔系统、收付费系统、监管系统等等。
第三点是关于测试数据
银行和保险数据链路非常长，在测试的过程中测试数据是非常难创建和管理的，因为数据不仅涉及到本行的业务还要对接央行系统以及其他银行系统，所以很难在短时间内制造出符合各个不同系统要求的合法数据。
电商行业相较于金融业，业务复杂性没有那么高，测试造数比较管理。电商行业更注重用户体验，是以用户为中心和驱动力。
测试经理工作中也需要技术基础，但是更多的是管理的能力。
一个测试团队中的测试经理，要制定测试计划，推动测试计划执行，还有包括活动反馈收集和测试人员管理等。
而测试架构主要是技术向。测试架构师需要多站在企业的角度来考虑问题，比如说公司可能在面临测试转型，怎样提升测试团队工作效率？解决测试领域的痛点？这时候就需要测试架构师利用自己的技术经验，设计合适的测试框架以及效能工具，引导和帮助测试团队，建设质量内建体系等。
总结一下，测试经理偏管理，测试架构师偏技术。
补充：在小公司，或者小型测试团队中，确实也存在测试经理负责测试架构的情况。但是对于测试人员多的大型测试团队，管理和技术领域划分清晰，测试经理和测试架构师的不同职责就更明显。
在自己的职业发展中，这个问题也困扰过我一段时间。刚开始做了一段时间测试管理后，因为很多的精力都投入在团队管理上，技术这一块就被落下了。当时就想，我到底是走管理还是走技术？最终我给自己的答案是：能够在公司需要做管理的时候，去做管理；需要我们去做技术的时候去做技术，这样是最好的一个平衡。
我本身其实比较喜欢技术方面的工作，现在做测试管理的过程中我还会坚持写代码，平时也会去看 Spring、Spring Boot、Spring Cloud 一些框架的源码，提升自己的编码能力。我觉得作为测试、作为一个技术人员，在任何时候都不要落下自己的技术能力。如果丢了自己的技术去做管理，有一天你可能会后悔。
另一方面，（职场上）到达一定位置的时候，资深和专家岗位本身会有管理的属性在，管理和技术并不是完全分裂开的。
比如资深测试工程师不免也要带人一起做事，那么就需要” 管理 “团队中的成员。
总结下来，我比较认可技术为主，管理为辅的策略。
在自动化的道路上，我自己曾经也走过很多弯路。最早期从使用开源工具，进行自动化测试。后来就发现这些开源的工具或者平台，无法满足实际使用的要求，就走到自主研发这条路上。
开始用 Python、Java 做了一段时间后发现跟自己自己的设想还是不一样。那段时间一度怀疑自动化是不是真的能解决问题。现在回过头来发现其实是当时只是解决了表面问题，没有解决自动化难题的本质问题。
在自动化测试平台建设的时候我们要考虑是为了解决什么问题、目的是什么，以及如何真正实现测试提效、研发质量度量，不能让自己的自动化测试平台变成一个发现不了问题的花架子。
我自己总结的关于高效自动化平台的标准有以下三点：
第一点：测试提效。想象一下，当你的测试用例有一千条一万条的时候，维护成本是非常大的；如果能够通过自动化测试技术创新，大大降低自动化维护、投入成本和执行用例的时间等，那么这就是一个很有价值的实践也解决了自动化的疼点。
第二点：质量保障，研发团队认可。在运行完自动化之后能发现 bug，并且发现 bug 的准确率高（90% 及以上），能够实现对研发质量的度量。在 DevOps 流程中测试自动化能够融入 DevOps 平台，做研发质量的卡点。
第三点：是企业级可复用的平台。一些大型企业中可能有很多团队，按照以往的模式，可能每个团队都有自己的自动化框架或者工具——这种模式对企业来说，成本是非常高的。如果说你的自动化框架在企业内部是可复用的平台，每个团队都能使用，也就是我们常说的 “测试中台” 概念，就能够帮忙企业实现降本提效。
去测试化，并不是说不需要测试，而是对测试人员的技能要求更高了。
不会写代码，只会手工点点点的功能测试应该行不通了。在未来的话，我觉得技术是基础，我们测试人员要有研发 60%~70% 的编码能力；再加上我们做为测试独有的测试方法和测试理念，从不同的维度进行提升质量和效能的工作。
我们要不断地提升自己的核心竞争力，不被去测试化。
今年可能会尝试做一些开源的工具，另一方面可能会写一本书。写书这件事，其实去年就已经开始规划了，但因为工作太忙，没有坚持下去。今年的话，会把这两件事做好。这本书也是自己的处女作，书的内容是偏技术方向，关于测试技术和实践经验的分享。
