需求与设计评审
4.3 需求与设计评审
软件测试项目的开启是从立项开始的，可以召开立项会议，主要对项目的可行性进行分析，并且确定项目经理及项目测试组长。
立项会议
| 输入条件 | 立项会议 |
|---|---|
| 工作内容 | 1. 项目（产品）可行性分析 2. 项目经理的确定 3. 根据项目信息，测试经理确定测试组长 |
| 退出标准 | 测试组长确定 |
| 责任人 | 测试经理（确定测试组长） |
软件评审概述
软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进（GB/T 9386-2008计算机软件测试文件编制规范）。
为什么要进行软件评审？
交付后的软件缺陷不只来自编码，其中来自需求的缺陷占15%，40%来自设计阶段，还有5%是各文档的问题，也就是大约有60%的缺陷来自各个文档和技术分析，而这些缺陷很大可能会导致之后的缺陷。因此通过软件评审有效及时的发现和纠正这些问题，避免扩散到后期的开发活动中，从而最大可能地降低软件缺陷率。
评审类型
评审分为：
- 管理评审
- 技术评审
- 文档评审
- 流程评审
评审计划的建立可以帮助更好地管理评审工作。在现在流行的敏捷测试中，每日构建和每日站立会议以及结对编程，本身就是一直是代码和评审并行的工作，也可以不需要制定评审计划。
静态评审点清单
| 评审点 | 评审目的和期望结果 |
|---|---|
| 客户需求 | 理解系统需要实现的真正的意图，确定系统范围 |
| 软件需求文档 | 评审需求规格说明书并初始化总体设计 |
| 测试计划 | 评审总体测试策略和测试方法 |
| 体系结构设计 | 建立初步的设计基线配置；体系结构设计文档评审 |
| 详细设计 | 详细设计评审；确认编码和单元测试开始 |
| 代码评审 | 评审单元代码、测试用例评审 |
| 集成测试 | 接口与集成评审，授权进入系统测试 |
| 系统测试 | 系统测试结果的评审，授权进入验收测试 |
| 验收测试 | 批准产品发布 |
评审计划要素
针对每个评审点，可以制定相应的评审计划，然后依据评审计划展开每个点的评审。评审计划的制定需要考虑以下方面：
- 谁来参加 - 评审工作需要的人员
- 评审工作需要的信息有哪些 - 评审输入
- 评审工作的准入条件 - 进入评审的前提条件
- 评审检查表或其他评审标准 - 评审依据
- 记录，并保存文档 - 评审输出
软件需求评审
软件需求评审（Software Requirement Review, SRS），也称为软件规格说明评审（Software Specification Review, SSR）：一种对于一个或多个软件配置项规定的需求的评审，它评价对系统需求的响应和解释以确定他们能否形成进一步的配置项的初步设计的满意的基础。
产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试——需求评审。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致。
需求评审工作
| 输入条件 | 需求定义完成 |
|---|---|
| 工作内容 | 测试团队成员对需求中不清楚、不完整、太概括或存在疑义的地方提出问题，相关人员解答并确认 |
| 退出标准 | 所有人员对需求无异议 |
| 参与人员 | 需求调研人员，开发组，测试部 |
参会人员
每个参会人员要求要：
- 明确自己的角色和责任
- 熟悉评审内容，为评审做好准备
- 针对问题阐述观点，而非针对个人
- 从客户角度想问题，多问几个为什么
- 在会前或会后提出自己建设性的意见
- 对发现的问题跟踪到底
- 针对需求文档等报告问题
需求评审标准
需求评审的标准有以下几个方面：
1. 完整性
每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
2. 正确性
每一项需求都必须准确地陈述其要开发的功能。
3. 一致性
一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
4. 可行性
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
5. 无二义性
对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
6. 健壮性
需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
7. 必要性
“必要性”可以理解为每项需求都是用来授权你编写文档的”根源”。要使每项需求都能回溯至某项客户的输入，如 Use Case 或别的来源。
8. 可测试性
每项需求都能通过设计测试用例或其它的验证方法来进行测试。
9. 可修改性
每项需求只应在 SRS 中出现一次。这样更改时易于保持一致性。
10. 可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。
评审技术
评审技术有：检查表、场景分析、头脑风暴和工具等。
检查表（Checklist）
检查表是一种常用的质量保证手段，也是正式技术评审的必要工具，评审过程往往由检查表驱动。一份精心设计的检查表，对于提高评审效率、改进评审质量具有很大帮助。
- 可靠性：人们借助检查表以确认被检查对象的所有质量特征均得到满足，避免遗漏任何项目
- 效率：检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率
需求检查表示例
| 序号 | 检查项 | 通过情况 | 情况说明 |
|---|---|---|---|
| 标准化 | |||
| 101 | 有规定的文档标识 | 是[ ]否[ ]免[ ] | |
| 102 | 引用的文档现行有效 | 是[ ]否[ ]免[ ] | |
| 103 | 文档编写的内容、格式符合相关标准、规定 | 是[ ]否[ ]免[ ] | |
| 104 | 文档签署完整 | 是[ ]否[ ]免[ ] | |
| 105 | 设计陈述的命名、属于和缩写是否上下文一致 | 是[ ]否[ ]免[ ] | |
| 完整性和正确性 | |||
| 201 | 文档有独立的版本说明 | 是[ ]否[ ]免[ ] | |
| 202 | 没有丢失任何需求和必要信息 | 是[ ]否[ ]免[ ] | |
| 203 | 是否包含所有的原始需求 | 是[ ]否[ ]免[ ] | |
| 204 | 规格说明书是否指明了所有已知的用户或系统需求 | 是[ ]否[ ]免[ ] | |
| 205 | 需求表达是否清晰、易理解、无二义性 | 是[ ]否[ ]免[ ] | |
| 206 | 每个功能需求都适当的指定了输入、输出项 | 是[ ]否[ ]免[ ] | |
| 207 | 已经明确陈述所有的条件和限制 | 是[ ]否[ ]免[ ] | |
| 208 | 数据精度、时间特性和适应性是否明确 | 是[ ]否[ ]免[ ] | |
| 209 | 运行需求是否明确 | 是[ ]否[ ]免[ ] | |
| 210 | 对质量的要求是否明确、合理 | 是[ ]否[ ]免[ ] | |
| 211 | 是否分析了潜在的需求 | 是[ ]否[ ]免[ ] | |
| 212 | 是否标识并解决了需求中的潜在问题 | 是[ ]否[ ]免[ ] | |
| 一致性 | |||
| 301 | 是否存在冲突或者重复项 | 是[ ]否[ ]免[ ] | |
| 302 | 开发计划、产品和活动需求是否一致 | 是[ ]否[ ]免[ ] | |
| 303 | 是否可以根据软件需求规范制定出详细的测试集 | 是[ ]否[ ]免[ ] | |
| 304 | 是否有《需求跟踪矩阵》 | 是[ ]否[ ]免[ ] |
需求评审过程
需求评审的过程是：
- 首先，对产品说明书或需求文档进行审查，找出根本性的问题、疏忽或遗漏之处
- 通过审查了解外部因素后，其次，对需求进行更细致的测试，常使用检查列表进行检查
- 最后对照需求和检查表，逐条检查判断
对于不符合要求的要素，要进行需求文档反复修改，防止将缺陷遗漏到之后的开发过程中。
软件设计评审
软件设计评审（Software Design Verification, SDV），主要是技术评审，审查软件在总体结构、外部接口、主要部件功能分配、全局数据结构及各主要部件间接口等方面的合适性、完整性，从而保证软件系统可以满足系统功能性和非功能性的需求。
成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。
最终的设计验证（即设计终止之前），其性质是建议性的。这些评审的结果采用推荐和建设性建议的形式。对设计验证中发现问题进行更改和对结论进行选择的权力在设计组。其目的是尽可能早的在开发阶段确认这些因素和工艺会不会造成最终产品质量偏差。
软件设计验证需求
软件设计验证的需求分为三个方面：
- 软件运行和服务的设计验证需求：性能、安全性、可用性、功能性、可使用性
- 软件部署和维护周期的设计验证需求：可修改性、可移植性、可复用性、可继承性、可测试性
- 与体系结构本质相关的验证需求：概念完整性、正确性、完备性和可构造性
设计技术评审标准
-
设计结果的稳定性：以设计维护不变的时间来衡量，如果因为用户需求的变化或现有的错误或不足必须修改设计，那么修改范围的大小和次数就是影响软件设计质量的重要因素
-
设计的清晰性：指涉及目标描述是否明确，模块之间的关系阐述是否清楚，是否阐述了设计所依赖的运行环境，业务逻辑是否准确并且完备。清晰的设计也是重用性的基础
-
设计的合理性：主要指合理地划分了模块和模块结构的完整性，类的职责单一性、实体关联性和状态合理性等
-
系统模块结构：显示的宽度、深度、扇入、扇出
-
模块间松耦合而模块内聚性：系统的模块之间应该是低耦合性，同时模块内部应该是强内聚力
-
功能性需求满足：给出的系统设计结构和数据处理流程是否能满足软件需求规格说明中所要求的全部功能性需求，模块的规格大小划分是否与功能需求项以及约束性需求项保持一致
-
可测试性和可追溯性：所有的设计目标（性能、容量、兼容性等）是否可以通过测试结果来衡量。每一部分的设计是否都可以追溯到软件需求的定义
-
系统地位和作用：所要设计的系统在整个项目软件中所处的地位和作用，以及与同级、上级之间的关系描述是否正确
-
潜在需求分析：是否对不完整、易变动或潜在的需求都进行了相应的设计分析，对各种设计限制是否做了全面的考虑
设计评审主要包括
- 系统架构的审查
- 设计规格说明书的审查
- 系统部署设计的审查
- 多层次审查，包括高层次（high level）和低层次（low level）
系统架构设计基本要求
系统架构设计的基本要求就是保证系统具有：
- 高性能
- 高可靠性
- 高安全性
- 高扩展性
- 可管理性
系统架构设计评审就是保证这些特性在设计中得到充分考虑。采用分层评审和整体评审相结合，经过整体评审到分层评审、再从分层评审到整体评审的过程，这样既能确保评审的深度，又能确保评审的一致性。
要求整个系统不应该存在单一故障点，考察系统是否建立了故障转移机制、是否建立了良好的负载平衡机制，审查关键业务或关键任务是如何处理的，对组件设计的审查。
组件设计审查包括
- 功能和接口定义正确性
- 算法的有效性和优化
- 合理的数据结构、数据流和控制流
- 功能、接口、数据可测试性
界面设计审查包括
- 易懂性、易用性
- 一致性和规范性
- 美观与协调性
- 遵守惯例和通用法则
- 独特性
- 快捷方式的组合
- 自助功能
- 错误保护