互联网公司未来开发测试运维产品职业发展走向的思考和预测

本是古典何须时尚 2022-09-17 03:19 160阅读 0赞

### 文章目录 ###

*  前言
 *  2021-10-25（北京）

# 前言 #

为啥会想到写这篇文章呢，因为在公司呆了有将近 1 年左右的时间，参与了不少项目也见识了不少职业的人，踩过许多坑，自然也引发了我不少思考，然后今天洗澡的时候在思考公司内的人员的组织结构的时候有一些感悟和想法，就打算理吗记录下来

未来的想法如果更新迭代也会往此稳重更新补充

# 2021-10-25（北京） #

这是文章的起始时间点，2021-10-25，此时的我在北京海淀区中关村某家互联网公司

这个时期内的互联网公司（我司内），大致角色有产品，开发，测试，数据分析这些类别。经过公司内将近 1 年左右的各种项目的捶打，思考发现有些角色似乎可以“转化”

**关于运维：**

以往的互联网公司存在运维的角色，因为那个时期的互联网公司运维的平台工具全部都不完善，所以会存在运维这样一个岗位角色，随着互联网的发展，平台工具的完善，软件部署上线流程越来越趋于固定化，导致运维这一角色是最快被“转化取代”的角色了，运维的职位趋于减少

**未来的运维：**

未来的运维的那一批人该做什么呢？传统运维行业的人会去做运维开发，开发 devops 的平台等一些运维平台，将这些平台当成基础服务提供出来给开发同学使用，对于开发来讲这些运维平台底层可能有很多较深的运维知识，但是对于开发来讲他们不 care，平台的使用降低了运维知识的学习成本。传统使用开发开发完之后，交给运维部署上线，存在 2 个问题：

*  开发开发完之后，运维上线，二者存在沟通成本，一个事情分给两个人去完成，就会存在两个人之间信息 gap 导致的风险（如果这整个流程交给开发去做呢，就不存在 gap）
 *  每次开发完之后，都要运维上线就增加了多余的人力成本（如果这整个工作交给开发去做呢，公司就不需要多出运维人力的钱）  
    以后的运维开发他们也有自己的业务，他们的业务就是“运维业务”，然后把开发的运维平台当成公司的服务提供给各个业务方来使用

**关于测试：**

以往乃至现在都有测试角色的存在，在小公司可能由开发来当测试了（小公司为缩减资金），大公司会存在测试的角色，这个是目前中国国内的现状。测试人员或者叫质量保障人员也存在很大的困境，他们非常的尴尬，因为他们要做的工作是开发开发完部署测试环境后来进行测试，但是一个合格的测试人员往往要做到哪些呢？

*  对业务的理解非常的透彻
 *  对开发的架构环境也很了解
 *  对运维部署上线业务要涉及

但是有多少测试同学能做到这些呢？我觉得太少太少了，几乎等同于 0，所以测试同学往往在项目工作中会处于一种很痛苦的局面，因为他们时常会遇到问题，什么问题呢？各种问题，比如各种业务问题，这个业务黑话是什么？这个产品数据是咋来的？这个产品这样设计的原因是啥？行业内产品的信息呢？如果一个测试人员对业务理解不深，他可能连最基本的手工测试都无法上手，因为他会读不懂 case；还有比如很多开发问题，这个环境部署是个啥意思？测试环境染色是啥？开发联调是个啥，能做点啥质量保障的工作吗？新的服务部署了架构是啥样子的呢，不知道架构如何做压测呢？如果一个测试不懂开发架构，他可能不知道哪里需要使用质量保障的手段，不知道如何做压测等等；还有很多运维问题，测试发现了问题，像排查日志咋排查呀？产品部署上线，但是开发流程不规范，怎么规范开发 devops 上线流程呀？可以看到这个时候各种问题就会涌向测试。测试人员也不是神仙，不可能一个人吃透产品研发运维三条线路，而且测试自己还有一些测试知识要掌握，对于测试人员来讲太难太难，所以他们每天会被各种问题萦绕，因为没法深入每一条线上，所以很难深耕。导致一个现象就是可以观察到现在很多测试人员都是一个比较厉害的管理者，因为他们变得善于和不稳定和疑问相伴，善于做交流时候问题化解者（虽然对每一条线都没法下钻深耕）

测试不会像运维那么早消亡，是因为测试设计到不同业务，每种业务测试需求无法像运维那样可以使用平台化来实现，测试还是得靠人力，即使存在自动化测试的技术，也依然逃不了人力测试的灵活和智能

现行的开发测试工作模式是，公司开出的薪水中测试往往比开发低一些，工作中开发完成后部署到测试环境中，测试同学开展测试，但是测试的开发依然还会跟着此项目，随着测试提 bug 不断的解决 bug 中，但是这样的模式其实有很多很多弊病，有哪些弊病呢？我们等下再说，我们先聊聊为什么是这样一种工作模式，我的思考是，从很早以前的互联网时代，大家优化互联网工作模式，希望做到每种职业各司其职，因此就有了产品开发运维测试，这是一个很通用简单的模式，但却不是最好的模式，随着行业的发展，运维就被智能的平台和工具替代了，而开发只需要了解一点平台和简单工具的使用就可以解决运维的问题了，对于开发同学的只是负担不算很重，但是测试没有消失很大原因是因为人工测试的不可替代性，因此测试职位就保留了下来，而且传承了以往各司其职的模式，测试的实际工作交给如今的测试人员来执行，但是“各司其职”真的就对吗？或者说这个“职”真的是属于测试角色吗？或者说真的有必要有测试角色吗？现在我们就可以来细致聊一下上面说到的当前开发测试工作模式的弊病：

