DevOps兴起意味着专职测试人员消失？

Posted 2021-04-16 软件质量报道

今天，咱们见证了DevOps被迅速采用，因为企业必须对市场变化作出更快的响应。借助DevOps，企业能够加快产品上市的时间，更好地响应并满足了不断变化的客户需求，帮助企业获得竞争优势和业务的快速增长。

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

DevOps强调构建、测试、部署和运维等工作的高度自动化，构建工具链或自动化全覆盖的持续研发的方法和工具，让基础设施、运维也成为产品代码的一部分，能够实现持续设计、持续编程、持续构建、持续测试、持续发布、持续部署、持续监控（持续-X / C-X实践）等，能够及早发现并更快修复缺陷，整个研发更具透明性、运维环境更加稳定，实现越来越快的软件交付，减少协作、测试和沟通成本。因此，DevOps不仅旨在持续交付价值，缩短产品上市时间，加快商业应用系统的开发和部署，而且旨在减少缺陷、改善质量和客户的满意度，以技术方法解决过去用流程要解决的问题，提高企业研发收益。

这里给出一组数据，不管你信不信：相对低性能的同行，高性能的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”角色，而是采用测试开发工程师 (SoftwareDevelopment Engineer in Test, SDET) ，或干脆像微软公司那样都叫软件工程师（Software Engineer，SE），你要知道，2014年前，微软公司还有一万多专制的测试工程师，而今天他们已经消失了，成为软件工程师。Google的SET (Software Engineer in test) 实际上也是一个开发角色，谷歌在我国有几百研发人员，但测试开发只有几十个。他们（SDET、SE、SET等）做的事情已经不同于传统的测试人员所做的事情，而是：

• 开发测试工具，搭建和维护测试环境和测试框架；

• 把不同层次的自动化测试集成到CI pipeline，改进和维护CI pipeline，维护整个研发的基础设施；

• 指导开发使用这些测试工具或测试框架

• 组织和指导团队制定自动化测试策略

• ……

除此之外，SDET对软件开发的了解往往集中在可测试性、健壮性和性能等方面，基于这些理解，构建框架服务于整个团队。开发人员不仅做单元测试，还用SDET搭建的测试框架做系统测试、做手工测试，开发团队遵循持续交付和持续集成的原则，拥有独立的CI pipeline，借助良好的架构每个开发人员做的每个任务都不大、都可以通过这个CI pipeline独立发布，所有代码都会经过CI pipeline、再经历code review，最终合并到主干（master branch）上。总的来说，开发人员是自己写的代码的质量的主要负责人，也就是将之前的QA、Quality Engineer或测试的角色分配给DevOps团队，让每个成员承担起来。

之前，开发团队的每个任务只有通过了测试才能发布（release），但是问题来了：一个测试人员应对多个开发人员，质量问题很可能就落到这个测试人员身上，例如一旦发现上线遗漏bug，大家的第一反应是为什么QA（=测试）没有找到。这种情况漏掉比较多的Bug也比较正常，因为很难进行充分的测试。如果要充分测试，测试速度上不去，很容易成为瓶颈，无法实现快速交付。许多情况下，要么质量得不到保证，要么干得很苦。总的来说，过去那种做法（设置“测试工程师”角色）不利于整个团队作为一个整体提高质量意识、质量监控和测试能力等等。

在敏捷方法持续集成的环境（如基于Jenkins 完成全过程的自动调度）的基础上构建DevOps的研发、部署全生命周期自动化环境（如基于容器技术平台Kubernetes平台），向团队提供一键式DevOps测试环境和测试数据分析的解决方案，提供适应DevOps的统一的测试自动化框架和质量管理平台，在整个软件生命周期软件质量状态（如qualitydashboard）能够一目了然。

如果觉得不放心，如果团队还不够成熟、或者说团队测试能力还不够，可以在团队设置一个“测试教练（Testing Coach，TC）”、“测试顾问（Testing Consultant，TC）”或“质量助理（Quality Assistant，QA）”，他的主要任务包括：

• 参与前期需求分析和定义验收标准

• 帮助团队提高整体测试技术和知识

• 帮助开发人员制定测试策略（策略执行还是团队）

• 定期组织exploratory testing session（bug bash）

• ……

现实中开发人员能力不够，不喜欢做测试，这就需要培养这种新的、敏捷/DevOps的质量文化，不断通过教育/培训、绩效考核加以引导。在招聘新人时，也要考察应聘者是否具有质量意识、是否愿意花时间提高自己写的代码质量。而且告诉他们来这公司需要自己测自己的代码。

