过时的传统软件开发方法并不能接管不断升级的市场趋势，并且这些方法缺乏解决方案，这些解决方案无法满足引入“ 持续集成（CI）和持续交付（CD） ”的快速软件发布的日益增长的需求。 除CI / CD之外，您还需要具有这种技术能力，开发人员可以适应缩短的交付周期和自动化流程。 要跟上测试领域变化的加速步伐，您还需要与其他QA专业人员加深，拓宽并建立牢固的网络。 说起来容易做起来难，我知道！ 从质量保证经理的角度来看，我经常观察到实施CI / CD管道发布周期，不正确的资源管理，不切实际的ETA以及任务管理中所涉及的犹豫所带来的挣扎。 这就是为什么我打算谈论CI / CD管道的兴起，每个QA应该遵循的共同挑战和可行的见解，以便使用CI / CD管道快速安全地浏览每个发行版。

为什么CI / CD管道成为大多数组织的明显选择？

到目前为止，测试人员迟早要转向项目和组织中的持续交付。 团队选择了CI / CD管道来利用快速发布版本所带来的好处，即只需按一下按钮。 企业需要更快的反馈，因此大大缩短了上市时间。 这导致CI / CD管道在全球范围内的采用率增加。 就个人经验而言，CI / CD流程对我过去进行测试的方式产生了影响，因为它帮助我的团队加快了上市进程。

我的开发人员朋友几乎不需要测试方法，尤其是冗长的测试阶段，从来没有跟上交付速度。 当开发人员获得有关其代码的快速反馈时，连续交付将取决于开发人员的能力。 他们签入的那一刻，如果他们错误地在包含不同测试层的构建管道中引入了某种问题，就会得到信号。 即使没有测试自动化，您也倾向于了解实时用户的反馈-来自客户群的直接联系。 开发人员永远不会削弱快速反馈，从而提高生产效率。 构建管道减少了集成和发布测试所需的等待时间。 这意味着一切都一口气发生：编写代码–在本地测试–审查–合并–集成–并交到测试人员手中。 关键部分之一是测试自动化，公司可以专注于软件的持续集成和持续交付。 只需单击一下即可将可执行文件放到本地，测试或生产环境中。 CI / CD流程中的最佳实践可以提供高质量的产品。

随着对敏捷，看板和其他最新SDLC方法的时间需求，CI / CD管道的重要性变得显而易见。 但是，作为专业的质量检查人员，我们应该如何在CI / CD管道中进行自我管理。 让我们找出答案。

每个QA应该注意的合理步骤，以确保CI / CD管道成功

在CI / CD管道中，技术部分可能是测试人员的陷阱。 基本上，他们的职责不仅限于此：对需求，实践，产品和过程的所有关注。 如果您要开始在持续交付环境中工作–考虑10倍！ 想一想：

