持续测试,第2部分:测试团队的策略和自动化目标

DevOps被描述为“类固醇敏捷”;DevOps也被描述为运维/IT敏捷。这两种描述我都喜欢。许多组织现在都希望开发、测试和运营团队迁移到DevOps。

DevOps是一个很大的主题,但是DevOps不是本文的重点。我们不会讨论,例如容器,Docker, Puppet,或基础设施代码.在本文中,我们将重点关注持续测试。我将专注于测试团队的职责:测试人员的实践和关注,使他们的工作成为团队的资产,而不是在这个激动人心的DevOps新世界中成为累赘。

这是关于持续测试的2部分系列文章的第2部分。第1部分主要关注基本原理、业务目标、文化变化,以及一些特定测试任务的概述。第2部分将深入研究测试团队的特定思想、实践和任务,这些需要更新或更改,才能在下一个产品开发阶段中取得成功。这集中于测试策略和自动化目标。

中,我们快速概述了持续测试过程第1部分

  1. 从自动烟雾测试开始。将它们移到CI构建过程工具中。
  2. 构建更大的回归套件。将它们移到CI构建过程工具中。
  3. 生长在水平的精彩词;在多个虚拟机上运行烟雾和/或回归。
  4. 简单有效地向组织汇报。
  5. 对于数据和完整的类似生产的环境,使用容器和/或虚拟化。
  6. 将自动化测试分发到不同环境中具有不同目标的不同套件中。在不同的环境中使用vm来提高自动化、覆盖率、速度、监控和对团队的反馈。

当我们深入讨论持续测试和测试自动化策略时,还有一个额外的想法需要记住:DevOps是关于在客户需要时向客户交付价值企业需要它在开发人员,测试人员和运维人员的时候得到到它。

这些话题是非常密切相关的。

  • 连续测试策略
  • 重新考虑你的自动化
  • 改变你对回归的理解
  • 采用精益和平均自动化回归套件

现在,让我们进行更详细的讨论。

连续测试策略

实现有效的连续测试策略的第一步是理解连续测试(CT)到底是什么。根据定义,连续测试是一种软件测试实践,通常包括早期测试、经常测试、到处测试和自动化测试的过程。它强调在持续集成和交付过程(CI/CD)的每一步评估质量。

持续测试不仅仅是持续测试——它比持续测试要聪明得多!一个非常常见的错误是在不同的环境中运行和重新运行相同的“完整回归套件”,并认为这就足够“进行持续测试”了。

相反,开发持续测试策略的关键部分是考虑在不同的环境中进行测试,包括需要在哪些环境中进行测试,以及为什么要在该环境中进行测试——需要考虑在不同的环境中进行什么测试以及为什么要进行测试。在敏捷/Scrum中,开发和测试团队通过这些环境“进展”。现在,在DevOps/持续测试中,您可能在许多或所有这些环境中同时运行您的自动化。例如:

  • 在构建环境中需要运行哪些测试?
  • 在测试环境中需要运行哪些测试?
  • 例如,有各种配置、语言、浏览器、移动设备等的虚拟机需要运行哪些自动化测试?
  • 在生产中运行什么?

我们还必须检查其他问题,比如,我们是否理解结果?它们是我们所期望的还是我们所期待的结果?最重要的是,它们是否满足了客户的需求、期望和项目要求?

很多时候,高级管理人员仅仅根据一个度量标准来判断“软件测试是否成功”:成本。然而,还有很多其他的相关的度量标准在分析一个成功的测试项目时要考虑到这一点!管理层不应再简单地看问题成本软件测试的价值软件测试带来的软件开发生命周期(SDLC)。188betios下载当衡量一个测试计划的成功时,这里有一些其他需要考虑的指标:

  • 测试覆盖的广度
  • 测试可重用性
  • 软件测试报告的数据值
  • 被测试软件的质量

要了解更多关于为什么这些特定指标是有益的,请查看我们在LogiGear博客上的文章,如何衡量测试的成功

考虑测试自动化

持续测试依赖于……持续测试!因此,一切都需要自动化——或者更好的是,一切都需要自动化可以需要自动化。这个概念是成功的连续测试的唯一关键。

什么需要自动化测试,测试不这样做,他们应该如何运行和环境,他们跑多快,测试将失败,”的可能性大小的测试和维修…所有这些因素应该影响以及如何事情会变得自动化。

很多人都在谈论DevOps中的自动化。但是,它们通常并不意味着自动化测试。他们可能指的是任务自动化行动小组的人。自动化构建环境、配置数据库、填充用户列表……这些都很常见任务对于许多IT/Ops团队来说,由于专注于Ops的新工具和“基础设施即代码”运动的涌现,现在可以被安排、自动化,并且运行得更快。

