单元测试和功能测试之间的区别是什么?

单元测试——测试单个单元，例如类中的方法(函数)，模拟所有依赖项。

功能测试——又名集成测试，测试系统中的一部分功能。这将测试许多方法，并可能与数据库或Web服务等依赖项交互。

单元测试告诉开发人员代码的工作是正确的;功能测试告诉开发人员代码正在执行正确的事情。

你可以在单元测试与功能测试上阅读更多

单元测试和功能测试在现实生活中的类比可以描述如下:

很多时候，系统的开发被比作房子的建造。虽然这个类比不太正确，但是为了理解单元测试和功能测试之间的区别，我们可以扩展它。

单元测试类似于建筑检查员视察房屋的建筑工地。他专注于房子的各种内部系统，基础，框架，电气，管道等。他确保(测试)房子的各个部分都能正确安全地工作，也就是说，符合建筑规范。

此场景中的功能测试类似于访问同一建筑工地的房主。他假设内部系统将正常运行，建筑检查员正在执行他的任务。房主关注的是住在这所房子里会是什么样子。他关心的是房子的外观如何，各个房间的大小是否舒适，房子是否适合家庭的需要，窗户是否在一个好的位置捕捉早晨的阳光。

房主正在对房子进行功能测试。他有用户的视角。

建筑检查员正在对房子进行单元测试。他有着建筑者的视角。

总结一下，

单元测试是从程序员角度编写的。它们用于确保类的特定方法(或单位)执行一组特定的任务。

功能测试是从用户的透视图编写的。它们确保系统是用户期望的功能。

“功能测试”并不意味着测试代码中的函数(方法)。一般来说，这意味着你在测试系统功能——当我在命令行上运行foo file.txt时，file.txt中的行可能会变反。相比之下，单个单元测试通常涵盖单个方法的单个情况——length("hello")应该返回5，而length("hi")应该返回2。

另见IBM在单元测试和功能测试之间建立了界线。

我认为它是这样的:单元测试确定代码执行了您希望代码执行的操作(例如，您想要添加参数A和b，实际上是将它们相加，而不是减去它们)，功能测试测试所有代码一起工作以获得正确的结果，因此您希望代码执行的操作实际上在系统中获得了正确的结果。

• 单元测试测试一个独立的行为单元。行为的单位是什么?它是系统中可以独立进行单元测试的最小部分。(这个定义实际上是循环的，IOW，它根本不是一个 的定义，但它在实践中似乎很有效，因为你可以直观地理解它。)

• 功能测试测试一个独立的功能部分。

• 行为单元非常小:虽然我非常不喜欢这种愚蠢的“每个方法测试一个单元”的咒语，但从size的角度来看，这是正确的。行为单元介于方法的一部分和几个方法之间。最多是一个对象，但不能超过一个。

• 一个功能块通常包含许多方法，并跨越多个对象，通常跨越多个体系结构层。

• 单元测试应该是这样的:当我调用validate_country_code()函数并将国家代码'ZZ'传递给它时，它应该返回false。

• 一个功能测试是:当我用国家代码ZZ填写运输表单时，我应该被重定向到一个帮助页面，允许我从菜单中选择我的国家代码。

• 单元测试是由开发人员从开发人员的角度为开发人员编写的。

• 功能测试可能是面向用户的，在这种情况下，它们由开发人员与用户一起编写(或者可能使用正确的工具和正确的用户，甚至由用户自己编写)，从用户的角度为用户编写。或者它们可能是面向开发人员的(例如，当它们描述一些用户不关心的内部功能时)，在这种情况下，它们是由开发人员为开发人员编写的，但仍然是从用户的角度出发。

• 在前一种情况下，功能测试还可以作为验收测试，并作为功能需求或功能规范的可执行编码，在后一种情况下，它们还可以作为集成测试。

• 单元测试经常更改，而功能测试在主要版本中不应该更改。

根据ISTQB的说法，这两者没有可比性。功能测试不是集成测试。

单元测试是测试级别的一种，功能测试是测试的一种。

基本上:

一个系统(或组件)的功能是“它做什么”。这是 通常在需求规范中描述的是功能性的

而

组件测试，也称为单元、模块和程序测试， 查找软件的缺陷，并验证软件的功能 (例如模块、程序、对象、类等)，它们是分开的 可测试的。< / p >

根据ISTQB，组件/单元测试可以是功能性或非功能性:

组件测试可能包括功能测试和特定的非功能特征，如资源行为(例如内存泄漏)、性能或健壮性测试，以及结构测试(例如决策覆盖率)。

