软件测试 - 级别

在测试过程中有不同的级别.在本章中，提供了有关这些级别的简要说明.

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

• 功能测试

• 非功能测试

功能测试

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

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

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

单元测试

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

单元测试的目标是隔离程序的每个部分，并显示各个部分的正确性.需求和功能的条款.

单元测试的限制

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

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

集成测试

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

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

系统测试

系统测试将系统测试为整个.一旦所有组件都集成在一起，整个应用程序就会经过严格测试，以确保它符合指定的质量标准.此类测试由专业测试团队执行.

系统测试非常重要，原因如下:

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

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

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

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

回归测试

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

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

• 当需要测试带有更改的应用程序时，最大限度地减少测试中的差距.

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

• 缓解在对应用程序执行回归测试时存在风险.

• 在不影响时间表的情况下提高测试覆盖率.

• 提高产品上市速度.

验收测试

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

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

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

Alpha测试

此测试是测试的第一阶段，将在团队(开发人员和QA团队).组合在一起的单元测试，集成测试和系统测试称为alpha测试.在此阶段，将在应用程序中测试以下方面 :

• 拼写错误

• 断开链接

• 多云路线

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

Beta测试

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

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

• 印刷错误，混乱的申请流程，甚至是崩溃.

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

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

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

非功能性测试

本节基于从非功能属性测试应用程序.非功能性测试涉及根据要求测试软件，这些要求本质上是非功能性的，但很重要，如性能，安全性，用户界面等.

一些重要且常用的非功能性测试类型将在下面讨论.

性能测试

它主要用于识别任何瓶颈或性能问题，而不是查找软件中的错误.导致降低软件性能的原因有所不同;

• 网络延迟

• 客户端处理

• 数据库事务处理

• 服务器之间的负载平衡

• 数据呈现

性能测试被认为是以下方面的重要和强制性测试类型之一 :

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

• 容量

• 稳定性

• 可扩展性

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

负载测试

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

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

虚拟用户(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插入攻击

• 注入漏洞

• 会话管理问题

• 跨站点脚本攻击

• 缓冲区溢出漏洞

• 目录遍历攻击

可移植性测试

可移植性测试包括测试软件旨在确保其可重用性并且可以也可以从其他软件转移.以下是可用于可移植性测试的策略 :

• 将已安装的软件从一台计算机传输到另一台计算机./p>

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

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

• 应该设计和编码软件，请记住便携性要求.

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

• 已经执行了集成测试.

• 测试环境已经建立.