软件开发与测试体系-测试开发有机会转开发吗

这是软件工程系列知识总结的第七篇，也是最后一篇。

在上一篇文章中，我讲了软件工程的基础理论、项目管理、需求分析、架构设计、软件测试和在线服务的质量保证。 其中软件开发与测试体系，在架构设计和线上服务的质量保证中，我也提到了持续集成和持续交付相关的内容。 软件工程的本质是用工程方法对软件开发进行规范，使软件开发项目能够按时、高质量、成本可控地完成。

除了交付的软件产品质量，交付效率对团队也非常重要，而高质量软件产品的持续高效交付需要高效的持续交付技术体系支持。

了解持续交付系统

无论是保证质量还是提高效率，都需要一定的持续能力来支撑。

这种支撑能力可以看成是类工厂的流水线能力，也就是业界通称的持续交付。

一般来说软件开发与测试体系，从质量保证的角度，我分为：CI持续迭代-CI持续集成-CD持续发布-CO持续运行-CM持续测量。

持续迭代

什么是技术？ 技术是工具，技术为架构设计服务，架构设计为产品服务，产品为业务服务，业务为业务服务。

这里的持续迭代更多的是指业务或需求的可持续变化。 在需求不断变化的驱动下，软件产品不断迭代，为用户提供更优质的服务，实现商业价值的实现。

持续集成

持续集成帮助技术团队更频繁地将代码更改合并到共享分支或“主干”中。 一旦对应用程序所做的更改被合并，系统将通过自动构建应用程序并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证更改，以确保更改不会破坏应用程序。 如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以加快修复这些错误的过程。

持续部署

这里的持续发布包括持续交付（Continuous Delivery）和持续部署（Continuous Deployment）。

在 CI 中完成构建和自动化测试过程后，持续交付可以自动将测试代码发布到仓库中。 持续交付的目标是让代码库准备好部署到生产环境中。 在持续交付中，每个阶段都涉及测试自动化和代码发布自动化。 应用程序可以在流程结束时快速部署到生产环境中。

成熟的 CI/CD 管道的最后阶段是持续部署。 持续部署作为持续交付的延伸，可以自动将应用发布到生产环境。 持续部署在很大程度上依赖于精心设计的测试自动化。 持续部署意味着开发人员对应用程序的更改在编写后的几分钟内生效（假设它通过了自动化测试）。 这使得持续接收和整合用户反馈变得更加容易。

所有这些 CI/CD 相关步骤都有助于降低应用程序的部署风险，从而更容易以更快的节奏发布对应用程序的更改。 然而，前期建设需要大量的资源投入，因为还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段。

连续运行

应用在生产环境发布后，需要持续跟踪线上质量、用户反馈和建议，以及线上可能出现的一些问题或故障。

所有在线用户的建议、可能出现的问题或故障，其实本质上都与交付质量息息相关。 因此，这里提出持续运行，就是提倡质量控制、验证和测量。 即使在生产环境中，这个机制也需要持续运行。

连续测量

没有数据谈论质量是空中楼阁。 从需求质量到交付质量的整个周期，将每个阶段要做的事情、问题、风险和结果进行量化的记录和展示，并进行分析和评估。 找到你的不足之处。 这是持续的衡量，需要持续的投入。

持续交付优势

持续交付系统工具

持续交付的前提是整个研发、测试和发布过程要高度自动化。 要实现持续交付，项目一般需要满足这些条件：

代码构建过程可高频重复，每次构建结果一致稳定；

所有环境配置信息都存储在源码管理工具中（现在有Nacos/Apollo等配置中心组件）；

对于需要部署在不同环境的代码包，需要自动编译创建不同的版本；

所有环境中的构建、编译、部署、发布等步骤都必须自动完成；

DevOps与持续交付的关系

持续交付要求代码可以反复、频繁地构建和编译，代码包的测试、部署和发布需要自动完成。 然而，传统的研发交付流程已经逐渐不能适应当前的业务变化。 所以这几年发展了DevOps，甚至Ops什么都有。

其实DevOps并不是一个职位，而是可以理解为一种紧密协作的高效工作方式。 无论是DevOps还是所谓的TestOps，其实都是指开发/测试和运维同学一起工作，通过高效协作，更快地构建、测试和发布软件。

DevOps 的优势

以DevOps为例，当团队采用这种工作协作方式时，好处如下：

实践 DevOps 意味着团队需要做以下事情：

DevOps 工程师所做的事情

如果不想一个人野蛮生长，找不到系统信息，遇到问题得不到帮助，坚持几天就放弃了，可以加入我们的QQ群：746506216，大家一起讨论交流一起，会有各种软件测试资料和技术交流。