软件测试方法和模型解释

完美的软件并不存在，每个程序都有潜在的故障点。软件测试是软件开发生命周期的一个阶段，在此阶段团队发现程序或系统中不需要的错误。

不同的测试方法有助于查明多种类型的软件错误。了解每个软件测试模型的工作原理对于构建、部署和维护高质量的测试策略和软件至关重要。

为什么测试在 SDLC 中很重要？

测试阶段是软件开发生命周期中的关键阶段。它发生在软件实现之后，测试的目的是发现并修复软件错误。

软件测试至关重要，因为产品经过测试后才会投入生产。每个软件开发团队都必须交付高质量的软件，原因有两个：

• 最终用户受益于根据要求和规格制造的高质量产品。
• 开发团队的完整性和新项目的可能性取决于软件的质量。

软件测试团队与开发人员分开对不同问题进行各种检查。这种方法有助于让团队专注于发现问题并允许实施持续开发。

软件测试方法

软件测试是由测试团队执行的正式过程，旨在帮助确认程序在逻辑上正确且有价值。测试需要使用特定的测试过程并创建测试用例。

软件测试分两个阶段进行：

• 验证 - 系统构建正确吗？
• 验证 - 系统是否根据用户要求构建？

软件测试使用多种方法和模型来回答这两个问题。

黑盒测试

在黑盒测试方法中，程序是一个细节未知的封闭（黑）盒子。测试人员唯一可见的组件是程序输入和输出。

测试人员可以通过观察各种输入的结果输出来确定程序是否正常运行。黑盒测试不考虑程序的规范或代码，只考虑不同测试用例的预期行为。黑盒测试人员不必非常熟练，因为他们不与任何代码交互。

黑盒测试既有优点也有缺点。黑盒测试的关键优势是不需要使用代码和编程逻辑。但是， 测试所有输入组合是不可能的。

三种类型的测试基于黑盒测试方法：功能测试、非功能测试和回归测试。

功能测试

功能测试检查软件是否执行特定功能，而不考虑系统中的哪个组件负责操作。

测试团队检查功能的好坏输入。一个示例功能是用户登录页面行为。功能测试检查用户是否可以使用正确的凭据登录或无法使用错误的凭据登录。

随着软件复杂性的增加，软件中的功能数量也随之增加。测试功能的顺序对于高效的功能测试策略至关重要。由于功能通常是嵌套的，因此软件的行为取决于人们使用软件时所采取的步骤的顺序。

功能测试的主要好处是测试团队可以在所有软件组件完成之前检查各个功能。在功能测试中检测到错误的概率非常高，因为它从用户的角度显示使用软件时的问题。

非功能测试

非功能测试方法除了功能和特性之外还验证软件的各个方面。这种测试方法侧重于程序在特定条件下如何执行某些操作。

非功能测试有助于揭示程序从用户的角度是否可用。该方法检查可用性问题，例如不同设备、浏览器或操作系统之间的交叉兼容性。

回归测试

回归测试是一种软件测试方法，可确保所有新代码更改不会导致先前测试的组件出现问题并对系统稳定性产生负面影响。该测试方法重复之前迭代的测试，确保最新的更改不会对现有代码造成不必要的影响。

在任何导致原始代码发生更改的程序操作之后都需要进行回归测试，例如：

• 落实新要求。
• 向程序添加新功能。
• 删除现有功能。
• 修复任何缺陷。
• 优化以获得更好的性能。

如果软件经常更改，最好的方法是使用自动化测试工具并为回归测试的多次迭代和周期创建可重用的测试。

白盒测试

白盒测试方法与黑盒测试相反。在这种方法中，程序是一个打开的（白色）盒子，测试人员知道其内部工作原理。

白盒测试分析源代码并需要以下技能：

• 编码和脚本知识。
• 熟悉所使用的特定编程语言。
• 特定组件的设计。

测试人员根据程序的结构制定计划。例如，白盒测试可以包括创建脚本测试，遍历整个代码并运行每个函数。具体测试可以检查是否存在死循环或者代码不运行的情况。

白盒测试的主要缺点是测试迭代次数，随着应用程序变得更加复杂，测试迭代次数也会增加。该方法需要创建一种策略，其中递归或循环对于精心选择的代表性值执行更少的次数

三种类型的测试基于白盒测试方法：语句测试、路径测试和分支测试。

语句测试

语句测试是白盒测试中的一种测试技术。该方法至少评估一次代码中的所有可执行语句。例如，如果代码块包含多个条件语句，则语句测试技术涉及遍历所有输入迭代以确保代码的所有部分都执行。

