上午11时5分
3.1正式评审概述
♦ 正式评审（formal review）是对评审过 程及需求文档化的一种特定评审
♦ 正式评审的最小可接受条件： 1. 团队参与（Team participation） 2. 文档化评审结果（Documented results
of the review） 3. 文档化实施评审的过程（Documented
♦ 这种方法简单适用，可以发生在软件开发的任 何时间和地点，也不拘泥于正式的形式，比如 走廊聊天（hallway chat），伙伴测试（buddy test）或者结对编程（pair programming）等。
♦ 优点：方便、廉价、有效，很多程序员都在自 觉不自觉地采用这种评审方式
上午11时5分
2.7 非正式评审的特点
2.4.3.2 审查和测试同类软件举例2
上午11时5分
中国的BL系列信号采集系统
2.4.6 评审成功的因素
♦ 要确保评审成功，如下因素很重要： 1. 每次评审都有非常明确的目标 2. 针对评审目标，有合适的评审人员参与 3. 对发现的缺陷持欢迎态度，并客观的描
述缺陷 4. 能够正确处理人员之间的问题以及心理
上午11时5分
6
3.2 正式评审的基本过程
♦ 典型的正 式评审阶 段构成：
团队构建 评审准备
指派角色 分配责任
评审输入
个人准备
评审过程
上午11时5分
评审结束 评审跟踪
评审报告
3.3.1 管理评审的成员
序号 角色
1 决策者
职责
决策者是管理评审的管理者，决策者确定是否达到评审目标， 决策者是公司领导，对评审结果进行认定
上午11时5分
1.2.1 提示
♦ 静态测试不仅具有更长的生命周期，而 且由于其大多数情况下是对软件系统高 层次的测试评审，能够在软件开发的早 期找出软件缺陷，更能体现测试的经济 学原则
上午11时5分
1
1.3 静态测试的重要性
♦ 发现设计的方向性问题 ♦ 更早的发现问题 ♦ 避免杀虫剂现象 ♦ 引起程序设计人员的重视 ♦ 静态测试可以训练程序员
user complaints） 26. 硬件性能计划（Hardware performance
plans） 27. 备份和恢复计划（Backup and recovery
plans） 28. 应变计划（Contingency plans）
上午11时5分
2.3 评审的软件产品(6)
29. 管理评审报告（Management review reports） 30. 技术评审报告（Technical review reports） 31. 审查报告（Inspection reports） 32. 走查报告（Walk-through reports） 33. 审计报告（Audit reports） 34. 进度报告（Progress reports） 35. 异常报告（Anomaly reports）
validation ） 16. 采购合同方法（Procurement and contracting
methods） 17. 安装计划（Installation plans） 18. 安装过程（Installation procedures）
上午11时5分
2.3 评审的软件产品(4)
19. 维护手册（Maintenance manuals） 20. 维护计划（Maintenance plans） 21. 操作及用户手册（Operations and user
2.5评审的分类
非
正
♦ 根据IEEE Std
式 评
1028-2008 软件
审
评审与审计标 评 准，按照评审过 审
程的正式程度、
严格程度可以将
正 式
评审分为非正式
评 审
评审和正式评审
上午11时5分
桌面审查 走廊聊天 伙伴测试 结队编程
管理评审 技术评审
审查 走查 审计
5
2.6 非正式评审
♦ 非正式评审（informal review）是一种不基于 正式（文档化）过程的评审
procedures for conducting the review）
上午11时5分
3.1.1正式评审的脚色
♦ 参与正式评审的人员会因评审的内容不 同而有差异，包括：
1. 评审领导（Review leader） 2. 评审员（Reviewer） 3. 记录员（Recorder）
上午11时5分
3.1.1正式评审的脚色
行，或者使用不同的编译器，如果代码遵循 设备标准，将更容易使软件具有移植性 ♦ 软件审查小组在开始审查前需要了解相应的 标准和规范
上午11时5分
2.4.2.4 符合标准和规范的要求
♦ 软件测试员要检查新设计的软件是否符合正 确的标准，有无遗漏，是否和某些标准有抵 触。
♦ 比如，软件界面是否符合Windows程序的通 用要求；采用的网络协议是否为通用网络协 议或政府部门的项目（要求极高的保密性） 是否符合这些行业的要求等
方面的问题
上午11时5分
2.4.6 评审成功的因素（cont.）
5. 采用的评审技术适合于软件工作产品和 评审参与者
6. 为提高缺陷标识的效率，可以采用检查 列表的方式或定义不同的脚色
7. 提供评审技术方面的培训 8. 管理层对评审过程的支持（安排时间与
资金支持） 9. 强调学习和过程的改进
上午11时5分
上午11时5分
4
2.4.3 审查和测试同类软件
♦ 了解软件最终结果的最佳方法是研究同 类软件，例如竞争对手的同类产品
♦ 审查竞争对手的产品需要注意的问题：
– 软件规模 – 软件的复杂性 – 软件的可测试性
上午11时5分
2.4.3.1 审查和测试同类软件举例1
澳大利亚AD公司的信号采集系统
上午11时5分
♦ 规范（Specification）——某一范畴内以明文 规定或约定俗成的形式规定的规则
上午11时5分
2.3 评审的软件产品(1)
♦ 软件产品（Software product）是指与 软件相关的全部文档、源代码及标准等
♦ 评审的软件产品包括 ：
1. 需求建议（Request for proposal） 2. 软件需求说明（requirements specifications ） 3. 风险管理计划（Risk management plans） 4. 软件质量保证计划（Software quality
♦ 以下人员会根据需要出现在不同的正式 评审中
1. 决策者（Decision maker） 2. 管理经理（Management staff） 3. 作者（Author） 4. 顾客或使用者代表（Customer or user
representative） 5. 其他利益相关者（Other stakeholder）
上午11时5分
2.4 评审的依据
♦ 评审的依据包括： 1. 从用户的角度看问题 2. 研究现有的标准和规范 3. 审查和测试同类软件
上午11时5分
3
2.4.1 从用户的角度看问题
♦ 软件产品的目的是满足用户要求 ♦ 测试员在审查软件产品时把自己当作
用户来考虑问题，通过与销售人员和 客户的交流来了解产品 ♦ 另外，测试员具有软件应用的领域知 识，比如财务知识，医学知识，航空 知识等，对于软件需求的审查将大有 裨益
2 评审领导 评审领导确保完成与评审相关的行政工作，为评审计划和准备 工作负责，他将确保引导评审按照有序的方式进行并达到其目 标，并发布评审结果
静态测试
Static Testing
提纲
♦ 静态测试概述 ♦ 评审
上午11时5分
1. 静态测试概述
♦ 静态测试和动态测试的概念 ♦ 为什么需要静态测试 ♦ 静态测试的重要性
上午11时5分
1.2 为什么需要静态测试
♦ 狭隘的软件测试思想只对可运行的软件 进行测试，广义的软件测试思想是将测 试遍布于软件开发生命周期的各个阶 段，包括软件需求、软件设计、软件编 码、软件测试及软件维护等阶段
♦ 非正式评审特点 1. 没有正式的评审过程 2. 对设计文档和代码以技术评审为主 3. 评审的过程和结果可能是文档化的 4. 评审的投入少，效率高 5. 评审主要目的是以较低成本即时的
发现问题
上午11时5分
3 正式评审（formal Review）
♦ 正式评审概述 ♦ 正式评审的基本过程 ♦ 正式评审的分类 1. 管理评审 2. 技术评审 3. 审查 4. 走查 5. 审计
上午11时5分
2.4.2 研究现有的标准和规范
♦ 标准比规范更加严格 ♦ 几乎所有产品都需要有参照规范和标
准，比如： 1. 公司惯用语和约定规范 2. 行业要求 3. 国家标准 4. 图形用户界面的标准 5. 硬件和网络标准等
上午11时5分
2.4.2.3 标准和规范的举例
国家标准、行业标准和企业标准
assurance plans ）
上午11时5分
2
2.3 评审的软件产品(2)
5. 软件配置管理计划（configuration management plans ）
6. 软件设计描述（design descriptions ） 7. 软件项目管理计划（project
management plans ） 8. 软件用户文档（user documentation ） 9. 软件安全计划（safety plans ） 10. 软件构架描述（architectural
descriptions ）
上午11时5分
2.3 评审的软件产品(3)
11. 源代码（Source code） 12. 系统构建过程（System build procedures） 13. 供应商文档（Vendor documents） 14. 软件测试文档（test documentation ） 15. 软件验证和确认计划（verification and