ci/cd自动化测试

 

导读：浅谈 CI/CD 和软件测试

知其然，知其所以然。相较于DevOps而言，CI/CD是一个相对具象的概念。在 IT 企业中，CI/CD的应用愈加广泛，成为推动软件研发活动的重要基础设施服务，同时推动 DevOps 模式的实际落地。

什么是 CI/CD

在实践 CI/CD 相关内容之前，我们有必要先认识下什么是 CI/CD。

一般传统或者狭义、普遍的 CI/CD，是指持续集成（Continuous Integration，CI）和持续交付（Continuous Delivery，CD）。而更加广义、全面的理解，是指持续集成（Continuous Integration，CI）、持续测试（Continuous Testing，CT）、持续交付（Continuous Delivery，CD）和持续部署（Continuous Deployment，CD）四个方面。通常，一个软件开发的流水线如下图所示。

• Design：这一阶段完成软件开发的需求分析和设计。
• Develop：这一阶段完成软件开发的功能代码，一个最佳实践是采用测试驱动开发（TDD）的方法，测试代码和功能代码的编写同时进行。需要注意的是，在 Develop 阶段也会运行单元测试和其他小型测试。
• Test：这一阶段完成软件的各项大型或专项测试，比如界面测试、API 测试、性能测试和系统测试等。
• Release：这一阶段完成软件产品的发布，并交付给用户使用。

 

 

每日构建和每日测试

每日构建（Daily Build）在反应速度上没有持续集成快，它更强调的是通过每天（通常是晚上）自动部署当天开发所累积的代码，并结合每日测试（Daily Test）方法进行自动化测试，用于评估和衡量项目的进度。

持续集成特性决定了不可能在该阶段加入大量的测试，而每日构建则一般是在夜里执行的，那么这时就可以做更多的事情，比如代码质量检查、单元测试、测试覆盖率、集成测试等。每日构建会把当天所有的提交代码都一起做集成，而不像持续集成那样每提交一次代码就做一次集成。持续集成属于增量式构建，而每日构建则是一次完全构建。

每日构建是项目的心跳线。一般而言，通过每日构建我们可以看到项目的进度。比如今天有10个 Bug 的修复代码都提交了，晚上进行自动部署并通过了自动化测试，第二天上班时通过查看邮件我们就可以发现每日构建成功了，那么项目就又往前迈了一大步，开发工作又有了具体的进展。

具体的，每日构建就是在每天晚上自动化部署一个 OpenStack 环境（可以是all-in-one，也可以是 multi-node），然后运行大型或专项测试，比如 API 性能测试、API 接口测试、功能测试、部署测试等。

现在做测试，经常听到一个概念 持续集成 CI - Continuous Integration。

那什么是持续集成呢？相信大家看了不少文章之后依然是一脸懵逼。

这里呢，用我自己的理解谈一下，不正确的地方还请指正。

要说持续集成，首先要明白什么是集成。很多测试同学说到集成，就想到集成测试。

这里的集成主要是指代码的集成：

举例来说，比如当前迭代，开发时间为两周。项目开始后，开发人员会从代码管理工具（SVN 或 GIT）的主干代码上复制一份代码到自己本地电脑。然后在自己的本地电脑上进行开发，假设这个项目有三个开发人员，分别是 jim（狗蛋）、lily（翠花）、tom（大锤）。

 

好，现在三个开发分别在自己电脑上开发。开发任务完成后，一次性提交自己本地代码到代码管理工具的主干代码上。

这个过程就叫集成，也就是代码集成，将自己本地的代码集成到主干代码。此时发生了所谓的集成地狱。三位开发有可能会改到同一个代码文件、同一个方法，这样就会出现代码冲突。为了处理集成过程中的冲突，会花费非常多的时间、精力和成本，并且提高了发布风险。

为了降低这种风险和成本，于是持续集成就被提出了。强调的是不再一次性把代码集成到主干，而是高频率的持续集成。一天集成1次，甚至多次。同时在集成过程中，进行自动化测试，保证主干代码一直可用。

为保证主干代码可用，开发每次代码集成后都需要进行 BVTBuild Verification Test测试，也就是类似冒烟测试的过程，比冒烟更简单一些，主要保证系统可用。这种测试由于测试频率高，因此对自动化测试的需求非常大。