• 团队是否朝着正确的方向前进？
• 是否所有业务需求都已转化为可执行规范？
• 作为质量检查测试人员，您将以何种方式在方案，验收标准和示例方面做出贡献。
• 您认为已经浮动的流程有改进的空间吗？ 您是否能够检测到废物并最终将其清除？
• 您在非功能测试，性能，可访问性和安全性方面的经验。
• 跨浏览器测试，以确保您的更改对从不同浏览器，浏览器版本，设备和操作系统查看Web应用程序的受众而言看起来不错。
• 使用Selenium进行自动化的跨浏览器测试，计算出自动化测试的投资回报率 。
• 跨浏览器测试和响应测试之间的区别 。 两种测试实践经常被误解为相同的。 但是，事实并非如此！
• 作为CI / CD管道的基础，版本控制使开发人员可以在共享代码库上进行协作。 版本控制是CD的绝对必需和伟大的伴侣。 您在版本控制系统中具有撤消功能，这意味着回滚到以前的版本。 此外，可以在整个历史记录中跟踪配置，数据库，脚本，文档。
• 跨所有暂存环境所需的数据和配置。 请记住， 登台环境对于您的组织而言失败的13个原因 。
• 使用测试框架和自动化工具在整个应用程序中创建自动化的稳定测试
• 深刻的见识：没有代码或功能未经测试，因此可能进一步降低速度； 有时会阻止您的团队发布软件。
• 保持回归测试套件有效性的良好跟踪机制可以清楚地概述流程，并确保仅将有用的测试添加到测试套件中，从而在控制回归缺陷时对所有质量活动具有统一的视图。
• 自动代码提交，测试套件和测试环境会立即产生反馈，当您使用CI / CD管道时，它会自动解决诸如版本控制之类的问题，或者当编码人员编写单元测试时通常很难将其转换为工作流程。 保持期望的水平是质量保证的关键。 质量保证意味着要包括不断发展的想法和长期维护，以及可以浮出水面的三个重要方面：测试，交付和优化。
• 其他QA成员如何编写测试包以在每次连续构建期间自动运行它们？ 将它们维护在CI系统中可以使测试套件更有条理，更易于访问。
• 您需要一个Continuous Integration Server来监视主存储库，您将在其中运行自动测试新提交的提交。
• 负责尽可能频繁地合并更改的开发人员的特定角色。
• 开发生命周期从清单或剧本开始，清单或剧本包括恰好是手动执行的任务。 稍后，这些任务可以使用脚本和工具转移到自动化。 这样，如果需要再次运行清单，您可以确保任务是可重复的，因为团队成员可以运行脚本。 此外，您可以在环境之间一致地运行剧本脚本，从而提高了可靠性，就像用于在生产环境中部署代码的脚本一样。

质量检查并不局限于为什么以及如何创建前端网站测试计划的基本方面，实际上，它可以为组织增加价值。 只要您倾向于优化质量检查，就可以更快地增加产品周期。 借助快速的反馈循环，您可以超越结果。

全面的测试对于软件产品的成功起着至关重要的作用。 总是三思而后行，三次测试案例以实现自动化，并从中获得最大收益，应尽早开始。 从第一天开始，逐步构建您的自动化套件，该套件可以以更便宜的价格检测错误，而您可以在周期的后期阶段发现相同的问题。 最后压缩测试还有很多问题，因此请继续弄清楚以下几点：

• 您将多久重复一次该场景？
• 过程的长度。
• 征集所有针对多个构建执行的重复测试用例。
• 检查涉及的人员和资源依赖关系以及可能由于这些原因造成的任何短缺或延迟。
• 如果要在任何地方跳过自动化，请确保它不会成为容易出错的过程。

每条CI / CD管道面临的最常见挑战

• 开发人员将专用时间的20-40％用于调试。 这意味着，在调试软件上花费更多的百分比而不是构建新功能会导致相反的结果，从而导致生产力下降，支出不受控制和员工流失。
• 即使是最全面的测试，分级和QA流程，也可能允许错误穿越裂缝，因此始终要准备面对意外或中断，并经常破坏CI / CD管道中的代码。
• 即使在部署代码后，工程团队也面临挑战，因为当您不为监视过程添加自动化功能时，周期将变得更加不受控制。 过时的生产监控实践通常会使CI / CD流程停滞不前，并且应该制定明智的生产错误处理策略以减轻相关风险。
• 一次执行的容易出错的任务可以阻止足够的精力损失，例如痛苦的琐事可能会耗费20分钟以上的时间，而一周要乘以5次，则可能会增加100分钟的痛苦时间。 因此，为了获得健康的剂量，请解决琐事并在初始阶段进行优化，从而完全避免痛苦的时间。 在这方面，首先要做最困难的部分，这将进一步分析和确定组织过程中的弱点。 拖延的任务表明了需要改进的地方，因此团队应该追求或保持他们的领先地位，以便尽早解决。
• 如果应用程序仅在开发人员的计算机上工作，则网站业务与之无关。 总体业务目标和同理心应该是每个团队成员的主要职责。 CI / CD管道完全旨在将代码更改发送到网站，以方便最终用户。 因此，当您“完成”时，请确保整个团队的责任和贡献是完整的。