DevOps需要对您的自动化程序进行彻底的重新思考测试任务自动化。例如,缩小“完全回归”以在更多环境中运行得更快是很常见的。对于许多测试团队来说,缩减自动化套件是一个不寻常的目标,但它发现自己在CT实现中非常有用和必要。

改变你对回归的理解

正如我上面所说的,CT是重复运行完整回归套件的想法是一种常见的误解。CT确实涉及回归;然而,为了有效地实现CT和自动化的目标,我们需要从传统的回归理念中重新思考和重构我们的回归套件。

回归测试经常与“缺陷优先级,范围从优先级1 (P1)到优先级4 (P4),前者缺陷需要在24小时内修复,后者确实存在缺陷,但不需要修复以匹配“退出”标准。回归通常只运行P1或P2测试,其中较低优先级的测试不那么重要,不自动化,也不需要重新运行。但是,回归可能只是根据自动化工程师需要自动化他们所做的任何测试的时间来记录和自动化的用户故事验证测试,而不是专注于持久的、建立信任的、发现bug的回归套件。事实上,回归对不同的人意味着不同的东西。在持续测试中,“一切自动化”是一个常见的口头禅。持续交付和持续部署的速度不给“备份计划”留下空间。

回归测试,根据定义,“是重新运行功能和非功能测试,以确保以前开发和测试的软件在更改后仍然运行。”基本上,它可以应用于任何必须运行多次的测试。开发人员通常在沙盒中或针对解决方案的“试点”版本构建解决方案时进行测试、测试和重新测试;这确保了他们的代码按照预期工作,结果是按照需求所期望的,输出看起来合理,并且性能在为解决方案设置的任何性能限制内。

在CT中,我们需要更频繁地在更多的环境中进行测试,这是非常明显的。但是,我们正在进行的测试必须改变。了解每个环境的目的以及该环境所需的监视或信息是选择运行哪些测试的关键。在相同的系统上使用相同的数据针对相同的构建反复运行相同的测试,这对任何人都没有帮助。我们知道我们有一个冒烟测试套件——一个在开发或测试环境的CI过程中运行的构建验证套件。我们都有一个“完全回归”套件,我们通常在测试环境中运行它。这就是我们需要重新规划的地方。

采用精益和平均自动化回归套件

对于一些团队来说,他们自动的“完全回归”套件可能需要几天的时间来运行。许多“完全回归”套件变得臃肿而缓慢。这是不对的。回归的新描述,很大程度上借用了精益软件开发的原则188betios下载减少浪费现在的回归必须是“精益和平均的”,“快速和激烈的”——而不是臃肿的,而不是旧的“我们上次自动化的任何东西”。

持续测试套件需要经济和高效。团队将需要重新设计、优化,甚至削减用于持续测试的自动化套件的规模,而不是让它们变得臃肿和缓慢。

为什么?原因如下:

  • 测试已经过时了
  • 测试需要维护
  • 经常失败或容易崩溃的测试需要重新考虑和重新设计,以发现bug,或者更快地崩溃和不那么脆弱。
  • 获得更多即时反馈。
  • 在持续测试中,团队中的其他人将运行一组有效的测试。
  • 用最少的测试数量获得最大的覆盖率。也就是说,让你的钱得到最大的回报。

您将需要各种测试套件。例如,你可能有一些“回归”套件:

  • 一种快速的烟熏回归,
  • 一个大的,完全的回归,
  • 一个更小的,“愉快的路径”/主要功能,bug发现回归套件,一个主要或核心的“精益和平均”回归套件,或者一个更小的端到端事务/集成风格的回归套件,适用于完整的集成环境。

它们将在DevOps过程中不同环境中的不同点上运行。重要的是要记住,所有这些测试都是在sprint中进行的新功能开发测试之外的,你会在产品中运行这些测试吗?我希望不是这样。这些套件的目标并不是您在生产环境中想要的!在生产环境中运行的自动化测试套件必须格外小心,以便在监视系统行为和可用性时维护生产环境和用户的完整性。因此,您可能希望在上面的“回归套件”列表中添加一个较小的集合,以便在生产环境中运行以进行监视。

测试在生产

多年来,我一直在测试,一直有一个严格的规则:不进行生产测试.您最不希望发生的事情就是在与客户一起运行的系统/环境中搞砸了,然后不小心做了一些事情把系统搞砸了。我完全支持这个概念,并严格坚持在沙盒或试点服务器上复制数据和解决方案,这样我们就可以玩任何需要玩的东西。它可能导致在生产中需要解决或返修在某种程度上如果有必要,但对的就是对的,客户和最终用户需要一个解决方案,提供了数据输出和性能expected-sometimes不管成本(虽然改变命令approved-can肯定让这个痛苦)。

