Appearance
CI/CD 常见问题解答
有哪些不同类型的测试？
自动化测试是任何 CI/CD 的关键组成部分。 引入不同类型的测试将帮助您的团队在扩展应用程序时不牺牲质量。 以下是最常见的测试类型。
- 无障碍功能测试。在无障碍功能测试期间，团队确保色盲、听障、视障等残障人士可以使用应用程序。 无障碍功能测试是实用性测试组的一部分。
- 验收测试。这类测试用于确定应用程序在多大程度上满足业务需求和最终用户需求。 通常，验收测试会产生二元结果 – 测试通过或失败。
- 黑盒测试。这是一种检查软件功能而不检查其代码或内部结构的软件测试。 基本上，测试是在无产品内部知识的情况下进行的。 在黑盒测试中，软件功能未知。
- 端到端测试。顾名思义，端到端测试也称为 E2E 测试，是一种从头到尾检查软件应用程序或产品的全部功能的测试。 端到端测试的目标是从头到尾模拟和测试真实世界的使用场景。
- 功能测试。功能测试是根据功能规范和要求验证软件应用程序的测试。 我们通过功能测试确定应用程序是否按预期运行。
- 集成测试。集成测试是一种软件测试技术，将软件应用程序的各个单元或组件组合在一起并作为一个群组进行测试。 集成测试的目的是验证应用程序的组件是否协同工作并按预期运行。 集成测试通常在单元测试之后和系统测试之前执行。
- 交互式测试。在交互式测试中，测试人员在软件应用程序上手动执行一组测试用例并验证结果。 交互式测试很实用，因为它允许测试人员详细探索应用程序并识别自动化测试技术可能无法捕获的问题。
- 负载测试。负载测试是一种性能测试，用于评估系统、网络或应用程序在高工作负载下的性能。 负载测试用于确定系统在正常和峰值负载条件下的行为，并识别可能出现的瓶颈或其他问题。 负载测试很重要，因为它有助于确保系统能够处理预期的流量或使用量而不会遇到性能问题。
可以为不同的操作系统运行并行测试吗？
可以在不同的操作系统上运行并行测试。 方法是设置在不同操作系统上运行的测试环境，然后在这些环境中同时运行测试。 自动执行测试很适合这种情况，因为它可以产生比手动测试更一致的结果。
我们如何并行运行测试？
可以通过多种方式在不同的操作系统上运行并行测试，具体取决于用于测试的工具和框架。 一些常见选项包括：
- 使用支持在不同操作系统上运行测试的基于云的测试平台。 许多基于云的测试平台，例如 Sauce Labs 或 BrowserStack，允许您指定要用于测试的操作系统和浏览器组合。 由此可以在不同的操作系统上轻松同时运行测试。
- 使用支持在多台机器上运行测试的本地测试执行工具。 一些测试执行工具，例如 Selenium Grid，允许您设置运行不同操作系统和浏览器的测试机器网格。 由此可以在不同的操作系统上轻松同时运行测试。
- 使用支持在不同操作系统上运行测试的持续集成 (CI) 工具。 许多 CI 工具，例如 TeamCity，允许您指定要用于测试的操作系统和浏览器组合。 由此可以在不同的操作系统上轻松同时运行测试，作为构建管道的一部分。
无论您选择哪种方式，重点都是确保拥有必要的基础架构以支持在不同的操作系统上同时运行测试。 这可能需要设置多个测试环境，配置测试工具以支持并行执行，并正确组织测试以利用并行执行
并行测试与跨浏览器测试有什么区别？
并行测试与跨浏览器测试都是用于确保软件应用程序在不同平台或环境中正常运作的技术。 但是，它们在测试范围和实现的特定目标方面有所不同。
并行测试是在不同环境、平台或设备上同时运行多个测试的技术。 并行测试的目标是通过同时运行多个测试来加快测试流程。 这非常适合使用许多测试用例测试大型应用程序，因为它可以让您更快完成测试流程。
跨浏览器测试则是在一系列不同 Web 浏览器上测试软件应用程序以确保其在所有浏览器上都能正常运作的技术。 跨浏览器测试的目标是确保应用程序与各种浏览器和设备兼容，并在所有浏览器和设备上提供一致的用户体验。
虽然并行测试和跨浏览器测试可以作为综合测试策略的一部分结合使用，但它们是具有不同目标和用途的不同技术。 并行测试的重点是加快测试流程，而跨浏览器测试的重点是确保不同浏览器之间的兼容性和一致性。
在这两种情况下，都适合自动执行测试以加快流程并避免任务重复。
什么是手动测试中的探索性测试？
探索性测试是一种手动测试，其中测试人员主动调查被测软件，利用经验和知识来识别和测试潜在问题区域。 这种测试方法让测试人员能够发动创造力和好奇心来发现传统测试用例可能未涵盖的软件问题和测试区域。
探索性测试通常与其他类型的测试结合使用，提供更全面和彻底的软件测试，作为持续交付流程的一部分。 它特别适合测试不寻常或意外的输入以及找出软件中的隐藏或意外行为。
构建和发布有什么不同？
在软件开发环境中，构建是已编译并准备好进行测试或部署的软件版本。 而发布是正式分发给用户的软件版本。 两者都是持续集成和持续部署流程的一部分。
构建软件的流程涉及将源代码编译为可执行形式，以及执行其他活动，如运行测试、创建文档和打包软件以供分发。 这个流程的结果是软件的构建，通常可供测试人员或开发者进行进一步的测试和调试。
然后，使软件可供下载、通过应用商店或其他分发渠道分发，或将其安装至用户系统。 在这个阶段，软件版本被称为 "发布版"，而不是 "构建版"。
通常，构建软件的流程涉及创建构建，然后对其进行测试和调试。 在构建经过测试并被认为具有足够的质量后，就可以发布给用户了。 发布软件的流程通常涉及额外活动，例如创建版本说明、执行最终测试和质量保证，以及将发布传达给用户。
什么是构建发布管理？
构建发布管理，也称为构建和发布管理或构建管理，是管理软件构建和发布的创建、测试和分发的流程。 流程所协调的活动涉及创建构建、测试构建并将其发布给用户。
构建发布管理是软件开发流程的重要组成部分，因为它有助于确保以受控和一致的方式创建和分发构建和发布。 它还有助于确保构建和发布具备出色的质量并且可供用户使用。
构建发布管理通常涉及许多阶段，包括：
- 编译和构建软件：涉及将源代码编译为可执行形式，以及执行其他活动，如运行测试、创建文档和打包软件以供分发。
- 测试构建：涉及验证构建是否具有足够的质量并且是否满足所需规范。 测试可能涉及手动测试、自动化测试，或者两者都涉及。
- 管理依赖项：涉及确保所有必要依赖项都在构建中并正确配置。
- 管理版本：涉及跟踪已发布的软件版本，以及维护更改和 bug 修正的历史记录。
- 分发发布：涉及通过应用商店、网站或其他分发渠道向用户提供发布。
持续交付的支柱是什么？
持续交付是一种软件开发方式，在这种方法中，代码更改会自动构建、测试并部署到生产中。 它旨在实现快速可靠的软件交付，并基于一组定义流程工作方式的核心原则或支柱。
持续交付的支柱是：
- 版本控制：所有代码和相关工件都存储在版本控制系统（例如 Git）中，以实现可追溯性和协作。
- 构建自动化：代码更改会自动编译、打包并构建到可部署工件中。
- 测试：代码更改会自动接受测试，以确保符合质量和性能标准。
- 部署自动化：使用 Ansible、Chef、Puppet 或 Docker 等工具将代码更改自动部署到生产或其他环境。
- 配置管理：运行软件所需的基础架构和依赖项由 Ansible、Chef、Puppet 或 Docker 等工具管理和配置。
- 监控：软件在生产中被持续监控以检测和诊断问题。 通过遵循这些支柱，组织可以在软件交付流程中实现高水平的自动化和可靠性，从而更快地以更少错误向用户交付软件更新和新功能。
什么是代码冻结？
代码冻结，也称为功能冻结或硬冻结，是指不允许将新的代码更改引入软件项目的一段时间。 代码冻结的目的是稳定代码库，为主要版本或其他里程碑做准备。
代码冻结期间，通常不允许开发者提交新的代码更改或对代码库进行其他修改。 这使项目团队可以专注于测试和调试现有代码，并确保软件稳定以及可供发布。
代码冻结通常在开发流程的关键点实现，例如准备生产发布或准备演示时。 它们可能会在特定时间段内实现，也可能在达到特定里程碑之前一直有效。
持续部署可以使小型增量更改自动持续部署到生产中，减少对代码冻结的需求。 但是，如果在主要版本之前需要更全面的测试和稳定期，仍可能使用代码冻结。
什么是金丝雀分析？
金丝雀分析通常与持续部署结合使用，确保在推送到生产之前以受控方式测试更改。 “金丝雀分析”一词源于在煤矿中使用金丝雀来检测危险气体水平的做法。 正如金丝雀用于提醒矿工注意潜在危险，金丝雀分析用于提醒系统管理员注意系统或服务行为的潜在问题或更改。
金丝雀分析为系统或服务建立正常行为的基线，与后续测量进行比较。 如果系统或服务表现出明显偏离基线的行为，这可能表明系统中存在需要调查的问题或更改。
CI 中最重要的操作参数是什么？
持续集成 (CI) 中有许多重要的操作参数，因为它是涉及多个步骤和组件的复杂流程。 CI 中最重要的操作参数可能包括：
- 代码质量：确保提交到仓库的代码具有高质量并符合要求的标准，这对于 CI 的成功至关重要。 这可能涉及实现代码审查流程、自动执行代码质量检查，以及设置自动化测试。
- 构建速度：确保构建及时完成对于维护工作流程和最大限度减少延迟非常重要。 这可能涉及优化构建流程、使用更快的构建服务器或实现并行构建。
- 集成和测试：确保代码更改得到正确集成和测试是 CI 成功的关键。 这可能涉及设置自动化集成和测试流程，以及实现持续交付和部署等技术。
- 沟通和协作：确保团队成员能够有效沟通和协作对于 CI 的成功非常重要。 这可能涉及使用聊天平台或问题跟踪系统等工具促进沟通和协作。
什么是 YAML？
YAML (Yet Another Markup Language) 是一种易于读写的数据序列化格式。 它通常用于配置文件的配置管理，但也可用于以结构化格式（如列表或字典）存储数据。
YAML 基于以树状结构表示数据的概念，树中的每个元素表示为一个节点。 节点可以包含其他节点，也可以包含标量值形式的数据（例如字符串或数字）。
YAML 使用率很高，因为它易于读写，并且比 XML 或 JSON 等数据序列化格式更简洁。 它也得到广泛支持，许多编程语言都提供用于解析和生成 YAML 的库。
YAML 在 CI/CD 中是如何使用的？
在 CI/CD 中，YAML 用作为应用程序或服务定义构建、测试和部署流程的配置文件格式。 它允许开发者指定构建和部署其应用程序所需的步骤，以及运行管道所需的依赖项、环境变量和其他参数。
在 CI/CD 中使用 YAML 的方式包括：
- 定义管道结构：YAML 用于定义管道的结构，包括阶段、作业和步骤。 这允许开发者创建运行适当步骤和测试的管道，确保正确构建、测试和部署应用程序。
- 指定构建和部署指令：YAML 用于为管道中的每个阶段和作业指定构建和部署指令。 这包括编译代码、运行测试和将应用程序部署到特定环境的命令。
- 配置环境变量和依赖项：YAML 用于配置管道所需的环境变量和依赖项。 这包括数据库连接详细信息、API 密钥和外部库等信息。
- 启用代码审查和审批：YAML 可用于定义代码审查和审批工作流，允许开发者确保代码更改在合并到主分支之前得到审查和批准。
Kotlin DSL 是 YAML 的替代方案，允许团队以更高级的方式将项目配置为代码，并大规模运行 CI/CD 项目。
我可以使用多少构建代理？
您可以使用的构建代理的数量取决于多种因素，包括构建服务器上可用的资源、构建流程的需求，以及待运行的并行构建的数量。
通常，推荐做法是以足够的构建代理确保构建及时完成，同时确保具有足够的可用资源来支持构建流程和发布编排。 这可能涉及结合使用本地构建代理和基于云的构建代理，具体取决于您的需求。
部分持续集成 (CI) 工具，例如 TeamCity，允许您向构建池添加更多代理或使用基于云的代理池，根据需要增加构建代理的数量。 这很适合处理峰值工作负载或运行并行构建。
什么是 CI 审核？
CI（持续集成）审核是对软件开发团队将代码更改集成到主代码库的流程的审查。 CI 审核的目的是评估团队的 CI 流程和 CI/CD 管道的有效性和效率，并确定需要改进的领域。
CI 审核将详细检查团队的 CI 流程，包括使用的工具和技术、代码集成的频率，以及测试和部署代码更改的方法。 审核还可能会查看团队如何处理冲突与合并冲突，以及如何跟踪和解决 CI 流程中出现的问题。
CI 审核的目标是确保团队的 CI 流程能够定期高效、可靠、有效地交付优质软件。 这有助于团队在开发流程早期发现和解决问题，从而节省时间和资源并提高软件的整体质量。