质量保证的新方法：TestOps 概念、原则、方法

TestOps初探

当您的应用程序增长时，您的自动化项目也会增长，添加工具、集成、测试和团队成员。作为一个QA领导者，你想快速的提高质量，但同时也面临着越来越复杂的问题。

TestOps 是有效管理测试过程、工具和人员以最大化交付速度和应用程序质量的规程。

TestOps 有助于QA Leader 确保控制、组织和管理增长，并提供见解以做出更好的决策和推动流程改进。

什么是TestOps

TestOps的目的是促进测试人员和开发人员、运营人员、IT项目管理人员之间密切互动的方法论。

在谈论TestOps是什么的时候，我们可以看到在TestOps的文化和模型中，它扩展了测试自动化工程师的角色，新的职责是建立和维护自动化测试环境。

这个定义意味着要执行自动化测试，工程师在Docker中打包测试，启动要测试的软件，运行测试，收集结果，并提供报告；

通过强制性负载和可靠性测试扩展软件测试类型，扩大测试人员的工作范围，包括在测试环境和生产中监控所有系统的责任；

一种只为节省资源（空间）和通常用于创建测试数据的时间而在生产中促进测试的方法。这允许更多的时间用于分析监控指标，以及做出影响小测试组而不是一次影响所有用户的更改。

后一种方法虽然听起来很奇怪，但在我所知道的几个项目中，它已经成功地作为开发过程的一部分被采用了。

在考虑了以上所有因素之后，我们来看看业界对TestOps定义：

TestOps是一种促进QA、Dev和Ops之间密切协作的方法，以降低开发成本并确保质量。它考虑到软件开发和支持的当前趋势，并概述了以下主要活动：

• 测试数据的准备；
• 功能E2E测试，包括：集成测试；事务测试；自动化；
• 微服务和整个系统的负载测试；
• 可靠性测试，包括：服务故障时；异步工作场景。
• 安全；
• CI/CD设置

此外，我们想详细说明上述优先测试领域。

测试数据（Test Data）

为测试准备测试数据一直是QA专家的一项关键任务。指示特定数据是允许创建常规测试用例的。随着微服务解决方案的日益普及和多种软件的全球集成，收集有效数据变得越来越具有挑战性。为确保结果可靠，所有系统的测试数据必须一致。因此，测试的第一阶段是为所有系统准备通用的数据集和相应的机制来更新或恢复它们的原始状态。

例子：

假设您的团队在一个大型项目中工作，该项目由多个服务组成，每个服务都有自己的数据库和一些第三方集成。如果第一个服务的对象引用第二个服务和第三方系统的对象id，那么必须创建这些特定对象。此外，数据准备不仅限于创建数据。如果在测试期间要创建的数据被认为是唯一的，那么您必须确保这些数据已经从可能存在的所有服务中删除。

功能测试 （Functional Test）

根据我们的统计，80%的测试都是功能性的。我们认为，这个数字是准确的，在最近的将来不大可能改变。然而，重点从测试单个系统/服务功能转移到测试整个系统。因此，测试应按传统方式进行：

• 组件测试-每个系统/服务单独测试。合同测试也可以包括在这里。
• 集成测试-多个服务的交互。在这个阶段，我们将需要一组预配置的一致数据。
• 系统测试—E2E测试，即验证整个系统是否按预期运行并处理预期错误。

在组件和集成级别，通过应用单元测试和web服务测试，测试自动化被证明是非常有效的。

在集成和系统级别，事务测试（Transactional testing）是必不可少的，因为有不同的方法来确保事务性。至少，测试人员应该了解这些方法，并确保在Positive和Negative场景中数据完整性的准确性和一致性。

在系统级，有必要测试系统使用的基本场景，可以手动测试，也可以使用自动UI测试。

例子：

虽然已经有很多关于Contract testing（契约测试）和 Web Service（WEB服务）的文章，但是事务测试需要更多的研究，因为它非常独特并且依赖于实现。

如果一个对象通过多个服务，改变了它的状态和属性，那么最好在一个系统发生故障或错误处理对象的场景中测试系统行为。

在这种情况下有可能完成处理吗？如果状态无效，是否可以更正状态？是否可以取消所有操作并将系统回滚到其初始状态？

契约测试是一种确保两个独立系统（如两个微服务）彼此兼容的方法。它捕获每个服务之间交换的交互，并将它们存储在一个契约中，然后可以使用该契约来验证双方是否遵守该契约。

