软件测试方法论 – 学习 QA 模型


什么是软件测试方法论?

软件测试方法论是指用于确保被测应用程序满足客户需求的策略和测试类型。为了验证 AUT,测试方法论包括功能测试和非功能测试。单元测试、集成测试、系统测试、性能测试等都是测试方法论的例子。每种测试方法论都概述了测试目标、测试策略和交付成果。

许多公司将开发方法论和测试方法论这两个术语互换使用,因为软件测试是任何开发方法论的重要组成部分。与之前对测试方法论的定义相反,测试方法论也可能指瀑布模型、敏捷开发等 QA 方法。讨论各种测试形式对读者来说并没有太大价值。因此,我们将回顾各种开发模型。

瀑布模型

在瀑布模型中,软件开发逐步通过多个阶段,例如需求分析、设计等。在此模型中,下一个阶段只有在先前阶段完成后才会开始。

什么是测试方法论?

在瀑布模型中,第一个阶段是需求阶段,在此阶段,在测试开始之前,所有项目需求都将完全确定。在这一阶段,测试团队会集思广益,确定测试范围,制定测试策略,并创建详细的测试计划。

只有在软件设计完成后,团队才会开始执行测试用例,以验证构建的程序是否按计划工作。

在此过程中,测试团队只有在完成前一个步骤后才能进入下一步。

  • **优点** - 此软件工程模型相对易于设计和管理。因此,具有明确定义和表达的需求的项目可以轻松地使用瀑布方法进行测试。

  • **缺点** - 在瀑布模型中,只有在完成前一阶段后才能进入下一阶段。因此,此模型无法适应意外情况和不确定性。此方法不适用于需求经常变化的项目。

迭代式开发

在此模型中,一个大型项目被分解成多个小块,并且每个块都经过多次瀑布迭代。在每个周期结束时,都会创建新的模块或改进现有的模块。此模块将构建到软件体系结构中,并且整个系统将进行测试。

测试方法是什么?

迭代完成后,将对整个系统进行测试。测试反馈可以立即获得,并包含在下一个周期中。

根据先前迭代的经验,可以最大程度地减少后续迭代中所需的测试时间。

  • **优点** - 迭代式开发的主要好处是,在每个周期结束时,测试反馈会立即提供。

  • **缺点** - 由于必须在每个周期结束时提供有关交付成果、工作量和其他因素的反馈,因此此模型会大大增加沟通开销。

敏捷方法论

传统的软件开发方法假设软件需求在项目期间不会发生变化。但是,随着需求变得越来越复杂,它们会经历多次调整并随着时间推移而发展。有时,购买者不确定自己想要什么。尽管迭代模型克服了此问题,但它仍然遵循瀑布方法。

使用敏捷方法,软件是按增量方式、快速周期构建的。客户、开发人员和客户端之间的交互优先于流程和工具。敏捷方法侧重于适应变化,而不是进行大量准备。

什么是测试方法论?

敏捷开发方法使用增量测试,确保每个项目版本都经过充分测试。这确保了在下一个版本发布之前解决任何系统问题。

  • **优点** - 可以随时对项目进行更改,以确保其满足需求。这种渐进式测试方法降低了风险。

  • **缺点** - 客户的持续参与给所有相关方带来了更多的时间压力,包括客户、软件开发和测试团队。

极限编程

极限编程是一种敏捷方法,强调快速开发周期。简单的工程活动被分组到一个项目中。程序员创建软件的基本部分,然后提供给客户反馈。客户的反馈被纳入考虑,工程师们继续进行下一个任务。

极限编程通常在两人一组的团队中进行。

极限编程用于客户需求频繁变化的环境中。

什么是测试方法论?

极限编程基于测试驱动开发方法,其定义如下:

  • 向测试套件添加一个测试用例,以验证尚未实现的新功能。

  • 运行所有测试,由于该功能尚未开发,因此新的测试用例必须失败。

  • 编写一些代码以实现该功能。

  • 重新运行测试套件。由于该功能已编写,因此新的测试用例这次应该通过。

**优点** - 极限编程可用于那些对软件设计概念模糊的客户。持续测试和集成小版本确保交付高质量的软件代码。

**缺点** - 软件开发团队与客户之间的会议增加了所需的时间。

您应该选择哪种软件方法论?

在软件开发和测试中,有许多方法可供选择。每种测试方法和方法论都针对特定目标,并且都有其自身的优缺点。

