软件测试 - 快速指南

---

软件测试 - 概述

什么是测试？

测试是评估系统或其组件的过程，旨在确定其是否满足指定的要求。简而言之，测试是执行一个系统，以识别与实际需求相反的任何差距、错误或缺失的需求。

根据 ANSI/IEEE 1059 标准，测试可以定义为 - 分析软件项目以检测现有条件和所需条件（即缺陷/错误/错误）之间的差异并评估软件项目功能的过程。

谁进行测试？

这取决于项目的流程和相关利益相关者。在 IT 行业，大公司有一个团队，负责根据给定的需求评估开发的软件。此外，开发人员还进行测试，称为单元测试。在大多数情况下，以下专业人员在各自的能力范围内参与测试系统 -

• 软件测试员
• 软件开发人员
• 项目负责人/经理
• 最终用户

不同的公司根据经验和知识对软件测试人员有不同的称呼，如软件测试员、软件质量保证工程师、QA 分析师等。

不可能在软件周期内的任何时间对其进行测试。接下来的两节说明了 SDLC 期间测试应何时开始以及何时结束。

什么时候开始测试？

尽早开始测试可以减少返工的成本和时间，并生成交付给客户的无错误软件。然而，在软件开发生命周期（SDLC）中，测试可以从需求收集阶段开始，一直持续到软件部署。

它还取决于正在使用的开发模型。例如，在瀑布模型中，在测试阶段进行正式测试；但在增量模型中，测试是在每次增量/迭代结束时执行的，并且整个应用程序在最后进行测试。

在 SDLC 的每个阶段都以不同的形式进行测试 -

• 在需求收集阶段，需求的分析和验证也被视为测试。

• 在设计阶段审查设计以改进设计也被视为测试。

• 开发人员在完成代码后执行的测试也被归类为测试。

何时停止测试？

很难确定何时停止测试，因为测试是一个永无止境的过程，没有人可以声称软件已经过 100% 测试。停止测试过程应考虑以下几个方面 -

• 测试截止日期

• 测试用例执行完成

• 功能和代码覆盖率完成到一定程度

• 错误率低于一定水平且未发现高优先级错误

• 管理决策

验证与确认

对于大多数人来说，这两个术语非常令人困惑，他们可以互换使用。下表重点介绍了验证和确认之间的差异。

软件测试 - 神话

下面列出了有关软件测试的一些最常见的误解。

误区一：测试成本太高

现实- 有句话说，在软件开发期间为测试支付更少的费用，或者为以后的维护或纠正支付更多的费用。早期测试在许多方面都可以节省时间和成本，但是在不进行测试的情况下降低成本可能会导致软件应用程序设计不当，从而导致产品无用。

误区 2：测试非常耗时

现实- 在 SDLC 阶段，测试从来都不是一个耗时的过程。然而，诊断和修复在正确测试过程中发现的错误是一项耗时但富有成效的活动。

误区 3：仅测试完全开发的产品

现实- 毫无疑问，测试取决于源代码，但审查需求和开发测试用例独立于开发的代码。然而，迭代或增量方法作为开发生命周期模型可以减少测试对完全开发的软件的依赖。

误区 4：完整的测试是可能的

现实- 当客户或测试人员认为完整的测试是可能的时，这就会成为一个问题。团队可能已经测试了所有路径，但完全测试是不可能发生的。可能有一些场景在软件开发生命周期中测试团队或客户从未执行过，而可能在项目部署后执行。

误区 5：经过测试的软件是没有错误的

现实- 这是客户、项目经理和管理团队都相信的一个非常普遍的神话。没有人可以绝对肯定地声称软件应用程序 100% 无错误，即使具有精湛测试技能的测试人员已经测试了软件应用程序应用。

误区 6：漏检缺陷是测试人员造成的

现实- 即使在执行测试后，将应用程序中仍然存在的错误归咎于测试人员并不是正确的方法。这个神话与时间、成本和需求变化的约束有关。然而，测试策略也可能导致测试团队遗漏错误。

误区七：测试人员对产品质量负责

现实- 这是一种非常常见的误解，认为只有测试人员或测试团队才应对产品质量负责。测试人员的职责包括向利益相关者识别错误，然后由他们决定是否修复错误或发布软件。当时发布软件会给测试人员带来更大的压力，因为他们会因任何错误而受到指责。