那么现在主流的持续集成工具，比如 Jenkins 做些什么事情呢？

先来说一下没有 Jenkins 的时候，我们怎么去更新测试环境的。

 

首先从 SVN 上获取最新代码；
在本地进行编译
构建一个发布包，通过 FTP 上传到测试环境服务器
将发布包中内容更新到相应的服务
重启相关服务，以使更新生效
如果部署了负载均衡，则在其他服务器上重复 4， 5
每次构建和更新测试环境都是很繁琐的任务，而且极易出现错误。那么 Jenkins 能干什么呢？

能让这一系列事情全部自动化：

根据规则轮询代码管理工具，获取最新代码（也可以手动或设置其他规则）
基于不同的语言进行构建（需要自行配置）
通过 FTP 把构建后的内容自动上传到对应的服务器
使用插件或者脚本，将发布包内容更新到各个环境
通过命令行调用自动化测试脚本，搭配代码覆盖率工具执行自动化测试
展示自动化测试报告，并邮件通知构建情况
也就是让集成过程中繁琐的事情都自动化了，那么进行持续集成也不会因为集成频率过高带来的环境部署和频繁测试而导致开发效率降低。

 

每个软件项目都涉及成功实施和部署项目的某种“过程”和“实践”。 随着项目规模和规模的增加，复杂程度也以指数方式增加。 领导团队应尽一切努力来开发，测试和发布软件，以便以递增的方式进行发布，从而对客户已经可用的软件影响最小（或没有影响）。

在本文中，我将介绍有关测试自动化的CI / CD最佳实践，以帮助您加快上市进程。

在上一篇文章“ 什么是持续集成和持续交付？”中 ，我们已经介绍了CD / CD 。 我们在哪里讨论了他们的目的？ CI / CD管道中涉及的贸易工具。 在测试/验证阶段发现的每个错误都经过严格的开发，集成，测试和关闭过程。 如果此活动是手动完成的，则可能会花费大量的工时和验证工作，因此理想的是在CI / CD中具有“测试自动化”功能 。

CI / CD中的“部署管道”和测试自动化的作用

一个自动化的系统，称为CI / CD中的Deployment Pipeline ，可以自动测试服务器上可用的增量版本。 由于整个过程是自动化的，因此与手动测试相比，总的周转时间（TAT）将大大减少。

在大多数情况下，不可能完全自动化测试。 可能有一些需要手动干预的测试场景，或者需要手动观察来确定测试是否通过的场景。 尽管自动化是CI / CD管道不可或缺的最佳实践，但确定测试方案是否自动化将被认为是CI / CD至关重要的最佳实践。

尽管使用自动化测试有许多好处，但在CI / CD管道中使用测试自动化的一些主要好处如下：

• 更快的错误关闭-问题检测->问题修复->问题关闭。
• 有效利用现有的整体资源，例如测试人员，测试基础结构等。
• 能够并行执行测试。
• 测试计划和执行的一致性。
• 自动化测试用例执行所需的最低技术技能要求。

如何在CI / CD管道中实现最佳的测试自动化？

尽管CI / CD管道中测试自动化的范围可能因一个项目而异，但CI / CD的某些最佳实践可应用于任何项目，而不论其规模和规模。

增量变化与及时沟通

开发人员可以遵循大爆炸的方法来开发新功能或解决测试团队报告的问题。 这意味着开发人员将使用该选项，一口气将功能实现推入其中。 尽管完成了实现工作，但是这种方法还是存在一些问题。 主要缺点是很难隔离问题（如果实现存在问题

明智的方法是将功能分解为不同的子功能，并为每个功能使用唯一的功能标志 。 该技术不仅有助于隔离潜在的问题，而且在需要时可用于进行增量功能构建。 当将最终功能（由许多子功能组成的组合）推到主线/生产分支时，这也降低了出现集成问题的可能性。

在某些情况下，功能之间存在相互依赖关系，即功能“ A”依赖于功能“ B”，在这种情况下，任何开发人员都必须等待100％完成依赖项的功能。 通过正确使用存根和功能标志，两个功能开发人员都可以避免死锁情况，因为存根将用于计划中/正在进​​行的实现。 一旦所需的功能准备就绪，开发人员就必须摆脱基于存根/虚拟的实现，该实现只是一个已知接口的实现的占位符。