项目类型、客户需求、项目时间表和其他因素都会影响所使用的方法。

某些方法鼓励在开发生命周期的早期进行测试输入,而其他方法则等到系统功能模型可用时才进行。

如何构建软件测试方法论?

软件测试方法论不应仅限于测试软件代码。应该审查整体情况,并且测试方法论应满足项目的首要目标。

  • **计划** - 实施良好测试方法的关键是现实的计划,并且该计划应适应每个团队成员的需求。

  • **已定义的交付成果** - 应提供明确定义的交付成果,以使所有团队成员保持一致。交付成果的内容不应有任何歧义。

  • **测试方法论** - 完成计划并提供已声明的交付成果后,测试团队应能够创建适当的测试方法论。通过定义文档和开发会议,应让团队了解项目最合适的测试方法。

  • **报告** - 难以获得透明的报告,但此阶段定义了项目测试策略的有效性。

验证和确认

V 模型方法是瀑布模型的一个分支,用于软件需求明确定义的小型项目。它以“V 形”组织,包括编码、验证和确认。由于编码是模型的基础,因此每个开发阶段都伴随着测试,从而能够在每个阶段尽早发现错误。

测试方法论

在每个开发步骤执行的并行测试流程方面,“V 模型”与瀑布模型不同。验证流程确保产品已正确构建,而确认阶段确保它是适合该工作的正确产品。

模型中的静态验证阶段从业务需求分析开始,然后是系统设计、体系结构设计和模块设计。之后,编码步骤确保根据编码标准和规则选择适当的语言和工具。最后,验证过程确保对每个模块和开发阶段执行单元测试、集成测试、系统测试和应用程序测试。

优点

  • 每个级别的测试和验证使开发过程中能够尽早发现错误。

  • 这是一种低成本、快速周转的测试方法。

  • 由于其刚性,它非常适合小型项目。

  • 验证和确认过程在每个级别都包含明确定义的目标。

缺点

  • 在测试过程中,没有固有的能力来响应故障。

  • 没有明确的方法来消除软件缺陷。

  • 对于可能发生大量更改的大型项目,此方法效率低下。

  • 它无法同时处理多个事件。

  • 模块进入测试阶段后,无法回头。

案例研究

  • 医疗设备和软件应用程序是两种类型的医疗设备。

  • 政府的应用程序和软件项目。

  • 国防项目和应用程序。

  • 商业应用程序可用。

快速行动开发方法论

测试模型是一种增量式方法,起源于敏捷软件开发流程。RAD的核心是原型设计,同时构建软件组件,允许测试人员专注于测试而不是计划和文档。虽然每个软件功能都被隔离并作为一个独立的组件创建,但它们被组合起来构建原型,然后使用该原型收集最终用户输入并进行进一步修改。

测试方法论

RAD技术包括五个阶段,在这些阶段中,系统组件被同时设计和测试。每个阶段都有一个设定的时间限制,并且必须尽快完成,这使其非常适合截止日期紧张的项目。

第一步称为“业务建模”,它定义业务需求并建立数据流向各个业务渠道。在建立数据流后,“数据建模”步骤会根据业务模型检查相关数据。

第三步“流程建模”将数据项转换为创建业务信息流。该阶段指定了QA程序,以根据客户输入进一步修改数据项。这样做是为了理解应用程序可能会随着时间的推移经历多次迭代。

原型步骤是“应用程序生成”的第四阶段,并且使用自动化技术对模型进行编码。最后,在“测试和移交”阶段,每个原型都独立进行测试,减少了整个软件程序中的故障和风险。

优点

  • 同时进行原型设计和可重用性减少了开发和测试时间。

  • 通过在每个增量步骤中使用时间盒技术,可以降低软件项目的总体风险。

  • 由于反馈循环,客户满意度会提高。

  • 进度是可观察的并且基于事实。

  • 更改易于实施。

缺点

  • 对于过时的系统,很难应用此技术。

  • 持续的客户输入和更改可能会导致部署延迟。

  • 技术技能和资源非常重要。

  • 由于自动化测试、工具和代码开发,成本会增加。

案例研究

  • 添加到应用程序的图形用户界面。

  • 原型应用程序(线框图、设计和可点击原型)

  • 系统的模块化。

更新于: 2021年12月1日

609 次浏览

启动您的职业生涯

通过完成课程获得认证

开始
广告