软件验证和验证

软件项目管理软件测试以及软件工程验证和验证V&V )中,是检查软件系统满足规范和要求的过程,以实现其预期目的。它也可以称为软件质量控制。通常是软件测试人员作为软件开发生命周期的一部分的责任。简单地说,软件验证是:“假设我们应该构建X,我们的软件是否实现了其目标而没有任何错误或空白?”另一方面,软件验证是:“ X是我们应该构建的吗?X是否满足高级要求?”

定义

验证和验证不是同一回事,尽管它们经常感到困惑。 Boehm简洁地表达了差异

  • 验证:我们建造产品吗?
  • 验证:我们是否正在建造正确的产品?

“正确构建产品”检查了系统是否正确实施规格,同时“构建正确的产品”回到了用户的需求。在某些情况下,需要对确定合规性的正式程序或协议都有书面要求。理想情况下,正式方法提供了数学保证,即软件符合其规格。

构建产品权利意味着使用需求规范作为开发过程的下一阶段的输入,设计过程,其输出是设计规范。然后,这也意味着使用设计规范来供应施工过程。每当过程的输出正确实现其输入规范时,软件产品就会更接近最终验证。如果过程的输出不正确,则开发人员没有构建利益相关者想要正确的产品。这种验证称为“工件或规格验证”。

构建正确的产品意味着创建一个需求规范,其中包含软件产品利益相关者的需求和目标。如果此类工件不完整或错误,则开发人员将无法构建利益相关者想要的产品。这是“伪像或规格验证”的一种形式。

验证在验证之前开始,然后并行运行,直到释放软件产品为止。不过,并非总是如此。

软件验证

这意味着要通过运行软件来验证是否满足规格,但这是不可能的(例如,谁能通过运行软件来正确实现体系结构/设计/等。)。只有通过审查其相关的工件,才能得出结论是否满足规格。

工件或规格验证

在针对其输入规范进行检查时,每个软件开发过程阶段的输出也可以进行验证(请参阅下面的CMMI定义)。

人工制品验证的示例:

  • 根据要求规范的设计规范:建筑设计,详细的设计和数据库逻辑模型规范是否正确实施了功能和非功能要求规范?
  • 针对设计规范的构造工件的构造:源代码,用户界面和数据库物理模型是否正确实施了设计规范?

软件验证

软件验证检查软件产品是否满足或适合预期用途(高级检查),即软件满足用户需求,而不是只能操作软件的人的规范工件或需要的规格工件或需求;但是,随着所有利益相关者的需求(例如用户,运营商,管理人员,经理,投资者等)。有两种执行软件验证的方法:内部和外部。在内部软件验证期间,假定正确理解了利益相关者的目标,并且在要求伪像精确,全面地表达了他们的目标。如果软件符合要求规范,则已在内部进行了验证。通过询问利益相关者是否满足他们的需求,可以在执行外部验证时进行外部验证。不同的软件开发方法要求不同级别的用户和利益相关者参与和反馈;因此,外部验证可以是离散的或连续的事件。当所有利益相关者接受软件产品并表明其满足他们的需求时,成功的最终外部验证会发生。这种最终的外部验证需要使用一个动态测试接受测试

但是,还可以执行内部静态测试,以找出该软件是否符合需求规范,但由于软件未运行,因此属于静态验证的范围。

工件或规格验证

在整个软件产品准备就绪之前,应验证要求(瀑布开发过程要求在设计启动之前对其进行完美定义;但是迭代开发过程不需要这样做并允许其持续改进)。

人工制品验证的示例:

  • 用户需求规范验证:通过检查“用户需求规范”中所述的用户要求通过检查是否确实代表利益相关者的意愿和目标来验证。这可以通过采访利益相关者并直接询问(静态测试),甚至发布原型,并让用户和利益相关者对其进行评估(动态测试)来完成。
  • 用户输入验证:用户输入(由键盘,生物 - 金属传感器等任何外围设备收集)可以通过检查软件运营商或用户提供的输入是否符合域规则和约束(例如数据类型,范围,范围,格式)。

验证与验证

根据能力成熟度模型(CMMI-SW V1.1),

  • 软件验证:在开发过程结束时或在开发过程结束时评估软件的过程以确定其是否满足指定要求。 [IEEE-STD-610]
  • 软件验证:评估软件以确定给定开发阶段的产品是否满足该阶段开始时施加的条件的过程。 [IEEE-STD-610]

软件开发过程中的验证可以看作是用户需求规范验证的一种形式;而且,在开发过程的结束时,相当于内部和/或外部软件验证。从CMMI的角度来看,验证显然是人工制品的。

换句话说,软件验证可确保软件开发过程的每个阶段的输出有效地执行其相应的输入工件指定的内容(要求 - > design->软件产品),而软件验证可确保软件产品满足需求所有利益相关者(因此,首先正确准确地表达了要求规范)。软件验证可确保“您正确构建它”,并确认所提供的产品可以满足开发人员的计划。软件验证可确保“您建造正确的东西”,并确认所提供的产品可以满足利益相关者的预期使用和目标。

