软件测试有两类；功能和非功能测试。在本文中，我描述了几种功能测试类型
功能测试和非功能测试是软件测试的两种类型。有多种类型的功能测试，如下所示：
- 单元测试
- 集成测试
- 系统测试
- 回归测试
- 冒烟测试
- 健全性测试
- 验收测试
- 用户验收测试
单元测试确保在一个段中编写的每一段代码都能产生最佳结果。开发人员在单元测试期间只看接口和确定部件。它提供了代码进展的文档，因为每个代码单元在继续下一个之前都经过了彻底的测试。
集成测试至少对软件的两个单元测试元素进行协调和测试，以确保它们的通信是准确的。
集成测试可以通过三种不同的方式执行：
- 自上而下的方法：首先评估来自控制流的高层或设计配置所建议的模块，然后是低层模块。如果低级模块不可用，则使用存根。
- 首先尝试低级模块，然后逐步添加重要的模块，这与自上而下的过程相反。如果高级模块不可用，则使用驱动程序。
- 自上而下和自下而上的方法结合在一种混合方法中。在这两个级别上，测试开始并在中间级别合并。
框架的所有组件都是连接的，并且针对所需的细节（功能或系统）测试框架的一致性和正确性。
这是一种黑盒测试方法，为协调系统开了绿灯。在 STLC 中，它总是在用户验收测试 (UAT)（软件测试生命周期）之前进行测试。系统测试是在几乎真实的环境中进行的，并根据实际使用情况进行。
回归测试事实证明，在开发人员进行特定升级或代码更新后运行复发测试套件至关重要。急于重现以确保这些代码修改没有妨碍当前的工作功能或在代码中引入任何新缺陷。回归实验是当前功能测试的一个子集，涵盖了系统最重要的特性。应用程序修改应刷新、添加和删除回归案例。
因为它们经常运行并且需要时间来执行，所以回归测试用例是自动化测试的最佳选择。
可以通过以下三种方式之一选择要运行的回归测试用例：
- 完成复发测试套件。
- 选择复发套件的高需求试验。
- 从重复套件中选择将用于测试因代码更改而发现的功能的案例。
在事态发展之后，当发布新表单时，会在应用程序上执行冒烟测试，以确保所有重要的功能从头到尾都能正常工作。冒烟测试通常针对在开发初期为尚不稳定的应用程序创建的原型进行。在测试期间，如果任何重要的有用性未按预期工作，则丢弃该特定形式。设计人员必须修复错误并创建新表单以进行进一步测试。
健全性稳定性测试选自回归测试套件并涵盖关键应用程序功能。健全性测试是在工程师设计的新表格上执行的，以便在一定程度上保持一致。当应用程序成功通过健全性测试时，它就可以进入下一个测试级别。不难混淆烟雾和合理的健全性测试。冒烟测试用于在完成另一个表单后测试底层应用程序。健全性测试是在多次部署后在类似的应用程序上完成的，并且只要它恢复了健全性。
验收测试最终用户对应用程序的接受在验收测试期间进行测试。此测试的目标是确保构建的框架满足在制定业务需求后建立的所有需求。它发生在系统测试之后不久和应用程序最终到达现实之前。确认测试是客户接受或拒绝框架的基础。这是一种黑盒测试技术，因为我们只对了解该软件为市场和真实用户做好准备的程度感兴趣。
用户验收测试用户验收测试 (UAT) 是一种测试，其中最终用户或客户在将软件系统转移到生产环境之前对其进行验证和接受。在功能、集成和系统测试之后，在测试的最后一步执行 UAT。
- Alpha 测试 - 由有才华的测试人员在开发人员的站点上执行。
- Beta 测试- 真正的用户在客户的站点执行 Beta 测试。
在我看来，功能测试对于将客户对客户需求的理解转化为满足这些目标的应用程序至关重要。发布具有重大功能缺陷的程序的后果可能很严重。当所有上述类型的功能测试在开发过程中的适当时间进行时，功能测试能够交付高质量的产品。
喜欢的朋友欢迎转发、关注~
,
