学习软件测试中的V模型

V模型是一种非常严格的软件开发生命周期模型，其中每个开发阶段都紧跟着一个测试阶段。V模型是瀑布模型的一个变体，其中测试在每个阶段都与开发同步进行。

软件工程术语

• 软件开发生命周期 (SDLC) − SDLC 代表软件开发生命周期。开发人员为了创建和构建高质量的软件，会执行一系列任务。

• 软件测试生命周期 (STLC) − 是软件测试生命周期的缩写。它是一套由测试人员有条理地执行的任务，以测试您的软件产品。

• 瀑布模型 − 瀑布模型是一种顺序模型，它将软件开发活动划分为多个阶段。每个阶段都旨在用于特定的活动。在瀑布模型中，测试过程仅在系统实现完成后才开始。

为了理解V模型，让我们举个例子。

假设您被分配了为客户创建定制软件的任务。无论您的技术经验如何，请尝试对您将采取的完成工作的操作顺序进行有根据的预测。

这是正确的顺序。

所有这些层都构成了软件开发的瀑布方法。

瀑布模型的缺点

如您所见，该模型的测试仅在实现完成后才开始。

但是，如果您正在处理一个包含复杂系统的庞大项目，则很容易在需求阶段忽略重要方面。在这种情况下，客户将收到完全错误的产品，您可能需要重新启动项目。或者，如果您正确记录了需求但在软件的设计和架构方面犯了严重错误，则您将不得不重新设计整个软件以纠正错误。

根据对数百个项目的评估，在需求和设计期间引入的问题约占所有缺陷的一半。

此外，随着开发生命周期的进行，修复故障的成本会上升。在生命周期中越早发现缺陷，修复它的成本就越低。“及时缝针，省九针”，俗话说。

V模型是答案。

为了解决这个问题，创建了V模型测试，其中包括开发生命周期每个阶段的测试阶段。

V模型的验证阶段分为多个阶段

• 单元测试 − 在V模型中，模块设计过程中会创建单元测试计划 (UTP)。这些 UTP 用于查找和修复代码或单元级别的错误。单元是最小的可以独立存在的东西，例如程序模块。当与其余代码/单元分离时，单元测试确认最小的对象可以正常执行。

• 组件测试 − 这些测试确保程序的最小的组件能够正常工作。组件可以是模块、单元或类，具体取决于编程语言。因此，这些测试将被称为模块测试、单元测试或类测试。组件测试在根据组件规范提供输入后检查组件的输出。这些是 BDD 测试驱动方法的功能文件。组件测试的特点是单独评估单个组件，而无需与其他组件通信。由于没有涉及其他组件，因此查找问题变得容易得多。

  通常，测试框架用于实现测试，例如 JUnit、CPPUnit 或 PyUnit，仅举几个著名的单元测试框架。可以使用我们的代码覆盖率分析工具 Coco 监控和检查代码覆盖率，以确保测试涵盖尽可能多的组件源代码。

  除了功能测试（例如代码复杂性、适当的文档）之外，组件测试还可以涵盖非功能因素，例如效率（例如存储消耗、内存消耗、程序计时等）和可维护性。Coco 的代码复杂性分析和函数分析器也可以帮助完成这些任务。

• 集成测试 − 集成测试确保已单独设计和测试的组件可以按计划组合并交互。软件系统的测试可能仅涵盖两个单独的组件、组件组，甚至单独的子系统。在组件在较低的组件测试级别进行评估后，通常完成集成测试。功能定义、系统架构、用例和流程描述都可以用于创建集成测试。集成测试侧重于组件接口（或子系统接口），并揭示由它们的交互引起的错误，但如果组件单独测试，则不会触发这些错误。

  集成测试还可以侧重于与应用程序环境交互的其他软件或硬件组件。与组件集成测试相反，这通常称为系统集成测试。

  根据程序类型，测试驱动程序也可能是单元测试框架。我们的 Squish GUI 测试器可以运行 GUI 应用程序的测试。除了被测应用程序之外，Squish 还可以自动化子系统或外部系统，例如配置工具。