实施可靠的CI / CD管道的每个质量检查的可行见解

除了理性的思考过程外，作为专业的质量检查人员，您还应对生产环境中发生的每分钟变化负责。 在任何发布周期中松懈都可能导致大量中断。 这就是为什么必须对所有需要采取的可行见解进行检查的清单，以确保CI / CD管道成功。

使用Selenium实现自动化跨浏览器测试的自动化测试

您的网站是您在互联网上的业务的标识，如果您最近通过CI / CD管道更改了生产代码后，它在某些浏览器和设备上看起来很奇怪，那将是非常糟糕的。 跨浏览器测试是一种衡量网站相对于不同浏览器和浏览器版本的不同渲染引擎的性能的过程。
使用Selenium进行测试自动化可以帮助您更快地加快产品开发速度，借助Selenium中的并行测试可以更快地将产品推向市场。

探索性和自动化测试

我们的普通读者会知道我们的主要重点在于快速测试的能力。 保持质量和质量保证对每条CI / CD管道的价值，我将与您分享我们如何专注于测试计划以适应CI和敏捷开发方法的经验。 探索性测试对于成功的CI / CD管道至关重要，您可以将其与自动化相结合，从而在测试和业务方面取得增长。 从探索性测试中了解更多信息：一切都与发现有关！

当您开始在流程中整合质量检查时，需要确定公司在质量检查中的所有方面。 一旦知道了需要自动化的内容，就可以进行自动化。 功能测试不能放在自动化测试的地方，因为您不知道接下来可以编程什么。 在这种情况下，我们根据探索性错误将其与自动测试创建混合在一起。 现在，在功能性探索性测试之后对构建进行过滤，以自动测试剩余的错误。 您在功能性探索性测试中的认知能力使您在开始组装所有功能以进行测试并将质量检查转变为发布的关守时达到了一个关键点。 开发人员开始将构建版本发布到质量保证部门的CI / CD服务器，由QA部门进行测试，然后再使用坚固的CI / CD管道进行发布。

功能和UI测试

功能和UI测试每天至少重复一次，对于中型应用程序，则需要2-3小时。 在使用Selenium进行测试自动化的情况下，无需频繁更新自动化脚本，但是UI经常会被修改，因此需要频繁更改脚本。 两者都依赖于多个依赖关系，并且都容易出错，并且当我们必须确定优先顺序时，我想说的是在进行UI测试之前先进行功能测试，以充分利用资源。

自动化回归测试

当开发人员更改功能或修复错误时，将使用回归测试。 CI系统可作为针对长期产品的自动回归测试套件的QA工具，非常适合敏捷开发，在敏捷开发中，团队应至少每周部署一次产品，并具有较短的期限以适应手动回归测试。 另一个优势是您可以将基础结构用于将来的产品，从而加速测试自动化。 当发现新的缺陷时，CI自动添加新的测试用例。 CI在自身的基础上构建了针对新代码自动运行的实质性回归测试套件。

结合敏捷测试人员和开发人员

我认为，如果将质量描述为事后的做法，那将永远是不幸的，这意味着您首先强调要求，然后进行设计，编码，最后将齿轮转向质量，然后说：“让我们请一些测试人员来”。 当您必须在一周或一个月之内提早发货时，测试或整体质量绝对是一个重要方面。 敏捷方法论将软件开发分解为用户故事（较小的任务）。 这样可以加快反馈速度，并进入市场。 帮助您更快地开发更好的Web应用程序。 使用CI / CD管道，您可以更频繁地验证Web应用程序。 但是，自动化构建，集成，测试和部署软件的各个方面可以降低风险。 而且，如果您在“ 敏捷与瀑布”方法学的背景下看到它，那么敏捷将通过支持预期需求经常变化和发展的过程而Swift落后于瀑布方法。 在开发经常进行大修的网站时，要与技术环境，客户需求保持同步，并通过选择有效的自动化流程来满足开发人员的需求。 查阅我们的文章“ 从瀑布式测试到敏捷测试时我学到了什么？ ”