我们来看看英文描述：

Contract testing is a methodology for ensuring that two separate systems (such as two microservices) are compatible with one other. 

It captures the interactions that are exchanged between each service, storing them in a contract, which can then be used to verify that both parties adhere to it.

负载和可靠性测试 （Load and Reliability Testing）

当系统的行为有可能发生变化时，其性能会在负载下发生变化。由于微服务倾向于用于可伸缩性，因此最好总是进行负载测试，而不管这些需求是否明确提出。单个微服务和整个系统（用于识别瓶颈）都可以成为负载测试的对象。最低目标是分析系统性能并向团队和客户提供信息。最大限度是根据规模预测系统能力，并防止与高负载相关的缺陷。

下一个讨论点是可靠性，它与系统的效率密切相关。我们的目标是检查：

• 系统能够处理负载下的错误；
• 出现错误时，微服务可以重新启动；
• 数据完整性得到保证；
• 正确执行异步操作。

后者是测试人员可能遇到的典型问题。异步操作（例如每小时运行一次的进程）在处理大量数据和繁重负载时可能没有足够的时间来完成。在这种情况下，测试人员应确保数据不会丢失或处理两次。

值得一提的是，对于分布式和微服务系统的可靠性测试，存在一种特殊的方法和一套工具混沌工程。

安全（Security）

现代软件开发方法意味着在短时间内编写和发布大量代码。在这种情况下，我们面临着与未知漏洞相关的新的安全挑战。传统的人工安全程序已经不能满足日益增长的需求，也不能提供所需的信息安全级别。

允许克服这些挑战的方法之一是在开发的早期阶段引入自动化的安全测试，而不是传统的发布后控制。最近的调查概述了将测试转移到更接近开发阶段的趋势，这只会有利于安全自动化。

来源

TestOps 的概念促进了在整个测试周期中自动化安全测试的思想。此外，还可以通过安全测试来保证管道的安全。例如，在CD期间扫描容器，并在CI处验证系统组件，以确保整个周期的系统安全性和稳定性。

CI/CD设置 （CI/CD Setup）

TestOp s的一个重要标志是能够独立地配置流程以确保产品质量，并理解现有流程以改进它们。

例子：

我们经常遇到这样一种情况：参与项目的 DevOps 专家不可用，因为他们支持测试和生产环境。为了加速操作，您可以手动设置自动测试的启动过程，甚至可以将它们添加到现有管道中。

TestOps Skills

TestOps 潜在角色所需的知识和技能：

• 数据库——SQL和NoSQL方面的专业知识；
• 基本了解现代数据交换方法和协议：REST、SOAP、JMS、WebSocket；
• 数据格式知识：XML，JSON，CSV；
• Unix/Linux系统技能；
• 操作系统中的脚本技巧：bash、PowerShell；
• 了解操作系统：软件如何工作，什么是服务等。；
• 编码技巧：Python，JS。最好使用脚本语言，因为按需编写脚本的能力往往比设计应用程序的能力更重要；
• 负载测试技能。仅仅了解JMeter、Locust、Gatling等工具是不够的。TestOps角色需要了解需要收集的度量的类型、如何收集它们以及在什么条件下收集它们；
• 自动化技能。值得注意的是，这个术语比只编写自动化测试有更广泛的含义：它包括任何团队的工作自动化；
• CI/CD配置技能（詹金斯，TeamCity）。

TestOps 的建议

遵循TestOps方法的主要方法之一是保持在不断发展的技术的前沿。为了跟上行业趋势，有必要定期：

• 更新你的知识；
• 阅读软件开发和测试的新方法。明天您可能需要测试今天才讨论的开发；
• 参加技术论坛和技术讨论会议。在那里你可以遇到一些想法，这些想法可以极大地丰富你的测试和相关学科的概念；
• 在会议和出版物上与同事分享您的知识。这似乎是最具挑战性的任务之一，因为我们往往低估了项目的重要性和潜在兴趣。然而，由于每个问题通常都有一系列的解决方案，基于您独特经验的解决方案可能是最适用的。

---

测试右移（Shift-Right Testing）

测试左移（ Shift-Left Testing）的概念在持续测试（Continuous Testing）实践中已经流行了一段时间。我们现在开始将测试右移（Shift-Right Testing）实践视为测试中的一个紧急趋势（an emergent trend in testing）。