• 系统测试 − 系统测试步骤检查整个软件系统。系统测试以用户的角度构建，并侧重于功能和非功能应用程序需求，而集成测试主要侧重于技术规范。后者例如性能、负载和压力测试。

  尽管组件及其集成已过评估，但仍需要系统测试以确保满足功能软件需求。在不执行整个软件系统的情况下，根本无法评估某些功能。系统测试中通常包含其他文档，例如用户手册或风险分析文档。

  系统测试应在尽可能接近生产环境的环境中进行。如果可行，请使用与生产系统相同的硬件、操作系统、驱动程序、网络基础设施或外部系统，并尽可能避免使用占位符。另一方面，不应将生产环境用作测试环境，因为在系统测试期间发现的任何问题都可能影响生产系统。

  为了避免耗时的手动测试，应自动化系统测试。Squish 现在可以自动化任何 GUI 程序并触发和馈送非 GUI 进程，这要归功于图像识别和光学字符识别。除了通过 GUI 验证应用程序输出之外，Squish 还可以访问 GUI 和非 GUI 对象中存在的内部应用程序数据。测试单个自动化测试中的多个应用程序，即使它们使用不同的 GUI 工具包；嵌入式设备测试；访问外部系统（例如数据库系统）；以及半自动化测试（包括手动验证和验证），涵盖了大多数系统测试需求。

• 验收测试 − 例如，对于尚未发布的软件版本，可以进行内部验收测试。内部验收测试通常由不参与开发或测试过程的人员执行，例如产品管理、销售或客户服务。

  另一方面，验收测试可能是由请求开发的公司或软件的最终用户执行的外部测试。

  最终版本的程序是否符合客户验收测试期间的高级标准，也可能部分或全部由客户决定。编写报告是为了跟踪测试结果，并促进开发实体与客户之间的沟通。

  与客户验收测试相比，用户可接受性测试 (UAT) 可能是最终软件发布之前的倒数第二阶段。它是一个以用户为中心的测试，以确保产品真正支持需要完成的工作流程。这些测试可能包括可用性和整体用户体验等因素。

  根据软件的类型，用于验收测试的时间和精力可能会有所不同。为特定客户创建的定制开发可能会进行大量的测试和报告。对于现成的软件，此测试阶段的投入较少，验收测试可能仅包括确认安装和一些过程。

  验收测试通常是手动测试，只有极少数是自动化的，尤其是在它们可能只在开发过程结束时运行一次的情况下。另一方面，验收测试侧重于流程和用户交互，因此我们建议使用 Squish 自动化验收测试。所有利益相关者都可以将 BDD 作为一种通用语言和规范。考虑在整个软件生命周期中针对软件的多个版本或敏捷项目中的多个迭代所花费的验收测试时间和精力。从中期和长期来看，测试自动化将为您节省大量时间。

除了 V 模型之外，还有迭代开发方法，其中软件分阶段开发，每个阶段都添加新功能。

每个阶段都包含其自身的一组开发和测试任务。

快速应用开发和敏捷开发是迭代开发生命周期的两个很好的实例。

何时应使用 V 模型？

• 当需求明确且无歧义时。

• 对于需求明确且固定的中小型项目，应使用 V 形模型。

• 当具备所需技术技能的样本文档技术资源可用时，应使用 V 形模型。

V 模型优势（优点）

• 易于理解。

• 诸如计划和测试设计之类的测试方法在编码之前进行。

• 这可以帮助您节省大量时间。因此，它比瀑布模型更有可能成功。

• 防止缺陷向下蔓延。

• 此方法适用于具有简单标准的小型计划。

V 模型缺点（缺点）

• 极其僵化和缺乏灵活性。

• 这并不适合大型项目。

• 由于软件是在实施阶段开发的，因此没有早期的软件原型。

• 如果中间有任何修改，则必须更新测试文档以及所需的文档。

结论

有多种开发生命周期模型可供选择。用于项目的开发模型取决于项目的目标和目标。

• 测试不是一项独立的活动，必须根据项目的开发过程进行调整。

• 在任何模型中，都应在所有级别进行测试，从需求到维护。

Vineet Nanda

更新于： 2021 年 12 月 1 日

747 次查看

启动您的职业生涯

通过完成课程获得认证

开始