软件测试方法和模型

完美的软件是不存在的，每个程序都有潜在的故障点。软件测试是软件开发生命周期的一个阶段，在此期间团队会发现程序或系统中不需要的错误。不同的测试方法有助于查明几种类型的软件错误。了解每个软件测试模型的工作原理对于构建、部署和维护高质量的测试策略和软件至关重要。

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

测试阶段是软件开发生命周期中的关键阶段。它发生在软件实施之后，测试旨在发现和修复软件错误。软件测试至关重要，因为产品在测试后会投入生产。每个软件开发团队都必须交付高质量的软件，原因有二：

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

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

软件测试方法论

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

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

• 验证——系统构建是否正确？
• 验证——系统是否按照用户要求构建？

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

黑盒测试

在黑盒测试方法中，程序是一个封闭的（黑）盒，细节未知。测试人员唯一可见的组件是程序输入和输出。测试人员可以通过观察各种输入的结果输出来确定程序是否正常运行。黑盒测试不考虑程序的规范或代码，只考虑不同测试用例的预期行为。黑盒测试人员不必非常熟练，因为他们不与任何代码交互。黑盒测试既有优点也有缺点。黑盒测试的关键优势是不需要使用代码和编程逻辑。然而， 测试所有输入组合是不可能的。三种类型的测试基于黑盒测试方法：功能测试、非功能测试和回归测试。

功能测试

功能测试检查软件是否执行特定功能，而不考虑系统中的哪个组件负责操作。测试团队检查功能的好坏输入。一个示例函数是用户登录页面行为。功能测试检查用户是否可以使用正确的凭据登录或不能使用不正确的凭据登录。

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

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

非功能测试

非功能测试方法除了功能和特性之外，还验证软件方面。这种测试方法侧重于程序如何在特定条件下执行某些操作。非功能测试有助于从用户的角度发现程序是否可用。该方法检查可用性问题，例如跨不同设备、浏览器或操作系统的交叉兼容性。

回归测试

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

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

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

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

白盒测试

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

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

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

测试人员根据程序的结构制定计划。例如，白盒测试可以包括创建脚本测试，这些测试遍历整个代码并运行每个功能。具体测试可以检查是否存在死循环或者代码不运行的情况。白盒测试的主要缺点是测试迭代次数，随着应用程序变得更复杂，迭代次数会增加。该方法需要创建一种策略，其中递归或循环对精心选择的代表性值执行次数更少。三种类型的测试基于白盒测试方法：语句测试、路径测试和分支测试。

语句测试

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

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

路径测试

路径测试在整个代码中创建独立的线性路径。测试团队创建代码的控制流程图，这有助于设计单元测试以评估所有代码路径。分析不同的路径有助于发现应用程序的低效、中断或冗余流。

分支测试

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

• 有条件的：当条件满足时执行。
• Unconditional：不管任何情况都执行。

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

如果条件 1：
    W
否则如果条件 2：
    X
    是
别的：
    Z

测试人员识别所有条件分支。在示例代码中，条件分支是W, X, 和Z因为语句只在特定条件下运行。另一方面，Y是一个无条件分支，因为它总是在X语句之​​后执行。分支测试旨在执行尽可能多的分支并测试所有分支条件。

功能测试

功能测试是黑盒测试的一种子类型，它考虑给定功能或程序的软件规范。该测试方法在不考虑内部软件结构的情况下提供各种输入并分析输出。功能测试包括 4 个不同的步骤，这些步骤从代码的更多次要部分开始，然后扩展到评估整个系统。该模型旨在分析组件或程序的合规性，并检查系统是否按照规范执行它应该执行的操作。

第 1 步：单元测试

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

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

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

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

第二步：集成测试

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

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

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

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

第三步：系统测试

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

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

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

第 4 步：验收测试

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

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

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

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

非功能测试

非功能测试从用户的角度对软件进行评估，着重于用户体验。测试方法旨在发现与软件功能无关但对用户体验至关重要的任何问题。

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

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

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

性能测试

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

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

所有性能测试都旨在发现并修复会降低用户体验的低延迟和性能问题。

安全测试

安全测试检查软件中的任何安全问题，是最关键的软件测试方法之一。该方法检查系统内的任何漏洞和网络攻击的可能性。渗透测试和漏洞扫描等方法有助于发现和降低软件内部的安全风险，还有许多渗透测试工具可以使测试过程自动化。

可用性测试

可用性测试评估软件对用户的用户友好性和便利性。这些测试突出了未受指导的用户在程序或应用程序中做某事的速度有多快。可用性测试结果表明新用户可以多快学会使用该软件，以及是否有必要对界面进行改进。

兼容性测试

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

软件测试模型

软件开发生命周期中的测试阶段并不是唯一可以识别和修复错误的地方。所有开发阶段都受益于包括软件测试。持续的软件开发也需要持续的软件测试。软件开发应与测试团队合作，尽早发现潜在问题或确定无法进行测试的地方。越早发现越好，随着步骤的推进，发现和修复错误的成本会增加。据 IBM 系统科学研究所称，在维护阶段发现和修复缺陷的相对成本要高出大约六倍。

因此，了解测试如何集成到各种软件开发过程和方法中至关重要。下面是对众所周知的软件开发模型以及测试如何集成到每种方法中的概述。

瀑布模型

瀑布模型是一种软件开发方法，分为顺序步骤或阶段。团队只有在完成前一阶段后才能进入下一阶段。测试团队在瀑布模型的需求阶段开始创建测试计划和策略。一旦软件进入实施阶段，测试人员将验证软件是否正常工作并符合规范。瀑布法在软件测试中的主要好处是需求定义明确并且在测试阶段很容易应用。该模型不适合条件经常变化和意外事件发生的项目。

优点

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

缺点

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

V型

V模型是瀑布模型的扩展和改进。该模型分为顺序步骤，每个开发阶段都有额外的测试步骤。V 模型通过功能测试的所有阶段来验证和验证软件。

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

优点

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

缺点

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

敏捷模型

敏捷方法是一种快速迭代的软件开发方法，它遵循敏捷宣言中定义的原则。它将软件开发分解为小的增量和多次迭代。敏捷模型允许与最终用户持续交互，并且需求不断变化。敏捷模型中的测试发生在每次迭代中。此环境中的软件测试需要通过自动化测试工具和测试框架对CI/CD 管道进行持续测试。

优点

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

缺点

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

Scrum模型

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

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 需要纪律严明的程序员，他们接受并遵循所要求的原则，并能紧密合作。
• 客户端依赖：客户端选择是否参与开发过程。不参与的客户通常会导致软件不尽如人意。

结论

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