测试右移意味着在应用程序生命周期的发布前和发布后阶段（即生产中的测试）要做更多的测试。这些实践包括：

• 发布验证（release validation）
• 破坏性/混沌测试（destructive/chaos testing）
• A/B和Canary测试 （A/B and Canary testing，金丝雀测试）
• 基于CX的测试（例如，将用户行为与测试需求关联）CX-based testing (e.g. correlating user behavior with test requirements)
• 群组测试 （crowd testing）
• 生产监控 （product monitoring）
• 从生产数据中提取测试细节等 （extraction of test insights from production data, etc）

Chaos Testing 是一种DevOps实践（Chaos testing is a DevOps practice）

混沌测试最初是由Netflix构想的，它是故意试图破坏生产中的应用程序的实践的一部分。混沌工程使测试人员能够扩展他们的技能，并在确定产品质量时增加价值申请。为什么做混沌测试？随着敏捷和DevOps实践在开发中占据主导地位，随着软件交付速度和频率的提高，这种类型的测试变得越来越具有挑战性。缺陷在生产中表现出来的可能性越来越高。

金丝雀测试（Canary Testing）是一种测试新特性和新功能的强大方法，在生产中对用户的影响最小。人们经常交替使用术语canary testing、canary release和canary deployment。

 

测试右移不仅引入了这种新的测试技术，而且要求测试人员掌握新的技能，积极利用生产数据来驱动测试策略，并与新的利益相关者（如站点可靠性工程师（SRE）和操作工程师）合作。

在测试的右移中，在与操作规程的增强协作中，我们看到了DevOps中一个新规程的演变，我们称之为TestOps。

接下来我们将讨论各种测试右移趋势和实践，是什么驱动了它们，新的技能和所需的协作，以便能够实现测试操作的好处。

是什么驱动了测试右移？

测试右移的目标是在应用程序的生产过程中确保正确的行为、性能和可用性。

采用测试右移趋势有几个驱动因素：

1. 客户体验（CX）是数字应用程序的关键质量指标

与经典测试不同，这需要考虑真实世界的用户及其体验。如果一个应用程序的传统质量分数（如FURPS）很好，但它不能让客户满意，那么它的CX仍然很差。顾客体验是使用各种度量标准来衡量的，如顾客努力度得分（CES）、净促销员得分（NPS）、顾客满意度得分（CSAT）等。虽然在某种程度上可以将这些度量中的一些向左移动，但大多数顾客体验度量是从生产（或接近生产）的系统中推导出来的。基于CX的测试示例包括：

基于真实用户旅程、行为和反馈的需求验证。

基于以上推导功能和性能测试场景。

A/B测试和金丝雀测试，测试客户喜欢（或不喜欢）变化的程度。

人群测试，更好地了解真实世界的用户体验。

在一个敏捷交付的世界中，在发布到生产之前，可能不可能测试所有的东西

上市时间（或变更的提前期）是数字应用程序的首要业务需求，这就是为什么QA/测试被认为是持续交付的主要瓶颈。虽然可以使用左移实践（例如基于模型的测试、变更影响测试、测试过程和执行自动化等）来优化测试工作和周期时间，但是在不断缩短的发布周期时间内，这些方法仍然可能花费太长的时间（或太多的工作）。在某些情况下，确切的使用模式甚至可能在发布之前还不能完全理解。这个想法是从生产中学习使用模式，并在shift left中使用它来实现更好的测试策略。

使用微服务（使用数千个组件）和云本地技术的复杂且日益分布式的系统允许在非常精细的级别上进行发布，这使得在预生产环境中进行全面测试变得越来越困难。这一点得到了这样一个事实的补充，即由于此类发布是如此细粒度，因此在导致问题的情况下，可以很容易地将其退出（回滚）。

因此，企业测试以确保“足够好”的质量（以确保及时发布），并依靠快速补救（或回滚）来解决出现的缺陷或问题。

此外，CX测量（如上所述）通常以灰色阴影提供真实的用户反馈，这与经典测试的黑白通过/失败测量不同。这意味着不可能完善预生产测试套件以确保全面的CX覆盖。

百分之百的可靠性（或质量）往往是不切实际的目标

