请参阅单个用例或示例，以举例说明该示例的每个单元，功能，验收和集成测试。
我们有理论，但实际示例可以帮助您进一步理解概念。
答案 0 :(得分：0)
举一个实际的例子，让我们考虑一个在英国出售服装的电子商务平台。以下是此示例的几个要求：
显然，这不是一套完整的要求，但足以说明要点。
单位
单元测试涵盖了最小的代码单元。假设实现包含一种计算特定篮子税额的方法。以下是单元测试的示例： -正确计算成人服装的税金 -正确计算童装税 -正确计算成人和儿童服装篮子的税金
这些测试将准备与要测试的案例相匹配的篮子，然后调用calculateTax方法并检查返回的结果。
通常由开发团队执行。
功能性
对同一段代码进行功能测试将考虑整个系统。您可能具有与单元测试相同的测试用例，但对于功能而言，它们将从用户界面（在这种情况下为Web UI）触发，并在网页上检查结果。
这时，您将继续拥有非常特定（或详细）的测试用例，它们正在检查一组特定功能。
这通常是由质量检查小组完成的。
接受
验收测试通常集中在特定的用例上。它允许客户或企业所有者检查产品是否适合目标用途。在这种情况下，验收测试可能是：
这通常是由企业主完成的。
集成
集成测试很难定义，因为在实践中它可能会发生巨大变化。
集成测试可能基本上是功能测试的一部分，而没有被分离到一个单独的阶段。也有可能对购物篮实现和付款实现进行测试，以确保两个组件一起工作（无需系统的其余部分）。
根据我的经验，大多数公司将在单元测试中测试小型组件的集成，并在功能测试中测试整个解决方案的集成。
答案 1 :(得分：0)
我将在下面的示例中解释测试的不同级别。
迈克·科恩（Mike Cohn）在其著作《敏捷的成功》中提出了“ Testing Pyramid”，作为在项目中进行自动化测试的一种方法。
该模型说明了需要创建哪种自动测试，它们可以多快的速度就被测应用程序提供反馈，以及由谁编写这些测试。 任何项目基本上都需要3个级别的自动化测试，它们如下。
单元测试- 它们测试您的软件应用程序的最小组成部分。从字面上看，这可能是代码中的一个函数，该代码根据某些输入来计算值。此功能是构成应用程序的硬件/软件代码库的其他几个功能的一部分。
例如-让我们以基于网络的计算器应用程序为例。该应用程序中需要进行单元测试的最小组件可能是执行加法的功能，另一个执行减法的功能，依此类推。所有这些小的功能组合在一起构成了计算器应用程序。
从历史上看，开发人员通常以与软件应用程序相同的编程语言来编写这些测试。为此，使用了单元测试框架，例如JUnit和NUnit（用于Java），MSTest（用于C＃和.NET）和Jasmine / Mocha（用于JavaScript）。
单元测试的最大优点是，它们在UI下运行得非常快，我们可以快速获得有关应用程序的反馈。这应该占您自动化测试的50％以上。
API /集成测试- 这些一起测试软件系统的各个组件。这些组件可能包括测试数据库，API（应用程序编程接口），第三方工具和服务以及应用程序。
例如-在上面的计算器示例中，Web应用程序可以使用数据库来存储值，使用API进行一些服务器端验证，并且它可以使用第三方工具/服务将结果发布到云中以使其完成可在不同平台上使用。
从历史上看，开发人员或技术质量检查人员会使用各种工具（例如Postman，SoapUI，JMeter和其他工具（如Testim））编写这些测试。
它们比UI测试运行得快得多，因为它们仍在引擎盖下运行，但可能要比单元测试花费更多的时间，因为它必须检查系统各个独立组件之间的通信并确保它们具有无缝集成。这应该占自动化测试的30％以上。
UI测试- 最后，我们有测试来验证应用程序的UI。通常将这些测试编写为测试通过应用程序的端到端流程。
例如-在计算器应用程序中，端到端流程可能是打开浏览器->输入计算器应用程序url->使用用户名/密码登录->打开计算器应用程序->执行一些操作在计算器上->从UI验证这些结果->注销应用程序。这可能是一个端到端的流程，将是UI自动化的一个很好的选择。
从历史上看，技术质量检查人员或手动测试人员会编写UI测试。他们使用Selenium之类的开源框架或Testim之类的UI测试平台来编写，执行和维护测试。通过查看屏幕截图，日志和测试报告，您可以查看测试的运行方式，预期结果与实际结果之间的差异，这些测试提供了更多的视觉反馈。
UI测试的最大限制是，与单元和API级别的测试相比，它们相对较慢。因此，它应该只占整个自动化测试的10-20％。
您已经提到过功能测试，根据您编写测试的方式的上下文，它可能属于API和UI级别的测试。
-Raj