软件质量工程 05

验证与确认概述

定义

• 验证与确认 (Verification and Validation, V&V) 是软件质量保证 (Software Quality Assurance, SQA) 的核心评价活动，贯穿软件项目生命周期。
• 目的:
  • 验证 (Verification): 确保软件产品或组件符合其规格说明 (Specifications)，即“是否正确构建了产品” (whether a software product conforms to its specifications）。
  • 确认 (Validation): 确保软件满足客户需求和预期用途，即“是否构建了正确的产品” (whether it satisfies the objectives of its intended use)。
• 特点:
  • 集成于项目计划中。
  • 需要与标准、流程、组织管理和项目经理密切协调。
  • 消除重复规格说明，减少评估时的分歧。
  • 提升产品最终质量。

V&V 在软件质量保证中的角色

• SQA 系统组件:
  • 项目前期质量组件
  • 软件生命周期质量组件
  • 基础设施错误预防与改进组件
  • 软件质量管理组件
  • 标准化、认证与 SQA 评估组件
  • 人力组织组件
• 支持标准:
  • IEEE Std. 1012-2016: 系统与软件验证和确认标准。
  • ISO/IEC/IEEE Std. 12207:2017: 系统与软件工程 - 软件生命周期过程。

V&V 计划

• 软件 V&V 计划文档: 描述 V&V 活动、任务和标准。
• 独立性 (Independence):
  • V&V 活动需作为独立活动 (Independent Verification and Validation, IV&V) 执行，分为管理、技术和财务功能，以确保客观性。

IEEE Std. 1012 标准详解

概述

• IEEE Std. 1012-2016 定义了整个软件生命周期中的 V&V 活动。
• 目标:
  • 确保软件产品符合规格说明 (Verification)。
  • 确保软件满足预期用途和用户需求 (Validation)。
  • 提供客观评估，确保产品和过程的正确性、完整性、准确性和一致性。
• 更新周期: 每 5-10 年更新一次。
• 兼容性: 与国际标准(如 ISO/IEC/IEEE Std. 12207)兼容，涵盖管理、系统、软件和硬件。

核心概念

• 完整性等级 (Integrity Levels):
  • 重大 (Major): 功能显著影响系统性能。
  • 中等 (Moderate): 功能影响系统性能，但有替代操作方法。
  • 轻微 (Low): 功能仅对用户造成不便。
• 最低 V&V 任务:
  • 为每个完整性等级定义最低任务。
  • 提供正确性、一致性、完整性、准确性、可读性和可测试性的标准。
• V&V 过程:
  • 包括概念定义、需求分析、设计、实现、过渡、操作、维护和处置等阶段。
  • 具体任务包括系统需求、流程文档、项目合作、验收标准和进度安排等。

验证 (Verification)

• 定义: 评估软件产品或组件是否符合规格说明的过程。
• 目标: 确保软件基于初始规格正确、完整地实现。
• 支持标准: ISO/IEC/IEEE Std. 12207:2017。
• 任务:
  • 合同验证(系统需求、变更管理流程、项目合作流程、验收标准等)。
  • 报告生成。
• 解释: 验证关注技术正确性，例如检查代码是否符合设计文档的要求。

确认 (Validation)

• 定义: 评估软件规格是否满足客户需求和预期用途的过程。
• 目标: 提高客户满意度。
• 支持标准: ISO/IEC/IEEE Std. 12207:2017。
• 任务:
  • 系统性后续活动：数据收集、代码错误数量统计、错误严重性分析等。
• 解释: 确认关注用户体验，例如验证移动银行应用是否满足用户对安全性和易用性的需求。

验证与确认的场景分析

学生管理系统的高层设计 (HLD) 评审

• 设计评审 V&V:
  • 验证(Verification)：检查高层设计是否符合需求规格说明。
  • 确认(Validation)：确保设计满足用户(如学生和管理员)的实际需求。
• 测试 V&V:
  • 验证(Verification)：测试用例是否覆盖所有规格说明的功能。
  • 确认(Validation)：测试结果是否满足用户预期。
• 操作 V&V:
  • 验证(Verification)：系统运行时是否符合设计规格。
  • 确认(Validation)：系统在实际使用中是否满足用户需求。

移动银行应用案例

• 背景: 银行开发一款移动应用，支持交易、余额查询、账单支付和贷款申请，需满足安全性、用户界面设计、性能和设备兼容性要求。
• 验证:
  • 检查代码是否实现所有安全性协议和性能指标。
  • 确保界面设计符合规格说明。
• 确认:
  • 测试应用是否满足用户在不同设备上的操作需求。
  • 验证安全性功能是否让用户感到放心。

IBM 软件验证工具 - ExpliSAT

• 概述: 用于 C/C++ 软件的验证工具，检查程序是否满足广泛的正确性属性和嵌入式断言。
• 功能:
  • 验证程序执行路径无违反断言或内置检查的情况。
  • 检查算术属性等。
  • 支持与调试器一起编译测试用例。
  • 结合符号输入值和执行路径，验证所有可能输入的失败情况。
• 应用: 嵌入式软件项目，关键代码单元测试。
• 解释: ExpliSAT 通过符号执行分析代码，检测潜在错误，如溢出或未定义行为。

IBM 云软件确认

• 流程:
  • 在测试环境中添加软件。
  • 完成版本细节、依赖和约束的配置。
  • 成功确认后，软件在 IBM 云上发布。
• 解释: 确认过程确保软件在云环境中运行时满足所有技术和服务要求。

Fagan 检查法

Fagan 代码检查流程(Fagan Inspection)是一种系统化、结构化的软件代码审查方法，由 Michael Fagan 在 1976 年提出。它是最早被广泛采用的正式代码审查技术之一，旨在通过有组织的团队协作发现软件缺陷，提高代码质量和可维护性。

概述

• Fagan 检查法 (Fagan Inspection Method): 一种用于发现代码、规格、设计和变更中缺陷的系统化方法。
• 缺陷定义:
  • 不完整、不正确或缺失的工作产品。
  • 未满足的需求。
  • 错误 (Bug)、故障 (Fault)、问题 (Issue) 或不符标准。
• 特点:
  • 使用定义的流程、知识共享、检查清单和标准。
  • 减少发布软件中的缺陷。
  • 包含入口部分和退出标准。
• 关键活动:
  • 计划、调度、会议、准备、检查、分析、重做、后续跟踪。

Fagan 检查流程的六个阶段

1. 计划阶段(Planning)

• 确定需要检查的模块或代码段。
• 安排会议时间、地点和参与人员。
• 分配角色：主持人(Moderator)、作者(Author)、阅读者(Reader)、测试员(Tester)、记录员(Recorder)等。
• 准备检查材料(如需求文档、设计文档、源代码等)。

2. 概要介绍阶段(Overview)

• 主持人组织一次简短的介绍会议。
• 作者向检查小组解释被检查模块的功能、设计思路和关键逻辑。
• 目的是让所有参与者对被检查内容有一个基本理解。

3. 准备阶段(Preparation)

• 检查组成员各自阅读相关材料，查找可能的问题。
• 成员需在会议前完成初步审查并记录问题。
• 这个阶段强调个人准备，是发现问题的关键环节。

4. 检查会议阶段(Inspection Meeting)

• 由主持人主持，阅读者逐行朗读代码。
• 其他成员指出已发现的问题或潜在缺陷。
• 所有问题会被记录下来，但不讨论如何修复。
• 会议时间通常控制在 1~2 小时，以保持效率。

5. 返工阶段(Rework)

• 作者根据会议中记录的问题进行修改。
• 修改后的代码需再次提交给主持人确认是否满足要求。

6. 跟踪阶段(Follow-up)

• 主持人验证所有问题是否已被正确修正。
• 如仍有遗漏问题，可能重新进入检查流程。
• 整个过程完成后，形成总结报告。

代码检查和代码走查

自动静态分析工具

• 定义: 静态分析 (Static Analysis) 是一种在不运行程序的情况下分析代码的技术，用于检测潜在错误和质量问题。
• 任务:
  • 选择熟悉的编程语言，查找其静态分析工具(如 Wikipedia 的静态分析工具列表)。
  • 编写文档描述工具检测的异常类型。
  • 选择一种重要异常，编写最小程序触发该异常的报告。
• 常见异常:
  • 变量未声明。
  • 整数大小超出范围。
  • 数组越界访问。
  • 内存分配/释放问题。
• 示例:
  • 异常: 数组越界访问。
  • 重要性: 可导致程序崩溃或未定义行为。
  • 检测方式: 工具(如 Clang Static Analyzer)分析代码，检测数组索引是否超出声明范围。

#include <stdio.h>
int main() {
    int arr[5] = {1, 2, 3, 4, 5};
    printf("%d\n", arr[10]); // 数组越界访问
    return 0;
}

静态与动态 V&V

• 静态 V&V: 不运行代码，分析源代码或设计文档(如 Fagan 检查、静态分析)。
• 动态 V&V: 运行代码进行测试(如单元测试、集成测试)。

知识点可能考法与示例考题

可能考法

1. 定义与区分:
   • 定义验证与确认的区别，并举例说明。
   • 区分静态与动态 V&V 的应用场景。
2. Fagan 检查法:
   • 描述 Fagan 检查法的流程。
   • 分析其优缺点及改进方法。
3. IEEE Std. 1012:
   • 解释标准中的完整性等级及其对 V&V 任务的影响。
   • 列举 V&V 在软件生命周期中的具体任务。
4. 静态分析:
   • 描述静态分析工具的作用及可检测的异常类型。
   • 编写代码触发特定异常并分析报告。
5. 实际应用:
   • 针对特定场景(如移动银行应用)设计 V&V 策略。

示例考题

问题: 解释 验证 (Verification) 和 确认 (Validation) 的区别，并以移动银行应用为例说明两者的具体活动。

参考答案:

中文:

• 验证 (Verification): 确保软件产品符合规格说明。例如，对于移动银行应用，验证包括检查代码是否实现所有安全协议、用户界面是否符合设计文档、性能是否达到规格要求。
• 确认 (Validation): 确保软件满足客户需求和预期用途。例如，确认包括测试应用在不同设备上的兼容性、用户是否能轻松完成交易、是否感到安全可靠。

英文:

• Verification: Ensures the software product meets its specifications. For the mobile banking app, verification includes checking if the code implements all security protocols, the UI matches the design document, and performance meets specified metrics.
• Validation: Ensures the software fulfills the client’s needs and intended use. For the app, validation includes testing compatibility across devices, ensuring users can easily complete transactions, and confirming the app feels secure and reliable.