软件测试 – 级别

---

在测试过程中有不同的级别。在本章中，对这些级别进行了简要说明。

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

• 功能测试

• 非功能测试

功能测试

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

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

Steps	描述
I	确定预期应用程序要执行的功能。
II	根据应用程序的规范创建测试数据。
III	基于测试数据和应用程序规范的输出。
IV	测试场景的编写和测试用例的执行。
V	基于执行的测试用例的实际和预期结果的比较。

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

单元测试

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

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

单元测试的局限性

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

开发人员可用于验证源代码的场景和测试数据的数量是有限的。在用尽所有选项后，别无选择，只能停止单元测试并将代码段与其他单元合并。

集成测试

集成测试被定义​​为测试应用程序的组合部分以确定它们是否正常运行。集成测试可以通过两种方式完成：自底向上集成测试和自顶向下集成测试。

Sr.No.	集成测试方法
1	Bottom-up integration 这种测试从单元测试开始，然后是对称为模块或构建的单元的更高级别组合的测试。
2	Top-down integration 在此测试中，首先测试最高级别的模块，然后逐步测试较低级别的模块。

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

系统测试

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

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

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

• 该应用程序经过彻底测试，以验证其是否符合功能和技术规范。

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

• 系统测试使我们能够测试、验证和验证业务需求以及应用程序架构。

回归测试

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

由于以下原因，回归测试很重要 –

• 当必须测试进行了更改的应用程序时，尽量减少测试中的差距。

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

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

• 在不影响时间表的情况下增加了测试覆盖率。

• 加快产品上市速度。

验收测试

这可以说是最重要的测试类型，因为它由质量保证团队进行，他们将衡量应用程序是否符合预期规格并满足客户的要求。QA 团队将拥有一组预先编写的场景和测试用例，用于测试应用程序。

将分享有关该应用程序的更多想法，并可以对其进行更多测试，以衡量其准确性以及启动该项目的原因。验收测试不仅旨在指出简单的拼写错误、外观错误或界面差距，而且还旨在指出应用程序中会导致系统崩溃或应用程序重大错误的任何错误。

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

阿尔法测试

此测试是测试的第一阶段，将在团队（开发人员和 QA 团队）之间执行。单元测试、集成测试和系统测试结合在一起称为 alpha 测试。在此阶段，将在应用程序中测试以下方面 –

• 拼写错误

• 断开的链接

• 多云方向

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

测试版

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

• 用户将安装、运行应用程序并将他们的反馈发送给项目团队。

• 排版错误、混乱的应用程序流程，甚至崩溃。

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

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

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

非功能测试

本节基于从非功能属性测试应用程序。非功能性测试涉及从本质上是非功能性但重要的需求（例如性能、安全性、用户界面等）来测试软件。

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

性能测试

它主要用于识别任何瓶颈或性能问题，而不是查找软件中的错误。降低软件性能的原因有多种 –

• 网络延迟

• 客户端处理

• 数据库事务处理

• 服务器之间的负载均衡

• 数据渲染

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

• 速度（即响应时间、数据渲染和访问）

• 容量

• 稳定

• 可扩展性

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

负载测试

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

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

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

压力测试

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

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

• 随机关闭或重启网口

• 打开或关闭数据库

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

可用性测试

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

根据尼尔森的说法，可用性可以用五个因素来定义，即使用效率、学习能力、记忆能力、错误/安全性和满意度。在他看来，一个产品的可用性是好的，如果系统具备上述因素，那么这个系统就是可用的。

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

Molich 在 2000 年指出，一个用户友好的系统应该实现以下五个目标，即易学、易记、高效、易用、易懂。

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

UI 与可用性测试

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

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

安全测试

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

• 保密

• 正直

• 验证

• 可用性

• 授权

• 不可否认性

• 软件针对已知和未知漏洞是安全的

• 软件数据安全

• 软件符合所有安全法规

• 输入检查和验证

• SQL 插入攻击

• 注射缺陷

• 会话管理问题

• 跨站脚本攻击

• 缓冲区溢出漏洞

• 目录遍历攻击

便携性测试

可移植性测试包括测试软件以确保其可重用性以及它也可以从另一个软件中移动。以下是可用于可移植性测试的策略 –

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

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

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

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

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

• 已执行集成测试。

• 测试环境已经搭建完成。