3. 静态测试

3.1.静态测试基础

与动态测试相比，静态测试依赖于软件工作产品的手动检查（即评审），或工具驱动的代码或其

他软件工作产品的评估（即静态分析）。

3.1.1. 由静态测试检查的软件工作产品

• 代码
• 模型，如可用于基于模型测试的活动图

3.1.2. 静态测试的好处

静态测试技术提供了多种好处。当在软件开发生存周期的早期应用静态测试，就能够在开展动

态测试之前尽早地检测缺陷（例如，在需求或设计规格说明评审，待办事项列表的细化工作等）。早期发现的缺陷通常比软件开发生存周期后期发现的缺陷经济得多，特别是与软件部署和使用后发现 的缺陷相比。使用静态测试技术来发现缺陷然后及时修复这些缺陷几乎总是比使用动态测试在测试 对象中发现缺陷然后修复它们所花费的成本要低得多，特别是在考虑到更新其他软件工作产品以及 开展确认和回归测试的额外成本。

静态测试的其他好处可能包括：

 在动态测试执行之前，更高效地检测和修复缺陷

 识别动态测试不易发现的缺陷

 通过发现需求中的不一致、含糊不清、矛盾、遗漏、不准确和冗余来防止设计或编码缺陷

 提高开发效率（例如，由于改进的设计、更易于维护的代码）

 降低开发成本和时间

 降低测试成本和时间

 减少在软件开发生存周期后期或上线运营后失效，从而降低了软件在整个生存周期内的总

的质量成本

 在参与评审过程中改善团队成员之间的沟通

3.1.3. 静态测试和动态测试的差异

静态测试和动态测试的一个主要区别在于静态测试直接发现软件工作产品中的缺陷，而动态测

试是在运行软件时识别由缺陷引起的失效。缺陷可以在软件工作产品中存在很长时间而不会导致失

效。缺陷所在的路径可能很少被执行或难以到达，因此设计并执行动态测试去发现这样的缺陷并不

容易。静态测试可能付出更少的工作量就能找到缺陷。

另一个区别是静态测试可用于提高软件工作产品的一致性和内部质量，而动态测试通常侧重于

外部可见行为。

与动态测试相比，通过静态测试可以更早期更经济的发现和修复一些典型的缺陷，包括：

 需求缺陷（例如：不一致、含糊不清、矛盾、遗漏、不准确和冗余）

 设计缺陷（例如：低效算法或数据库结构、高耦合、低内聚）

 代码缺陷（例如：未定义值的变量、已声明但从未使用的变量、无法访问的代码、重复的

代码）

 与标准的偏差（例如：未完全遵循编码规范）

 错误的接口规格说明（例如：主叫系统使用的测量单位与被叫系统不同）

 安全漏洞（例如：对缓冲区溢出的敏感性）

 测试依据的可追溯性或覆盖率的差距或不准确性（例如：针对验收准则缺少测试）

此外、大多数类型的维护性缺陷只能通过静态测试才能被发现（例如：没有很好的模块化、组

件的可重用性较差、难以分析的代码以及很难保证修改代码而不引入新缺陷）。

3.2.评审过程

3.2.1. 工作产品的评审过程

计划

 定义范围，包括评审目的、需评审的文档或部分文档以及需评估的质量特性

 估算工作量和时间表

 识别评审特性，例如评审类型以及相应的角色、活动和检查表

 选择参与评审人员并分配角色

 针对较正式的评审类型（例如：审查）制定入口和出口准则

 核对入口准则是否满足（针对较正式的评审类型）

评审启动会

 分发工作产品（以物理方式或通过电子方式）和其他材料，例如：事件日志表、检查表和

相关工作产品

 向评审参与者解释评审的范围、目标、过程、角色和工作产品

 回答评审参与者可能对评审提出的任何问题

独立评审（即个人准备）

 评审全部或部分工作产品

 标注可能的缺陷、建议和问题

事件交流和分析

 交流已识别的潜在缺陷（例如：在评审会议中）

 分析潜在缺陷，并为这些缺陷分派责任人和状态

 评估和记录质量特性

 根据出口准则评估评审发现，以确定评审结论（拒绝；需重大变更；接受，但可能需

要小修改）

