# 测试类型 URL: https://deploy-preview-2974--selenium-dev.netlify.app/zh-cn/documentation/test_practices/testing_types/ --- ### 验收测试 进行这种类型的测试以确定功能或系统是否满足客户的期望和要求. 这种测试通常涉及客户的合作或反馈, 是一种验证活动, 可以用于回答以下问题： >我们是否在制造 **_正确的_** 产品? 对于Web应用程序, 可以通过模拟用户期望的行为 直接使用Selenium来完成此测试的自动化. 可以通过记录/回放, 或通过本文档中介绍的各种支持的语言来完成此类模拟. 注意：有些人可能还会提到, 验收测试是 **_功能测试_** 的子类型. ### 功能测试 进行这种类型的测试是为了确定功能或系统是否正常运行而没有问题. 它会在不同级别检查系统, 以确保涵盖所有方案并且系统能够执行预期的 _工作_ . 这是一个验证活动, 它回答了以下问题： >我们是否在 **_正确地_** 制造产品？ 这通常包括： 测试没有错误 (404, 异常…) , 以可用的方式 (正确的重定向) 正常运行, 以可访问的方式并匹配其规格 (请参见前述的 **_验收测试_** ) . 对于Web应用程序, 可以通过模拟预期的结果, 直接使用Selenium来完成此测试的自动化. 可以通过记录/回放或通过本文档中说明的各种支持的语言来完成此模拟. ### 性能测试 顾名思义, 进行性能测试是为了衡量应用程序的性能. 性能测试主要有两种类型: #### 负载测试 进行了负载测试, 以验证应用程序在各种特定的负载 (通常是同时连接一定数量的用户) 下的运行状况 >For example, **_Testing that the site can handle numerous orders/users at once._** #### 压力测试 进行压力测试, 以验证应用程序在压力 (或高于最大支持负载) 下的运行状况. >For example, **_Testing that your ecommerce site can handle Black Friday_** 通常, 性能测试是通过执行一些Selenium书写的测试来完成的, 这些测试模拟了不同的用户 使用Web应用程序的特定功能 并检索了一些有意义的指标. 通常, 这是由其他检索指标的工具完成的. **_JMeter_** 就是这样一种工具. 对于Web应用程序, 要测量的详细信息包括 吞吐量、 延迟、数据丢失、单个组件加载时间... 注意1：所有浏览器的开发人员工具 均具有“性能”标签 (可通过按F12进行访问) 注2：这属于 **_非功能测试_** 的类型, 因为它通常是按系统而不是按功能/特征进行测量. ### 回归测试 此测试通常在修改, 修复或添加功能之后进行. 为了确保所做的更改没有破坏任何现有功能, 将再次执行一些已经执行过的测试. >For example, **_Testing that your new search bar doesn't break the other buttons on the menu_** 重新执行的测试集可以是全部或部分, 并且可以包括几种不同的类型, 具体取决于具体的应用程序和开发团队. ### 测试驱动开发 (TDD) TDD本身不是一种测试类型, 而是一种迭代开发方法, 用于测试驱动功能的设计. 每个周期都从创建功能应通过的一组单元测试开始 (这将使首次执行失败) . 此后, 进行开发以使测试通过. 在另一个周期开始再次执行测试, 此过程一直持续到所有测试通过为止. 如此做的目的是基于以下情况, 既缺陷发现的时间越早成本越低, 从而加快了应用程序的开发. ### 行为驱动开发 (BDD) BDD还是基于上述 (TDD) 的迭代开发方法, 其目的是让各方参与到应用程序的开发中. 每个周期都从创建一些规范开始 (应该失败) . 然后创建会失败的单元测试 (也应该失败) , 之后着手开发. 重复此循环, 直到所有类型的测试通过. 为此, 使用了规范语言. 因为简单、标准和明确, 各方都应该能够理解. 大多数工具都使用 **_Gherkin_** 作为这种语言. 目标是为了解决潜在的验收问题, 从而能够检测出比TDD还要多的错误, 并使各方之间的沟通更加顺畅. 当前有一组工具可用于编写规范 并将其与编码功能 (例如 **_Cucumber_** 或 **_SpecFlow_** ) 匹配. 在Selenium之上构建了一系列工具, 可通过将BDD规范直接转换为可执行代码, 使得上述过程更为迅速. 例如 **_JBehave, Capybara 和 Robot Framework_**.