语句测试技术可以发现未使用的代码部分、丢失的引用语句以及先前版本中剩余的代码。因此，语句测试有助于清理现有代码并减少冗余代码或添加缺失的组件。

路径测试

路径测试在整个代码中创建独立的线性路径。测试团队创建代码的控制流程图，这有助于设计单元测试来评估所有代码路径。

分析不同的路径有助于发现应用程序的低效、损坏或冗余流。

分支测试

分支测试映射代码中的条件语句并标识单元测试的分支。分支类型有：

• 有条件：满足条件时执行。
• 无条件：无论任何情况都执行。

例如，以下代码包含多个嵌套语句：

if condition 1:
    W
else if condition 2:
    X
    Y
else:
    Z

测试人员识别所有条件分支。在示例代码中，条件分支为 W、X 和 Z 因为这些语句仅在特定条件下运行。另一方面，Y 是无条件分支，因为它始终在 X 语句之后执行。

分支测试的目的是执行尽可能多的分支并测试所有分支条件。

功能测试

功能测试是黑盒测试的一个子类型，它考虑给定功能或程序的软件规范。该测试方法提供各种输入并分析输出，而不考虑内部软件结构。

功能测试涉及 4 个不同的步骤，从代码的较小部分开始，然后扩展到评估整个系统。该模型旨在分析组件或程序的合规性，并检查系统是否按照规范执行其应执行的操作。

第 1 步：单元测试

单元测试是一种验证源代码各个部分的软件测试方法。单元测试有助于确定特定模块（单元）的功能，并且该过程隔离各个部分以确定它们是否正常工作。

单元是单个函数、过程或面向对象的编程类。通常，单元测试有助于验证前端界面。

单元测试的主要好处是在开发生命周期中及早发现问题。在测试驱动的开发中，例如 Scrum 或极限编程，测试人员在任何代码存在之前创建单元测试。

应用单元测试的主要缺点是需要评估程序中复杂的执行路径。单元测试是本地化的，并且不兼容发现集成或系统范围的错误。

第 2 步：集成测试

集成测试是单元测试之后的一个阶段。该方法将先前评估的各个程序单元（模块）组合成更大的组，并对聚合进行测试。

集成测试有几种不同的方法：

• 自下而上策略首先评估并集成低级组件，然后再转向更复杂的组。
• 自上而下方法使用逆向工程来评估更复杂组中的组件，并将它们简化为更小的单元。
• 三明治（混合）测试通过同时测试低级和高级组件来结合自下而上和自上而下的策略。
• 大爆炸测试将所有组件组合成一个大单元进行测试。与其他测试方法相比，该方法没有增量方法。

集成测试验证前端接口和应用程序后端之间的连接。

第3步：系统测试

系统测试对完全集成的系统进行测试。该步骤分析行为并将其与预期要求（质量保证）进行比较，从而验证完全集成的软件。

系统测试的目的是发现集成和单元测试遗漏的问题，并提供软件是否已准备好发布的全面概述。系统测试中的不同测试方法考虑软件在各种环境中的运行情况以及软件的可用性。

系统测试的主要挑战是设计一种适合可用时间和资源限制的策略，同时在集成后提供整个系统的全面分析。

第 4 步：验收测试

功能测试的最后一部分是验收测试。该测试方法旨在评估应用程序最终用户的认可程度。该方法让最终用户参与测试过程，并收集用户对任何先前测试阶段中任何潜在可用性问题或遗漏错误的反馈。

验收测试属于以下两类之一：

• 用户接受度测试允许目标用户通过 Beta 测试或类似策略来评估和使用软件。用户群决定了软件是否按预期运行。
• 操作验收测试检查软件是否功能正常并按预期运行。该测试检查各种软件组件，例如安全性、备份和灾难恢复以及故障转移测试。

验收测试后，如果结果符合验收标准，则软件即可投入生产。否则，如果测试未通过阈值，软件将被推回到之前的开发和测试阶段。

非功能测试

非功能测试从用户的角度评估软件，重点关注用户体验。测试方法旨在捕获与软件功能无关但对用户体验至关重要的任何问题。

非功能测试考虑以下参数：

• 安全
• 可靠性
• 可扩展性
• 可用性
• 可用性

非功能测试的重点是产品如何运行，而不是它在特定用例中的行为方式。该测试模型通过性能测试、安全测试、可用性测试和兼容性测试进行。

性能测试