总结

为持续测试开发测试策略是对在哪里进行测试的内容进行全面的重新检查。这与精益软件开发(LSD)的思想有关188betios下载每一步的品质是持续测试策略的基础。它包括重新检查您所称的“回归”,并为即时反馈开发多个精益和平均套件。

这也意味着要重新考虑自动化的内容和方式。老式的自动化,甚至是小型的独立自动化测试,都需要重新检查,并由高效的、低级的测试以及更长的、以客户为中心的事务工作流取代。尽早进行测试,测试通常是最好的解决方案,而自动化测试(无论可能达到何种程度)能够很好地为交付团队工作,从而消除过程中的人为错误,并大大加快测试过程和我们所关注的生产准备时间。

迈克尔·哈克特
Michael是LogiGear Corporation的联合创始人,在银行、证券、医疗保健和消费电子产品领域拥有超过20年的软件工程经验。Michael是一名认证的Scrum大师,并与人合著了两本关于软件测试的书。Web上的测试应用:基于移动和互联网系统的测试计划(Wiley, 2003年第2版),以及全球软件测试自动化(Happy About Publishing, 2006)。他是加州大学伯克利分校(University of California Berkeley Extension)顾问委员会的创始成员,并在加州大学圣克鲁兹分校(University of California Santa Cruz Extension)教授软件质量工程和管理证书。作为IEEE的成员,他的培训课程将硅谷的测试技术带到16个国家。他持有Carnegie Mellon University的工程学学士学位。

相关的帖子

在过渡到EaaS之前你需要知道的内容基于云的环境和云基础设施之间的主要区别是什么?环境是一组基础设施元素的集合,它们协同工作,使应用程序堆栈能够工作。例如,一个简单的三层应用程序,一个web前端组件,一个业务逻辑…
从文化的转变,到敏捷的差异,Dave Farley和Michael Hackett讨论了DevOps测试的本质。在本期LogiGear杂志中,我们的迈克尔·哈克特采访了“连续交付”的教父之一大卫·法利。在这个独家采访中,David讨论了如何测试团队和自动化……
从采用文化,到实现持续交付,DevOps相对较新,目前还没有大量的DevOps书籍。这就是为什么我们根据四个标准整理出了7本最好的DevOps书籍:来自Amazon的评分数量、Amazon的平均评分数量、来自GoodReads的评分数量和……
时代变了,工具也改进了,有了这样的书,您没有理由不尝试一下CI。我仍然记得我第一次使用NAnt和cruisecontroll.net的项目。那是几年前的事了,而且这两种工具都是有很多漏洞的新工具。项目经理……
测试团队的工作是报告测试结果,而不是设置或保证您将满足sla。在云服务的热潮中,一切都是服务,你会听到人们谈论sla。这和测试有什么关系?服务水平协议(SLA)是一种…
在持续部署的情况下,每天多次发布新软件到产品中是很常见的。一个回归测试套件,无论设计得多么好,可能仍然需要超过10分钟的时间来运行,这可能会导致在向生产发布变更时出现瓶颈。所以,做……
云计算在相当长的一段时间内一直是信息技术领域的流行词,在未来几年内,它很可能会保持这一地位。与所有其他现有交付模式相比,云计算一直在帮助企业更快、更便宜地交付服务。中小企业已经改变了他们的…
介绍一切都变了。它是唯一的常数。由社会、商业和技术的变化所驱动的软件测试领域正在经历着快速而剧烈的变化,这些变化已经将软件置于世界各地。计算是无处不在。今天几乎没有什么东西不包含CPU或信息传输能力,并由软件驱动。从智能烤面包机……
扔掉笨重的超级hypervisor,在开发项目期间不要考虑计算机硬件和软件许可。当你听到“云”的时候,你首先想到的可能不是开发和测试。云计算市场充满了SaaS应用程序、托管和基于云的文件系统。所有这些都非常有用,提供了一个清晰的……
Docker是一个虚拟化平台,可以让你创建容器——迷你虚拟机——它们有自己的预定义环境,包括文件系统、库和设置。最重要的是,这些轻量级图像只占用几兆字节。
LogiGear杂志2020年6月刊:用持续测试来改变你的SDLC
LogiGear杂志2018年6月刊:DEVOPS测试

留下一个回复

您的电子邮件地址将不会被公布。必填字段被标记

有最新消息要及时通知
软件测试消息

订阅
Baidu