一、测试架构的演进

从有测试开始之初，是比较偏纯手工测试的方式，那就是大家说的“测试就是点点嘛”，这时候的测试“龟缩在测试阶段”，还经常被产品、研发压缩时间，可谓惨不忍睹。此时的测试阶段，效率低下，覆盖度不高，重复工作高，以黑盒测试为主，整体测试效率不高。
然后测试团队意识到，不能一直这样的，麻木的重复性点点，没有技术含量，自身成长也不高。此时，测试团队里有想法的小伙伴，开始把部分重复性工作，写成一些脚本工具，测试团队开始有部分工具支持，提升了部分测试效率。但从测试的深度和广度，并没有得到提升。还是停留在功能、UI层面测试。
接着为了提升深度和广度，开始有白盒测试，重新定义测试方法，深入代码级别的测试，此时从功能的黑盒测试，流转到了对代码的测试，然后测试和研发不在功能的bug上去沟通，而是测试指着代码给研发说，看这里有bug，应该怎么怎么改
这时候，测试发现我怎么比以前还累了，以前只要测试功能，不需要review代码。随着白盒测试的深入，codereview的时间占据了大部分时间，研发和产品说，你们能提升效率吗？然后测试开始思考，如何提升效率和质量，然后开始搭建自动化测试，持续集成，持续部署。部署流pipeline 随时检测业务代码。如此，降低了功能测试的覆盖，这时候测试同学，大部分时间在完善pipeline 和codereview。
此时团队来了一位架构师，开始思考，团队的质量体系如何建设，难道一直是流水线完善，怎么做到研发自测，测试不参与到具体的项目，提测研发测试比，从1:3 => 1:5 => 1:10 ,甚至部分业务无测试。这就需要研发在不断ci代码的同时，项目不断推进时，质量体系是一直默默的在“保护”项目的质量，要求对线下和线上，都能快速无感知的，发现问题，也就是devops开始了。

质量模型演化进程

二、devops是什么

devOps（Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（RD）、产品运营（PM）和质量保障（QA）部门之间的沟通、协作与整合。

devops能力模型

简单来说，其核心理念是提倡开发、测试、运维人员之间的高度协同，在高频率部署的同时，保证生产环境的可靠性、稳定性和安全性。

三、devops解决了什么问题

“升级”到devops后，有几个特点，线下有完整的质量流水线在检测项目和代码，从多维度去检测质量，同时不需要测试人员干预，可以说devops将会干掉测试，干掉那些纯手工测试的测试，因为devops的高度自动化，解决了很多功能测试所能覆盖的问题，而且在功能、性能、安全、兼容性等层面测试保障。具体几个特点，

1. 标准化的流程

如果需要做到devops，重要的前提是把项目和代码的流程标准化，各角色如何配合，各项目阶段如何做到准入。同时需要把人为的执行流程，使用工具管理起来。既保证了流程标准化，也同时对于项目的数据做到集中共享。推荐使用jira。

2. 增加测试广度宽度

devops是一种框架，类似于一艘航母，需要装备“电磁炮”，“战斗机”，“核潜艇”等等，才能发挥最大作用。从项目开始，devops这艘航母就开始保障项目质量。从深度上讲，单测、模块自动化、集成自动化、系统自动化，多层覆盖；从广度上讲，功能测试、性能测试、兼容性测试、静（动）态代码扫描，多维度覆盖。这些测试组件，有的叫测试服务化，是devops最尖端的武器。在配合项目流程场景下，分别从代码开发、提测准入、功能回归、全链路压测、线上回归等等，对项目提供质量保障

3. 提升整体质量

没有devops时，测试服务（工具/平台）是游离在项目之外的，即使有工具平台，但缺少完善的使用场景，对于不同的业务，不同的端，不同的测试同学，所使用的工具平台是不一样的，同时对测试场景的制定，也需要线下制定，然后手动，非常费时成本较高。而devops是无需人力干预，从项目开始就在保障了，整个流程中，都是自动的，且在每个环节都有标准，保证质量的持续提升。此外，在不停地持续构建部署中，做到测试前置，在交付给QA的代码，是保证高质量的。

4. 质量可度量

一般评估项目的质量，是从项目效率、代码质量、服务稳定性、线上事故、用户反馈等几个维度来评估的。在devops中的各个武器，都需要对质量检测做数据输出，比如说自动化测试的代码覆盖度率、接口覆盖率、bug率等等；而项目管理工具，可以对项目的各阶段效率数据化；从线上监控，可以拿到事故的数据指标，什么级别，什么原因，影响面等等；用户反馈接口，获取用户的数据，并通过一定算法（后续文章可以解答），抽取有效信息并聚合。如此，线上、线下、用户侧多个场景拿到数据，评估整体项目的质量。

5. 提高研发测试比

基于高效，高质的持续部署方式，测试同学不用在执行重复低效的点点工作，而更多关注在如何提高devops的测试赋能（后续也会提到），这样devops第一批干掉了纯测试的同学（说真的，这些同学前景堪忧），这时候从常规的比例提高（1:3 => 1:5），而测试赋能，把测试技能输出给研发，这时候研发自测的效率和质量更高了，新功能测试的工作量降低了，测试的排期进一步压缩（1:5 => 1:7），而devops的武器库使得更多的项目，无需测试参与，极限情况下可以把比例压缩到1:10.这就是阿里之前提过的，干掉QA。正式通过devops方式，干掉了QA

四、总结

现在大厂都在实施devops，bat依托于各自的云计算，优秀的团队，快速地搭建地devops。这方面，阿里做的最好（个人感觉）。而小厂比大厂缺少搭建devops条件，devops实施的成本非常高。后续会讲到如何devops更多内容。
参考资料：

devops架构的优点