性能测试检查软件的速度、可扩展性和稳定性。存在几种不同的性能测试子类型，例如：

• 负载测试检查软件在常规用户需求下的运行情况。
• 压力测试检查软件在高用户负载或其他复杂环境下的行为方式。
• 峰值测试检查软件在突然的高用户负载峰值下的行为。
• 耐久性测试显示应用程序在较长时间内的稳定性。

所有性能测试的目的都是为了发现并修复降低用户体验的低延迟和性能问题。

安全测试

安全测试检查软件中的任何安全问题，是最关键的软件测试方法之一。该方法检查系统内的任何漏洞以及网络攻击的可能性。

渗透测试和漏洞扫描等方法有助于发现和降低软件内的安全风险，并且还有许多渗透测试工具可以自动化测试过程。

可用性测试

可用性测试评估软件对用户的友好程度和便利程度。这些测试强调了无指导的用户在程序或应用程序中执行某些操作的速度有多快。可用性测试结果显示了新用户学习使用该软件的速度以及是否需要进行任何界面改进。

兼容性测试

兼容性测试显示系统在各种环境中以及与其他软件的行为。该方法侧重于与现有解决方案和技术的集成。

软件测试模型

软件开发生命周期中的测试阶段并不是唯一可以识别和修复错误的地方。所有开发阶段都受益于软件测试。

持续的软件开发也需要持续的软件测试。软件开发应与测试团队合作，尽早发现潜在问题或确定无法进行测试的地方。早期发现效果更好，随着步骤的进展，发现和修复错误的成本也会增加。据 IBM 系统科学研究所称，在维护阶段发现和修复缺陷的相对成本大约高出六倍。

因此，了解测试如何集成到各种软件开发流程和方法中至关重要。下面概述了著名的软件开发模型以及测试如何集成到每种方法中。

瀑布模型

瀑布模型是一种分为连续步骤或阶段的软件开发方法。团队只有完成上一阶段后才能进入下一阶段。

测试团队在瀑布模型的需求阶段开始创建测试计划和策略。一旦软件进入实施阶段，测试人员就会验证软件是否正常工作并符合规范。

软件测试中瀑布方法的主要好处是需求定义明确并且易于在测试阶段应用。该模型不适合条件经常变化且发生意外事件的项目。

优点

• 简单：高度抽象简化了与最终用户的沟通过程，最终用户不需要了解技术流程细节即可参与开发过程。
• 易于遵循：项目经理可以访问项目开发中的关键点，这使他们能够了解开发过程中的进度水平。
• 易于应用：模型经过一次迭代，便于用新软件替换现有解决方案。

缺点

• 没有反馈循环：瀑布模型缺乏反馈机制和多次迭代。在项目开始时定义所有需求是不可能的，并且模型中不支持返回到任何先前步骤进行更改。
• 阶段之间没有明显的联系：该模型假设之前的每个开发阶段都是后续步骤的输入。然而，该模型没有定义需求如何转化为设计。
• 不专注于解决问题：瀑布模型将软件设计视为硬件或生产机制。另一方面，软件设计需要测试和尝试不同的方法。该模型限制了软件开发过程中的任何模块化和创造性过程。
• 有限的最终用户交互：瀑布模型仅在开发阶段的第一步和产品完成的最后阶段与用户进行通信。该方法限制了用户交互，从而导致开发过程效率低下。

V型

V模型是瀑布模型的扩展和改进。该模型分为连续的步骤，每个开发阶段都有额外的测试步骤。 V模型经历了功能测试的所有阶段来验证和确认软件。

V 模型的形状显示了与开发生命周期阶段相对应的测试阶段。从左到右查看时，模型展示了随着时间推移的步骤顺序，而从上到下查看则揭示了抽象级别。

优点

• 反馈机制：V模型对于简单和复杂的项目都很实用，因为它可以返回到之前的任何阶段。
• 验证和验证：该模型可以检查项目是否开发良好、是否完全实施以及是否满足用户需求。
• 高质量的产品：开发过程组织严密，控制良好，保证了软件的质量。
• 早期阶段测试：测试团队参与早期开发阶段，这样可以从一开始就更好地了解项目。该模型显着节省了开发后期测试的时间和资源。

缺点

• 不灵活：当出现问题时，团队必须更新所有阶段，必须适应软件的变化并进行更新，包括文档。任何改变都会减慢开发过程。
• 成本高昂：实施 V 模型需要大量资源来支持众多开发团队。该模型更适合较大的项目和企业。

