软件验证和验证

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

定义

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

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

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

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

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

笔记：验证在验证之前开始，然后并行运行，直到释放软件产品为止。[需要澄清]（反之亦然，请参见下面的原因:)

期限确认通常与该术语相关联验证并理解为一个单一的概念V＆V。验证用于确保一个正在解决正确的问题，而验证用于确保一个人解决了问题（Martin 1997）。从实际和词源含义中，术语验证来自拉丁语Verus，这意味着真理，方面，这意味着要制作/执行。因此，验证意味着证明某事是真的或正确（属性，特征等）。术语验证来自拉丁语阀，这意味着变得坚强，并且具有与单词相同的词源根。价值。因此，验证意味着证明某事具有产生预期效应的正确功能。（改编自“普通英语的验证和验证”（Incose Lake 1999）。[1][ISO/IEC/IEEE 15288]

软件验证

这意味着要通过运行软件来验证是否满足规格，但这是不可能的（例如，任何人都知道是否可以通过运行软件来正确实现体系结构/设计/等？）。只有通过审查其相关的工件，才能得出结论是否满足规格。

工件或规格验证

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

人工制品验证的示例：

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

软件验证

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

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

工件或规格验证

在整个软件产品准备就绪之前，应先验证要求（瀑布开发过程要求它们在设计启动之前正确定义；但是迭代开发过程不需要这样做，并允许其持续改进）。

人工制品验证的示例：

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

验证与验证

根据能力成熟度模型（CMMI-SW v1.1），[2]

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

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

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

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

从测试的角度来看：

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


相关概念

验证和验证都与质量和软件质量保证。验证和验证本身不能保证软件质量；规划，可追溯性需要配置管理和软件工程的其他方面。

在建模和仿真（M＆S）社区，验证，验证和认证的定义相似：

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

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

V＆V方法

正式的

在关键任务软件系统，正式方法可用于确保系统的正确操作。但是，这些正式方法可能成本高昂，占软件设计总成本的80％。

独立的

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

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

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

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

历史

ISVV源自IV＆V（独立验证和验证）在软件中的应用。早期的ISVV应用（如今）可以追溯到1970年代初美国军队赞助了与IV＆V有关的第一个重要程序反弹导弹系统。[6]另一个例子是NASA的IV＆V计划，该计划成立于1993年。[7]

到1970年代末，IV＆V迅速变得流行。软件的复杂性，大小和重要性的不断增加导致对软件的IV＆V的需求不断增加。

同时，IV＆V（用于软件系统的ISVV）合并，现在已被诸如组织（例如国防部，FAA，[8]NASA[7]和ESA.[9]IV＆V在DO-178B，ISO/IEC 12207并正式化IEEE 1012.

在ESA

最初在2004 - 2005年，由欧洲航天局，由DNV，关键软件SA，Terma和CODA SCISYS PLC在其他组织的支持下创建了专门针对ISVV的指南的第一个版本，称为“独立验证和验证指南”。[10]本指南涵盖了适用于所有软件工程阶段的方法。

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

方法

ISVV通常由五个主阶段组成，这些阶段可以顺序执行或作为裁缝过程的结果。

规划

  • ISVV活动计划
  • 系统批判性分析：通过一组识别关键组件公羊活动（物有所值）
  • 选择适当的方法和工具

要求验证

  • 验证：完整性，正确性，可检验性

设计验证

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

代码验证

验证

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

监管环境

软件通常必须满足法律监管行业的合规要求，该行业通常受到政府机构的指导[11][12]或工业行政当局。例如，FDA需要软件版本和补丁被验证。[13]

也可以看看

进一步阅读

  • 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。doi：10.1109/MC.2003.1244531.

外部链接

参考

  1. ^Pham，H。（1999）。软件可靠性。 John Wiley＆Sons，Inc。p。 567。ISBN 9813083840.软件验证。确保软件执行正确过程的过程。软件验证。确保软件正在正确执行该过程的过程。？'''''我们是在建造正确的产品吗？'。
  2. ^“用于软件工程的CMMI，版本1.1，上演表示形式（CMMI-SW，v1.1，上演）”.Resources.sei.cmu.edu。检索2021-03-20.
  3. ^一个bc“国防部验证，验证和认证（VV＆A）的模型和模拟文件”。导弹国防机构。2008。{{}}：引用期刊需要|journal=（帮助）
  4. ^Rogers，R。（1981-10-26）。“计划独立软件验证和验证”.航空航天会议的第三台计算机。航空航天会议中的计算机。美国加利福尼亚州圣地亚哥：美国航空和宇航学院。doi：10.2514/6.1981-2100.
  5. ^安布罗西奥，安娜；Fátima的Mattiello-Francisco；Martins，Eliane（2008-05-12）。“空间应用程序的独立软件验证和验证过程”.SpaceOps 2008会议。德国海德堡：美国航空和宇航学研究所。doi：10.2514/6.2008-3517.ISBN 978-1-62410-167-0.
  6. ^刘易斯（Robert O.）（1992）。独立验证和验证：高质量软件的生命周期工程过程。纽约：威利。ISBN 0-471-57011-7.OCLC 74908695.
  7. ^一个b阿斯伯里，迈克尔（2015-03-09）。“关于NASA的IV＆V程序”.NASA。检索2021-03-20.
  8. ^Balci，O。（2010）。“验证，验证，测试以及建模和仿真应用程序认证的黄金规则”.S2CID 61476570。检索2021-03-20.
  9. ^“飞行软件系统部分（TEC-SWF）”.www.esa.int。检索2021-03-20.
  10. ^一个blavva.pt。“新的ISVV空间指南”.www.criticationsoftware.com。检索2021-03-20.
  11. ^“软件验证的一般原则；行业和FDA员工的最终指南”（PDF）.食品和药物管理局。 2002年1月11日。检索7月12日2009.
  12. ^“行业指南：第11部分，电子记录；电子签名 - 范围和应用”（PDF）.食品和药物管理局。 2003年8月。检索7月12日2009.
  13. ^“行业指南：包含货架（OTS）软件的网络医疗设备的网络安全”（PDF）.食品和药物管理局。 2005年1月14日。检索7月12日2009.