验收测试和功能测试的区别？

Posted 2023-02-16

【中文标题】验收测试和功能测试的区别？

【英文标题】：Difference between acceptance test and functional test?

【发布时间】：2011-03-23 04:05:11

【问题描述】：

验收测试和功能测试的真正区别是什么？

每个项目的亮点或目标是什么？在我读到的所有地方，它们都模棱两可地相似。

【参考方案1】：

在我的世界里，我们使用以下术语：

功能测试：这是一个验证活动；我们是否构建了一个正常工作的产品？软件是否满足业务需求？

对于这种类型的测试，我们的测试用例涵盖了我们能想到的所有可能场景，即使该场景不太可能存在于“现实世界”中。在进行此类测试时，我们的目标是最大化代码覆盖率。我们使用我们当时可以获取的任何测试环境，它不必是“生产”口径，只要它可用即可。

验收测试：这是一个验证活动；我们建造了正确的东西吗？这是客户真正需要的吗？

这通常与客户合作完成，或由内部客户代理（产品所有者）完成。对于这种类型的测试，我们使用的测试用例涵盖了我们期望使用该软件的典型场景。此测试必须在“类似生产”的环境中进行，在与客户将使用的硬件相同或接近的硬件上进行。这就是我们测试我们的“能力”的时候：

可靠性、可用性：通过压力测试验证。

可扩展性：通过负载测试验证。

可用性：通过检查和向客户演示验证。 UI 配置是否符合他们的喜好？我们是否将客户品牌放在了所有正确的位置？我们有他们要求的所有字段/屏幕吗？

安全性 （又名，安全性，只是为了适应）：通过演示验证。有时客户会聘请外部公司进行安全审计和/或入侵测试。

可维护性：通过我们将如何交付软件更新/补丁的演示进行验证。

可配置性：通过演示客户如何修改系统以满足他们的需求进行验证。

这绝不是标准的，我认为没有“标准”定义，正如这里相互矛盾的答案所表明的那样。对您的组织而言，最重要的是准确定义这些术语并遵守它们。

【讨论】：

加 1 以获得好的答案和“又名，安全性，只是为了适应”:)。有趣的事情:) SO 团队没有考虑到这样一个事实，即在现实世界中，有人可能会像我一样用真实的单词替换 + 符号。所以他们不允许在评论中输入+1作为第一个单词，但他们允许“加1”:)。因此，在功能上，他们未能正确测试:)。 Myabe 他们刚刚尝试了验收测试 :)

【参考方案2】：

我喜欢 Patrick Cuff 的回答。我想补充的是 test level 和 test type 之间的区别，这让我大开眼界。

测试级别

测试级别使用V-model很容易解释，例如： 每个测试级别都有其对应的开发级别。它具有典型的时间特性，它们在开发生命周期的某个阶段执行。

组件/单元测试 => 验证详细设计 组件/单元集成测试 => 验证全局设计 系统测试 => 验证系统要求 系统集成测试 => 验证系统要求 验收测试 => 验证用户需求

测试类型

一个测试类型是一个特征，它专注于一个特定的测试目标。 测试类型强调您的质量方面，也称为技术或非功能方面。 测试类型 可以在任何测试级别执行。我喜欢使用 ISO/IEC 25010:2011 中提到的质量特性作为测试类型。

功能测试 可靠性测试 性能测试 可操作性测试 安全测试 兼容性测试 可维护性测试 可迁移性测试

让它完整。还有一种叫做回归测试的东西。这是测试级别和测试类型旁边的额外分类。 回归测试是您想要重复的测试，因为它涉及到您产品中的一些关键问题。它实际上是您为每个测试级别定义的测试子集。如果您的产品中有一个小错误修复，那么人们并不总是有时间重复所有测试。 回归测试就是对此的回答。

【讨论】：

这是这个问题的最佳答案，“测试级别和测试类型之间的区别”是大多数答案在这里忽略的东西，你说得对，它是“大开眼界”

【参考方案3】：

区别在于测试问题和解决方案。软件是解决问题的方法，两者都可以测试。

功能测试确认软件在您解决问题的方式范围内执行功能。这是开发软件不可或缺的一部分，可与批量生产的产品在出厂前进行的测试相媲美。功能测试可验证产品是否确实像您（开发人员）认为的那样工作。

验收测试验证产品确实解决了它要解决的问题。这最好由用户（客户）完成，例如执行软件协助完成的他/她的任务。如果该软件通过了这个真实世界的测试，它就可以取代以前的解决方案。这种验收测试有时只能在生产中正确完成，特别是如果您有匿名客户（例如网站）。因此，新功能只有在使用数天或数周后才会被接受。

功能测试 - 测试产品，验证它是否具备您设计或构建的品质（功能、速度、错误、一致性等）

验收测试 - 在产品的上下文中测试产品，这需要（模拟）人机交互，测试它对原始问题的预期效果。

【讨论】：

这是我在这个问题上最喜欢的答案。问题和解决方案之间的区别有助于使这种区别更加清晰。

【参考方案4】：

答案是意见。我在很多项目中工作过，并且担任过测试经理和问题经理，所有不同的角色和不同书籍中的描述都不同，所以这里是我的变体：

功能测试：从功能的角度考虑业务需求并对其进行全面彻底的测试。