敏捷模型

敏捷方法是一种快速迭代的软件开发方法，遵循敏捷宣言中定义的原则。它将软件开发分解为小增量和多次迭代。敏捷模型允许与最终用户不断交互，并且需求不断变化。

敏捷模型中的测试发生在每次迭代中。这种环境中的软件测试需要通过自动化测试工具和测试框架将持续测试应用到 CI/CD 管道中。

优点

• 快速开发：软件部署速度比其他模型更快。该模型具有适应性并能响应变化，从而缩短周转时间。
• 较小的迭代：错误和缺陷更容易在较小的块中发现和分析。交付软件所需的时间更少，并且经常发生新的迭代。
• 高水平的用户交互：持续的最终用户反馈可确保经常进行验收测试。因此，产品每次迭代都更接近需求。

缺点

• 不可预测：尽管测试团队收集了用户反馈，但不能保证下一次迭代将包含这些更改。快节奏创造了不可预测的产品路线图。
• 成本高昂：持续发布到生产和开发会导致更高的费用。预测每次变革所需的努力变得很困难。
• 阶段重叠：每次迭代都会经历所有开发阶段。随着冲刺的进展，区分谁负责哪个任务变得更加棘手。

Scrum 模型

Scrum 模型是一种使用敏捷模型原则的项目管理方法。该模型以目标为导向，并且受时间限制，进行迭代（称为冲刺）。每个 Sprint 都包含由 Scrum Master 管理的会议、里程碑和事件。

Scrum 模型没有测试团队，开发人员负责构建和实施单元测试。最终用户也经常在每个冲刺中测试该软件。

一些 Scrum 团队设有功能测试人员，在这种情况下，测试人员必须在 Scrum 会议期间为每个测试会话提供时间估计。

优点

• 快节奏：scrum 模型可确保项目快速交付，这使其适合正在开发的快节奏项目。
• 成本效益：每个冲刺都由多名成员组成，快节奏的环境确保项目在指定的时间范围内完成。
• 高水平的用户交互：与敏捷模型一样，scrum 经常发布代码，这导致了持续的用户交互。持续的反馈可以在每个冲刺中满足用户的需求。

缺点

• 失败的可能性高：Scrum 模型需要高水平的交互和承诺。日常会议压力很大，一名团队成员的离开会影响整个项目。在不合规的团队中，软件出现故障的风险更高。
• 缺乏质量：当模型缺乏测试团队时，软件的质量是不可接受的。由此产生的软件的等级低于那些经过密集测试的软件。

开发运营模式

DevOps 模型将持续测试结合到每个开发阶段，同时在团队中也有专门的测试角色。 DevOps 管道中的测试目标侧重于软件质量和风险评估。

自动化测试和测试驱动开发提高了代码可靠性，这有助于最大限度地减少新构建破坏现有代码的可能性。

优点

• 快速软件交付：DevOps 提高了新功能和错误修复的交付速度。对问题的快速响应可以提高客户对产品的满意度。
• 优质软件：自动化测试和持续部署可提高软件质量。 DevOps 确保在将软件部署到生产环境之前对每个更改进行测试。
• 错误效率高：在开发的初始阶段集成测试可以避免在开发周期后期修复问题。

缺点

• 实施困难：DevOps需要将开发与运维结合起来，并遵循DevOps原则，这在系统复杂的大型组织中很难实现。
• 风险增加：DevOps 严重依赖自动化，如果配置不当，就会导致问题。当问题确实发生时很难追踪。
• 成本过高：该模型需要对基础设施和 DevOps 工具进行大量投资。配置错误的系统会带来难以管理的集成挑战。

迭代开发

迭代开发将软件开发步骤根据功能划分为子系统。该方法是增量的，每个增量都会交付一个完整的系统。每一次新的迭代都会改进每个子系统内的现有流程。

早期版本提供了软件的原始版本，而每个后续版本都提高了现有功能的质量。测试在早期阶段比较简单，但随着迭代的进行，复杂性也会增加。

优点

• 风险控制：迭代开发允许首先从高风险任务开始。开发方法的受控性质可以通过迭代来改进任何问题。
• 易于遵循：每次迭代都比前一次迭代有所改进。对于项目经理来说，测量迭代之间的变化变得很简单。
• 早期培训：由于迭代开发提供了完整软件的简单版本，因此用户可以尽早参与并使用该软件。用户反馈基于整个系统，在接下来的迭代中改进更容易实现。
• 专业版本：软件版本控制变得简单，因为开发团队可以在每次迭代中专注于特定改进。例如，一次迭代改进了用户界面，而下一次迭代则改进了软件的性能。该方法简化了测试设计过程。

