开发人员的一项最佳最佳实践是对持续集成/连续 交付 （CI / CD）管道进行检测 ，该管道可自动构建软件，打包应用程序，将其部署到目标环境以及对启用该应用程序的服务调用进行检测。 这种自动化要求编写脚本编写各个过程，并编排从代码检入到运行应用程序的步骤。 开发团队一旦成熟，就会使用自动化来推动流程变更，并努力进行更小，更频繁的部署，以向用户提供新功能并提高质量。
但是有一个重要的假设，即自动化与频繁部署相结合将提高质量。 这是自动化测试必须测试的内容：应用程序和代码更改是否已经过彻底测试？ 该发行版是否符合部署的最低接受标准？ 新版本是否会引入影响用户，难以调试且可能破坏组织解决的生产缺陷？ 应用程序的性能是否得到充分评估？ 该应用程序是否已针对已知的安全漏洞进行了测试？
定义：什么是连续测试？
为了真正运行CI / CD ，测试必须自动化并集成到CI / CD管道中。 换句话说，以并实现此目标为目标的开发团队正在实施连续测试。
连续测试要求团队已经自动化了一组可以插入CI / CD管道的测试。 尽管测试应用程序是在开发软件的大多数组织中完成的，但要具备评估风险，确定质量保证实施的优先级并自动化最关键的应用程序测试的技术实践，这需要人员，实践和技术来建立。
为什么测试自动化在当今更加重要
在开始自动化测试然后在连续的测试管道中实施测试之前，重要的是要确定一些目标和收益。 为此，请考虑手动测试暴露的一些问题。 对于仍在手动运行测试的组织，自动化使测试过程具有一定程度的一致性。 由于新测试是自动化的，因此可以将它们编排为回归测试，以根据所有已建立的标准完全验证应用程序。 由于测试是自动化的，因此可以在更短的时间内，更频繁地以更低的成本运行它们。
除了提高生产率和增加测试范围外，自动化还提供了其他好处。 诸如无服务器计算之类的分布式计算体系结构使调试问题变得更加困难且耗时。 自动化使团队能够针对单个或一组应用程序组件和服务进行测试，从而更容易在问题变成生产缺陷之前进行隔离。
如今，围绕应用程序的整体质量和性能，在业务上的重要性可能更高。 作为数字化转型计划一部分而投资于客户体验的企业应该寻求高质量和快速执行的体验。 移动应用程序需要在iOS和Android上进行测试。 使用来自企业系统，面向客户的应用程序和第三方数据源的更多数据和分析的组织应测试其数据集成过程和数据质量。
从技术角度来看，有很多理由要投资自动化。 对于正在开发面向客户的应用程序的组织而言，安全漏洞和数据保护如今已变得更为重要。 此外，能够轻松，一致地测试应用程序使IT组织可以更频繁地修补和执行升级。
持续测试需要定义围绕风险的优先级
自动化测试不是简单的任务。 对于大多数组织而言，问题在于他们的测试人员太少，在应用程序开发过程中进行的更改太多，执行测试和修复缺陷的时间太少。 因此，尽管连续测试非常重要，但领导者必须从战略上优先考虑其实施。 然后，它需要一种业务和技术策略，因为大多数组织无法轻易承担承受相同优先级的所有测试的费用。
要确定应用程序的哪些区域优先于测试工作，您需要对关键业务流程和用户体验进行评估。 如果一个应用程序具有十个功能，但大多数用户活动是使用其中三个功能，则测试应从这三个更关键的功能开始。
然后是一个问题，哪种测试最重要。 在典型的Web或移动应用程序中，开发团队可能希望在代码级别实施单元测试，对任何Web服务进行正式的API测试，对主要用户交互的用户体验测试，浏览器或设备测试，代码分析，性能和负载测试，和（最近最关键的）安全测试。 这是很多测试，尤其是对于小型测试团队而言。
哪些类型的测试团队关注的重点还应该与业务需求和风险相适应。 例如，如果要对API进行商业化，则测试该层将变得更加关键。 如果应用程序在高峰时段有大量用户活动，那么性能测试就变得很重要。 如果应用程序处理大量数据或提供分析功能，则具有多种数据输入的回归测试非常重要。
有关持续测试的关键问题
一旦制定了业务风险评估和技术策略，组织就应该研究用于开发和执行测试的技术和流程。 Microsoft，IBM，HP Enterprise，MicroFocus和其他公司的企业级工具与专门测试软件的供应商的工具（例如Parasoft，Tricentis和SmartBear）竞争。 然后，有大量的特定于测试类型和特定于平台的工具可用于单元测试，功能测试，渗透测试，管理验收标准，性能测试和API测试。 许多都是开源测试工具和框架，例如Selenium，JMeter，Junit，Maven和SoapUI，它们具有悠久的历史，可同时用于小型和大型测试需求。
审查测试工具时应考虑几个问题：
- 该工具在围绕风险和重点领域实施测试策略方面做得如何？
- 开发人员，测试人员或系统工程师正在使用该工具，还是将这三者结合使用？
- 在敏捷开发过程中何时将创建并执行测试？
- 该工具与CI / CD工具集成起来有多容易？
- 工具组如何在CI / CD流程中测试不同类别并在不同阶段使用？
第一个问题似乎很明显：如果您将测试工作集中在功能和浏览器级别的测试上，那么十个您将更有可能想要使用专注于此功能的解决方案。 当组织支持具有不同测试需求的多个应用程序时，答案就不那么明显了。 当没有质量保证工程师并且对测试能力的期望越来越高时，尝试为应用程序开发的规模和不同的应用程序开发需求选择合理数量的工具并非易事。
作为考虑不同工具的一部分，重要的是讨论谁将操作它们以及如何使用它们。 例如，对于开发人员来说，负责单元和API级别的测试是最常见的，因为它通常被集成到编码环境中。 大多数功能测试，浏览器测试和设备测试留给质量保证测试人员使用，而性能和渗透性测试通常需要开发人员，测试人员和工程师之间的协作。
关键是要根据框架执行哪种类型的测试，以及一个框架中的测试脚本是否可以在其他框架中使用，进行协调。 复制单元测试已经在做的功能测试并没有增加价值。 另一方面，在性能测试中使用功能测试可以扩大测试范围。
接下来的考虑是在敏捷开发过程中的何处将创建和执行不同类型的测试。 大多数团队在开发应用程序时实施单元和API测试。 但是何时实施功能，负载和渗透测试不太明显。 这取决于冲刺和发布的管理方式，发布频率，每次部署的总体风险以及实现的自动化水平。
从自动化测试到持续集成的因素
下一组注意事项是是否将自动化测试集成到CI / CD管道中，在何处以及如何将其集成到CI / CD管道中。 Devops团队应该寻找文档化的集成，例如将Jenkins与Selenium集成或运行Travis的Postman API测试 。 这些集成应该使进行服务调用以运行测试变得容易，而且还能够解析响应并处理错误情况。
有了适当的集成后，团队应该考虑哪种类型的测试最适合连续集成。 由于devop团队经常会频繁运行CI / CD管道，因此需要长时间运行的自动化测试不是连续测试的最佳选择，而应在CI / CD管道之外运行。 另一方面，运行单元测试以及对开发，测试或登台服务器进行的每个自动部署，都可以在新代码破坏回归测试时向开发人员提供快速反馈。
成熟的团队将测试定向到不同的渠道。 冒烟测试需要快速运行，并提供有关应用程序核心功能是否正常工作的快速，全面的视图。 单元测试和API测试可以通过软件组件进行调整，并且当相关组件中的代码发生更改时，可以使用基于规则的触发器来执行它们。 端到端测试通常包括更全面的功能测试，性能测试和渗透测试，可以按定义的时间表运行，并且仍会向CI / CD平台提供反馈。
与所有技术实践一样，持续集成需要一种战略来上手，要考虑新的实践并不断地致力于成熟。 希望实施CI / CD的Devops团队应将持续测试作为实施的第三条轨道，并使其与持续集成和交付一起成熟。
From: https://www.infoworld.com/article/3289104/how-to-align-test-automation-with-agile-and-devops.html
413
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