这项开发活动需要精心计划并在开发团队之间进行及时互动，以充分利用CI / CD管道中的测试自动化。 遵循这种方法的任何纪律都会影响您的总体测试进度。

识别可以自动化的测试

如前所述，不太可能100％的测试可以自动化，因为至少在某些测试中，与自动化测试相比，手动测试会更有效。 由于测试自动化是CI / CD管道的核心，因此实现那些可以自动化的测试用例对于CI / CD是至关重要的最佳实践。

可以自动化的两大类测试：

频繁执行的测试：如果测试人员“手动”执行此类测试，则可能会出错，因为生产率可能会降低，因为测试人员一天必须多次执行相同的测试。 以必须要进行浏览器兼容性测试的Web产品为例。 某些测试案例可能涉及在不同浏览器/设备/操作系统组合上测试Web应用程序时捕获其屏幕截图。 为这些组合中的每一个拍摄屏幕截图可能是一项繁琐的任务。 因此，自动化的跨浏览器测试可以使测试人员腾出时间来编写有效的测试用例 。

需要知识并依赖特定测试人员集合的测试：如果项目关键阶段没有可用资源，则仅具有测试执行所需领域知识的资源（开发人员/测试人员）的依赖可能会带来风险。 因为只有该测试人员才知道测试的前提条件和程序，所以他的缺席会影响整个项目的可交付成果。 通过将测试自动化集成到CI / CD管道中可以避免这种情况，从而不会对项目截止日期造成不利影响

在许多其他情况下，可以使用自动化测试，其目的应该是利用工具和测试平台（可扩展）来帮助您实现这一大胆的目标。

一键迁移

如果具有一键式功能将代码从一个应用程序环境迁移到另一个应用程序环境，则可以大大减少将代码更改移至生产环境的工作。
架构良好的CI / CD管道应进行一键式迁移，因为它可以减少不同操作之间的摩擦（代码迁移）。 选择具有此功能的优良云基础架构以及高效，优雅地使用测试自动化可以优化开发和运营流程。 只需单击一下即可推动您的开发，非常适合作为CI / CD的最佳实践。

利用并行测试作为CI / CD管道的最佳实践

CI / CD的另一个最佳实践是并行测试执行。 一旦确定了需要自动化的测试，下一步应该是在测试方法中纳入“并行执行”因素。 将测试自动化作为CI / CD管道的最佳实践已经可以加速整个过程，但是如果将其与并行测试结合使用，结果会更好。 您可以同时执行多个自动化测试，这可以更快地产生结果。

如果在一台计算机上执行测试，则无法从并行测试中获得最佳吞吐量。 这种情况会占用机器上的关键资源，例如CPU，GPU等，这可能会减慢机器上运行的其他测试的执行速度。 因此，执行测试的基础结构非常重要。 对于测试Web应用程序/网站，拥有内部测试部署和执行基础结构可能不是理想的解决方案（就成本和可伸缩性而言）。 这是LambdaTest的用处，可帮助您在包含2000多种浏览器和浏览器版本的云上在线Selenium Grid上，使用TestNG，Pytest等测试自动化框架执行并行测试 。

从先前执行的项目中学到的东西

每个软件项目都有不同的阶段，即项目计划，需求收集，实施，测试，产品部署等。每个阶段都涉及学习，这些学习可用于更好地计划和实施下一个项目。 即使项目的性质有所不同，您仍然可以利用过去项目中的一些最佳实践，从而可以加快当前项目的每个阶段。 另外，为避免重复其他项目中犯的错误。

您应该记下用于加速流程的测试自动化技术，这是CI / CD的最佳实践。 您应该让您的团队成员（即开发人员，测试人员）参与进来，以探讨可以重用测试自动化最佳实践的可能性，这样您和您的团队就不必重新发明*了。 例如，他们可能使用了某些测试框架，这些框架帮助我在较短的时间内获得了更好的测试结果。 记录这些学习内容，因为这可能有助于制定合理的测试管理策略 。

为什么绝对需要文件？

在某些情况下，项目需求会随着项目执行的过程而变化/发展。 同样，测试自动化策略的设计方式应考虑到短期目标和长期目标的考虑。