如果您无能为力，请不要使用Selenium启动测试自动化！

当然， 使用Selenium进行自动化测试会有好处 。 但是，如果没有策略，最终可能会使用复杂的代码进行简单的代码测试。 重要的是分析如何自动化不同的零件。 实施自动化计划不容忽视，但该战略将帮助我们实现目标。 我总是建议隔离的单元测试，每种语言都支持。 快速运行的单元测试可提高置信度，并在短短几秒钟内确保代码的正确性。 如果单元测试失败，则无需进一步。 通过单元测试表明组件运行良好，应用程序正在根据客户的期望进行构建。 是的，BDD是编写更好的自动化测试的最佳实践。 这里有8条可行的见解，旨在编写更好的自动化代码 。

根据您的项目需求选择正确的自动化测试工具

您可以看到自动化测试工具的广泛市场，重要的是选择适合您总体需求的正确测试工具：它应该支持C＃，Java或.Net应用程序等平台和技术，并使用哪种操作系统？ 此外，根据是否需要测试Web应用程序或移动应用程序（Android或iOS还是这两种操作系统）来做出决定。 例如，如果您希望执行自动化的跨浏览器测试，那么将Selenium作为可靠的开源软件作为首选。 但是，如果您选择使用Selenium进行内部测试自动化，它仍然有一些限制。 限于使用Selenium Grid可以在其上并行测试的浏览器的数量。 另外，要运行4到8个并行测试会话的Selenium Grid，将需要非常坚实的硬件要求。 对此的最佳解决方案将被视为基于云的跨浏览器兼容性测试工具，例如LambdaTest。

LambdaTest提供了一个Selenium Grid，它与支持Selenium的每种框架和语言都兼容。 您可以使用Selenium on cloud进行大规模的测试自动化。 您还可以集成到许多第三方项目管理工具CI CD工具，以及它们的Chrome扩展程序和WordPress插件 。

LambdaTest还提供了Open Selenium API ，可帮助您提取测试详细信息，将测试自动化Selenium脚本执行从LambdaTest平台执行到您的首选系统的测试报告，而无需登录LambdaTest。

在CI / CD管道中纳入连续测试

连续测试是使用广泛的自动化测试套件来评估Web应用的E2E评估的过程。 它可以确保快速传播反馈和即将到来的冲刺。

CI系统不限于代码级单元测试，甚至可以立即在相互依赖的平台上执行集成测试。 不要使用集成测试来测试业务逻辑，这就是单元测试的目的。 CI系统运行单元测试对于每个构建都非常快。 集成测试的运行时间要长得多，而单元测试则针对代码的基本正确性。 单元测试应清除所有业务逻辑错误。

将连续测试纳入您的CI / CD管道中，并通过测试自动化和反馈功能使您的质量保证团队能够更快地进行评估。 查看我们的读者以了解更多有关像Pro一样在DevOps中实施连续测试的信息 。

引入故障注入测试以更好地覆盖CI / CD管道

顾名思义，“故障注入测试”是您有意将故障放入代码中的地方，以增强Web应用程序的坚固性以及测试范围。 将故障注入测试作为检查的标准部分进行介绍，并且当您的流程和实践变得成熟时，它将确保Web应用程序的弹性。 确实，当您能够在错误或错误出现在生产环境中之前分析它们的结果时，这是一个好习惯。 尽管您可以手动执行故障注入测试，但是也可以使用一些工具。

不要让无人参与的测试失败

团队必须有一定的纪律性，以便团队停止跳过任何失败的测试，并且当您暂时暂不进行测试时（即抛出SkipException）或使用工具将其静音，暂时放置适当的注释并确保不保留它配置中的无人值守或忽略时间更长。 单个构建不包含很多更改，因此可以不时查看构建以找到测试。 实际上，审阅带有某些更改的内部版本可帮助您确定任何损坏的测试。 而且CI / CD管道必须稳定，并带有中继线，该中继线可以通过电子邮件或IM通知您构建是否失败。 TeamCity提供了许多功能，其中一个功能可以让您知道—谁负责测试失败。

