DevOps 最佳实践: 第 6 部分. 使用 DevOps 执行质量保证和测试
-
简介
如果您想要开发并提供满足和超出客户期望的可靠系统，那么质量保证和测试不可或缺。恰当地测试软件是许多公司在努力完成的事情。事实上，许多时候，测试团队无法理解隐含在所有全面的软件测试工作中的技术复杂性。甚至敏捷团队（他们常常将测试资源融入在 SCRUM 中）可能很难实现全面而又有效的测试。一些先进的技术（包括 API 测试和服务虚拟化测试）促进了质量保证和测试的进步，但它们需要大量专业技术经验。组织真正需要的是一种全面的质量保证和测试方法，包括使用最新方法的技术能力。DevOps 原则和实践可通过改善所有必要涉众之间的通信和协作，帮助推进质量保证和测试的执行。本文将介绍如何使用 DevOps 最佳实践将公司转变为一个以质量为中心的成功组织。
建立一种质量文化
质量需要的不仅是行为的转变，还需要组织文化的巨大转变。许多公司最初通过满足市场需求和快速扩张来获得成功，但是，随着市场力量对公司盈利能力施加压力，他们发现自己无法成长和调整。成功的公司学会了通过响应竞争压力和它必须在其中运作的全球生态体系来成长和调整。最重要常常也是最具挑战的因素是，不断确保质量，同时发展和改进它们提供的服务。如果组织希望改进自己的文化，那么 DevOps 原则和实践是其成功的基础。质量管理专家 W. Edwards Deming 多年前就曾指出，必须从一开始就建立高质量。建立一种质量文化，还需要理解开发的系统所在的生态体系。
理解质量生态体系
大多数大型系统都内置在一个复杂的生态体系中，这个体系包含来自竞争对手的市场压力和外部力量（包括联邦法规需求）。许多公司仓促地满足这些需求，同时试图保持利润。开发人员通常匆忙地使用充满挑战和风险的最新技术来提供新特性。对新特性的这些需求，需要最好使用敏捷方法来完成的快速应用程序开发。不幸的是，许多敏捷团队难以提供充足的质量保证和测试资源来满足这些需求。理想情况下，SCRUM 在团队中融入了专门的测试资源，但许多大型组织已建立了组织级结构，这些结构要求质量保证和测试资源与开发资源分开。在许多行业，这种分离是联邦法规所要求执行的。开发人员与质量保证测试职能部门之间的关系通常有些欠佳。
功能失调的质量保证
开发人员专注于提供新特性，而质量保证和测试团队负责确保代码没有缺陷。此模式类似于开发与运营之间的关系，其中运营部门负责确保系统始终可用。
在开发人员完成代码（常常比预期更晚），而代码交付的延误让质量保证和测试流程偏离计划时，开发与测试团队之间就会发生功能失调的关系。一个更大的问题是，质量保证和测试团队通常缺乏在比功能级别更高的任何级别上测试代码所需的技术知识，而且只能使用应用程序中提供的接口。通常，存在着一种不健康的动态，在这种动态中，组织拥有的测试团队负责 “捕获” 错误，但没有提供足够的工具和培训来完成此目标。在发生一个影响到客户的事故时，质量保证团队通常会被问责并要求解释 “为什么找不到这个缺陷。”一些开发人员提供了自动化的单元测试，尽管这是必要的，但往往还不够。单元测试
开发人员通常编写自动化的单元测试案例。有时他们甚至可能使用测试驱动的开发 (TDD) 实践，在创建要测试的代码之前，就创建好了测试代码。单元测试必不可少，但存在范围上的限制。仅基于单元测试的测试覆盖范围，很少能确保应用程序没有缺陷。另一种重要的方法是持续集成。
持续集成
持续集成 (CI) 是一种有效的方法，它将来自每个开发人员的变更集成、构建、打包和部署到一个开发测试环境中。大多数敏捷团队都很重视持续集成，在代码变更签入到版本控制系统中后，就会立即依靠它来识别代码编译和集成问题。与必须筛选从一组开发人员签入的许多变更相比，如果在签入来自某个开发人员的特定变更集后就立即发现了问题，则更容易识别和调试这些问题。因为 CI 服务器通常被配置为在提交来自开发人员的变更后进行构建、打包和部署，所以调试流程更简单，更容易快速完成。这类似于持续交付背后的基本原理。
持续交付
持续交付 (CD) 涉及到在变更可用时构建、打包和部署它们的自动化过程。在部署时，这些特性仅可供最终用户在一个特定时刻访问。持续交付需要成熟的自动化构建、打包和部署过程。这通常被称为一个部署管道。持续交付有助于确保部署流程是一个例行事件，进而使组织能够更频繁地交付特性，甚至每天交付一次或多次。CD 在改善质量上特别有效，因为它通常会得到更小的部署规模。风险减少了，而且在存在问题时，这些问题通常更容易解决。拥有成熟的持续集成和交付流程的组织更加敏捷，因为他们可以快速向客户交付新特性，在出现缺陷时高效地解决它们。
代码评审
代码评审是在软件开发流程中尽早查找和删除代码中的缺陷的最有效方法之一。文档、测试案例、甚至是用户案例的评审也存在类似的方法。
持续质量保证和测试
质量保证 (QA) 和测试是贯穿整个生命周期的工作，会在整个软件和系统生命周期中执行。持续集成和持续部署为测试提供了更新的代码库，更重要的是提供了更新的测试环境。实现有效的质量保证和测试流程，需要一个全面的框架，这个框架首先需要明确地理解需要测试的内容。
我们在测试什么？
测试人员需要了解业务本身和验证的系统的需求。从 DevOps 角度讲，测试人员应该与业务专家（包括产品所有者）合作，理解测试的系统需要如何运行才能为业务提供支持。第一步是创建功能测试。
功能测试
工业级功能测试工具有助于确保功能测试可重复，还有助于确保具有最大的测试覆盖范围。不幸的是，功能测试常常受到可通过用户界面访问的特性的限制。编写优秀的功能测试案例常常极富挑战。幸运的是，整个生命周期中都存在反馈循环。这些循环有助于识别可能阻止缺陷影响未来的生产发布的潜在测试案例。反馈循环是 DevOps 中的一种重要资源。
反馈循环
反馈循环范围丰富，从服务台对用户发现的错误的报告，到正式的事故和问题管理流程。发现问题时，总是有必要与质量保证和测试团队共享此信息，因为可能需要其他测试案例来确保缺陷未交付到未来的版本中。回溯也为提供反馈来改善测试流程提供了必要的机会，改善包括解决发生的任何问题。这些问题通常无法使用功能测试过程来测试，一种更偏向技术性的测试方法至关重要。
API 测试
许多应用程序如今都提供了一个 Restful API，可以用它来执行详细和全面的自动化测试。使用 API 的测试需要大量编程技能，许多质量保证和测试专业人员都没有掌握这些技能。即使是拥有技术技能的质量工程师，也有可能没有掌握足够深入的应用程序知识来有效地使用 Restful API 开发自动化测试。将熟练且经过训练的测试人员与了解代码的开发人员相结合的 DevOps 实践，是使用 Restful API 开发健全的自动化测试的有效方法。不过，消息协议仍可能难以发现。
发现消息协议
许多系统非常复杂，甚至熟练的软件开发人员也会觉得难以识别在生产环境中使用系统时可能找到的所有潜在的消息协议。如今已有工具和过程来监视消息协议。得到的信息可用于开发健全的测试案例，这些案例可包含无法轻松地从现有用户访问的特性或行为。此方法适用于测试人员在使用系统，而技术人员同时在利用代理来监视和捕获消息的情形，这些消息在实际中可以 XML、JSON 或其他某种表示形式显示。用户可以对消息进行复制和修改，以便提供更多测试案例来提供更大的测试覆盖范围。甚至可以使用在 API 级别上开发的健全的测试案例，许多组织也会受到测试环境可用性的约束。这时，服务虚拟化测试就可以发挥巨大作用。
服务虚拟化测试
测试环境常常很昂贵，而且可能具有有限的可用性。服务虚拟化测试有效地解决了这一问题。服务虚拟化测试通常涉及到使用一个 API 来录制一个测试案例，而这个代理同时在 API 级别监视消息。消息可回放，实际地模拟 测试资源。例如，您可能只有有限的时间来向 IBM 大型机测试新系统特性，而这个大型机每周仅在较短的时间内可用。记录所测试的应用程序与虚拟化的测试资源之间交换的消息，让虚拟化的测试环境可以在该大型机不可用时使用。详细的 API 和服务虚拟化测试需要大量专门技术。可以让经过训练的质量保证和测试人员与开发人员配合使用 DevOps 方法，这有助于组织紧密关注学习和知识管理。
为测试人员充实知识
与开发人员配合的测试人员拥有获取大量技术知识的绝佳机会。开发人员自身也可了解测试的艺术和原则。DevOps 对改善通信和协作非常关注，这有助于组织开发一种经常分享知识并将其视为重要战略资源的文化。
结束语
DevOps 提供了一组强大的原则和实践，它们可以帮助改善组织孤岛之间的通信和协作，质量保证和测试组织与开发组织之间通常存在这样的孤岛。尽管许多敏捷团队在 SCRUM 中配备了测试人员，但其他团队可能需要让这些团队之间的组织彼此分离。DevOps 最佳实践可帮助这些技术人员共享他们的知识、经验和专业技能，提供让客户满意的高质量系统，并确保成功和盈利。
