【问题标题】:What is the difference between unit tests and functional tests?单元测试和功能测试有什么区别?
【发布时间】:2011-02-14 01:42:31
【问题描述】:

单元测试和功能测试有什么区别?单元测试也可以测试功能吗?

【问题讨论】:

标签: unit-testing testing functional-testing


【解决方案1】:

单元测试告诉开发人员代码做对了;功能测试告诉开发人员代码在做正确的事情

您可以在Unit Testing versus Functional Testing阅读更多内容


单元测试和功能测试的一个很好解释的现实类比可以描述如下,

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

单元测试类似于检查房屋建筑工地的建筑检查员。他专注于房屋的各种内部系统、地基、框架、电气、管道等。他确保(测试)房屋的各个部分将正确和安全地工作,即符合建筑规范。

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

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

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


总结一下,

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

功能测试是从用户的角度编写的。他们确保系统按用户期望的方式运行

【讨论】:

  • 对于这个概念的新手来说,这句话有点含糊。
  • @fig-gnuton,我试图详细说明希望不要使描述含糊不清。在链接中他们提供了一个很好的例子,如果您认为这可能有助于 OP,我可以用引号更新答案。
  • 也许换一种说法,“单元测试确保代码执行程序员想要的操作,功能测试确保程序员执行客户想要执行的操作”?
  • 我喜欢这样,但会调整到。 功能测试确保应用程序允许用户执行操作。 单元测试确保代码的行为符合程序员的期望。
  • 程序员想要的不就是最终用户想要的吗?为什么要编写一个不能满足客户期望的测试?
【解决方案2】:

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

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

【讨论】:

  • 让我不同意“AKA 集成测试”。集成测试,检查代码中 2 个或更多系统/子系统之间的集成。例如,通过 ORM 检查 SQL 查询,检查 ORM 和数据库是否协同工作。功能测试又名端到端恕我直言。
  • 我同意@graffic 功能测试!= 集成测试您一定会混淆系统子组件之间的“集成”,例如持久状态等。但总的来说,集成测试有很多范围更广。
  • 不,对任何事情都没有感到困惑。
  • 集成测试 IS-A 功能测试。但反之亦然。谷歌“功能和非功能测试”并检查“图像”。
  • 这个答案是完全错误的!功能测试甚至不接近集成测试..
【解决方案3】:
  • 单元测试测试一个独立的行为单元。什么是行为单位?它是系统中可以独立进行单元测试的最小部分。 (这个定义实际上是循环的,IOW 它真的不是一个定义根本,但它在实践中似乎工作得很好,因为你可以直观地理解它。)

    李>
  • 功能测试测试一个独立的功能。


  • 一个行为单元非常小:虽然我绝对不喜欢这种愚蠢的“每个方法一个单元测试”的口头禅,但从 size 的角度来看它是正确的。行为单元是方法的一部分和几个方法之间的某种东西。最多一个对象,但不超过一个。

  • 一项功能通常包含许多方法并跨越多个对象,并且通常跨越多个架构层。


  • 单元测试类似于:当我调用validate_country_code() 函数并将国家代码'ZZ' 传递给它时,它应该返回false

  • 1234563 /p>

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

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


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

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


【讨论】:

  • 优秀的答案!一件事 - “功能测试不应该在主要版本中改变”为什么会这样?
  • @Lazer, @cdeszaq:在许多项目中,主要版本号的更改用于指示向后不兼容,如果主要版本向后更改,则使用 OTOH -兼容性是保证。 “向后兼容”是什么意思?这意味着“不会改变用户可见的行为”。功能测试是用户可见行为规范的可执行编码。因此,如果主编号不变,则功能测试也不允许更改,反之,如果功能 tets确实发生更改,则主编号必须 也要改变。
  • 注意:我没有说添加功能测试!添加以前不存在的功能是否构成向后不兼容的更改,取决于项目。对于最终用户软件,可能不是。但是对于编程语言呢?也许:例如,引入一个新关键字会使当前工作的程序碰巧使用该关键字作为变量名无效,因此是向后不兼容的更改。
  • @JörgWMittag 喜欢这个想法:'功能测试是用户可见行为规范的可执行编码'......无论其他超级专家是否真的同意,它都对我有帮助问题,即“他们之间的区别”
  • "功能测试是:当我填写带有 ZZ 国家代码的运输表格时,我应该被重定向到一个帮助页面,该页面允许我从菜单中选择我的国家代码。 "这有点挑剔,但我称之为“验收测试”。功能测试将测试在运输表单上输入 ZZ 是否会将用户转发到正确的 URL 或引发特定的异常或错误。
【解决方案4】:

TLDR:

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


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

(1) 单元测试: 测试小sn-ps 的代码(函数/方法)。它可以被视为(白盒)功能测试。

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

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

然后您集成第 3 个模块,然后按您或您的团队认为合适的任何顺序集成第 4 和第 5 个模块,一旦所有拼图块放在一起,就会出现

(3) 系统测试: 测试整个软件。这几乎是“所有部分的集成测试”。

如果没问题,那就来

(4) 验收测试:我们是否构建了客户实际要求的内容? 当然,验收测试应该在整个生命周期中进行,而不仅仅是在您意识到客户想要一辆跑车并且您制造了一辆面包车的最后阶段。