注意负载冲突

CI / CD流水线包含测试以确保交付的构建稳定且无错误。 在遵循CI / CD流程的同时，报告问题是关键因素。 完整的报告提供了有关如何运行测试以及如果任何人失败的原因的详细信息。 您是否曾经测试过Web服务器的性能？ 您使用了哪个工具？ 我认为有60％的机会是JMeter。 该工具模拟真实用户的行为并提供复杂的报告。

最好的事情是，Jmeter与Selenium Grid一起检查在多个用户并发用户流量下的软件性能。 Maven，Jenkins和Selenium可以一起使用，以创建良好的端到端报告，创建APPDEX（应用程序性能指数）以及通过同时点击浏览器来记录应用程序的行为。 我将性能测试包括在讨论中，以便您从开始就可以对其进行标记，以避免意外的负载冲突。

有意义的仪表板

确实，如果没有自动化，则更早，更快速地进行测试会很麻烦。 任何CI / CD管道的主要挑战之一是各个团队或部门（例如DevOps，QA，安全团队等）之间的协作，他们正在努力将通用的Web应用程序推向市场。 您需要一个对所有人透明的地方，或者一个仪表板，并传达有意义的和有条理的信息。 诸如Jenkins，Git和Jira之类的CI / CD工具使团队能够无缝地进行协作，并通过评估每个人想要的对您的DevOps项目最重要的数据来定制有意义的仪表板。 我建议添加从DevOps工具的不同数据源配置的功能部件，以帮助管理CI / CD管道。 “功能”小工具可分解故事，并让您知道哪些故事已完成或正在进行中。 一种更深入地挖掘以发展DevOps文化的方法。 不同的成员具有不同的优先级，因此在计划设计仪表板时需要执行渐进评估。 为CI / CD管道创建有用的仪表板，以及每个人的同意都很重要时，是有点棘手的。 但是，这也至关重要！

例如，如果您要使用LambdaTest和跨浏览器测试云使用Selenium进行测试自动化，则会获得一个直观的仪表板，该仪表板显示有关测试用例执行时间戳，元数据，逐个命令的屏幕截图，Selenium日志，网络日志，命令日志，视频日志，它们代表测试执行的记录等。

寻求独特的命名约定以确保UI抵抗CI / CD管道

自动化工具是基于属性的测试工具，可帮助查找和标识对象。 根据位置坐标，如果发现控件标题或位置发生变化，则该工具可能会失败。 任何Web应用程序的UI都是一个不断变化的部分。 随着时间的推移，您将有不同的开发人员致力于不同的需求。 现在，您不希望这些开发人员在不遵循标准命名约定的情况下继续前进。 由于命名重复，基于属性的测试工具将无法精确定位对象。 稍后将变得很麻烦，因为您将不得不为整个Web应用程序重命名旧名称。 因此，请为您的控件提供唯一的名称，以确保自动测试本身不需要更改并且可以抵抗UI更改。

持续部署与持续交付，了解差异！

如果在代码库中进行了一些修改后立即部署了构建，则可能会使用户感到烦恼。 持续交付的关键是保持代码库处于可部署状态，不进行持续部署并不意味着您未在进行持续交付。 连续交付是一个很小的构建周期，并且周期中的短距离冲刺可以缩短检测错误的周转时间，从而快速修复这些错误。 总体而言，它为早期提供了稳定的代码基础。 这是一种首选方法，它允许团队立即解决问题，而在您计划发布代码库时不会解决。 它提供对产品推出，风险因素和功能的全面控制。

用户体验测试

在用户体验测试中，您从用户那里收集定性和定量数据，并且在组装完应用程序之后，测试目标就变成了用户体验，可以通过结合负载测试和跨浏览器兼容性或移动测试工具来实现。 端到端测试很重要，还需要避免不必要地延长端到端测试的时间。 如果这会影响生产率，那么如果您继续执行更多测试，那么请继续关注正确和重要的事情。

