7月27日，每月一期的明兰面对面如期跟大家见面了，是这本栏目的第11期，感谢铁粉们一如既往地支持。

本期主题是：《穿越CICD的那些误区》，满满的干货分享。

本期嘉宾：

陶老师：翰德恩高级敏捷咨询师，20多年软件工程经历，前华为公司杰出敏捷教练，现任华为公司顾问，擅长领域：敏捷软件开发、CI/CD、软件设计与代码质量、自动化测试王明兰

王明兰：翰德恩咨询创始人，原华为精益敏捷专家

接下来是小编为广大粉丝总结的活动现场经典互动问题。

1.      明兰老师提问：根据您的咨询观察，您认为目前CI/CD普遍的问题在哪儿？

最普遍的问题是，很多企业忽视了包括开发者测试、自动化验收测试、持续重构等工程实践的开展。

这些企业有独立的工具部门（如工具平台部/DevOps平台部/ DevOps运营团队），一个很大的误区是，似乎CI/CD只是工具部门的事，他们专注于工具平台本身建设，持续地为平台添加新功能、制定统一的流水线规范，也有漂亮的构建结果报告等，但开发团队却很少开展开发者测试、自动化验收测试，也没有严格要求的持续集成纪律、没有持续重构等。

2.      明兰老师提问：大家经常说CI/CD，那到底什么是CI、什么是CD呢？

CI是20多年前就有的实践，是指每天将代码做集成和测试验证，持续反馈；CD更多关注自动化部署，以便于快速获得用于自动化测试、非功能测试、手工测试、演示、生产等运行环境。

咨询中我们发现一些企业在CI/CD上存在的误区是：要么只关注CI，要么只关注CD，例如，某公司可以做到代码及时编译生成部署包并在K8S上部署，但却没有做任何自动化测试。

下图可帮助理解CI/CD

3.      明兰老师提问：前面的交流我们已经了解到CI/CD只是一个结果，做实它其实不容易，需要我们做好一些基础性的活动，那具体我们要怎么做呢？

需要从以下4个方面做实：迭代式开发、开发者测试/测试驱动开发、自动化验收测试、自动化部署

1)     迭代式开发

一次迭代，产品经理（PO）、开发人员、测试人员三条线并行，产品经理输出需求、开发人员实现、测试人员测试，CI/CD则是三方互相协作的基础平台，每天将代码持续集成、持续部署、持续测试、持续反馈。

2)     开发者测试/测试驱动开发

CI/CD的基础工程活动是自动化测试，自动化测试的主要参与者不是测试人员，而应该是开发人员，他们做的测试称为开发者测试，下图是一个典型场景的测试分类，其中的单元测试、组件测试、契约测试、接口测试都是开发人员要做的，与之相关的实践是测试驱动开发，开发人员每天提交的代码也应该包括测试代码，持续地在CI/CD流水线中运行。

测试人员要做的自动化测试是验收测试，也称为功能测试或系统测试，一些公司也将接口自动化测试作为功能测试的一部分。另外，非功能测试也测试人员所关注的。

测试金字塔模型告诉我们要将测试工作量重点投在单元测试和组件测试上（开发者测试），但遗憾的是很多公司则与之相反，他们几乎不做自动化的开发者测试，而将大量精力投在手工的功能或系统测试上。

究其原因有：开发人员没有测试意识，不知道如何正确地写代码；缺乏测试技能，包括工具和方法；一些公司的管理者在对待开发者测试的观念上存在误区，他们认为开发人员做测试是在浪费时间，延误了交付进度。

那开发人员做自动化测试的真正价值在哪儿呢？我要强调的是开发者测试的本质不在测试，我们所说的开发者测试更多的是指测试驱动开发（TDD）这个实践，本质在于如何快速高效地写代码，它的核心思想是“写一点测一点”，先定一个小目标（也就是先写一个测试用例），然后驱动代码实现，测试，重构，然后再定下一个小目标，如此反复，实现一个小目标差不多需要5分钟、3分钟，甚至更短，正所谓“小步快跑”，每一步走稳了累积起来才能快跑。没有自动化测试的开发，步调一定是不稳的，短期来看似乎很快，但长远看欠下了太多的技术债务，未来增加新需求和修改Bug将举步维艰，高昂的研发成本就此开始，坚持不了多久，很多公司就关门大吉了。所以，我要提醒管理者的是，没有测试驱动开发的软件研发是极其低效的、极其危险的。

开发者测试的工具选择上，我将工具大致分成4类：（1）测试框架，如xUnit、TestNG、Spring Test、pytest、GoogleTest；（2）断言库，如Hamcrest、chai；（3）Mock工具，如Mockito、JMock、EasyMock；（4）测试覆盖率工具，如Cobertura、JaCoCo。还有更多细分领域的工具可供选择，所以，开发中我们遇到的问题基本上都能找到对应的工具。

一个常见的误区是前端可以不用做开发者测试。可是，现如今，前端开发的复杂度已经不亚于后端了，相应的开发者测试工具也已经超级多，以下是常用的工具，供参考。

3)     自动化验收测试

验收测试包括功能测试和系统测试，很多公司还停留在手工测试阶段，原因有很多，但我认为一个重要的原因是测试技能缺乏，做自动化测试是门技术活，编程能力是基础。验收测试的工具有很多，如Selenium、RF等，下图是Robot Framework实现的验收测试脚本（用户正常登录功能），底层用到了Selenium驱动UI测试。

需求（用户故事）的质量也是阻碍自动化验收测试的重要因素，需求没有验收标准就急匆匆进入开发，这就没有了“完成标准”这个大目标（相对于测试驱动开发的小目标而言）。

4)     自动化部署

CD的核心能力是自动化部署，很多公司已经将应用部署在公有云或私有云上。CI/CD实践中，常见的，是通过构建输出容器镜像，然后通过自动化的部署脚本一键部署到K8S/K3S中，参见下图。

4.      在线提问：接口测试和契约测试的区别和联系是什么？

共同点是都关注接口，但契约测试用于确保不同团队（如前后端、后端不同微服务）之间对接口理解的一致性，重点在接口协议本身，接口测试则关注业务功能的正确性。

5.      在线提问：前期推动开发单元测试很难，再加上我们现在的系统优化是在厂商的产品的基础上进行新需求的实现，这种单元测试如何推进呢？

很多公司由于历史的原因有大量存量代码没有做单元测试，但首先我们必须要求新增代码要做单元测试，然后有计划有策略地逐步补充存量代码的单元测试，这是在偿还技术债务。

6.      在线提问：我们企业自动化测试已经有一个平台可以定时去跑，开发也是用自己的一个开发部署工具，在平台上提交就部署成功了。与此相对的，我们还有一个DevOpsp平台，它是可以集成嵌入了，一点质量门禁检测，会自动触发，只是没有触发自动化。

很多公司在建设DevOps平台之前就已经有了自动化测试平台，这些平台也能够做到持续地部署和自动化测试，这很好！我的建议是在维持现状的基础上可以考虑只需花少量的工作就可以将其集成到新的DevOps平台上，作为流水线的一部分。

7.      在线提问：我们做自动化测试的阻力来自于根本就不好做、无法做、成本高

这不是阻力而应该是动力，这些问题恰恰说明代码设计质量差、系统紧耦合，这是重要信号，由此驱动我们重构代码形成良好设计，这就是测试驱动开发。

8.      现场演示：一个Web App的开发和快速反馈

以下是现场演示的全局视图