DevOps会导致测试人员失业，何去何从（上）？

Posted 2021-04-16 鲁德

DEVOPS 是什么鬼

DevOps可以看做是敏捷开发模式的延伸，将持续集成（CI）、持续部署、持续交付（CD）扩展到运维，打通开发与运维之前的壁垒，在整个生命周期中消除传统的孤岛，促进研发与运维的协作，从而缩短软件产品交付周期，提高软件服务质量。

DevOps强调构建、测试、部署和运维等工作的高度自动化，构建工具链或自动化全覆盖的持续研发的方法和工具，让基础设施、运维也成为产品代码的一部分，能够实现持续设计、持续编程、持续构建、持续测试、持续发布、持续部署、持续监控（持续-X / C-X实践）等，能够及早发现并更快修复缺陷，整个研发更具透明性、运维环境更加稳定，实现越来越快的软件交付，减少协作、测试和沟通成本。 

这里给出一组数据，不管你信不信：相对低性能的同行，高性能的IT组织遇到的失效减少为60分之一，失败后恢复的速度提高到168倍、部署频率提高到30多倍、从研发周期缩短为原来的200分之一。

   随着DevOps实践的兴起，测试需求正在下降。这个观点的支撑是：自动化方法已经足够先进，在整个研发、发布和运维过程中在很大程度上人为干预可以逐步减少，先进的、高度自动化的技术解决方案的速度和效率胜过了传统的、基于流程改进的QA/测试方法。

   与之相反的观点，认为DevOps只是一个概念，上述想法只是理论上一种理想，难以落地实施。许多互联网企业由于能力和资源等限制做不了自动化全覆盖，而且工具发现缺陷的能力比较弱，即使能发现60～80%的缺陷，还有20～40%的缺陷会遗留到上线后，这样的质量对大多数应用（更不要说像银行、电信等关键系统）根本不能接受。其次，如果需求定义不规范、不可测或者需求不稳定，自动化测试就很难，还有诸如UI、移动体验之类的组件呈现出许多不可控或不确定的因素，这对于自动化测试来说更具挑战性，而人类测试者却很容易地完成这类测试（UI测试和易用性测试），自动化的代价反而大得多。再者，DevOps只能适用于SaaS（Software asa Service, 软件即服务）这类软件的研发与运维，非SaaS的软件研发很难采用。不同类型的产品、不同的用户和不同的研发团队，采用的软件开发模式和实践千差万别，DevOps在许多场合是不适用的，而适合自己的开发模式和实践才是最好的。

   但是如果公司（如非关键系统的SaaS公司）采用了DevOps模式，有没有可能彻底消灭传统意义的软件测试专职人员？

         如果能，软件研发是怎样的一道风景？

       如果不能，软件测试或QA的地位是不是会下降？

    DevOps这个名字绕过了“测试”，也许是对的，更强调“质量是构建的”。但做测试、做QA的人们一定会有意见，希望将DevOps改为DevQAOps，以纠正DevOps忽视QA的问题，有没有这个必要？甚至有没有必要增加一个新术语TestOps？可能都没有必要，彻底的DevOps也许是未来研发的趋势。

1.  适合采用DevOps的企业，传统意义的软件测试人员可以消失吗？

这完全是有可能的。Google、微软和一些欧美公司等的实践证明这是可行的。他们去掉了专职测试人员，没有“TestEngineer”角色，而是采用“测试开发工程师 或全栈测试架构师” ，或干脆像微软公司那样都叫软件工程师（Software Engineer，SE），你要知道，2014年前，微软公司还有一万多专制的测试工程师，而今天他们已经消失了，成为软件工程师。Google的SET (Software Engineer in test) 实际上也是一个开发角色，谷歌在我国有几百研发人员，但测试开发只有几十个。他们（SDET、SE、SET等）做的事情已经不同于传统的测试人员所做的事情，而是：

    需求分析

    测试环境搭建和部署；  

    自动构建与集成

    协调组织和指导团队制定自动化测试

    定位瓶颈，指导优化改善瓶颈

跟全栈性能很像，请期待鲁德相关DEVOPS新书     

 ……

  

参考资料来自测试质量报告-朱少民