与上述内容相关，我们从SRE的DevOps规程中学到的一个关键原则是，100%的可靠性不仅不现实，而且往往成本过高。SRE建立了服务级别目标（slo）和错误预算的概念，以量化生产系统中可接受的风险容限。同样的原则也适用于测试和整体质量。有关这个问题的更多信息，请参阅我的相关博客

有些验证很难在测试环境中运行

其中包括当测试环境相对于生产环境的大小（或配置）不合适时的大规模性能测试。

另一个例子是破坏性或混沌测试。虽然可以在测试环境中使用服务虚拟化（模拟依赖组件中的故障）等技术来运行孤立的混沌测试，但对于大规模破坏性测试来说很难执行。例如，Netflix在生产中进行了大量的测试。

类似地，只有在生产环境中才能通过企业监控来收集有关实际使用模式和故障的信息。虽然我们提倡在测试环境中启用监视（作为左移的一部分），但这种监视只帮助进行本地化监视（例如，对正在测试的特定应用程序或系统），在测试条件下也是如此。但是，测试人员开发的性能测试场景可以在生产中重新使用（右移）作为综合监控器来度量应用程序性能和回归。

最后，作为监控的扩展，如果没有生产数据的访问，测试一些基于人工智能的应用程序可能会很困难。例如，一些机器学习算法需要根据真实世界的数据不断改进。虽然这些算法是使用有限的一组训练和测试数据开发的，但它们需要根据其在生产中的性能进行监控和调整。

开发人员和测试人员需要来自生产的更简单的闭环反馈

来自操作的更简单的闭环反馈允许开发人员和测试人员更好地理解应用程序的行为，预测成功

测试操作规程的演变

从上面讨论的客户调查数据和驱动因素可以清楚地看出，右转实践正在发生变化。

就像我们对左移测试所做的那样，为了使这些实践具有可持续性并实现其好处，我们还需要将测试人员用例、技能、工具和协作模式与应用程序生命周期（即操作）右侧的人员和规程一起演进。换句话说，需要建立一个新的规程，我们称这个新规程为TestOps，在更广泛的DevOps上下文中是一个子规程。

尽管术语TestOps（像DevOps中的所有X-Ops子规程一样）暗示了测试和操作之间的协作，但它不仅仅是关于右移。为什么？因为在DevOps中，操作规程本身已经左移（比如监控、配置管理、SRE等的左移）。因此，符合连续测试原则的测试操作指的是在整个DevOps生命周期中与操作规程更好地协作。

早期可靠性测试：这包括系统架构的静态可伸缩性分析，以及性能和压力测试。

配置质量和测试：这包括测试“作为代码”（任何“作为代码”的东西都可以也应该这样测试，就像应用程序代码一样）环境和部署配置，以及部署测试（以测试部署的正确性）和回滚测试（以确保回滚可以快速而成功地完成）。

早期监控：包括在生命周期的早期（例如在开发和测试环境中）对系统进行监控，以及在将合成监控器部署到生产环境之前对其进行开发和测试。

早期AIOps洞察：这包括早期使用AIOps技术（在开发/测试环境中）来收集测试和质量洞察，例如用于缺陷和发布风险预测。

下面是一些关键的测试操作右移实践（参见下图）

• 混沌工程：这包括通过注入受控失效场景来测试系统的可靠性。
• A/B测试：由两个（或更多）变异体的随机实验组成，以研究哪些变异体对使用者更有效。
• Canary Release：由用于降低在生产中引入新软件版本的风险的技术组成，方法是在将更改逐步推广到一小部分用户之前，将其推广到整个平台/基础设施，并向所有人提供。
• 综合监控：包括使用模拟或脚本记录事务（反映典型用户行为）的监控技术。
• CX测试和分析：包括提取CX数据以了解客户体验并从中获得见解（如客户问题、新功能需求等）。
• 生产中的其他测试：包括性能测试和基于AI的应用程序测试。
• 从AIOps数据中测试洞察力：如上所述，可以从操作数据中收集各种各样的测试洞察力。

TestOps的关键技能和工具

让我们考虑一下TestOps关键实践所需的新技能。这包括以下内容：