误区 8：应尽可能使用测试自动化来减少时间

现实- 是的，测试自动化确实减少了测试时间，但在软件开发过程中不可能随时启动测试自动化。当软件经过手动测试并达到一定程度的稳定后，应启动测试自动机。此外，如果需求不断变化，测试自动化就永远无法使用。

误区 9：任何人都可以测试软件应用程序

现实- IT 行业以外的人认为甚至相信任何人都可以测试软件，而测试并不是一项创造性的工作。然而测试人员很清楚这是一个神话。考虑替代方案，尝试使软件崩溃以探索潜在的错误对于开发它的人来说是不可能的。

误区 10：测试人员的唯一任务是查找 Bug

现实- 查找软件中的错误是测试人员的任务，但同时，他们是特定软件的领域专家。开发人员只负责分配给他们的特定组件或区域，但测试人员了解软件的整体工作原理、依赖关系是什么以及一个模块对另一模块的影响。

软件测试 - QA、QC 和测试

测试、质量保证和质量控制

当谈到确定质量保证、质量控制和测试之间的差异时，大多数人都会感到困惑。虽然它们是相互关联的，并且在某种程度上可以被视为相同的活动，但也存在将它们分开的区别点。下表列出了 QA、QC 和测试的区别点。

审核与检查

审计- 这是一个系统过程，用于确定如何在组织或团队内进行实际测试过程。一般来说，它是对软件测试过程中涉及的流程的独立检查。根据 IEEE，这是对组织实施和遵循的记录流程的审查。审计类型包括法律合规审计、内部审计和体系审计。

检查- 这是一种正式技术，涉及通过识别任何错误或差距对任何工件进行正式或非正式的技术审查。根据 IEEE94，检查是一种正式的评估技术，由作者以外的个人或团体详细检查软件需求、设计或代码，以检测故障、违反开发标准和其他问题。

正式检查会议可能包括以下过程：计划、概述准备、检查会议、返工和跟进。

测试与调试

测试- 它涉及识别软件中的错误/错误/缺陷而不纠正它。通常具有质量保证背景的专业人员会参与错误识别。测试是在测试阶段进行的。

调试- 它涉及识别、隔离和修复问题/错误。编写软件代码的开发人员在遇到代码错误时进行调试。调试是白盒测试或单元测试的一部分。调试可以在开发阶段进行单元测试，也可以在修复报告的错误时分阶段进行。

软件测试 - ISO 标准

全球许多组织制定并实施不同的标准来提高其软件的质量需求。本章简要介绍了一些与质量保证和测试相关的广泛使用的标准。

ISO/IEC 9126

该标准涉及以下方面以确定软件应用程序的质量 -

• 质量模型
• 外部指标
• 内部指标
• 使用质量指标

该标准为任何软件提供了一些质量属性，例如 -

• 功能性
• 可靠性
• 可用性
• 效率
• 可维护性
• 可移植性

上述质量属性又细分为子因素，详细研究标准时可以研究。

ISO/IEC 9241-11

该标准的第 11 部分涉及特定用户在特定使用环境中使用产品以实现特定目标的有效性、效率和满意度的程度。

该标准提出了一个描述可用性组件及其之间关系的框架。在该标准中，可用性是根据用户表现和满意度来考虑的。根据 ISO 9241-11，可用性取决于使用上下文，可用性级别将随着上下文的变化而变化。

ISO/IEC 25000:2005

ISO/IEC 25000:2005 通常被称为提供软件质量要求和评估 (SQuaRE) 指南的标准。该标准有助于组织和增强与软件质量需求及其评估相关的流程。事实上，ISO-25000 取代了两个旧的 ISO 标准，即 ISO-9126 和 ISO-14598。

SQuaRE分为几个子部分，例如 -

• ISO 2500n – 质量管理部门
• ISO 2501n – 质量模型部门
• ISO 2502n – 质量测量部门
• ISO 2503n – 质量要求部门
• ISO 2504n – 质量评估部门

SQuaRE的主要内容是 -

• 术语和定义
• 参考模型
• 一般指南
• 个别部门指导
• 与需求工程相关的标准（即规范、规划、测量和评估过程）

ISO/IEC 12119

