测试过程中有不同的级别。在本章中，将简要介绍这些级别。

测试级别包括在进行软件测试时可以使用的不同方法。软件测试的主要水平是-

• 功能测试

• 非功能测试

功能测试

这是一种黑盒测试，它基于要测试的软件的规范。通过提供输入来测试应用程序，然后检查结果是否符合其预期的功能。在完整的集成系统上进行软件的功能测试，以评估系统是否符合其特定要求。

测试应用程序的功能时，涉及五个步骤。

有效的测试实践将把上述步骤应用于每个组织的测试策略，因此，它将确保组织在软件质量方面保持最严格的标准。

单元测试

开发人员会在将设置移交给测试团队以正式执行测试用例之前执行这种类型的测试。单元测试由相应的开发人员在分配源代码区域的各个单元上执行。开发人员使用的测试数据与质量保证团队的测试数据不同。

单元测试的目的是隔离程序的每个部分，并表明各个部分在需求和功能方面都是正确的。

单元测试的局限性

测试无法捕获应用程序中的每个错误。无法评估每个软件应用程序中的每个执行路径。单元测试也是如此。

开发人员可以用来验证源代码的方案和测试数据的数量受到限制。在用尽所有选项之后，别无选择，只能停止单元测试并将代码段与其他单元合并。

整合测试

集成测试被定义为应用程序的组合的部件的测试，以确定它们是否正确函数。可以通过两种方式完成集成测试：自下而上的集成测试和自上而下的集成测试。

在全面的软件开发环境中，通常先进行自下而上的测试，然后再进行自上而下的测试。该过程以对整个应用程序的多次测试结束，最好是在旨在模拟实际情况的方案中。

系统测试

系统测试对整个系统进行测试。集成所有组件后，将对整个应用程序进行严格测试，以确保其符合指定的质量标准。这种测试由专业的测试团队执行。

由于以下原因，系统测试很重要-

• 系统测试是软件开发生命周期中的第一步，其中对应用程序进行了整体测试。

• 对该应用程序进行了全面测试，以验证其是否符合功能和技术规范。

• 在非常接近将部署应用程序的生产环境的环境中测试了该应用程序。

• 系统测试使我们能够测试，验证和确认业务需求以及应用程序体系结构。

回归测试

每当对软件应用程序进行更改时，应用程序中的其他区域很可能已受到此更改的影响。执行回归测试以验证已修复的错误没有导致其他功能或业务规则违规。回归测试的目的是确保诸如错误修复之类的更改不会导致应用程序中发现另一个错误。

回归测试很重要，因为以下原因-

• 当必须对进行了更改的应用程序进行测试时，可以最大程度地减少测试间隙。

• 测试新的更改，以验证所做的更改不会影响应用程序的任何其他区域。

• 在应用程序上执行回归测试时，降低风险。

• 在不影响时间表的情况下增加了测试范围。

• 提高产品上市速度。

验收测试

可以说，这是最重要的测试类型，因为它是由质量保证团队进行的，该团队将评估应用程序是否符合预期的规格并满足客户的要求。质量检查团队将具有一组预编写的方案和测试用例，这些方案和测试用例将用于测试应用程序。

将分享有关该应用程序的更多想法，并可以对其进行更多测试以评估其准确性以及启动该项目的原因。验收测试不仅旨在指出简单的拼写错误，修饰错误或界面空白，而且还指出应用程序中可能导致系统崩溃或应用程序重大错误的所有错误。

通过对应用程序执行验收测试，测试团队将减少应用程序在生产中的性能。接受系统还有法律和合同要求。

阿尔法测试

该测试是测试的第一阶段，将在团队(开发人员和质量检查团队)中进行。单元测试，集成测试和系统测试结合在一起时称为alpha测试。在此阶段，将在应用程序中测试以下方面-

• 拼写错误

• 链接断开

• 多云方向

• 该应用程序将在规格最低的计算机上进行测试，以测试加载时间和任何延迟问题。

Beta测试

在成功执行alpha测试之后执行此测试。在Beta测试中，目标受众的样本对应用程序进行了测试。 Beta测试也称为预发布测试。 Beta版测试软件的理想状态是在Web上广泛分发给用户，部分目的是为该程序提供“真实世界”的测试，而另一部分则是预览下一个版本。在此阶段，观众将测试以下内容-

• 用户将安装，运行该应用程序并将其反馈发送给项目团队。

• 印刷错误，应用程序流程混乱，甚至崩溃。

