持续测试与自动化测试的区别是什么?

测试人员多年来一直在与自动化测试进行斗争,但大多数团队对他们当前的自动化测试水平或维护它所需的开销不满。此外,在过去几年中,软件的架构,开发和使用方式也发生了翻天覆地的变化 - 增加了测试的复杂性和软件故障的业务影响。

鉴于软件交付的复杂性和速度的增加,软件测试专业人​​员如何帮助控制业务风险呢?

你需要的是 持续测试。

什么是持续测试?


持续测试是一个过程,它将自动化测试作为软件交付通道中内嵌的一部分,以尽快获得软件发布后业务风险的反馈。

自动化测试旨在生成一组与用户故事或应用程序要求相关的通过/失败的数据点。另一方面,持续测试侧重于业务风险,并提供有关软件是否可以发布的判断。要实现这一转变,我们需要停止询问“我们是否已完成测试?”而是集中精力在“发布版本是否具有可接受的业务风险级别?”

持续测试与自动化测试有何不同?

持续测试和自动化测试之间的主要区别可分为三大类:风险,广度和时间。

风险
今天的企业不仅向最终用户展示了他们的许多内部应用程序,他们还开发了大量额外的软件,可以扩展和补充这些应用程序。例如,航空公司远远超出了飞机预订系统。他们现在让客户计划和预订完整的假期,包括酒店,租车和游玩活动。向用户展示越来越多的创新功能现在是竞争优势 - 但它也增加了潜在故障点的数量,种类和复杂性。

大规模的“软件失败”产生了如此严重的业务影响,以至于与应用相关的风险现在成为企业公共财务报告的重要组成部分。鉴于[值得注意的软件故障导致股票价格平均下跌-4.06%](相当于平均25.5亿美元的市值损失),企业领导人正在注意并期望IT领导者采取行动并不奇怪。

如果您的测试用例没有考虑到业务风险,那么您的测试结果将无法提供评估风险所需的洞察力。大多数测试旨在提供有关用户故事是否正确实现要求的低级详细信息,而不是高级别评估发布版本是否风险太高而无法发布。你会根据测试结果立即停止发布吗?如果没有,您的测试与业务风险不一致。

需要明确的是:我们并不是说低粒度测试没有价值; 我们要说的是,需要更多的措施来阻止高风险的版本失去控制。

广度


即使一家企业设法避开大型软件失败成为头条新闻,即使是看似微不足道的故障仍然可能会造成麻烦。如果用户体验的任何部分未能满足他的期望,您不仅有可能将该客户丢失给竞争对手 - 如果该用户决定将他的问题带到社交媒体上,您还可能面临品牌损害风险。

只知道单元测试失败或通过UI测试并不能告诉您最近的软件更改是否会影响整体用户体验。为了保护最终用户体验,您需要足够广泛的测试来检测软件更改何时无意中影响用户所依赖的功能。

时间


现在,组织运送软件的速度已成为竞争优势,绝大多数组织正在转向敏捷和DevOps以加速其交付流程。

当自动化测试出现时,它专注于测试根据瀑布式开发过程构建和更新的内部系统。系统都在组织的控制之下,在测试阶段准备好开始之前,一切都已完成并准备好进行测试。既然敏捷流程正在成为常态,那么测试必须与开发并行开始; 否则,用户故事不太可能在极度压缩的迭代时间范围内(通常是两周)进行测试并被视为“完成”。

如果您的组织已采用DevOps并且正在执行持续交付,则可能每小时或甚至更频繁地发布软件。在这种情况下,过程每个阶段的反馈不能只是“快速”; 它必须几乎是瞬间完成的。如果质量不是您软件开发的首要考虑因素(例如,如果在生产中发现缺陷时进行回滚的影响很小),则在每个版本上运行一些快速单元测试和冒烟测试可能就足够了。但是,如果企业希望最大限度地降低故障软件到达最终用户的风险,则需要一些方法来实现必要的风险覆盖水平和快速测试。

对于测试,有几个重大影响:

测试必须成为开发过程的一部分(而不是在开发完成时加上“保健”任务)
实现完相关功能后测试必须马上准备好运行
组织必须有办法确定在交付管道的不同阶段执行的正确测试(签入时的冒烟测试,集成后的API /消息层测试,系统级别的端到端测试,…)
每组测试必须足够快地执行,以免在软件交付管道的相关阶段产生瓶颈
需要一种稳定测试环境的方法来防止频繁更改导致大量误报
持续测试>测试自动化

如果您只从本文中提出一个想法,我们希望它是这样的:

自动化测试≠连续测试

持续测试>自动化测试

即使是使用传统测试自动化工具取得了相当成功的团队,当他们的组织采用现代架构和交付方法时,也会遇到严重的障碍:

  • 他们不能足够快或足够频繁地创建和执行真实的测试
  • 持续的软件更改会导致大量的误报,并且需要看似永无止境的测试维护量
  • 他们无法提供关于发布版本是否风险太大而无法通过交付渠道的即时洞察

重要的是要认识到没有任何工具或技术可以立即给你持续测试。与Agile和DevOps一样,持续测试需要在整个人员,流程和技术方面进行变革。然而,当你的技术无法完成任务时,尝试启动人员和流程的相关变化,从一开始就是一场艰苦的战斗…最终会失败。

如果您的组织正在开始或扩展您的持续测试自动化工作,我们建议您查看Forrester和Gartner的两项新研究。这两份报告都提供了对持续测试和测试自动化趋势的深入了解,以及顶级持续测试工具的比较。

CC先生说,持续**的名词模式已经成为现在企业转型的一个热度词汇。

不管是精益中提倡的 持续改善,还是Devops里提倡的CI(持续集成)- CD(持续部署) - CT(持续测试)- CD(持续交付)

持续进化终归是演进的一个大前提。

 

合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!

供 肿 郝  程序媛木子 免费领取资料

原文不易呀,眼睛都留眼泪了!麻烦伸出发财小手点个赞,感谢您的支持,你的点赞是我持续更新的动力。

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
自动化测试是一种测试方法,用于使用自动化测试工具和脚本来执行测试自动化测试可以提高测试效率和可靠性,并且可以在短时间内执行大量测试测试人员会编写脚本来执行测试,这些脚本可以重复使用,并且可以快速执行。自动化测试通常用于重复性测试、回归测试等场景。 在以下情况下,我认为应该使用自动化测试: 1. 频繁重复测试:如果测试需要频繁地重复执行,例如每次发布新版本时都需要执行回归测试,那么使用自动化测试可以提高测试效率,并且可以在短时间内执行大量测试。 2. 大规模数据测试:如果测试需要对大规模数据进行测试,例如性能测试、负载测试等,那么使用自动化测试可以减少测试时间和测试成本,并且可以模拟大规模数据的测试场景。 3. 复杂测试场景:如果测试需要模拟复杂的测试场景,例如多个用户同时进行交互、多个系统之间进行数据交互等,那么使用自动化测试可以减少测试时间和测试成本,并且可以模拟复杂的测试场景。 4. 快速反馈:如果测试需要快速反馈测试结果,例如持续集成、持续交付等,那么使用自动化测试可以快速执行测试,并提供测试结果,以便及时进行修复和改进。 5. 频繁更改:如果应用程序或系统需要频繁更改,例如敏捷开发中的迭代开发,那么使用自动化测试可以确保每个更改都得到充分测试,以确保更改不会破坏现有功能。 总之,在需要频繁重复测试、大规模数据测试、复杂测试场景、快速反馈和频繁更改的情况下,使用自动化测试可以提高测试效率和可靠性,并且可以减少测试成本。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值