“自动化测试”和“自动化回归测试”有什么区别?

软件测试 自动化测试 回归测试 术语
2022-01-16 21:06:05

“自动化测试”作为一个术语似乎有许多不同的用途。对于某些人来说,这意味着内置单元测试,当运行新构建时,执行以确保代码重构没有破坏某些东西。这不是问题所在。

然而,问题似乎在于,用于针对程序/产品/功能执行初始测试以进行初始验证的自动化测试与针对程序/产品/功能运行以确保以前一直在工作的东西现在都没有损坏。我知道我对两者的定义有点回答了我自己的问题,但我正在寻找的是实际特征差异。你会在“自动测试”中做什么而在“自动回归测试”中不会做,反之亦然?有什么不同吗?一个会导致另一个吗?

4个回答

事实是对很多人来说,没有区别。

回归测试将根据某些要求检查您的测试结果。单元测试和功能测试就是很好的例子。他们告诉你你的应用程序的功能是否已经退化(因此,回归)。当然,这首先假设它是正常的,但这一点仍然有效。(注意:有人可能会纠正我并说功能测试不是回归测试。如果他们这样做并解释他们为什么符合或不符合条件,我会很好!)

还有其他类型的自动化测试:模糊输入和自动化探索性测试浮现在脑海。这些并不总是像回归测试那样具有可预测的、可重复的结果。对于测试人员而言,手动执行它们将是一项相当乏味且耗时的工作,因此将其自动化并查看结果并没有错。它有助于将测试的限制限制在您可以思考的速度,然后自动化,而不是您可以点击的速度。

与我交谈过的大多数人,尤其是那些处于开发阶段的人,都认为“自动化测试”是指“自动化回归测试”,而他们真的没有意识到这一点。

为了补充glowcoder的答案,主要是更多的例子,自动化回归测试是自动化测试的一个子集,但还有其他种类。非回归自动化测试的一些示例是:

  • 任何将被丢弃且不用于回归测试的自动化测试都不是回归测试,包括以后不用于回归测试的单元测试。从技术上讲,任何为新功能编写的自动化测试都不是回归测试,除非它至少验证了一次正确的功能。只有这样它才能验证功能没有改变。
  • 可靠性测试,让您的系统在接近生产的环境中尽可能长时间地运行,以查看它可以运行多长时间而不会出现错误或崩溃
  • 压力测试,即查看被测系统在大量使用或资源有限的情况下的行为;您可能会移除 CPU 或减少带宽,或模拟大量用户。
  • 一些性能测试可能没有特定的检查来验证并且可能需要一个人来解释结果,尽管一些性能测试可以作为回归测试运行(例如,“运行这个函数的 100 次迭代。如果花费的时间少于 5 秒,则通过; 否则,失败。”)。
  • Glowcoder 提到了模糊测试,这是一个函数的随机输入,但这个主题值得扩展。通过模糊测试,测试人员正在寻找可能导致问题的意外行为,例如安全漏洞、崩溃和挂起。

我正在把它变成一个社区 wiki,所以人们可以添加其他示例。

已经添加了一些好的答案,但我还没有看到这种区别,所以我将它添加到堆中:

您可以自动化一些测试,以根据需求对构建进行初始验证——但另一种描述方式是,您可能决定举办规范研讨会,目标是提炼关键示例,然后您可以将其转化为Executable Specifications

Gojko Adzic 在我上面链接的博客中更好地描述了这一点 - 但对我们来说,这里的关键区别在于这种自动化旨在说明需求而不是测试它们。因此,与其像使用回归套件那样试图获得大量不同排列的覆盖范围,不如故意使示例集更小。

我想另一种看待方式是,如果您熟悉敏捷测试象限,那么它就是支持团队的面向业务的测试和批评产品的面向业务的测试之间的区别。

更多信息: http ://www.acceptancetesting.info/the-book http://specificationbyexample.com/

通常,当谈到回归测试时,它是确保功能不会从一个版本中断到另一个版本的测试。

自动化测试是一个很大的类别。它包括但不限于回归测试及其子类别,如烟雾/bvt 测试、单元测试、脚本化 UI 自动化。还有很多其他类型的自动化。只是随机按下按钮并查找崩溃的猴子自动化、随机模糊测试、数据库的数据完整性测试和半自动化任务就是一些例子。还有很多

此外,良好的回归测试的特征与其他类别的自动化不同。回归测试代码需要相对快速、可靠、可诊断且易于维护。目标不是找到“好”或新的错误。目标是确保对代码库的更改不会产生早期没有注意到的连锁反应。您的回归测试应该始终通过。如果一个测试每天都失败,并且没有人关心你有问题。很快就会是两个,然后是十个,然后没有人会关心回归报告,因为“那些事情无论如何都不会过去”。

有一大类临时自动化和半自动化测试。这些应该很便宜,计划寿命很短,并且在发现新错误或指出错误可能潜伏的区域时非常有用。简单地使用 perl 脚本或 logparse.exe 解析日志文件并查找异常就是一个很好的例子。由于结果通常需要人工判断来解析,因此编写超级干净的自动化程序来查找可能存在或不存在的错误的投资回报率很低。有可能找到整个类别的错误,然后需要非常便宜的根本原因和一些集中的回归测试。不要应用严格的编码标准来丢弃测试。经验法则,如果在下一个版本中再次编写脚本比记录并签入更快,

性能和压力自动化通常不被视为回归自动化。您可以将性能和压力自动化纳入回归测试,但这并不总是具有成本效益。他们通常最终进入半自动训练营,一个人必须策划每次运行的测试和结果。

最后是基础设施自动化。部署脚本、数据库清理作业和回归测试框架就是示例。他们经常陷入测试和产品之间的灰色地带。一些最好的基础设施自动化已经建立在构建-测试-部署周期中。这些都不是回归测试本身,但拥有良好的基础设施自动化是顺利过程的关键。