软件测试 - 快速指南

---

---

软件测试 - 概述

什么是测试？

测试是评估系统或其组件的过程，目的是确定其是否满足规定的要求。简单来说，测试是为了识别系统中与实际需求相反的任何差距、错误或缺失的需求而执行系统。

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

谁来进行测试？

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

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

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

并非在软件周期的任何时间都可以测试软件。接下来的两节将说明在 SDLC 中何时开始测试以及何时结束测试。

何时开始测试？

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

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

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

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

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

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

何时停止测试？

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

• 测试截止日期

• 测试用例执行完成

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

• 错误率降至一定水平，并且没有发现高优先级的错误

• 管理决策

验证与确认

这两个术语对大多数人来说都非常令人困惑，他们可以互换使用。下表突出显示了验证和确认之间的区别。

软件测试 - 误区

以下是一些关于软件测试最常见的误区。

误区 1：测试成本过高

**现实** - 有句谚语，在软件开发过程中为测试支付更少的费用，或者以后为维护或更正支付更多的费用。早期测试在许多方面都节省了时间和成本，但是减少测试的成本可能会导致软件应用程序设计不当，从而使产品变得毫无用处。

误区 2：测试耗时

**现实** - 在 SDLC 阶段，测试绝不是一个耗时的过程。但是，诊断和修复在适当测试期间发现的错误是一个耗时但富有成效的活动。

误区 3：只有完全开发的产品才进行测试

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

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

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

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

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

误区 6：错过的缺陷是由于测试人员造成的

**现实** - 将应用程序中即使在执行完测试后仍然存在的错误归咎于测试人员，这不是一种正确的方法。这种误区与时间、成本和不断变化的需求约束有关。但是，测试策略也可能导致测试团队错过了错误。

误区 7：测试人员负责产品的质量

**现实** - 这是一个非常普遍的误解，即只有测试人员或测试团队应该对产品质量负责。测试人员的职责包括向利益相关者识别错误，然后由他们决定是否修复错误或发布软件。在此时发布软件会给测试人员带来更大的压力，因为他们将对任何错误负责。

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

**现实** - 是的，测试自动化确实可以缩短测试时间，但在软件开发的任何时间都无法启动测试自动化。当软件经过手动测试并在一定程度上稳定时，应开始测试自动化。此外，如果需求不断变化，则永远无法使用测试自动化。

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

**现实** - IT 行业以外的人认为甚至相信任何人都可以测试软件，并且测试不是一项创造性的工作。但是测试人员非常清楚这是一个误区。思考替代方案、试图使软件崩溃以探索潜在错误对于开发它的人来说是不可能的。

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

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

软件测试 - 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

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

• 软件包的一组需求。
• 根据指定需求测试交付的软件包的说明。

其他

下面列出了一些其他与 QA 和测试流程相关的标准 -

软件测试 - 测试类型

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

手动测试

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

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

自动化测试

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

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

自动化什么？

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

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

何时自动化？

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

• 大型关键项目
• 需要频繁测试相同区域的项目
• 需求不经常变化
• 使用许多虚拟用户访问应用程序以进行负载和性能测试
• 在手动测试方面稳定的软件
• 可用时间

如何自动化？

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

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

软件测试工具

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

• HP Quick Test Professional
• Selenium
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Testing Anywhere
• WinRunner
• LoadRunner
• Visual Studio Test Professional
• WATIR

软件测试 - 方法

软件测试有多种方法。本章简要介绍了可用的方法。

黑盒测试

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

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

白盒测试

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

测试人员需要查看源代码内部，并找出哪个单元/代码块的行为不正常。

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

灰盒测试

灰盒测试是一种在对应用程序内部工作原理了解有限的情况下测试应用程序的技术。在软件测试中，测试应用程序时“了解得越多，越好”这句话很有分量。

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

测试方法比较

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

软件测试 - 层次

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

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

• 功能测试

• 非功能测试

功能测试

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

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

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

单元测试

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

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

单元测试的局限性

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

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

集成测试

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

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

系统测试

系统测试将系统作为一个整体进行测试。一旦所有组件都集成在一起，就会对整个应用程序进行严格的测试，以确保它满足指定的质量标准。这种类型的测试由专门的测试团队执行。

系统测试之所以重要，原因如下：

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

• 对应用程序进行彻底测试，以验证它是否满足功能和技术规范。

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

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

回归测试

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

回归测试之所以重要，原因如下：

• 在必须测试已进行更改的应用程序时，最大程度地减少测试中的差距。

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

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

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

• 加快产品上市速度。

验收测试

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

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

通过对应用程序执行验收测试，测试团队将减少应用程序在生产环境中的表现。系统验收也存在法律和合同要求。

Alpha 测试

此测试是测试的第一阶段，将在团队（开发团队和质量保证团队）之间执行。单元测试、集成测试和系统测试组合在一起称为 Alpha 测试。在此阶段，将在应用程序中测试以下方面：

• 拼写错误

• 断开的链接

• 模糊的说明

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

Beta 测试

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

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

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

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

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

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

非功能测试

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

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

性能测试

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

• 网络延迟

• 客户端处理

• 数据库事务处理

• 服务器之间的负载平衡

• 数据渲染

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

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

• 容量

• 稳定性

• 可扩展性

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

负载测试

它是一个通过应用最大负载（以软件访问和处理大量输入数据的方式）来测试软件行为的过程。它可以在正常和峰值负载条件下进行。这种类型的测试可以识别软件的最大容量及其在峰值时间的行为。

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

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

压力测试

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

压力测试的目的是通过向系统施加负载并接管软件使用的资源来测试软件，以识别其断点。可以通过测试以下不同的场景来执行此测试：

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

• 打开或关闭数据库

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

可用性测试

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

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

奈杰尔·比文和麦克莱奥德认为，可用性是可以衡量为与计算机系统交互结果的质量要求。如果通过使用适当的资源有效地实现了预期目标，则可以满足此要求，最终用户将感到满意。

莫利奇在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 方法