验收测试：“付费”客户进行他喜欢做的测试，以便接受交付的产品。这取决于客户，但通常测试不如功能测试那么彻底，特别是如果它是一个内部项目，因为利益相关者会审查并信任在早期测试阶段完成的测试结果。

正如我所说，这是我的观点和经验。功能测试是系统的，验收测试是业务部门测试的东西。

【讨论】：

我喜欢这个答案 :) 它们几乎是一回事。

UAT 最终是由“付费”客户完成的。然而，大多数时候首先由一个“优秀”的 QA 人员完成，他通过测试和“尝试”破坏系统并在“付费”客户接触之前寻找所有“小”东西。用于重复乏味事情的 Selenium 自动化也可以与 QA 测试人员的真正 UAT 测试一起使用，但永远不要重复真正的测试来测试所有预期浏览器的所有预期功能。 UAT 是非常不言自明的。我认为大多数功能测试描述似乎都是机器人和字典。

正如我所说，这是我如何解释这些术语的经验。

没关系。当我注意到这个模糊的定义时......我只需要评论“功能测试：接受业务需求并从功能的角度对所有需求进行良好和彻底的测试。”

哈哈，是的，现在我理解你了。好吧，这是你可以写一整本书的东西。写这篇文章的那一刻，我不想过多讨论。

【参考方案5】：

观众。功能测试是为了确保开发软件的团队成员能够按照他们的期望进行。验收测试是为了向消费者保证它满足他们的需求。

范围。功能测试一次只测试一个组件的功能。验收测试涵盖了产品的任何对消费者来说重要到足以在接受软件之前进行测试的方面（即任何值得花费时间或金钱来测试它以确定其可接受性的东西）。

软件可以通过功能测试、集成测试和系统测试；只有当客户发现这些功能不能满足他们的需求时才会通过验收测试。这通常意味着有人搞砸了规范。软件也可能无法通过某些功能测试，但通过验收测试，因为客户愿意处理一些功能错误，只要该软件能够很好地完成他们需要的核心事情（测试版软件通常会在它之前被一部分用户接受）功能齐全）。

【参考方案6】：

功能测试：应用源自指定功能的测试数据 不考虑最终程序结构的要求。也被称为 黑盒测试。

验收测试： 为确定系统是否满足其验收标准而进行的正式测试——使最终用户能够确定是否 接受系统。

【参考方案7】：

在我看来，主要区别在于谁说测试是成功还是失败。

功能测试测试系统是否满足预定义的要求。由负责开发系统的人员执行和检查。

验收测试由用户签署。理想情况下，用户会说出他们想要测试的内容，但在实践中，由于用户没有投入足够的时间，因此很可能是功能测试的落日。请注意，此视图来自我与其他用户组打交道的业务用户，例如航空和其他安全关键可能没有这种区别，

【讨论】：

验收测试将确定系统是否满足给定用例或所有可想象用例的验收标准。它通常由专家用户执行以确定系统是否可以接受。在航空学中，试飞员是通过特定动作来测试新飞机的飞行员。***飞行员、导航员和工程师进行飞行测试，并在测试任务结束时提供评估和认证数据。

【参考方案8】：

Acceptance testing:

... 是在交付之前对系统（例如软件、大量制造的机械零件或成批的化学产品）进行的黑盒测试。

虽然这继续说：

也称为功能测试、黑盒测试、发布验收、QA 测试、应用程序测试、置信度测试、最终测试、验证测试或工厂验收测试

带有“需要引用”标记。

Functional testing（实际上重定向到系统测试）：

在一个完整的集成系统上进行，以评估系统是否符合其指定要求。系统测试属于黑盒测试的范围，因此不需要了解代码或逻辑的内部设计。

所以从这个定义来看，它们几乎是一回事。

根据我的经验，验收测试通常是功能测试的一个子集，由客户在正式签署过程中使用，而功能/系统测试将由开发人员/QA 部门运行。

【参考方案9】：

验收测试只是客户进行的测试，包括其他类型的测试：

功能测试：

“此按钮不起作用”

非功能测试：

“此页面可以运行，但速度太慢”

对于功能测试与非功能测试（它们的子类型） - 请参阅我对此 SO question 的回答。

【参考方案10】：

两者的关系： 验收测试通常包括功能测试，但也可能包括附加测试。例如检查标签/文件要求。

功能测试是指将被测产品置于测试环境中，该测试环境可以产生各种刺激（在测试范围内），而目标环境通常会产生甚至超过目标环境产生的刺激，同时检查被测设备的响应。

对于物理产品（而非软件），有两种主要的验收测试：设计测试和制造测试。设计测试通常使用大量已通过制造测试的产品样品。不同的消费者可能会以不同的方式测试设计。

当根据产品规范对设计进行测试时，验收测试称为验证，当产品放置在消费者的真实环境中时，验收测试称为验证。

【参考方案11】：

它们是一样的。

在系统部署或交付之前，在尽可能与实际生产/部署环境相同的完整系统上执行验收测试。

您可以自动或手动进行验收测试。

【讨论】：

虽然 Selenium 和 Watin（或 Watir）等自动化是非常有价值的第一道防线，但没有什么能比一个训练有素的质量保证人员更能“打破系统”。自动化很棒，但是随着 AJAX 和 javascript 框架的现代发展以及页面输出的变化，自动化一切是脚本更新的噩梦。它们不是一回事