*  产品的产出上线整个过程交给了两个角色来完成，这样必然会导致信息 gap，造成产品存在风险
 *  现实中的测试人员对开发环境测试环境，以及测试过程中的配置发布等了解太少，对于开发的代码逻辑了解太少，很难测到真正可能会出现问题的地方，很难从底层考虑去较好的保障工程质量
 *  开发同学在测试环境部署后，测试同学需要熟悉业务流程，最后进行测试，经常会出现测试对于业务场景有疑问反过来去问开发同学，这无疑增加了沟通成本时间成本，同时测试同学提 bug 时候，开发同学还需要重新理解一边逻辑走一遍流程方能定位问题，这无疑也增加了沟通成本和时间成本
 *  如果产品上线出现了问题，责任很难划分清晰，导致是归结于测试没有测出来呢还是归结于开发开发时候写错了呢？似乎两个角色都有问题，那事故如何划分责任人呢？似乎也不太好划分，虽然项目上是一个团队是一个整体，但是规则制定一定是需要看到最坏的情况的
 *  开发部署测试环境之后等待测试同学测试，实际上开发也还是在项目上，那何必增加测试这一块的人力呢？如果把开发同学安排成开发完成后，他也需要保障自己开发的产品的质量，自己给自己测试排期呢？

我把上面的问题归一个类别大致就是：

*  信息 gap 风险增加
 *  难测试好
 *  增加时间成本
 *  出现问题，责任难划分
 *  增加公司资金开销

我觉得这些问题都是不可忽视的，像信息 gap 和没有测试好导致的线上事故线上资损很有可能影响着一条产品线的命运走向，而一个公司可能就是多条产品线构成的。出现线上问题责任难划分又容易计划团队矛盾，造成办公室政治。如果传统的开发测试模式转成只由开发完全掌握自己产品的开发和质量，对自己开发的产品负责，既可以测试的更好减少线上问题，一旦出现线上问题也好划分责任，甚至可以减少公司资金投入，因为原本测试时间段内需要开发和测试，但是这里只需要开发即可，测试人力的资金就可以节省了。可能会有人说测试人员有一套自己的测试方法，但是实际公司项目中会发现有多少测试用到了什么测试方法呢，为了产品尽快上线，实际中测试也很难去使用到一些高深莫测的测试理论了，而且即使有很切实的测试理论方法，这些方法对于开发人员来讲学习理解也并非难事

**未来的测试：**

未来的测试都是测试开发，未来的测试开发会做什么呢？会去开发测试平台，开发测试工具，和运维开发一样，测试开发也是某一种开发，他们的业务是“测试”，他们开发的所有工具和平台离不开质量保障的目的，但是实际中他们不会参与测试某一个具体的产品业务，具体产品业务的手工测试工作需要业务方向的开发同学自己去做。然后测试开发会把他们的平台和工具当成一个服务的形式提供给全公司各个业务线，当成一个基础能力。像传统的接口自动化，UI 自动化，monkey 稳定性测试这些东西都可以弄成平台服务的形式提供给全公司使用，有人会说假如开发重构代码，可能需要回归，这个时候就需要自动化测试的服务，同时的确也需要人力的回归，不可能让开发都回归吧，这就算是一种人力的浪费了，这个时候可以使用上外包类型的测试人员，所以未来的手工测试人员越来越多会是外包的形式，而且未来公司内最好是非必要不使用外包测试人员，当且仅当回归测试量很大或者新需求手工测试工作量很大时候方可考虑，这样的情况应该保持在极少数的范围。据我了解一些公司已经推行去 QA 化了，像国外的亚马逊，国内美团的一些业务。那估计多久之后会成为这样呢？可能 5 年可能 10 年，如果 5 年后像阿里这样的巨头大厂能够实施，其他公司也会陆续敢于想此模式转换，但是要多久具体还不好说，至少还需要 5 年，因为目前似乎还看不到像此模式转变的大趋势

**关于产品和未来的产品**

以前的互联网产品很多事专做产品的，现在很多人发现如果一个产品不懂开发架构是很难做好产品的，因为一个是没法理解开发提出的异议，另一个是懂开发的产品能够设计出更合理的产品。当前的产品很多都是由不想做开发的同学转型的。未来的产品大部分应该是由想做管理的开发担任的，未来的产品还负责项目进度的把控和管理

**关于数据分析和未来的数据分析**

数据分析整个职位其实非常重要，因为它影响公司的走向和方针。数据分析接触不多不太能给出细致的结论

**关于开发和未来的开发**

开发的工作当前基本已经把运维给接过来了，未来开发的工作是主导掌控产品的产出以及质量，未来的开发会有自己的开发专项工作推进，其中质量专项建设回归属于开发专项之一。那开发未来有可能接替产品的工作吗，这个还是不太可能的，因为产品涉及产品行业的知识太多以及工作内容也较多，开发不可能兼顾。那开发未来有可能接替数据分的工作吗，这个也不太肯能，因为数据分析的工作会涉及到一些较深的数学知识，开发也很难兼顾齐全。所以未来的角色会进行收敛，留下产品，开发，数据分析几大角色，运维和测试会转变为运维开发和测试开发，变成另一种业务的开发