测试动态 / 质量专栏 /完整的自动化测试——可行吗?
完整的自动化测试——可行吗?
2022-06-06 浏览次数:996

事实上,软件测试非常耗费时间和资源。可以从不同的角度观察软件的测试。它可以根据我们正在测试的内容进行划分。例如,项目中的每个可交付成果,如需求、设计、代码、文档、用户界面等,都应该进行测试。此外,我们可以根据用户和功能需求或规范对代码进行测试,即黑盒测试。在这个级别,我们将代码作为黑盒进行测试,以确保程序预期的所有服务都存在,按预期工作并且没有问题。我们可能还需要测试代码的结构,即白盒测试。测试也可以根据测试中的子阶段或活动来划分,例如,测试用例的生成和设计、测试用例的执行和验证、构建测试数据库等。测试确保开发的软件最终是错误的自由。但是,没有任何流程可以保证所开发的软件是 100% 无错误的。

尽管手动测试通常会导致遗漏的错误、次优的测试覆盖率和人为错误,但即使在大型项目中,也无法用自动化测试完全取代它。UX、可用性、探索性等测试需要人为因素,因为自动工具无法模仿用户行为。自动化测试也不适用于安全测试。自动漏洞扫描需要随后的手动检查,因为它会提供许多误报。

在当今的现实场景中,应用程序会根据用户反馈、Web 流量(性能/负载)、竞争、合规法律等频繁变化。因此,要保持竞争优势,就需要创新、升级和增强您的产品,使一切自动化变得具有挑战性。那么实施完整的自动化测试策略意味着什么呢?它甚至可行吗?全自动 QA 能保证质量吗?

我们需要完整的自动化测试吗?

自动化测试不是精确测试;它正在检查事实。检查是机器可决定的;测试需要感知。测试是一项调查活动,我们旨在通过探索获得有关被测系统的新信息。测试(手动)需要人类对可用性做出合理的判断。因此,我们可以在没有预料到的情况下注意到违规行为。此外,在实施测试自动化解决方案时,除了编写测试用例脚本之外,还有其他相关的开发活动。

通常,企业会开发一个框架来演示测试用例选择、报告等操作。框架的开发是一项艰巨的任务,需要熟练的开发人员,并且需要时间来构建。此外,即使有一个功能齐全的框架,编写脚本自动检查所需的时间也比手动执行相同的测试要长。

但是,企业不应该对其中一种宽容,因为这两种方法都需要深入了解应用程序的质量。企业花费大量时间使用最佳工具和实践来开发完美的测试自动化解决方案,但如果自动化检查对团队没有帮助,那就无益了。我们不应该以取代手动 QA 为目标,而应该接受它对团队的优势。例如,自动化测试有助于腾出 QA 的时间进行更多探索性测试,并会发现错误。

哪些测试应该自动化?

团队通常希望尽可能地自动化一切。但是当他们遇到各种问题时,这又会困扰他们。企业应该分析他们希望自动化的测试用例的类型以及不能自动化或不应该自动化的用例。团队不应该仅仅为了测试而自动化测试。例如,如果您将需要大量维护的一整套测试自动化,那么您正在投入额外的时间和金钱,而这些时间和金钱您可能没有。相反,如果您专注于采用基于风险的方法,这将有所帮助,这样您就可以只自动化最有价值的测试。

让我们看一下最可行的自动化测试场景:

1、回归测试:回归测试需要多次测试相同的变量,以确保新功能不会与旧功能混淆。回归测试非常适合自动化。

2、复杂的功能:企业可以自动化所有需要复杂计算的测试。

3、冒烟测试:可以通过运行自动化测试为企业验证重要功能的质量,这将快速分析功能是否需要更多测试。

4、数据驱动测试:使用大量数据集重复测试功能也是考虑自动化测试的好方案。

5、性能测试:在不同情况下监控软件性能的测试非常适合自动化测试。为手动测试团队进行性能测试将非常详细且耗时。

6、功能测试:每当开发人员需要执行快速执行以获得即时反馈的功能测试时,这是另一个有意义的自动化测试示例。如果没有自动化,就不可能实现这一目标,尤其是在快速发展的组织中。

自动化测试的问题

问题的症结在于敏捷团队不再进行测试。由于 DevOps 等开发实践和文化,手动测试已经失去了优势。QA 领域存在分歧——会编码的和不会编码的。大多数测试人员现在都在努力跟上自动化需求。在每个 sprint 中都存在自动化测试的压力,并且没有足够的时间进行彻底的探索性测试。

敏捷开发中的问题是测试人员采用用户流程并自动化其验收标准。但是,在这样做的同时,他们主要也是唯一的重点是与他们有限的编码技能作斗争以通过测试。因此,当您只对自动化测试感兴趣并看到它在构建管道中通过时,这自然会产生狭窄的焦点。

1、高期望

大多数商界人士相信新的技术解决方案将化险为夷。测试工具也不例外!我们不能否认,如今的工具几乎可以解决我们目前在测试自动化中面临的所有问题。然而,这种不切实际的乐观也导致了不切实际的期望。无论工具多么称职,如果管理层的期望不切实际,它就不会满足期望。

2、自动化不必要

测试不要仅仅为了测试而自动化测试。取而代之的是,在这个过程中投入一些想法。研究产品的高层和低层架构。问会出什么问题。分析集成点并寻找潜在的突破点。

在您的整体测试方法中采用基于风险的自动化方法。例如,某物发生故障的可能性有多大,故障的影响是什么?如果答案很高,那么这些场景应该在每次构建时自动化并执行。

3、有缺陷的安全性

仅仅因为测试工具没有发现任何缺陷并不意味着软件中没有缺陷。至关重要的是要了解,如果测试包含缺陷,它们将带来不正确的结果。自动化测试将无限期地保留那些不满意的结果。

4、忽略重要场景

一个严重的问题经常会泄漏到生产中,因为没有人考虑过特定的场景。执行多少自动化测试并不重要。如果忽略了某个场景,那么根据 Sod 定律就会出现错误,即如果出现问题,就会出现问题。

结论

大多数测试自动化工程师花时间与自动化代码作斗争,并使测试在现代软件开发中发挥作用。他们几乎不专注于适当的测试和探索系统。

没有足够的时间编写自动化代码和执行探索性测试。团队在冲刺后自动化冲刺,忘记大局。

通常企业最终会执行大量自动化测试,但探索性测试会发现大多数错误。相反,企业应该根据风险评估选择要自动化的内容。

卓码软件测评是一家[ 具备CMA、CNAS双重资质 ]的专业做软件测试的第三方软件测试服务机构, 可根据您的需求提供各类软件测试服务,并出具合格有效的软件测试报告。点击→→可了解测试报价

部分文字、图片来自网络,如涉及侵权,请及时与我们联系,我们会在第一时间删除或处理侵权内容。负责人:曾菲       电话:4006070568


文章标签: 自动化测试 软件测评 软件测试
专业测试,找专业团队,请联系我们!
咨询软件测试 400-607-0568