软件测试 - 级别

---

测试过程中有不同的级别。本章对这些级别进行了简要描述。

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

• 功能测试

• 非功能测试

功能测试

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

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

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

单元测试

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

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

单元测试的局限性

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

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

集成测试

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

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

系统测试

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

系统测试很重要，原因如下 -

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

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

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

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

回归测试

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

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

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

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

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

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

• 加快产品上市速度。

验收测试

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

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

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

阿尔法测试

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

• 拼写错误

• 损坏的链接

• 多云方向

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

贝塔测试

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

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

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

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

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

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

非功能测试

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

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

性能测试

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

• 网络延迟

• 客户端处理

• 数据库事务处理

• 服务器之间的负载平衡

• 数据渲染

在以下方面，性能测试被认为是重要且强制性的测试类型之一 -

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

• 容量

• 稳定

• 可扩展性

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

负载测试

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

大多数时候，负载测试是借助自动化工具来执行的，例如 Load Runner、AppLoader、IBM Rational Performance Tester、Apache JMeter、Silk Performer、Visual Studio Load Test 等。

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

压力测试

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

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

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

• 打开或关闭数据库

• 运行不同的进程，消耗 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) 以在不同平台上运行该软件。

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

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

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

• 已执行集成测试。

• 测试环境已经建立。