adc不连续转化测试程序_您做连续测试的5个错误标志

最新推荐文章于 2024-04-29 07:40:32 发布

cumo7370

最新推荐文章于 2024-04-29 07:40:32 发布

阅读量276

点赞数

文章标签：数据库大数据 java 编程语言面试

原文链接：https://opensource.com/article/18/11/continuous-testing-wrong

版权

adc不连续转化测试程序

在过去的几年中，许多公司已经进行了大量投资，以自动化在生产中部署功能部件的每个步骤。测试自动化被公认为是关键推动因素：

“我们发现测试自动化是持续交付的最大贡献者。” – 2017年DevOps状况报告

尽管付出了您的承诺和资源支出，但结果可能还是自动化测试套件，维护成本高且执行时间长。更糟糕的是，您的团队不信任它。

这是五个常见的测试自动化错误，以及如何使用（在某些情况下）开放源代码工具缓解这些错误。

1.孤立的自动化团队

在拥有数百甚至数千名工程师的大中型IT项目中，无法维护和昂贵的自动化测试的最常见原因是使测试团队与提供功能的开发团队分开。

在遵循敏捷实践的组织中也会发生这种情况，在这种实践中，分析师，开发人员和测试人员共同研究功能接受标准和测试案例。在这些敏捷组织中，自动化测试通常由Scrum团队之外的工程师部分或完全管理。如果您想随着时间的推移发展自动化测试套件，那么低效的沟通很快就会成为瓶颈，尤其是在团队分布于地理位置的情况下。

此外，在没有开发人员参与的情况下编写自动验收测试时，它们往往与UI紧密耦合，因此易碎且分解不佳，因为大多数测试人员对UI的底层设计不了解，并且缺乏创建抽象层的技能或针对公共API运行验收测试。

一个简单的建议是拆分您的孤立的自动化团队，并直接将测试工程师包括在进行功能讨论和实施的Scrum团队中，并且可以立即发现并修复对测试脚本的影响。这当然是一个好主意，但这不是真正的意义。更好的是让整个Scrum团队负责自动化测试。然后，产品所有者，开发人员和测试人员必须共同努力，以完善功能接受标准，创建测试用例并为自动化确定优先级。

当开发团队内部或外部的不同参与者参与运行自动化测试套件时，提高整体协作过程水平的一种实践是BDD或行为驱动的开发。它有助于创建整个团队可以理解的业务需求，并有助于为自动化测试提供唯一的真实来源。诸如Cucumber ， JBehave和Gauge之类的开源工具可以帮助您实现BDD并保持测试用例规范和测试脚本自动同步。这些工具使您可以创建一个具体示例，以通过使用一个包含“ Given-When-Then”场景的简单文本文件来说明业务规则和接受标准。它们用作可执行软件规范，以自动验证软件的行为是否符合预期。

2.您的大多数自动化套件都是通过用户界面测试完成的

您应该已经知道，用户界面自动化测试非常脆弱，即使进行很小的更改也会立即破坏所有引用特定已更改GUI元素的测试。这是技术/业务涉众认为自动化测试维护成本高的主要原因之一。用于生成GUI自动测试的记录和回放工具（例如SeleniumRecorder ）与GUI紧密耦合，因此很脆弱。这些工具可以用于创建自动测试的第一阶段，但是需要第二个优化阶段才能提供抽象层，以减少接受测试和被测系统的GUI之间的耦合。诸如PageObject之类的设计模式可用于此目的。

但是，如果您的自动化测试策略仅专注于用户界面，则它将很快成为瓶颈，因为它占用大量资源，执行时间长且通常难以修复。实际上，解决UI测试失败可能需要您遍历所有系统级别以找出根本原因。

更好的方法是在适当级别上优先开发自动化测试，以平衡维护测试的成本，同时尝试在软件部署管道的早期阶段发现错误（连续交付中引入的关键模式）。

正如上面所示的敏捷测试金字塔所建议的那样，绝大多数自动化测试应包括单元测试（后端和前端级别）。单元测试的最重要属性是它们应该非常快地执行（例如5到10分钟）。

