设计验证和确认流程

设计验证

设计验证 设计验证是一种通过检查和提供证据来确认已设计软件产品的输出是否符合其输入规范的方法。软件开发过程中设计验证的目标是确保已设计的软件产品与规范中规定的内容一致。

设计输入是指作为设计基础的任何物理和性能要求。设计输出是每个设计阶段以及整个设计工作的成果。在医疗器械等受监管行业，最终设计输出将成为设备主记录的基础，这就是为什么设计控制词汇在验证文档中如此频繁出现的原因。

在实践中，验证是将两套文件进行比较：一套是输入的规范、标准和约束条件，另一套是输出的图纸、代码和测试说明。两者之间的任何不匹配都构成验证结果。

设计验证

验证旨在证明内部一致性。而确认则提出了一个更难的问题：规范最初描述的是否是正确的产品。

设计验证 设计验证是指根据最终用户或利益相关者的具体需求评估软件产品的过程。其目的是在软件产品开发完成后对其进行测试，以确认其在用户实际环境中使用时是否满足这些需求。

验证旨在证明设计在满足用户需求方面是否一致且完整。在这个阶段，您需要实际构建产品版本，并根据用户需求对其进行验证。

下面的横幅标注了活动的两部分，就像它们通常在设计记录中呈现的那样。

下图展示了设计验证过程本身，从用户需求到最终验证的产品。

其目的是用客观证据证明产品满足已记录的用户需求。客观证据是指输出结果的实物证明——例如图像、文本文件、音频文件或签字报告——以表明该流程已实际执行。

通过这些客观证据，验证过程会持续检验产品是否符合预先设定的要求。它涉及测试活动、检验、分析和类似技术，因此验证通常会借鉴…… 系统测试 和 用户验收测试 而不是进行单元级检查。

设计验证和确认之间的区别

人们常常将验证和确认混淆起来。它们是不同的活动，而且两者都应在开发过程的每个阶段执行，而不是在某个单一里程碑节点执行。

一个有用的快捷方式：验证主要 静态工作 针对文档进行验证，而验证主要针对文档。 动态测试 针对正在运行的构建。

设计验证过程

验证过程分为五个阶段，每个阶段都会产生一个工件，下一阶段依赖于该工件。

鉴别与准备：

• 在制定规范的同时，验证活动也会同步进行。这使得设计人员能够确保规范确实可验证，从而让测试工程师着手制定详细的测试计划和流程。任何规范变更都必须及时沟通。
• 确定进行验证的最佳方法，并定义测量方法、所需资源、工具和设施。
• 完成验证计划后，会与设计团队进行审查，以便在计划最终定稿前发现问题。

规划：

• 验证计划的制定是核心团队和开发团队的同步工作。它贯穿整个项目生命周期，并在设计输入发生变化时及时更新。
• 在此阶段，被测软件或系统的范围将被记录下来。
• 首先编写一份初步测试计划，然后对其进行完善。该计划涵盖了能够降低项目风险的关键里程碑。
• 选择工具、测试环境和开发策略，并确定需要通过检查或分析来确认的要求。

德韦洛ping:

• 测试用例 发展与……相吻合 SDLC 方法 项目团队已实施。目前阶段确定了多种测试方法。
• 设计输入必须经过精心设计，使得即使是最简单的验证活动也清晰明确且可验证。
• 按顺序验证类似概念可以减少验证时间，因为一个测试的输出可以作为后续测试的输入。
• Trac在测试用例及其对应的设计输入之间建立可验证性联系，以确保每个要求都得到测试，并且设计输出满足设计输入。

执行机制：

• 在开发阶段制定的测试程序将按照测试计划执行，并在验证活动中严格遵守。
• 如果出现无效结果，或者任何程序需要修改，则必须记录这些更改并获得正式批准。
• 发现的任何问题都会通过常规流程记录为缺陷。 缺陷管理流程.
• A trac能力矩阵 创建此测试的目的是验证验证测试计划中确定的每个设计输入是否都经过测试，并确定通过率。

报告：

• 此活动在验证执行的每个阶段结束时执行。
• 设计验证报告详细总结了验证结果，包括配置管理、每种测试类型的结果以及在验证活动中发现的问题。
• 设计验证 trac可行性报告是根据需求和相应的测试结果创建的，以确认所有需求都已测试，并且已记录适当的结果。
• 任何不符合项都会被记录并得到妥善处理。
• Rev在设计验证活动完成后进行评审，评审结果将正式获得批准。

设计验证过程

验证过程并没有固定的顺序。相反，它依赖于一组公认的方法，一个项目通常会使用其中不止一种方法。

• 与同类设计进行比较。 某些设计可以通过与用途相似的同类设备进行比较来验证。这在验证现有基础设施的配置变更，或将标准设计集成到新系统或应用程序中时尤为重要。
• 演示和检查。 两者之一或两者都可用于验证产品的需求和其他功能。
• 分析。 可以通过数学建模或模拟来分析设计，从而重现所需的功能。
• 测试。 对最终设计进行测试，以验证系统是否能够按规定运行，这就是测试的目的所在。 功能测试 和 非功能性测试 满足用户需求。
• 文档。 测试计划、执行过程和结果应作为设计记录的一部分进行记录和保存。最终，验证是对所有验证活动结果的汇总。
• 等效性论证。 当在最终设计验证中使用同等产品时，制造商必须记录其相似性以及与初始生产的任何差异。

例如：

一个简短的例子就能具体说明这种区别。

• 以一款简单的产品为例：防水手表。
• 产品需求文档可能会规定“手表必须在游泳时防水”。这是用户需求，也是验证的标准。
• 设计规范可能会规定“即使用户长时间游泳，手表也应能正常工作”。这是设计输入，也是验证的标准。
• 测试结果应确认该手表符合这些要求。如果不符合，则将继续进行重新设计迭代，直到符合要求为止。

注意，手表可能通过了验证，但仍然无法通过确认。如果规范将长时间游泳定义为十五分钟，而实际游泳者会在水中待一个小时，那么设计输出与输入完全匹配，但仍然无法满足用户需求。

设计验证和确认的优势

持续开展这两项活动，而不是将其作为最后的关卡，才能产生以下好处。

• 设计过程可以持续监控，从而在每个阶段都能满足用户定义的要求。
• 验证设计可以指出实际功能与预期功能之间的差异。
• 记录验证程序可以方便以后进行更改或改进时理解其功能。
• 开发时间不断缩短，生产效率不断提高，这有助于按预期交付产品。
• 该流程定义了必须采用的每种验证方法的范围和程度。
• 可以使用代表最终用户需求的详细设计数据进行验证。
• 结果与用户需求文档之间的任何差异都会被记录下来，而不是丢失。
• 对已验证的设计进行更改会触发重新验证活动，因此记录永远不会偏离产品。
• 记录验证过程中发生的每一项活动，才能充分证明设计满足用户需求。

因此，设计验证和确认最好在更广泛的范围内进行规划。 软件测试生命周期 并与其他项进行比对 软件测试类型而不是将其视为一项单独的合规性工作。

常见问题