什么是单元测试、集成测试、冒烟测试、回归测试?

• 单元测试 :指定并测试类的单个方法的契约的一个点。这应该有一个非常狭窄和明确的范围。与外界的复杂依赖关系和交互 stubbed or mocked .

• 集成测试 :测试多个子系统的正确互操作。从测试两个类之间的集成,到测试与生产环境的集成,都有一个完整的范围。

• 烟雾测试(又名 理智 检查) :一个简单的集成测试,我们只是检查当被测试的系统被调用时,它是否正常返回并且没有崩溃。

  • 冒烟测试与电子学都有相似之处,第一次测试发生在电路通电时(如果冒烟,那就很糟糕!)。..
  • …而且, apparently ,与 plumbing ,其中管道系统被烟雾填满,然后进行目视检查。如果有东西冒烟,说明系统漏水。

• 回归测试 :修复错误时编写的测试。它确保此特定错误不会再次发生。全称是“非回归测试”。它也可以是在更改应用程序之前进行的测试,以确保应用程序提供相同的结果。

对此,我将补充:

• 验收试验 :测试功能或用例是否正确实现。它类似于集成测试,但侧重于要提供的用例,而不是所涉及的组件。

• 系统测试 :将系统作为黑匣子进行测试。在测试过程中,对其他系统的依赖性经常被嘲笑或打断(否则它更像是一个集成测试)。

• 飞行前检查 :在类似生产环境中重复的测试,以缓解“基于我的机器构建”综合症。通常,这是通过在类似生产的环境中进行验收或冒烟测试来实现的。

• 单元测试 :测试类内部工作的自动测试。它应该是一个独立的测试,与其他资源无关。
• 集成测试 :在环境中进行的自动测试,类似于单元测试,但使用外部资源(数据库、磁盘访问)
• 回归测试 :在实现新功能或修复错误后,您可以重新测试过去有效的场景。在这里,您将介绍新功能破坏现有功能的可能性。
• 冒烟测试 :测试人员可以得出结论是否要继续测试的第一个测试。

每个人的定义都略有不同,而且往往存在灰色地带。然而:

• 单元测试:这一点(尽可能孤立)有效吗?
• 集成测试:这两个(或更多)组件是否协同工作?
• 烟雾测试:整个系统(尽可能接近生产系统)是否合理地连接在一起?(也就是说,我们有理由相信它不会产生黑洞吗?)
• 回归测试:我们是否无意中重新引入了之前修复的任何错误?

我刚刚意识到的一个新的测试类别是 canary test 金丝雀测试是一种自动化的、非破坏性的测试 定期运行 在一个 生活 环境,如果它失败了,就会发生非常糟糕的事情。

例如:

• 是否出现了只应在开发/测试中可用的数据 生活 ?
• 后台进程是否运行失败?
• 用户可以登录吗?

来自软件测试技术最佳网站之一的答案:

软件测试类型完整列表 click here

这是一个相当长的描述,我不打算粘贴在这里:但对于那些想知道所有测试技术的人来说,这可能会有所帮助。

单元测试 :应用程序中单个模块或独立组件的测试被称为单元测试。单元测试将由开发人员完成。

集成测试 :组合所有模块并测试应用程序,以验证模块之间的通信和数据流是否正常工作。开发人员也执行了此测试。

烟雾测试 在烟雾测试中,他们以浅而宽的方式检查应用程序。在烟雾测试中,他们检查应用程序的主要功能。如果应用程序中存在任何阻塞问题,他们将向开发团队报告,开发团队将修复并纠正缺陷,并将其交还给测试团队。现在,测试团队将检查所有模块,以验证在一个模块中所做的更改是否会影响另一个模块。 烟雾测试 测试用例是脚本化的。

回归测试 重复执行相同的测试用例,以确保未更改的模块不会造成任何缺陷。回归测试属于功能测试

单元测试:验证特定组件(即类)是否按设计创建或修改了功能。该测试可以是手动或自动的,但不会超出组件的边界。

集成测试:验证特定组件的交互是否按设计运行。集成测试可以在单元级别或系统级别进行。这些测试可以是手动或自动的。

回归测试:验证现有代码中没有引入新的缺陷。这些测试可以是手动或自动的。

取决于你 SDLC ( waterfall , RUP , agile 等)特定测试可以分“阶段”进行,也可以或多或少同时进行。例如,单元测试可能仅限于开发人员,然后他们将代码交给测试人员进行集成和回归测试。然而,另一种方法可能是让开发人员进行单元测试以及一定程度的集成和回归测试(使用 TDD 方法以及持续集成和自动化单元和回归测试)。