其次，面向接口的编程、微服务架构等实践可以让自动化测试容易开展，使被测对象具有很好的可测试性，自动化测试快、效率高，自动化测试的覆盖率也很高，这样开发就比较容易接受测试工作。之前谈到，测试开发SDET会关注可测试性、健壮性和性能，这样自动化测试就有一定保障。但是，总有一部分UI测试需要手工进行的，这就需要团队在后期一起参与做测试，通过缺陷大扫除活动（bug bash session）来完成。

最终能做到这样，需要管理层和研发人员的共同支持，从上到下、由下到上形成合力，才能做到真正的“将质量构建于产品之中”的研发过程。

2.    测试会慢慢成为一项锦上添花的工作？

靠自动化测试、缺陷大扫除这样的实践，软件质量还存在较大风险。没有人工智能（AI）的、传统的自动化测试发现缺陷的能力还是很弱的，而且当我们把主要精力放在技术、自动化上面，就很有可能忽视业务、忽视用户的需求。如果采取ATDD、BDD实践，情况会有所改善，但是对于复杂的业务逻辑，ATDD/BDD就会面临较大的挑战，这时就需要专业的测试人员进行业务层、端到端的测试。单元、功能没有问题，不能代表系统能够完全满足业务的需求，而系统满足业务的需求才是终极目标。

其次，开发人员测试自己的代码或程序，会有心理障碍、思维障碍。如果开展TDD测试实践，测试在先、开发在后，这种障碍就不存在了。但现实中几乎难找到全程以TDD方式开发产品的公司。当然，开发人员也可以进行交叉测试，这时候，在短暂的时间区间内，开发人员在扮演专职测试人员的角色，也就是说，一个软件工程师经常交替扮演开发人员、测试人员等不同角色。

再者，软件开发的各项工作都是专业的事情，软件测试也不例外。每个开发人员能做测试，这有信心。但让大多数开发人员成为高水平的测试能手，依旧困难重重。许多开发人员的一项工作做得不够好，要把两项工作都做得很出色，就更困难。过去也是这样，但质量多了一道守护——专职测试人员的系统测试，质量会有一定的保障。对于极少数优秀的开发人员，的确可以相信，测试促进开发，开发促进测试，两者相辅相成，将开发和测试溶于一身，反而是有利的。

当我们说，质量由团队负责，从我国国情看，质量可能就没有人负责，有时还需要一、两个QA、TC或质量助理专职人员，他们全程监控研发过程，帮助开发人员消除不规范行为、尽可能避免产生缺陷，尽一切可能来评价系统的伸缩性和性能，不断寻求机会提高代码的可复用性和可预测性，积极影响开发的质量意识，和团队一起防止缺陷进入实际的运行环境中，在整个开发周期中进行质量跟踪、持续改进质量。这种预防，不仅是产品缺陷预防，而且包括过程问题的预防，持续揭示产品质量风险、改进软件研发和运维的过程。

从这些角度看，少量的专职测试人员暂时还离不开，特别是对质量有更高要求，希望获得更好的客户满意度。可以参考：

3.    如果AI再助软件测试一臂之力，多数专职测试人员还可以回家

过去，我们谈到探索式测试，觉得这必须由测试人员亲自动手来做，正如前面所说，传统的自动化测试（TA）发现缺陷的能力比较弱，而人类测试工程师具有创造性，能够举一反三，能够不断深入探索下去。但是，随着AI的越来越多的应用，赋予传统的TA工具的智能特性，就有可能超过人类测试人员。虽然工具（这里指测试机器人）可能再优秀不能超过顶尖的测试人员（不到20%，也许只有5%），但完全可以超过80%～95%的普通测试人员。在今年举行的人机大赛中，差不多就证明了这点，稍微具有一点AI能力的单元测试工具evoSuite打败了绝大多数人类选手，虽然它最终输给最优秀的人类选手。

刚开始，人类选手需要较长学习时间，干不过任何工具

（这几位优秀选手都是很优秀的，他们是从几千个选手中选出来的）

很快人类选手打败随机测试工具，但还干不过低智能的AI工具

顶尖的人类选手可以打败低智能的AI工具

在之前，我将软件测试定义为一个公式：

过去，也许你还认为，有一块自留地（未知领域）交给我们手工测试（探索式测试），当我们引入AI技术之后，连这块自留地也不给人类测试工程师剩下，可以彻底实现完全的自动化。

前两天在中兴测试技术大会上分享了App游戏的UI自动化测试——借助蒙特卡罗树搜索算法、增强神经元网络算法，进行150次模拟后，就能够超过人类的游戏玩家。

今天，AI不仅可以模拟人工操作，而且还能应用到测试的其它方面，包括测试数据的产生、测试Oracle的建立。不仅可以进行功能性测试，而且可以进行安全性测试、可靠性测试。正如Gartner告诉我们，到2020年，普通人与机器人的交谈会比与他们的配偶更多！留给我们测试人员的时间只有三年，三年内必须转型，成为AI不能代替、更具智慧、创造性工作的专业人员。