尽管一段时间内可能会对测试计划或测试策略进行更改，但团队至少应将某些流程标准化。 标准化可能意味着短名单中的特定测试框架，确定适合您预算和要求的云基础架构，组建一支能胜任测试脚本（使用Python / C＃/ Java /其他编程语言）的自动化团队。 您还应该有一个备份计划（Plan-B），以防组织内的日程安排或整体业务发生任何变化。

记录这些内容很重要，以便可以在任何时间点进行引用。 除了上面已经提到的指针外，文档还应该包括一个部分，突出显示与执行测试策略相关的“风险和假设”。 例如，将以4名自动化工程师作为资源计数来创建测试计划/测试策略。 但由于某些不可预见的情况，您可能需要缩减团队规模。 因此，通过查看与项目关联的所有不同参数来创建防呆测试策略。 强调测试策略的文档应该是*流通的文档，即用重要的时间表和里程碑进行更新，并且应该进行版本控制，以便重新访问该文档以跟踪进度。

用于代码开发和维护的*存储库

在任何项目中，团队中都会有很多开发人员推送其代码，这些代码可能是功能实现或错误修复。 同样，开发人员将执行拉取请求，以从服务器获取最新的代码更改。 在*存储库中维护源代码至关重要，并且被认为是CI / CD管道的最佳实践之一。 这样开发人员就可以使用生产服务器上可用的最新源代码来使更改保持最新。

修订/版本控制系统对于跟踪更改，识别差异以及维护简化任务以跟踪应用程序构建的环境也很重要。

使用版本控制回滚

在某些情况下，测试团队可能会遇到一些以前的软件版本中未发现的问题； 可能的原因可能是受测试的发行软件中推送的修复程序的副作用。 执行RCA（根本原因分析）有时可能会很耗时，并且您在生产环境中长期承受不起失去有价值的功能的负担。

在这种情况下，推动该修复程序的开发人员应该能够回滚其更改，以使发布不会停止，并且他还有更多的时间重新查看其实现。 没有版本控制系统，这种无缝回滚是不可能的。 回滚并不仅限于源代码； 它可以扩展到文档，演示文稿，流程图等。

临时环境模仿生产环境

无论用于跟踪代码更改的版本控制工具如何，在所有开发环境中都经常使用开发和测试环境。 开发团队可以为不同的客户组使用不同的“开发分支”，但是代码仍将被推送到生产服务器/登台服务器。 为了提高效率，过渡环境应该理想地反映生产环境。 我观察到的一个常见错误与实时路况有关。 通常，登台环境会错过生产环境用于处理负载的实时流量。 以下是登台环境使您的组织失败的13个原因 。

这种方法使将工作代码从登台服务器部署到生产服务器变得容易。 实际上，开发人员还应该具有灵活性，他们可以通过单击按钮来创建和设置新环境。 有一些工具，例如Jenkins，可以帮助实现相同目的。 使用开发团队和DevOps团队通用的工具对于简化CI / CD流程的最佳实践至关重要。

让相关的利益相关者参与测试代码的开发

让正确的利益相关者参与测试自动化计划，开发和执行变得至关重要。 由于团队中的开发人员可以为测试工程师实施的测试代码增加更多的价值，因此最好让他们参与测试用例的实现。 开发人员对软件开发的体系结构，编码技术和最佳实践有更好的了解。 经验丰富的QA工程师可能对测试基础结构，测试框架等有很好的了解。因此，与QA工程师合作的开发人员可以减少测试用例开发中的工作量和时间，从而加快CI / CD管道的测试自动化。

在紧急情况下，开发团队可以在不参与测试团队的情况下处理自动化代码，因此不会延迟实施自动化测试。 但是，建议让相关的利益相关者，尤其是质量保证工程师和开发人员参与测试用例的实现。

结合反馈，以在CI / CD管道中提供可靠的测试自动化策略

测试策略文档为如何计划和执行测试自动化以及其他与测试相关的活动制定了公平的计划。 除了更新测试策略（在需要时以及在需要时）之外，反馈循环还应用于及时更新CI / CD管道中测试自动化的代码。