工具集在很大程度上取决于代码库,但有许多用于单元测试的开源工具(JUnit)。惠普(水星)QTP或Borland的 Silk Test 都是自动化集成和回归测试的工具。

回归测试-

“回归测试对更改后的软件重新运行之前的测试,以确保当前软件中的更改不会影响现有软件的功能。”

我只是想补充并提供一些更多的背景,说明为什么我们有这些级别的测试,它们对示例的真正意义是什么

Mike Cohn在他的《敏捷成功》一书中提出了测试金字塔作为一种在项目中实现自动化测试的方法。这个模型有各种解释。该模型解释了需要创建什么样的自动化测试,它们对被测应用程序的反馈速度有多快,以及谁编写这些测试。 任何项目基本上都需要3个级别的自动化测试,如下所示。

单元测试- 这些测试软件应用程序的最小组件。这实际上可能是代码中的一个函数,它根据一些输入计算一个值。此功能是组成应用程序的硬件/软件代码库的其他几个功能的一部分。

例如,让我们以一个基于网络的计算器应用程序为例。这个应用程序中需要进行单元测试的最小组件可能是一个执行加法的函数,另一个执行减法的函数等等。所有这些小函数加在一起组成了计算器应用程序。

从历史上看,开发人员编写这些测试是因为它们通常是用与软件应用程序相同的编程语言编写的。为此,使用了JUnit和NUnit(用于java)、MSTest(用于C#和.NET)和Jasmine/Mocha(用于JavaScript)等单元测试框架。

单元测试的最大优点是,它们在UI下运行得非常快,我们可以快速获得有关应用程序的反馈。这应该占你自动化测试的50%以上。

API/集成测试- 这些测试一起测试软件系统的各个组件。这些组件可能包括测试数据库、API(应用程序编程接口)、第三方工具和服务以及应用程序。

例如,在上面的计算器示例中,web应用程序可能使用数据库存储值,使用API进行一些服务器端验证,并可能使用第三方工具/服务将结果发布到云端,使其在不同平台上可用。

从历史上看,开发人员或技术QA会使用各种工具编写这些测试,如Postman、SoapUI、JMeter和其他工具,如Testim。

这些测试的运行速度比UI测试快得多,因为它们仍然在引擎盖下运行,但可能比单元测试消耗更多的时间,因为它必须检查系统各个独立组件之间的通信,并确保它们无缝集成。这应该占自动化测试的30%以上。

UI测试- 最后,我们进行了验证应用程序UI的测试。这些测试通常是为了测试应用程序中的端到端流而编写的。

例如,在计算器应用程序中,端到端流程可以是打开浏览器->;输入计算器应用程序url->使用用户名/密码登录->打开计算器应用程序>在计算器上执行某些操作->从UI验证这些结果>退出应用程序。这可能是一个端到端的流程,是UI自动化的一个很好的候选者。

从历史上看,技术QA或手动测试人员编写UI测试。他们使用Selenium等开源框架或Testim等UI测试平台来编写、执行和维护测试。这些测试提供了更多的视觉反馈,因为您可以通过屏幕截图、日志、测试报告看到测试是如何运行的,以及预期结果和实际结果之间的差异。

UI测试的最大限制是,与Unit和API级别的测试相比,它们相对较慢。因此,它应该只占整个自动化测试的10-20%。

接下来的两种测试可能会根据您的项目而有所不同,但想法是-

冒烟测试

这可以是上述3个测试级别的组合。其想法是在每次代码签入时运行它,并确保系统的关键功能仍按预期工作;合并新代码更改后。他们通常需要跑5-10分钟才能更快地获得故障反馈

回归测试

它们通常每天至少运行一次,涵盖系统的各种功能。它们确保应用程序仍按预期工作。它们比烟雾测试更详细,涵盖了应用程序的更多场景,包括非关键场景。

• 集成测试:集成测试是集成的另一个要素
• 冒烟测试:冒烟测试也称为构建版本测试。冒烟测试是初始测试过程,用于检查被测软件是否已准备好/稳定,可以进行进一步测试。
• 回归测试:回归测试是 重复的 测试。新软件是否在另一个模块中生效。
• 单元测试:这是一个白盒测试。仅 开发者 参与其中

单元测试 针对实施过程中可能的最小部分。在Java中,这意味着您正在测试单个类。如果该类依赖于其他类,则这些类是伪造的。

当你的测试调用多个类时,这是一个 集成测试 .

完整的测试套件可能需要很长时间才能运行,因此在更改后,许多团队会运行一些快速完成的测试来检测重大的漏洞。例如,您已经将URI分解为基本资源。这些是 冒烟测试 .

回归测试 在每个构建上运行,并通过捕捉你破坏的东西来有效地重构。任何类型的测试都可以是回归测试,但我发现单元测试最有助于找到故障源。

单元测试

单元测试通常由开发人员完成,而测试人员在这种类型的测试中部分进化,在这种测试中,测试是逐个单元完成的。 在Java中 JUnit 测试用例也可以测试编写的代码是否设计完美。

集成测试:

当所有/部分组件都集成在一起时,这种类型的测试可以在单元测试后进行。这种类型的测试将确保在集成组件时,它们是否会影响彼此的工作能力或功能?

冒烟测试

这种类型的测试是在系统成功集成并准备在生产服务器上运行时进行的。

这种类型的测试将确保从头到尾的每个重要功能都正常工作,并且系统已准备好部署到生产服务器上。

回归测试

这种类型的测试对于测试开发人员修复某些问题时系统中不存在意外/不需要的缺陷非常重要。 此测试还确保所有错误都已成功解决,因此不会出现其他问题。

冒烟和健全性测试都是在软件构建后进行的,以确定是否开始测试。烟雾测试后可能会也可能不会进行卫生测试。它们可以单独执行,也可以同时执行——在吸烟后立即恢复理智。

因为健全性测试更深入,需要更多时间,在大多数情况下,它非常值得自动化。

烟雾测试的执行时间通常不超过5-30分钟。它更一般:它检查整个系统的少数核心功能,以验证软件的稳定性是否足够好,可以进行进一步的测试,并且没有问题,从而阻止计划测试用例的运行。

卫生测试比吸烟更详细,可能需要15分钟到一整天,具体取决于新建筑的规模。这是一种更专业的验收测试,在进展或重新测试后进行。它检查某些新功能和/或错误修复的核心功能以及与之密切相关的一些功能,以便在更大规模地执行回归测试之前,验证它们是否按照所需的操作逻辑运行。

单元测试:它总是由开发人员在开发完成后执行,以便在为QA准备任何需求之前从测试方面找出问题。

集成测试:这意味着当一些数据/功能输出被驱动到一个模块到另一个模块时,测试人员必须验证模块到子模块的验证。或者在您的系统中使用第三方工具,该工具使用您的系统数据进行集成。

冒烟测试:测试人员执行测试以验证系统的高级测试,并在更改或代码上线之前尝试找出显示停止错误。

回归测试:测试人员执行回归,以验证由于系统中实施的新增强或系统更改而导致的现有功能。

回归测试是一种软件测试,我们试图覆盖或检查错误 修理 。围绕错误修复的功能不应因提供的修复而改变或更改。在此过程中发现的问题称为 回归问题 .

冒烟测试:是一种测试,用于决定是否接受构建/软件进行进一步的QA测试。

已经有一些好的答案了,但我想进一步完善它们:

单元测试是这里唯一的白盒测试形式。其他的都是黑盒测试。白盒测试意味着您知道输入;你知道机制的内部工作原理,可以检查它,你知道输出。通过黑盒测试,你只知道输入是什么,输出应该是什么。

所以很明显,单元测试是这里唯一的白盒测试。

• 单元测试测试特定代码。通常的方法。
• 集成测试测试您的新功能软件是否可以与其他所有功能集成。
• 回归测试。这是为了确保你没有损坏任何东西而进行的测试。过去有用的东西现在应该还能用。
• 烟雾测试是一种快速测试,以确保在您参与更激烈的测试之前,一切看起来都正常。

烟雾测试已经在这里解释过了,很简单。回归测试属于集成测试。

自动化测试可以分为两种。

单元测试和集成测试 (这才是最重要的)

对于所有测试,如集成测试、功能测试、回归测试、UI测试等,我会称之为“长测试”(LT)。单元测试被称为“短期测试”。

LT示例可以是自动加载网页、登录帐户并购买书籍。如果测试通过,它更有可能以相同的方式在实时网站上运行(因此是“更好的睡眠”参考)。长=网页(开始)和数据库(结束)之间的距离。

这是一篇很好的文章,讨论了 integration testing (long test) over unit testing .