【测试理论基础之测试左移/测试右移/CI/CD】

测试左移

通俗的讲：左移是往开发阶段移，右移是往发布之后移。

测试左移就是在测试阶段到来之前，尽可能的抓紧开发前（需求分析）和开发中的时间做测试，提前发现问题，防微杜渐，避免积重难返。提测之前的测试。如：代码单元测试，代码质量检测，代码接口持续测试 等

在需求源头就要控制伪需求，在代码设计阶段就要控制劣质代码。

测试左移的思想本质是越早的发现不合理的地方，出问题的几率就越低。

测试右移

测试右移是往发布之后移，也就是产品上线了之后也可以进行一些测试活动。

当然在生产环境直接做测试是不推荐的，但可以在生产环境做监控，监控显示性能和可用率，一旦发现任何问题，尽快反应，在用户发现之前，把问题解决了。

 测试左移：测试左移，本质上是借助工具和测试手段更早地发现问题和预防问题。

• 需求：对需求、架构和设计模型的测试；
• 开发：着重增加对单元、组件和服务层的测试；
• 持续测试：自动化测试。

■ 测试右移：对测试同学来说，版本上线后需要持续关注线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。

• 灰度发布：新版本线上测试；
• 监控：合理的性能监测、数据监控和预警机制；
• 用户反馈：线上问题处理、跟踪机制。

CI/CD

持续”是什么意思？

“持续”用于描述遵循我在此提到的许多不同流程实践。这并不意味着“一直在运行”，而是“随时可运行”。在软件开发领域，它还包括几个核心概念/最佳实践。这些是：

• 频繁发布：持续实践背后的目标是能够频繁地交付高质量的软件。此处的交付频率是可变的，可由开发团队或公司定义。对于某些产品，一季度、一个月、一周或一天交付一次可能已经足够频繁了。对于另一些来说，一天可能需要多次交付也是可行的。所谓持续也有“偶尔、按需”的方面。最终目标是相同的：在可重复、可靠的过程中为最终用户提供高质量的软件更新。通常，这可以通过很少甚至无需用户的交互或掌握的知识来完成（想想设备更新）。
• 自动化流程：实现此频率的关键是用自动化流程来处理软件生产中的方方面面。这包括构建、测试、分析、版本控制，以及在某些情况下的部署。
• 可重复：如果我们使用的自动化流程在给定相同输入的情况下始终具有相同的行为，则这个过程应该是可重复的。也就是说，如果我们把某个历史版本的代码作为输入，我们应该得到对应相同的可交付产出。这也假设我们有相同版本的外部依赖项（即我们不创建该版本代码使用的其它交付物）。理想情况下，这也意味着可以对管道中的流程进行版本控制和重建（请参阅稍后的 DevOps 讨论）。
• 快速迭代：“快速”在这里是个相对术语，但无论软件更新/发布的频率如何，预期的持续过程都会以高效的方式将源代码转换为交付物。自动化负责大部分工作，但自动化处理的过程可能仍然很慢。例如，对于每天需要多次发布候选版更新的产品来说，一轮 集成测试(integrated testing)下来耗时就要大半天可能就太慢了。

首先从CI开始说，CI就是持续集成，为什么要持续集成，这就要说到持续集成里面包括有哪些内容，我现在做的持续集成包括有代码下载，代码分析，单元测试，代码编译，镜像制作这些过程，当然也可以根据情况进行增删流程，可以增加的流程还包括镜像推送等，所以在这里我把持续集成理解成是软件开发同事那边的职责，更多是他们那边需要关注持续集成这个环节出的问题。

简单说，持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。持续集成是启动管道的环节（尽管某些预验证 —— 通常称为 上线前检查(pre-flight checks) —— 有时会被归在持续集成之前）。

持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。

如何做到持续集成？

首先，持续集成需要：

1. 单一的代码仓库，团队成员都像该仓库提交代码；

2. 自动化构建且构建过程需要包含自动化测试；

3. 有单独的集成机器用于构建；

4. 保证构建速度不要太慢(曾经有一个项目构建需要20分钟，就会很痛苦)；

5. 在类产品环境进行测试；

6. 能够方便获取最新的可执行程序；

7. 可视化，大家都能看到构建过程及结果；

8. 自动化部署。

其次，我们通过以下步骤进行持续集成：

1. 程序员将代码下载到本地，并在完成修改后提交代码；

2. CI服务器监测代码库，并在有提交时自动触发；

3. CI服务器对代码进行构建，运行单元测试和集成测试；

4. CI服务器发布可部署的artefact用于后续测试，并加上本次构建版本的标签。

5. CI服务器通知团队构建成功或者失败；失败发生时团队需要尽快修复，以免耽搁后续的持续集成过程，因为失败时处于持续集成的暂停阶段。

最后，需要就团队责任达成共识：

1. 频繁提交；

2. 提交之前确保测试通过；

3. 不在持续集成失败时提交代码；

4. 提交代码后保证持续集成成功，不然不准回家

CI工具

Jenkins + K8s + docker

然后就是CD。

CD可以表示为持续交付，也可以理解成持续部署。持续交付的在我工作当中我理解就是在持续集成的流程走完之后，我们将持续集成流下来的产物，或是jar/war/tar包等服务，或是镜像实例文件等进行更新到测试环境或者部署到新的测试环境上的，然后对测试环境进行回归验证的这么一个过程，如果回归验证通过，那么持续集成的产物，就是服务包或者是镜像，就可以交付到现场或者说是线上的正式环境进行正式部署操作了，当然，交付的产物很多时候不单单是包或者说是镜像，还有sql脚本，配置等。

简言之：持续交付（CD）通常是指整个流程链（管道），它自动监测源代码变更并通过构建、测试、打包和相关操作运行它们以生成可部署的版本，基本上没有任何人为干预。

持续交付在软件开发过程中的目标是自动化、效率、可靠性、可重复性和质量保障（通过持续测试）。

持续交付包含持续集成（自动检测源代码变更、执行构建过程、运行单元测试以验证变更），持续测试（对代码运行各种测试以保障代码质量），和（可选）持续部署（通过管道发布版本自动提供给用户）。

如何做到持续交付？

1. 保证每次提交的修改都是可上线的修改。

2. 完善的测试(包括单元测试，组件测试，验收测试)来测试新功能和进行回归测试；

3. 持续交付的前提条件是自动化的集成和部署；需要开发/测试/运维人员一起完成。

总结：

那么为什么要去做CICD这个事情呢，我觉得有几个方面。第一，使软件整个流程规范化，从代码提交到线上更新完成整个软件生命周期都在一条不断的流程线上；第二，减少在生产环境进行部署升级时踩的坑；第三，减少测试人员在产品上线前的工作，因为有自动化回归测试的存在，只要在持续交付完成之后，一边跑自动化回归测试用例，一边重点跟进此次升级的需求即可。