引用自软件测试基础- ISTQB认证

单元测试

单元测试包括测试最小的代码单元，通常是函数或方法。单元测试主要由单元/方法/函数的开发人员完成，因为他们了解函数的核心。开发人员的主要目标是通过单元测试来覆盖代码。

它有一个限制，即某些函数不能通过单元测试进行测试。即使在成功完成所有单元测试之后;它不保证产品的正确操作。相同的函数可以在系统的少数部分中使用，而单元测试仅为一种用途而编写。

功能测试

这是一种黑盒测试，在这种测试中，只对产品的功能方面进行测试，而不查看代码。功能测试主要由专门的软件测试人员完成。它将包括正、负和BVA技术，使用非标准化数据来测试产品的指定功能。通过功能测试比通过单元测试以更好的方式进行测试覆盖。它使用应用程序GUI进行测试，因此更容易确定接口的特定部分具体负责什么，而不是确定代码是函数负责什么。

TLDR:

回答这个问题:单元测试是子类型的功能测试。

有两大组:功能和非功能性测试。我发现的最好的(非详尽的)说明是这个(来源:www.inflectra.com):

(1)单元测试:测试小段代码(函数/方法)。它可以被认为是(白盒)功能测试。

当功能放在一起时，你创建了一个模块=一个独立的部分，可能有一个可以测试的用户界面(模块测试)。一旦你有了至少两个独立的模块，然后你把它们粘在一起，然后就来了:

(2)集成测试:当你把两个或多个(子)模块或(子)系统放在一起，看看它们是否能很好地一起工作。

然后你整合了第3个模块，然后是第4和第5个模块，按照你或你的团队认为合适的顺序，一旦所有的拼图碎片放在一起，就完成了

(3)系统测试:测试SW作为一个整体。这几乎是“所有块的集成测试”。

如果没问题，那就来吧

(4)验收测试:我们建立什么客户要求实际上?当然，验收测试应该在整个生命周期中进行，不只是在最后阶段，当你意识到客户想要一辆跑车，你就造了一辆货车。

单元测试通常由开发人员完成。这样做的目的是确保他们的代码正常工作。一般的经验法则是使用单元测试覆盖代码中的所有路径。

功能测试:这是一个好的参考。功能测试说明

AFAIK，单元测试不是功能测试。让我用一个小例子来解释。您希望测试电子邮件web应用程序的登录功能是否正常工作，就像用户一样。为此，您的功能测试应该如下所示。

1- existing email, wrong password -> login page should show error "wrong password"!
2- non-existing email, any password -> login page should show error "no such email".
3- existing email, right password -> user should be taken to his inbox page.
4- no @symbol in email, right password -> login page should say "errors in form, please fix them!"

我们的功能测试是否应该检查我们是否可以使用无效输入登录?如。电子邮件没有@符号，用户名有多个点(只有一个点是允许的)，.com出现在@之前等等?一般来说，没有!这种测试会进入单元测试。

您可以检查单元测试中是否拒绝了无效输入，如下面的测试所示。

class LoginInputsValidator
method validate_inputs_values(email, password)
1-If email is not like string.string@myapp.com, then throw error.
2-If email contains abusive words, then throw error.
3-If password is less than 10 chars, throw error.

注意，功能测试4实际上做的是单元测试1所做的。有时，由于不同的原因，功能测试可能会重复单元测试所完成的部分(而不是全部)测试。在我们的例子中，我们使用功能测试4来检查特定出现错误消息在输入无效输入时是否存在。我们不想测试是否所有坏的输入都被拒绝了。这就是单元测试的工作。

我们可以很简单地说:

• 黑盒:用户界面测试，比如功能测试
• 白盒:类似单元测试的代码测试

阅读更多在这里。

测试类型

• Unit testing -在Procedural programming单元中是一个过程，在Object oriented programming单元中是一个类。单元是隔离的，反映开发人员的角度
• Functional testing -大于Unit。用户的角度，它描述了一个特性、用例、故事……
  • Integration testing -检查是否所有单独开发的components一起工作。它可以是其他应用程序、服务、图书馆、数据库、网络等。
    • 使用Narrow integration test - double<一口>[对]< /一口>。主要目的是检查组件是否以正确的方式配置
    • Broad integration test(端到端测试，系统测试)-活动版本。主要目的是检查所有组件是否以正确的方式配置
  • UI testing -检查用户输入是否触发了正确的操作，当某些操作发生时UI是否被改变
  • .．.
• Non functional testing -其他情况
  • Performance testing -计算速度和其他指标
  • __abc0 - ux
  • .．.