“自动测试”一词似乎有许多不同的用途。对于某些人来说,这意味着内置的单元测试,在运行新版本时,执行以确保代码重构不会破坏某些内容。在这里这不是问题。

问题似乎在于,用于针对初始验证程序/产品/功能执行初始测试的自动测试与自动测试之间的区别针对程序/产品/功能运行的测试,以确保以前没有发生过任何故障。我知道我已经回答了关于两者的定义的问题,但是我要寻找的是实际的特性差异。在“自动测试”中您将做什么,而在“自动回归测试”中您不会做什么,反之亦然?有什么区别吗?一个人会导致另一个人吗?

#1 楼

事实是,对于很多人而言,没有什么区别。

回归测试是一种可以根据某些要求检查测试结果的工具。单元测试和功能测试就是很好的例子。它们告诉您应用程序的功能是否已回归(因此,回归。)当然,首先假定它已正常运行,但是这一点仍然有效。 (注意:有人可能会纠正我,并说功能测试不是回归测试。如果他们通过并解释了为什么要通过或不通过测试,我会很好的!)自动化测试:想到模糊的输入和自动化的探索性测试。这些并不总是像回归测试那样具有可预测的,可重复的结果。对于测试人员而言,这将是相当繁琐且耗时的工作,因此自动执行并查看结果没有任何问题。它可以帮助您将测试的极限设置为可以思考的速度,然后实现自动化,而不是可以单击的速度。 ”的意思是“自动回归测试”,而老实说他们没有意识到。

评论


这就是为什么我们应该给任何将自动测试和自动回归测试混为一谈的人!

– Ethel Evans
11年5月17日在19:01

欢迎来到一个充满主观术语的行业!

– MichaelF
2011年5月17日在20:05

你知道这很讽刺。作为程序员(所有开发人员,QA,PM,DBA等中只有一个程序员),我们被告知,对计算机所说的必须遵守严格的语法和语法规则。关于我们在编写代码时声明的含义没有争议。您可能会认为我们会将相同的标准应用于极客间的交流(因为缺少更好的词汇)!为什么我们让自己被流行语所吸引,让博客圈定义我们的词汇量呢?敏捷定义标准委员会在哪里?

–corsiKa♦
2011年5月17日在20:08

我选择这个作为答案,因为它确实回答了这个问题。但是,上述Ethel的答案是一个很好的补充,它给出了什么是非回归自动化测试的详细示例。

– Tristaan​​Ogre
2011年5月19日在12:49

当我说“自动”的意思是“没有手动输入”时,我是否很专一?测试独立于测试机制,因此自动回归测试是自动测试的子集。删除术语“自动”(运行测试的机制),即可获得“测试”和“回归测试”。另外,OP中两种自动测试中的第一种似乎是自动烟雾测试。我试图在sqa.stackexchange.com/questions/1216/中说明术语混乱

– Kinofrost
2011年6月22日14:07

#2 楼

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


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

我将其作为社区Wiki,因此人们可以添加其他示例。

#3 楼

已经添加了一些好的答案,但是我还没有看到这种区别,所以我将其添加到堆中。描述方式是您可以决定举办规格研讨会,目的是提炼关键示例,然后您可以将其转变为可执行规格。

Gojko Adzic在我上面链接的博客中对此进行了更好的描述-但是对我们而言,此处的主要区别在于这种自动化旨在说明需求而不是对其进行测试。因此,您没有像使用回归套件那样尝试覆盖很多不同的排列,而是故意使示例集更小。

我想另一种看待方式是重新熟悉敏捷测试象限之后,这就是支持团队的面向业务的测试与批评该产品的面向业务的测试之间的区别。

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

评论


以下@Ethel的答案已转换为Wiki。也许您可以将这些答案添加到下面的Wiki中。

– Tristaan​​Ogre
2011年5月18日在12:59

#4 楼

通常,在谈论回归测试时,它是确保功能不会从一个版本发布到另一个版本的测试。

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

此外,良好的回归测试的特征与其他自动化类别不同。回归测试代码需要相对快速,可靠,诊断且易于维护。目标不是找到“好”或新的错误。目的是确保对代码库的更改不会产生连锁效应,这种连锁效应不会在早期引起注意。您的回归测试应始终通过。如果一个星期中每天的测试都失败了,没人关心您有问题。很快将是两个,然后是十个,然后再没有人会关心回归报告,因为“这些东西永远都不会过去。”

有大量的临时自动化和半自动化测试。这些应该便宜,计划寿命很短,并且对于发现新的错误或指出可能存在错误的区域非常有用。一个简单的例子就是使用perl脚本或logparse.exe解析日志文件并查找异常。由于结果通常需要人工判断才能解析,因此编写超干净的自动化程序来查找可能存在或不存在的错误的投资回报率很低。可以找到整个错误类别,然后需要根本原因和非常有成本地进行一些集中的回归测试。不要应用严格的编码标准来丢弃测试。根据经验,如果在下一个版本中再次编写脚本要比记录并签入它更快,则将您的垃圾代码扔掉,并记下要在下一个版本中再次执行的脚本。自动化通常不被视为回归自动化。您可以将性能和压力自动化纳入回归测试中,但这并不总是划算的。他们通常最终会进入半自动训练营,在此训练营中,每个人都必须整理测试和结果。部署脚本,数据库清理作业和回归测试框架就是示例。它们通常落在测试和产品之间的灰色区域。一些最佳的基础结构自动化内置了构建-测试-部署周期。这些都不是回归测试本身,但是拥有良好的基础架构自动化是流程顺利进行的关键。

评论


@Ethel在下面启动了一个社区Wiki作为答案。也许您可以将它们添加到该列表中。

– Tristaan​​Ogre
2011年5月18日在12:59

#5 楼

我们在对应用程序进行代码更改后立即对其进行回归测试,以确保新代码不会影响软件的其他部分。但是自动化测试是一个广泛的概念,回归可以成为其中的一部分。我认为不可能对此进行比较。但是,对于回归测试和重新测试,我们可以使用相同的方法。您可以在本文的此处查看这种差异。