本文使用了严格或狭窄的验证定义。

从测试的角度来看:

  • 故障 - 代码中的错误或丢失功能。
  • 失败 - 执行过程中故障的表现。该软件无效。它不做应该做的“什么”。
  • 故障 - 根据其规范,系统不符合其指定功能。该软件不是有效的(花费了太多的资源,例如CPU周期,它使用了太多的内存,执行了太多的I/O操作等),它是不可用的,不可靠的。它应该做的“如何”。

相关概念

验证和验证都与质量软件质量保证的概念有关。验证和验证本身不能保证软件质量;需要计划,可追溯性,配置管理和软件工程的其他方面。

建模和模拟(M&S)社区中,验证,验证和认证的定义相似:

  • M&S验证是确定模型和仿真实现的计算机模型,模拟或联合会的过程,准确地代表了开发人员的概念描述和规格。
  • M&S验证是确定模型和仿真模型,模拟或联合联合的程度,其相关数据是从预期用途的角度来确定现实世界的准确表示。
  • 认证是正式的证明,即可以接受模型或模拟来用于特定目的。

M&S验证的定义侧重于M&S代表现实世界中预期用途的准确性。由于所有M&S都是现实的近似值,因此需要确定M&S精度的程度,并且通常至关重要的是确定近似程度是否可以接受预期用途。这与软件验证相反。

V&V方法

正式的

关键任务软件系统中,可以使用正式方法来确保系统的正确操作。但是,这些正式方法可能成本高昂,占软件设计成本的80%。

独立的

独立的软件验证和验证(ISVV)针对安全至关重要的软件系统,旨在提高软件产品的质量,从而通过软件的运营寿命降低风险和成本。 ISVV的目的是提供保证软件在其设计的参数和定义的要求中执行指定的置信度级别。

ISVV活动由不参与软件开发过程的独立工程团队进行,以评估流程和产生的产品。 ISVV团队独立性在三个不同的层面上进行:财务,管理和技术。

ISVV超出了开发团队应用的“传统”验证和验证技术。尽管后者的目的是确保软件符合名义要求的良好性能,但ISVV侧重于诸如鲁棒性和可靠性等非功能要求,以及可能导致软件失败的条件。

ISVV结果和发现可以追溯到开发团队进行更正和改进。

历史

ISVV源自IV&V(独立验证和验证)在软件中的应用。早期的ISVV应用(如今)可以追溯到1970年代初,当时美国陆军赞助了与IV&V有关的第一个重要计划,用于保障的反焊接导弹系统。另一个例子是NASA的IV&V计划,该计划成立于1993年。

到1970年代末,IV&V迅速变得流行。该软件的复杂性,大小和重要性的不断增加导致对IV&V的需求不断增加,将其应用于软件。

同时,IV&V(用于软件系统的ISVV)合并,现在已被DODFAANASAESA等组织广泛使用。 IV&V在DO-178BISO/IEC 12207中提到,并在IEEE 1012中正式化。

在ESA

最初是在2004 - 2005年,由欧洲航天局领导的欧洲财团,由DNVCritical Software SATermaCoda Scisys PLC创建了专门针对ISVV的指南的第一个版本,称为“ ESA独立验证和验证指南” “在其他组织的支持下。本指南涵盖了适用于所有软件工程阶段的方法。

2008年,欧洲航天局发布了第二版,并收到了许多欧洲太空ISVV利益相关者的意见。

方法

ISVV通常由五个主阶段组成,这些阶段可以依次执行,也可以作为裁缝过程的结果。

规划

  • ISVV活动计划
  • 系统批判性分析:通过一组RAMS活动(物有所值)来识别关键组件
  • 选择适当的方法和工具

要求验证

  • 验证:完整性,正确性,可检验性

设计验证

  • 设计适当和符合软件要求和界面
  • 内部和外部一致性
  • 验证可行性和维护

代码验证

验证

  • 识别不稳定的组件/功能
  • 侧重于错误处理的验证:关于开发团队执行的互补(不是并发)验证
  • 遵守软件和系统要求
  • 黑匣子测试白盒测试技术
  • 基于经验的技术

监管环境

软件通常必须满足法律监管行业的合规要求,该行业通常以政府机构或工业行政当局为指导。例如, FDA需要验证软件版本和补丁程序

也可以看看

进一步阅读

  • 1012-2012 IEEE系统和软件验证和验证标准。 2012. doi:10.1109/ieeestd.2012.6204026。 ISBN 978-0-7381-7268-2。
  • Tran,E。(1999)。 “验证/验证/认证” 。在Koopman,P。(编辑)。可靠的嵌入式系统中的主题。卡内基·梅隆大学。检索2007-05-18
  • Menzies,T。; Y. Hu(2003)。 “非常忙碌的人的数据挖掘”。电脑. 36 (1):22–29。 doi10.1109/MC.2003.1244531