反馈可用于了解用户的痛点并获得有关自动化测试提供的基础结构的总体用法的详细信息。 例如，测试自动化工程师和DevOps团队可能会在短暂的测试过程中对基础架构有所了解。 这些观察结果可能与用于捕获日志/将Python和Selenium中实现的自动化测试代码捕获到用于测试/与测试执行相关的性能的云基础架构的方法有关。

所有这些反馈都应记录在文档中，并且相关的反馈应作为最佳实践纳入CI / CD自动化管道，以使测试代码与当前要求保持同步。

CI / CD管道测试自动化中的频繁代码承诺具有微敏捷性

开发人员根据规范中提到的要求开始开发。 一旦实现完成，开发人员将对代码执行单元测试，并修复在这一轮测试中遇到的问题。 由于测试是独立测试，因此他应该能够解决独立于集成的问题。 本地测试完成后，开发人员会将代码推送到代码存储库。 在大多数开发环境中，通常将代码推送到“开发部门”，一旦批准并测试了代码，便可以将其推送到“生产部门”。

因此，应该鼓励和激励开发人员更加频繁地推动代码更改，以便轻松跟踪更改。 团队中的开发人员应认真遵循CI / CD的这一重要最佳实践，以便您能够在与CI / CD管道中的开发和测试自动化有关的活动中实现微敏捷性。

记住，它是CI + CD！

如果我们提到CI / CD流程的最佳实践，则交流与协作是关键Struts，因为有多个团队（产品规划，开发团队，验证团队，DevOps团队等）必须协同工作才能确保项目的成功。 因此，与这些领域中最优秀的领导者对CI / CD流程进行基准测试很重要。 并且被视为CI / CD管道的关键最佳实践，可为优化提供敏锐的意见和建议。

CI和CD是两个独立的过程，但不能将它们称为不可分割的过程。 执行CI流程的任何延迟或延迟都可能妨碍CD流程的输出。 尽管可以使用自动化来提高CI / CD过程的效率，但是在很多方面自动化可能没有效果。

另外，请记住，在任何项目中，都不会发生孤岛活动，因为总会有人依赖于您的活动结果。 为此，项目利益相关者之间需要适当的沟通。 例如，您的质量检查工程师可能正在研究某些测试用例，而这些测试用例并不能满足所有要求。 如果执行了这样的测试，您可能无法获得良好的测试覆盖率，因为在测试用例/测试套件实现中会漏掉重要的场景。

通过先执行较小的测试用例，使其保持简单和井井有条！

我在许多项目中都见证过，当涉及到CI / CD管道的测试自动化时，我们常常会忘记以一种系统的方式优先考虑我们的测试用例。 这就是我的意思！ 作为CI / CD的最佳实践，始终建议先执行较小和简单的测试用例，然后再执行较长和复杂的用例。

这样，您可以确定以独立方式进行功能测试的各个测试用例的覆盖范围和性能。 设计测试用例以检查多个模块之间的交互的复杂测试用例可能会在以后出现！

团队内部和团队之间的透明度

许多项目都有位于不同地区的开发和质量检查团队。 除了需要确保每个团队成员同步的高度协调之外，更好的透明度可以使事情变得更好。 在这里CI可以非常有效，因为它为团队的主要利益相关者带来了非常需要的透明度。

有了CI，团队就可以更好地了解测试的总体状态以及可以采取哪些措施来提高测试效率。 这就是如何促进集体智慧的使用，以改善团队和项目。 必须让每个人都在同一页面上工作，尤其是在远程工作时。 作为CI / CD流程的最佳实践，项目管理工具可能非常有效。 使用项目管理工具，每个人都会改变其他团队成员所进行的活动，还必须完成任务的截止日期。 以下是针对您的软件测试团队的19种最佳协作工具 。

为CI / CD处理选择正确的工具

上述所有技巧和可行见解将帮助您使用针对CI / CD管道的最佳实践来加快测试自动化的步伐。 尽管最终，起搏CI / CD管道在很大程度上取决于工具。 CI / CD有许多可用的工具，但是您应该根据预算，要求和经验选择合适的工具。 一些常用的CI / CD工具是Jenkins，Travis CI，Gitlab，TeamCity，Codeship，Circle CI等。

在对任何特定工具进行调零之前，我们强烈建议您先看一下该工具的优缺点，因为在开发过程中CI工具的任何更改都可能会影响您的交付成果和截止日期。