该标准涉及交付给客户的软件包。它不关注或处理客户的生产过程。主要内容涉及以下几项 -

• 软件包的要求集。
• 根据指定要求测试交付的软件包的说明。

各种各样的

下面提到了与质量保证和测试流程相关的一些其他标准 -

软件测试 - 测试类型

本节描述可用于在 SDLC 期间测试软件的不同类型的测试。

手动测试

手动测试包括手动测试软件，即不使用任何自动化工具或任何脚本。在这种类型中，测试人员接管最终用户的角色并测试软件以识别任何意外的Behave或错误。手动测试有不同的阶段，例如单元测试、集成测试、系统测试和用户验收测试。

测试人员使用测试计划、测试用例或测试场景来测试软件，以确保测试的完整性。手动测试还包括探索性测试，测试人员探索软件以识别其中的错误。

自动化测试

自动化测试也称为测试自动化，是测试人员编写脚本并使用另一个软件来测试产品。此过程涉及手动过程的自动化。自动化测试用于重新运行手动、快速、重复执行的测试场景。

除了回归测试之外，自动化测试还用于从负载、性能和压力的角度测试应用程序。与手动测试相比，它增加了测试覆盖范围，提高了准确性，并节省了时间和金钱。

自动化什么？

不可能将软件中的所有内容自动化。用户可以进行交易的区域（例如登录表单或注册表单）以及大量用户可以同时访问软件的任何区域都应该实现自动化。

此外，所有 GUI 项目、与数据库的连接、现场验证等都可以通过自动化手动过程进行有效测试。

何时自动化？

使用测试自动化时应考虑软件的以下方面 -

• 大型关键项目
• 需要频繁测试同一区域的项目
• 需求不经常变化
• 通过许多虚拟用户访问应用程序以了解负载和性能
• 相对于手动测试而言稳定的软件
• 可用时间

如何实现自动化？

自动化是通过使用支持性计算机语言（例如 VB 脚本）和自动化软件应用程序来完成的。有许多工具可用于编写自动化脚本。在提到工具之前，让我们确定可用于自动化测试过程的过程 -

• 识别软件中的自动化领域
• 选择适当的测试自动化工具
• 编写测试脚本
• 测试服的开发
• 执行脚本
• 创建结果报告
• 识别任何潜在的错误或性能问题

软件测试工具

以下工具可用于自动化测试 -

• HP 快速测试专业版
• Selenium
• IBM Rational 功能测试仪
• 丝绸测试
• 测试完成
• 随处测试
• 赢跑者
• 负载运行器
• Visual Studio 测试专业版
• Watir

软件测试 - 方法

有不同的方法可用于软件测试。本章简要介绍了可用的方法。

黑盒测试

在不了解应用程序内部工作情况的情况下进行测试的技术称为黑盒测试。测试人员不了解系统架构，也无法访问源代码。通常，在执行黑盒测试时，测试人员将通过提供输入和检查输出来与系统的用户界面进行交互，而不知道如何以及在何处处理输入。

下表列出了黑盒测试的优点和缺点。

白盒测试

白盒测试是对代码内部逻辑和结构的详细调查。白盒测试也称为玻璃测试或开盒测试。为了对应用程序执行白盒测试，测试人员需要了解代码的内部工作原理。

测试人员需要查看源代码内部并找出代码的哪个单元/块Behave不当。

下表列出了白盒测试的优点和缺点。

灰盒测试

灰盒测试是一种在对应用程序内部工作了解有限的情况下测试应用程序的技术。在软件测试中，“你知道的越多，越好”这句话在测试应用程序时具有很大的影响力。

掌握系统领域总是让测试人员比领域知识有限的人更具优势。与黑盒测试不同，测试人员仅测试应用程序的用户界面；在灰盒测试中，测试人员可以访问设计文档和数据库。有了这些知识，测试人员可以在制定测试计划时准备更好的测试数据和测试场景。

测试方法比较

下表列出了黑盒测试、灰盒测试和白盒测试的区别点。

软件测试 - 级别

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

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

• 功能测试

• 非功能测试

功能测试

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

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

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

单元测试

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

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

单元测试的局限性

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

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

集成测试

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

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

系统测试

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

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

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

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

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

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

回归测试

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

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

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

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

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

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

• 加快产品上市速度。

验收测试