• 数据分析技能：由于大多数生产数据都是大量的、多样的，而且通常是暂时的，测试人员现在必须进行数据分析，以便他们能够快速地从这些数据中收集见解，并执行与其他数据集的关联以确定操作。高级分析技能（如预测分析或机器学习）也是预测事件（如发布质量）所必需的。虽然这些分析技能在运营社区中得到了很好的理解（随着AIOps的日益采用），但对于开发人员和测试人员来说，这些技能相对较新。
• CX技能：正如我们所讨论的，CX现在被认为是衡量生产质量的关键指标。新类型的CX测试包括A/B和Canary测试（金丝雀测试）以及众包测试（Crowd testing）。与其他操作数据一样，CX数据通常也是海量的，而且通常是非结构化的。虽然CX团队专门研究这些原则，但测试人员需要获得足够的技能，以便从CX流程和数据中获得洞察力，并与这些团队进行有效的协作。
• 监控和操作技能：了解监控原则（如创建、测试和部署监控器以及使用监控器数据）是测试操作所需的关键技能。同样，测试人员还必须了解操作原则（事件、故障、警报、MTBF、MMTR、配置定义等），以便这些信息可以用于测试目的以及与Ops团队的协作。
• 可靠性技能：可靠性也是测试人员需要熟悉的另一个关键操作质量属性。这包括混沌/弹性测试、部署和回滚测试以及配置测试。在DevOps中，SRE的规程已经发展到解决可靠性问题，它的许多原则与TestOps重叠。
• 新工具技能：除了使用传统测试工具外，TestOps还需要使用其他工具，如监视、数据分析（用于生产和CX数据）、CX测试（如A/B和Canary测试）和可靠性测试。支持具有这些新功能的测试人员的技术创新包括RunScope（一种轻量级API监视工具，可用于在测试和生产环境中进行监视）、Blazemeter（用于CX和可靠性的性能测试）和a/B测试的优化。对于数据分析，技术自动化.ai简化数据聚合和建模的工作，以便测试人员可以更容易地从整个生命周期收集的数据中提取可操作的见解。

TestOps 的关键协作

除了新的技能，测试人员现在必须学会更好地与上面提到的其他涉众协作。其中包括：

• 与数据科学和AI/ML工程师合作：这对于测试人员调整或构建执行测试操作所需的分析所需的新算法和模型是必要的。
• 与CX工程师和团队协作：这对于测试人员监视适当的CX度量和数据以及研究他们的测试/QA活动对CX的影响是必要的。
• 与运营工程师和团队协作：这对于测试操作来说是非常重要的，不仅可以支持所有正确的测试活动，还可以访问测试操作分析所需的生产数据。这类似于测试人员如何作为测试左移的一部分与开发人员协作。
• 与SREs的协作：如前所述，SRE和TestOps原则之间有相当程度的重叠，因此与SREs的协作对于测试人员来说是关键。

TestOps 的特性

传统的测试方法是在整个产品建成后才出现的。否则，TestOps的工作重点是提供产品团队需要测试的内容。

与DevOps集成

TestOps提供了一个透明的工作流。构建系统作为一个中央应用程序工作。测试人员和开发人员访问构建系统中的代码。他们检查所有API并确保它们正常运行。在这里，完成的构建被标记为成功。

TestOps中的侦听器应用程序在开始时会记录每个构建，在结束时，API会将构建状态指示为“success”。

什么时候运行什么测试

为了产品的顺利运行，团队需要清楚地知道应该测试什么和什么时候测试。在每次提交之后，应该测试代码并删除bug。这必须在没有任何人为干预的情况下进行。TestOps确保QA团队已经检查了所有的测试API，并且产品正在运行。

不需要站起来测试整个系统

模块和微服务分开测试，排除了整个测试平台的重复性。单独的测试确保在原始阶段检测并删除错误。除了更快的产品交付之外，还应该保持API的一致性。测试一个服务意味着，从原始服务发送一条消息，消息代理将接收该消息。

只要接收消息的服务维护相应的API，次要和下游服务就不需要在此时进行测试。例如，当一个团队的服务依赖于一个消息代理、向另一个服务发送消息以及它依赖于多个服务时，服务之间的连续性就进入了主题。

使团队还能够与上游和下游消费者一起测试其更改

一些测试特性很难独立工作，因为它依赖于许多外部服务，或者有助于其他产品/特性。可能存在这样一种可能性，即消费者通常不在同一位置或代码库中。为了确保一致性并根除对下游用户的任何更改，而无需手动干预，TestOps应该支持在构建后提供其他模块。

代码的一致性将在生成后进行维护。TestOps提供了所有可以使用的模块，并将它们提供给下游用户，而无需人工干预。这些模块应该放置在与其他待测试配置相同的位置。

（未完）