• 获得反馈后，项目团队可以在将软件发布给实际用户之前解决问题。

• 您解决的解决实际用户问题的问题越多，应用程序的质量就越高。

• 当您向大众发布更高质量的应用程序时，将会提高客户满意度。

非功能测试

本节基于从应用程序的非功能属性对应用程序进行测试。非功能测试涉及根据本质上非功能但很重要的需求(例如性能，安全性，用户界面等)来测试软件。

下面讨论一些重要且常用的非功能测试类型。

性能测试

它通常用于确定任何瓶颈或性能问题，而不是在软件中查找错误。有多种原因可导致软件性能降低-

• 网络延迟

• 客户端处理

• 数据库事务处理

• 服务器之间的负载平衡

• 数据渲染

就以下方面而言，性能测试被视为重要且强制性的测试类型之一-

• 速度(即响应时间，数据渲染和访问)

• 容量

• 稳定性

• 可扩展性

性能测试可以是定性或定量的，可以分为不同的子类型，例如负载测试和压力测试。

负载测试

它是通过在软件访问和操纵大型输入数据方面施加最大负载来测试软件行为的过程。它可以在正常和峰值负载条件下完成。此类测试可确定软件的最大容量及其在高峰时间的行为。

大多数情况下，负载测试是在自动化工具的帮助下执行的，例如Load Runner，AppLoader，IBM Rational Performance Tester，Apache JMeter，Silk Performer，Visual Studio Load Test等。

在自动测试工具中定义了虚拟用户(VUsers)，并执行了脚本以验证软件的负载测试。用户数量可以根据要求同时增加或减少。

压力测试

压力测试包括在异常情况下测试软件的行为。例如，它可能包括占用一些资源或施加超出实际负载限制的负载。

压力测试的目的是通过将负载施加到系统上并接管软件用于确定断点的资源来测试软件。可以通过测试不同的场景来执行此测试，例如-

• 随机关闭或重新启动网络端口

• 打开或关闭数据库

• 运行消耗CPU，内存，服务器等资源的不同进程。

可用性测试

可用性测试是一种黑盒技术，用于通过观察用户的使用和操作来识别软件中的任何错误和改进。

根据尼尔森(Nielsen)的说法，可以根据五个因素来定义可用性，即使用效率，学习能力，记忆能力，错误/安全性和满意度。据他介绍，如果产品具有上述因素，则产品的可用性将是良好的，并且该系统是可用的。

Nigel Bevan和Macleod认为可用性是质量要求，可以将其作为与计算机系统交互的结果来衡量。如果使用适当的资源有效地实现了预期目标，则可以满足此要求，并且可以满足最终用户的需求。

Molich在2000年指出，用户友好的系统应实现以下五个目标，即易学，易记，高效，易用和易于理解。

除了可用性的不同定义外，还有一些标准，质量模型和方法以属性和子属性的形式定义可用性，例如ISO-9126，ISO-9241-11，ISO-13407和IEEE std。 610.12等

UI与可用性测试

UI测试涉及测试软件的图形用户界面。 UI测试可确保GUI根据要求运行并在颜色，对齐方式，大小和其他属性方面进行测试。

另一方面，可用性测试确保了可以轻松处理的良好且用户友好的GUI。 UI测试可以视为可用性测试的一部分。

安全测试

安全测试包括测试软件，以便从安全和漏洞的角度识别任何缺陷和漏洞。下面列出的是安全测试应确保的主要方面-

• 保密

• 廉洁

• 认证方式

• 可用性

• 授权书

• 不可否认

• 该软件可抵御已知和未知漏洞

• 软件数据是安全的

• 软件符合所有安全法规

• 输入检查和确认

• SQL插入攻击

• 注射缺陷

• 会话管理问题

• 跨站点脚本攻击

• 缓冲区溢出漏洞

• 目录遍历攻击

便携性测试

可移植性测试包括对软件进行测试，以确保其可重用性以及也可以将其从其他软件中移出。以下是可用于可移植性测试的策略-

• 将已安装的软件从一台计算机传输到另一台计算机。

• 构建可执行文件(.exe)以在不同平台上运行该软件。

可移植性测试可以被视为系统测试的子部分之一，因为这种测试类型包括针对软件在不同环境中的使用情况的整体测试。计算机硬件，操作系统和浏览器是可移植性测试的主要重点。便携性测试的一些前提条件如下-

• 软件的设计和编码应牢记可移植性要求。

• 已经对相关组件执行了单元测试。

• 集成测试已执行。

• 测试环境已经建立。