这可以说是最重要的测试类型，因为它是由质量保证团队进行的，他们将衡量应用程序是否符合预期规格并满足客户的要求。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) 以在不同平台上运行该软件。

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

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

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

• 已执行集成测试。

• 测试环境已经建立。

软件测试 - 文档

测试文档涉及应在软件测试之前或期间开发的工件的文档。

软件测试文档有助于估计所需的测试工作、测试覆盖率、需求跟踪/追踪等。本节描述了一些与软件测试相关的常用文档工件，例如 -

• 测试计划
• 测试场景
• 测试用例
• 追溯矩阵

测试计划

测试计划概述了用于测试应用程序的策略、将使用的资源、执行测试的测试环境以及测试的限制和测试活动的时间表。通常，质量保证团队负责人将负责编写测试计划。

测试计划包括以下内容 -

• 测试计划文档简介
• 测试应用程序时的假设
• 测试应用程序中包含的测试用例列表
• 待测试的功能列表
• 测试软件时使用哪种方法
• 需要测试的可交付成果列表
• 为测试应用程序分配的资源
• 测试过程中涉及的任何风险
• 要实现的任务和里程碑的时间表

测试场景

这是一行语句，通知将测试应用程序中的哪些区域。测试场景用于确保所有流程都经过端到端测试。应用程序的特定区域可以有少至一个到几百个的测试场景，具体取决于应用程序的规模和复杂性。

术语“测试场景”和“测试用例”可以互换使用，但是测试场景有多个步骤，而测试用例只有一个步骤。从这个角度来看，测试场景就是测试用例，但它们包括多个测试用例以及它们应该执行的顺序。除此之外，每个测试都依赖于前一个测试的输出。

测试用例

测试用例涉及执行测试任务时可以使用的一组步骤、条件和输入。此活动的主要目的是确保软件在功能和其他方面是否通过或失败。测试用例有很多种类型，例如功能测试用例、否定测试用例、错误测试用例、逻辑测试用例、物理测试用例、UI 测试用例等。

此外，编写测试用例是为了跟踪软件的测试覆盖范围。通常，在测试用例编写过程中没有可以使用的正式模板。但是，以下组件始终可用并包含在每个测试用例中 -

• 测试用例ID
• 产品模块
• 产品版本
• 修订记录
• 目的
• 假设
• 前提条件
• 脚步
• 预期结果
• 实际结果
• 后置条件

许多测试用例可以从单个测试场景中派生出来。此外，有时会为单个软件编写多个测试用例，这些测试用例统称为测试套件。

追溯矩阵

可追溯性矩阵（也称为需求可追溯性矩阵 - RTM）是用于跟踪软件开发生命周期期间的需求的表。它可用于向前跟踪（即从需求到设计或编码）或向后跟踪（即从编码到需求）。RTM 有许多用户定义的模板。

RTM 文档中的每个要求都与其相关的测试用例链接，以便可以根据提到的要求进行测试。此外，还包含 Bug ID 并与其相关的需求和测试用例链接。该矩阵的主要目标是 -

• 确保软件是按照上述要求开发的。
• 帮助找到任何错误的根本原因。
• 帮助跟踪 SDLC 不同阶段开发的文档。

软件测试 - 估计技术

估计测试所需的工作量是 SDLC 中主要且重要的任务之一。正确的估计有助于以最大的覆盖范围测试软件。本节介绍一些可用于估计测试所需工作量的技术。

功能点分析

该方法基于对以下类别的软件功能用户需求的分析 -

• 输出
• 查询
• 输入
• 内部文件
• 外部文件

测试点分析

该估计过程用于黑盒或验收测试的功能点分析。该方法的主要要素是：规模、生产力、策略、接口、复杂性和一致性。

Mark-II 方法

它是一种基于最终用户的功能视图来分析和测量估计的估计方法。Mark-II 方法的程序如下 -

• 确定观点
• 计数的目的和类型
• 定义计数边界
• 识别逻辑事务
• 识别数据实体类型并对其进行分类
• 计算输入数据元素类型
• 计算功能尺寸

各种各样的

您可以使用其他流行的估计技术，例如 -

• 德尔菲法
• 基于类比​​的估计
• 基于测试用例枚举的估计
• 基于任务（活动）的估计
• IFPUG法