【讨论】:

  • 我在google上看到很多这样的图片,将“单元测试”描述为“功能测试”的一种。但是为什么这里的其他答案描述了完全不同的概念:“功能测试”是端到端的测试,而单元测试不是功能测试?我很困惑。有两种不同的“宗教”以不同的方式定义“功能测试”一词还是什么?
  • 答案(即使是高度赞成的)也可能是错误的;)
  • 我喜欢这张图片,但是对于系统集成测试,拼图应该看起来是“完整的”,没有更多的地方可以连接其他部分。
  • @JonathonReinhart - 不一定。开放的边缘可以表示具有新功能的系统易于扩展,这在使用像敏捷这样的开发方法时特别有用。
  • 从以上多个相互矛盾的答案来看,Functional Test 显然不是一个标准化术语,对不同的人有不同的含义。
【解决方案5】:

“功能测试”并不意味着您正在测试代码中的功能(方法)。这通常意味着您正在测试系统功能——当我在命令行运行foo file.txt 时,file.txt 中的行可能会颠倒过来。相比之下,单个单元测试通常涵盖单个方法的单个案例——length("hello") 应该返回 5,length("hi") 应该返回 2。

另见IBM's take on the line between unit testing and functional testing

【讨论】:

  • 嗯,很有趣,但是您显示的链接意味着不同的东西:功能是关于通过实现执行的功能,即从用户的角度进行测试,这是用户的功能。
【解决方案6】:

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

单元测试是测试级别之一,功能测试是测试类型。

基本上:

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

同时

组件测试,也称为单元、模块和程序测试, 搜索缺陷并验证软件的功能 (例如模块、程序、对象、类等)是分开的 可测试。

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

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

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

【讨论】:

  • 我同意太多的绒毛,但无论如何他们是最大的参与者,这个问题是关于理论的,所以我认为 ISTQB 应该足够好。
【解决方案7】:

在 Rails 中,unit 文件夹用于保存模型的测试,functional 文件夹用于保存控制器的测试,而 integration 文件夹用于保存涉及任意数量的控制器交互的测试。夹具是一种组织测试数据的方式;它们位于fixtures 文件夹中。 test_helper.rb 文件包含测试的默认配置。 你可以访问this

【讨论】:

    【解决方案8】:

    我们可以很简单地说:

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

    阅读更多here

    【讨论】:

      【解决方案9】:

      我的想法是这样的:单元测试确定代码执行您希望代码执行的操作(例如,您想添加参数 a 和 b,实际上是添加它们,而不是减去他们),功能测试测试所有代码一起工作以获得正确的结果,以便您希望代码执行的操作实际上在系统中得到正确的结果。

      【讨论】:

        【解决方案10】:

        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 来检查输入无效输入时是否出现特定的错误消息。我们不想测试是否所有错误的输入都被拒绝。这就是单元测试的工作。

        【讨论】:

        • 关于功能测试的优点通常比单元测试的范围要窄得多(就功能测试而言,更侧重于从本质上证明预期功能已实现),但我想说它们有点描述不同的维度(单元测试中的组成与功能测试中的目的);有些单元测试是功能测试,有些功能测试是单元测试,但也有很多维恩不重叠。
        • 功能测试范围内和不在范围内的好例子。
        【解决方案11】:

        单元测试

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

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

        功能测试

        这是一种黑盒测试,无需查看代码即可对产品的功能方面进行测试。功能测试主要由专门的软件测试人员完成。它将包括正面、负面和 BVA 技术,使用非标准化数据来测试产品的特定功能。与单元测试相比,功能测试以改进的方式进行测试覆盖。它使用应用程序 GUI 进行测试,因此更容易确定接口的特定部分到底负责什么,而不是确定一个代码负责什么功能。

        【讨论】:

          【解决方案12】:

          测试类型

          • Unit testing - Procedural programming 中的单元是一个过程,Object oriented programming 中的单元是一个类。单元是孤立的,反映了开发人员的观点
          • Functional testing - 超过 Unit用户视角,描述功能、用例、故事...
            • Integration testing - 检查所有单独开发的 components 是否一起工作。它可以是其他应用程序、服务、库、数据库、网络等。
              • Narrow integration test - 使用 double[About]。主要目的是检查组件是否配置正确
              • Broad integration test(端到端测试,系统测试)- 实时版本。主要目的是检查所有组件是否配置正确
            • UI testing - 检查用户输入是否触发了正确的操作,并在某些操作发生时更改 UI
            • ...
          • Non functional testing - 其他情况
            • Performance testing - 计算速度和其他指标
            • Usability testing - 用户体验
            • ...

          [iOS tests]
          [Android tests]

          【讨论】:

            【解决方案13】:

            单元测试:- 单元测试专门用于在产品开发过程中逐个组件地测试产品。 Junit 和 Nunit 类型的工具也将帮助您按照单元测试产品。 **与其在集成后解决问题,不如在开发早期解决问题。

            功能测试:- 至于测试,有两种主要类型的测试: 1.功能测试 2.非功能测试。

            非功能测试是一种测试,测试人员将测试产品将执行客户未提及但那些质量属性应该存在的所有质量属性。 喜欢:-性能、可用​​性、安全性、负载、压力等。 但在 功能测试 中:- 客户已经提出了他的要求并且这些要求已正确记录,测试人员的任务是交叉检查应用程序功能是否按照建议的系统执行。 为此,测试人员应使用提议的系统测试已实现的功能。

            【讨论】:

              【解决方案14】:

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

              功能测试:这是一个很好的参考。 Functional Testing Explanation

              【讨论】:

              • 请将最重要的文字粘贴到您的答案中,您永远不知道页面何时会被删除,从而导致链接无效。
              【解决方案15】:

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

              功能测试是从用户的角度编写的。他们确保系统按用户期望的方式运行。

              【讨论】:

                猜你喜欢
                • 2011-06-21
                • 1970-01-01
                • 1970-01-01
                • 2011-04-09
                • 2011-07-18
                • 1970-01-01
                • 1970-01-01
                • 2011-03-23
                相关资源
                最近更新 更多