缺点

• 成本高昂：每次迭代都需要整个软件开发团队的参与。
• 缺乏完整的规范：迭代开发方法从简单的需求开始创建系统。随着时间的推移，条件也会发生变化。规范的流动性使得项目何时结束变得具有挑战性。
• 难以管理：迭代开发需要对每次迭代进行严格的项目管理和风险评估。随着项目的增长，系统的复杂性也会增加。

螺旋模型

螺旋模型是一种专注于风险评估的敏捷模型。该模型结合了自上而下和自下而上开发方法的最佳品质。该方法使用瀑布模型阶段作为日益复杂的原型。

由于风险分析是每个步骤的重点，因此螺旋模型可以尽早发现故障和漏洞。该模型对问题进行早期评估，从长远来看，这使得安全测试的成本更低。

优点

• 灵活；即使在开发了功能之后，螺旋模型也能适应需求的变化。报告问题时测试团队的压力更小。
• 安全；风险分析存在于开发过程的每一步中，迭代方法也有助于管理风险。与其他开发模型相比，螺旋模型更关注软件安全性。
• 高水平的用户互动；螺旋模型中的迭代方法允许客户参与开发过程并接收持续的反馈。开发团队在开发过程中快速进行更改，从长远来看可以节省成本和资源。

缺点

• 成本高昂：螺旋模型最适合大型项目和复杂的软件。
• 专业风险分析师：该模型依赖于在每个开发步骤中包含高质量的风险分析师，以进行有效的风险评估。
• 复杂：该模型很难遵循，需要在开发的每个步骤中更加关注协议和文档。
• 时间管理：每个阶段的持续时间未知。该模型很容易超出预算并落后于时间限制。

RAD模型

RAD（快速应用程序开发）模型是一种将原型设计与迭代开发相结合的敏捷方法。该方法的重点是收集用户需求，而开发过程的其余部分没有具体的计划或步骤。

RAD 是一种快节奏的技术，专注于创建可重用的组件，作为后续项目或原型的模板。测试团队在每次迭代中评估所有原型，并立即将组件集成到最终产品中。

优点

• 灵活：模型快速实现需求变更并适应新的用户需求。
• 可重用：创建可重用原型提供了一种模板化开发方法，提高了代码的可重用性，从长远来看，需要更少的工作量。
• 快速：开发时间和短迭代实现了持续的软件集成和快速交付。 RAD 模型结合了各种自动化工具来加快开发过程。

缺点

• 对专业知识的高度依赖：基于 RAD 的团队规模较小、技能精湛且技术力量雄厚。 RAD 模型需要经验丰富的开发团队来识别和建模用户需求。
• 仅适用于模块化系统：并非所有软件都有明确的组件。 RAD 需要创建可重复使用的较小原型。复杂的系统需要专门的功能，但这些功能并不适用于所有用例。

极限编程

极限编程 (XP) 是一种敏捷的软件开发方法，最适合中小型团队（6-20 名成员）。该技术侧重于测试驱动开发和短迭代，为用户提供直接结果。

XP 没有严格的方法论可供开发团队遵循。相反，该方法提供了一个灵活的框架，其中过程或步骤顺序根据活动而变化。敏捷宣言原则和结对编程等技术是 XP 的重要组成部分。

优点

• 专注于软件开发：团队创建软件而不是专注于会议和文档。开发人员的工作环境很舒适，有很多学习和提高技能的机会。
• 开发时间短：缺乏规则和流程，使得软件交付速度很快。快速的结果有利于客户。
• 测试驱动开发：单元测试在编写代码之前就存在，程序员在创建软件之前就知道要测试什么。这种方法会刺激程序员在编码时采取更好的预防措施。

缺点

• 难以实施：该方法很难实施。 XP 要求程序员有严格的纪律，接受并遵循规定的原则，并且能够紧密合作。
• 取决于客户：客户选择是否参与开发过程。不参与的客户通常会导致软件不令人满意。

结论

高质量的软件测试是区分优质软件和平庸项目的关键。软件测试的重要性对于开发至关重要，这就是为什么有如此多的测试方法和途径。开发团队应该遵循软件测试的趋势，并准备好从根本上改变他们的方法，以从新的软件测试方法和模型中获利。

接下来，了解自动化测试框架如何帮助简化测试流程并提高测试阶段的测试速度。