服务层（或组件测试）允许在API或服务级别上测试业务逻辑，而用户界面（UI）不会妨碍您。级别越高，测试变得越慢且越脆。

通常，在每次开发人员提交时都运行单元测试，并且在测试失败或测试覆盖率低于预定义阈值的情况下（例如，当单元测试覆盖不到80％的代码行时）停止构建过程。。构建通过后，将其部署在阶段环境中，并执行验收测试。然后，任何通过验收测试的内部版本通常都可用于手动和集成测试。

单元测试是任何自动化测试策略的重要组成部分，但是它们通常无法为应用程序的发布提供足够高的信心。在服务和UI级别上的验收测试的目的是证明您的应用程序能够满足客户的要求，而不是按照程序员认为的方式工作。单元测试有时可以共享这一重点，但并非总是如此。

为了确保应用程序在平衡测试套件成本和价值的同时为最终用户提供价值，您必须考虑敏捷测试金字塔，从而自动执行服务/组件和UI接受测试。

在ThoughtWorks的这篇综合文章中，了解有关测试类型，级别和工具的更多信息。

3.外部系统在您的部署管道中集成得太早了

与外部系统的集成是常见的问题根源，并且可能很难解决。这意味着必须仔细有效地测试这些集成点。问题是，如果将外部系统本身包括在自动验收测试的范围内，则对系统的控制较少。设置外部系统的启动状态很困难，而这又将导致无法预测的测试运行，该测试在大多数情况下会失败。您剩下的时间可能会花在与外部提供商讨论如何解决测试失败上。但是，我们进行连续测试的目的是尽早发现问题，并且要实现这一目标，我们旨在不断集成我们的系统。显然，这里存在压力，不存在“一刀切”的答案。

在每个集成点周围有一组旨在在与外部系统真正连接的环境中运行的测试套件非常有价值，但是这些测试应该很小，关注业务风险并涵盖核心客户旅程。相反，请考虑创建代表与所有外部系统的连接的测试双打，并在开发和/或早期环境中使用它们，以使您的测试套件更快并且测试结果具有确定性。如果您不熟悉双重测试概念，但听说过模拟和存根，则可以在Martin Fowler博客文章中了解它们的区别。

Jez Humble和David Farley在他们的《持续交付：通过构建，测试和部署自动化实现可靠的软件发行》一书中建议：“在以下情况下，几乎必须总是使用测试倍数来测试外部系统的一部分：

外部系统正在开发中，但接口已提前定义（在这种情况下，请为接口的更改做好准备）。
外部系统已经开发，但是您没有该系统的测试实例可用于测试，或者测试系统太慢或有故障，无法充当常规自动测试运行的服务。
存在测试系统，但是响应不是确定性的，因此无法通过自动化测试（例如，股票市场供稿）来验证测试结果。
外部系统采用难以安装或需要通过UI手动干预的另一个应用程序的形式。
自动连续集成系统所施加的负载以及所需的服务水平，使轻量级的测试环境不堪重负，该环境被设置为仅应付一些手动的探索性交互。”

假设您需要集成一个或多个正在积极开发中的外部系统。反过来，架构，合同等也可能会发生变化。这种情况需要仔细定期进行测试，以识别不同团队的分歧点。基于微服务的架构就是这种情况，该架构涉及部署多个独立系统以测试单个功能。在这种情况下，请检查总体自动化测试策略，以支持一种更具可扩展性和可维护性的方法，例如用于消费者驱动合同的方法。

如果您不在这种情况下，我发现以下开放源代码工具可用于从API合同规范开始实施双重测试：

SoapUI模拟服务：尽管名称如此，但它可以模拟SOAP和rest服务。
WireMock ：它只能模拟休息服务。
对于其余服务，请查看用于“模拟服务器”的OpenAPI工具，这些工具能够从OpenAPI合同规范开始生成测试存根。

4.测试和开发工具不匹配

将测试自动化工作转移给除开发团队以外的其他团队的后果之一是，这在开发工具和测试工具之间造成了分歧。这使开发人员和测试工程师之间的协作和沟通更加困难，增加了测试自动化的总体成本，并助长了不良做法，例如使测试脚本和功能代码的版本不一致或根本没有版本化。