修正和报告

 当发现需要修改工作产品时而创建缺陷报告

 修正在工作产品评审中发现的缺陷（通常由作者来进行）

 与相关人员或团队交流缺陷（当工作产品中的发现关联到被评审的工作产品）

 记录缺陷更新的状态（在正式评审中），可能包括对评审意见提交人的认同

 收集度量数据（对较正式的评审类型）

 核对出口准则是否满足（对较正式的评审类型）

 接受满足出口准则的工作产品

3.2.2. 正式评审的角色和职责

作者：

 创建被评审的工作产品

 修复工作产品评审过程中发现的缺陷（如果需要的话）

经理（管理者）：

 负责制定评审计划

 决定是否需要进行评审

 分派人员、预算和时间

 监督进行中的成本-效益

 当产出不充分时，执行控制决策

促进者（通常称为主持人）：

 保证评审会议的有效进行（当召开时）

 需要时在评审的不同观点之间进行协调

 通常是评审成功与否的关键人物

评审组长：

 全面负责评审

 决定哪些人员参加评审，并组织何时何地进行评审

评审员：

 可能是专题相关专家、项目工作人员、对工作产品感兴趣的利益相关方，和/或具有

特定技术或业务背景的人员

 在评审中识别工作产品中的潜在缺陷

 可能代表不同的视角（例如：测试员、开发人员、用户、操作员、业务分析师、易用

性专家等）

书记（或记录员）：

 在独立评审活动期间，收集发现的潜在缺陷

 记录评审会议中的新发现的潜在缺陷、未解决的问题和决策（当评审会议召开时）

3.2.3. 评审类型

非正式评审（例如：伙伴检查、结对、结对评审）

 主要目的：检测潜在缺陷

 可能的附加目的：产生新的想法或解决方案，快速解决小问题

 不基于正式的（文档化的）过程

 可能不包含评审会议

 可能由作者的同事（伙伴检查）或更多人参与评审

 可能记录评审结果

 有效性根据评审人员的不同而变化

 使用检查表是可选的

 敏捷开发中使用的非常普遍

走查

 主要目的：发现缺陷、改进软件产品、考虑替代实施、评估与标准和规范的符合程度

 可能的附加目的：交换关于技术或风格变化的想法、参与者的培训、达成共识

 评审会议前的个人准备是可选的

 评审会议通常由工作产品的作者主持

 必须指定书记（记录员）

 使用检查表是可选的

 可能采用场景、演练或模拟的形式

 生成潜在的缺陷记录和评审报告

 在实践中可能从相当非正式到非常正式

技术评审

 主要目的：获得共识、发现潜在缺陷

 可能的进一步目的：评估质量和建立对工作产品的信心、产生新想法、激励和使作者

能够改进未来的工作产品、考虑替代实施

 评审员应该是作者的技术同行，以及同一学科或或其他学科的技术专家

 需要在评审会议之前进行个人准备

 评审会议是可选的，最好由经过培训的促进者（主持人）（通常不是作者）主持

 必须指定记录员，最好不是作者

 使用检查表是可选的

 生成潜在的缺陷记录和评审报告

审查

 主要目的：检测潜在缺陷，评估质量并建立对软件工作产品的信心，通过学习和根本

原因分析防止未来出现类似缺陷

 可能的进一步目的：激励和使作者能够改进未来的工作产品和软件开发过程、达成共

识

 遵循已定义的过程，基于规则和检查表，正式地记录输出

 使用明确定义的角色，如第 3.2.2 节中规定的强制性角色，也可能包括专门的朗读

者（在评审会议期间朗读工作产品的人经常会用自己的话来解释，即描述。）

 需要在评审会议之前进行个人准备

 评审参与者是作者的同行或与工作产品相关的其他学科专家

 使用已规定的入口和出口准则

必须指定书记（记录员）

 评审会议由经过培训的促进者（主持人）（不是作者）引导

 作者不能担任评审组长、朗读者或书记（记录员）

 通常生成潜在的缺陷记录和评审报告

 收集度量并用于改进整个软件开发过程，包括审查过程

3.2.4. 评审技术的应用

临时评审

基于检查表的评审

场景和演练的评审

基于视角

若本文有帮助到阅读本文的同学，欢迎点赞、关注、收藏，互相学习交流。