“如果您想要一个出色的网站，则必须进行测试。 在一个网站上工作了几周后，您再也看不到它了。 你知道太多了 找出它是否真正可行的唯一方法是对其进行测试。” –史蒂夫·克鲁格–不要让我想

烟雾测试

冒烟测试将监视系统并验证最重要的功能或核心功能是否正常运行。 冒烟测试实际上允许您对主要功能进行快速回归测试，确定产品是否准备好进行测试以防止进一步浪费时间和资源。

自动化交付和部署

自动生成的可交付成果仍然可供更广泛的受众使用，而功劳归功于自动化。 Alpha和Beta测试可以转移到更多的开发阶段。 CI / CD管道系统可通过系统测试部署脚本实现自动部署，有助于确保在移至其他环境时不会出现纠结。

文档是坚固的CI / CD管道的基础

在自动化的单元测试中，可以将代码质量保护为文档标准，从而帮助提高下一个解决方案的质量。 自动化的单元测试也可以用作自记录代码。 维护代码在软件开发中起着至关重要的作用。 应该解决文档短缺或难以理解代码的问题，因为程序员可能不愿意或不喜欢编写文档。 拥有一个包含所有信息的文件的文档，代码正在执行的操作应减轻不必要的软件维护成本。

未处理的中断一定会导致测试失败

平台安全性，在自动化测试过程中向框架中添加故障转移逻辑，记录任何类型的中断，所有这些累积的努力可以在很大程度上减少或避免中断，从而导致使用测试自动化进行全面验证。 合法的错误或重试尝试也可能无法处理中断，因此在这种情况下，更安全的方法是“测试失败”。

资源管理可以大大帮助您的航行

编写自动脚本的工作应分配给具有自动测试工具提供的丰富脚本语言经验的专家。 与此相反，如果不精通自动测试脚本的编写，则可能是QA工程师更擅长编写测试用例，并且在不需要深入了解脚本语言的情况下可以被聘用。 一旦设计了自动化脚本，您就可以向经验不足的自动化测试人员提供知识转移，并让他们负责通过该脚本进行日常评估。 同时，您团队中经验丰富的质量检查人员可以提出更多开箱即用的测试用例。

连续的提高

CI / CD管道不会在部署时结束。 反馈循环是CD的核心，它指示监视部署的附加阶段。 该阶段将再次使用自动化工具来确定部署对最终用户的影响。 您需要密切关注诸如业务收入之类的明显指标，以及诸如参与时间和用户转化率之类的更精细的指标，以观察相关性。

所有团队成员都在同一页面上

即使他们不在您的CI服务器上，也应始终告知所有团队成员。 自动化通知可以循环获取无法访问的质量检查小组成员，从而有助于总体上保持较高的质量。 紧密的反馈循环可防止意外事件发生，并且每个人都可以通过Slack等通信应用程序在同一页面上转换情况，从而可以轻松集成更新，尤其是在您的团队有大量日常用户的情况下。

结论

在CI / CD方法论中，您将质量融入到CI / CD流程的每个步骤中。 特别是，持续交付的中央反馈回路是不断进行重新检查的地方，以确保将优质的产品交付给最终用户。 自动化测试允许以无错误的代码和预期的质量交付新功能。 新功能的项目计划涉及到有关分析，自动化测试仪器任务和性能监视的考虑。

整个组织都扮演着重要的角色，应保持专注和激励，以生产高质量的可交付成果。 当产品经理需要监督部署和质量保证时，他们便扮演了角色。 安全团队应注意发布过程。 质量检查团队成员在测试开发和登台环境时所承担的主要责任。

质量保证小组的所有职能应与最终发布之前的生产一样严格。 开发人员应专注于产品发布并进行详细调查。 最后，在正确的自动化工具选择上明智地选择。 LambdaTest提供了2000多种真实的浏览器，以及与CI / CD工具（如Jenkins，Travis CI等）的集成，可帮助您将连续测试纳入CI / CD管道中。 测试愉快！

翻译自: https://www.javacodegeeks.com/2019/06/professional-qa-implementsrobust-pipeline.html