我已经看到很多团队都在为昂贵的UI / API自动化测试工具而苦苦挣扎，这些工具与标准版本系统（如Git）的集成度很差。其他工具，尤其是具有可视工作流程功能的基于GUI的商业工具，通常会在测试经理之间产生错误的期望，即您很容易期望测试人员开发可维护且可重用的自动化测试。即使有可能，他们也无法随着时间扩展您的自动化测试套件。测试必须与功能代码一样多，这需要开发人员级别的编程技能和最佳实践。

有几种开源工具可帮助您编写自动验收测试并重用开发团队的技能。如果您的主要开发语言是Java或JavaScript，则可能会发现以下有用的选项：

Java
- Cucumber-jvm，用于在Java中为UI和API自动化测试实现可执行规范
- REST确保进行API测试
- 用于网络测试的SeleniumHQ
- Selenium WebDriver的ngWebDriver定位器。它针对使用Angular.js 1.x或Angular 2+构建的Web应用程序进行了优化。
- 使用Selenium WebDriver进行移动测试的Appium Java
JavaScript
- Cucumber.js与Cucumber.jvm相同，但在Node.js平台上运行
- Chakram用于API测试
- 用于针对用AngularJS 1.x或Angular 2+构建的Web应用程序进行了优化的Web测试量角器
- 用于在Node.js平台上进行移动测试的Appium

5.您的测试数据管理不是完全自动化的

要构建可维护的测试套件，必须具有有效的策略来创建和维护测试数据。它既需要自动迁移数据模式，又需要测试数据初始化。

使用大型数据库转储进行自动化测试很诱人，但这使它们难以版本化和自动化，并且会增加测试执行的总时间。更好的方法是捕获DDL和DML脚本中的所有数据更改，这些更改可以由数据管理系统轻松地版本化和执行。这些脚本应首先创建数据库的结构，然后使用启动应用程序所需的任何参考数据填充表。此外，您需要逐步设计脚本，以便可以迁移数据库而不必每次都从头开始创建数据库，最重要的是，也不会丢失任何有价值的数据。

诸如Flyway之类的开源工具可以帮助您基于数据库中包含其当前版本号的表来协调DDL和DML脚本的执行。在部署时，Flyway会检查当前部署的数据库版本以及正在部署的应用程序版本所需的数据库版本。然后，它确定要运行哪些脚本以将数据库从当前版本迁移到所需版本，并按顺序在数据库上运行它们。

自动化验收测试套件的一个重要特征（使其随时间推移具有可扩展性）是测试数据的隔离级别：测试数据仅对该测试可见。换句话说，一个测试不应依赖于其他测试的结果来确定其状态，其他测试也不应以任何方式影响其成功或失败。相互隔离测试可以使它们能够并行运行以优化测试套件的性能，并且由于您不必按任何特定顺序运行测试，因此更易于维护。

在考虑如何设置验收测试的应用程序状态时，Jez Humble和David Farley 在他们的书中指出，区分三种数据是有帮助的：

测试参考数据：这是与测试相关的数据，但与被测行为无关。此类数据通常由测试脚本读取，并且不受测试操作的影响。可以通过使用预先填充的种子数据进行管理，该种子数据可以在各种测试中重复使用，以建立测试运行的一般环境。
特定于测试的数据：这是驱动测试行为的数据。它还包括在测试执行期间创建和/或更新的交易数据。它应该是唯一的，并使用测试隔离策略来确保测试在不受其他测试影响的良好定义的环境中启动。测试隔离实践的示例包括在测试执行结束时删除特定于测试的数据和事务性数据，或使用功能分区策略。
应用程序参考数据：该数据与测试无关，但应用程序需要启动它。

应用程序参考数据和测试参考数据可以以数据库脚本的形式保存，并作为应用程序初始设置的一部分进行版本控制和迁移。对于特定于测试的数据，应使用应用程序API，以便由于执行业务逻辑而使系统始终处于一致状态（否则，如果您使用脚本将测试数据直接加载到数据库中，则会绕过该状态）。